esaj

Nothing like fart-sounds riding around big crowd. Also, this is a good song to play while riding around:

I've often wondered about this. Is it the fundamental PWM-frequency "playing back" on the coils, or a subharmonic of it, or something else?

I'm not looking at the wheel when I ride it, other people are. If they want carbon fiber or faux puke, they should pay for it, not me

There's a gazillion connectors available, but probably the balancing doesn't need to be done that often. So off the top of my head, if I'd bother doing something like this, at simplest I'd just get something like a basic 40-pin ribbon IDC cable (if you've worked with PC's, it's the "old" 2x20 -pin IDE-hard drive connector), or something with 17 or more wires/pins, cut the cable and strip 17 wires and solder the wires to the cells (16 wires to "+" -sides of the cells, which is the "-" -side of "previous" cell, and the last wire to the "-" of the last cell) , and leave it inside the shell. Since it's a female connector ("holes" instead of "pins"), it shouldn't cause a short circuit at any point (well maybe if there's water inside, but then the connector probably isn't your biggest problem anyway). When checking the voltages, you just take 2 "consecutive" (one after another) pins to check the voltage between them. To automate this, you'd need to connect two consecutive wires to the measurement circuit, so that the "low" side is connected to the ground and the high side is connected to the measument high side. To automate this, my first thought was using something like using a bunch of basic (and older than me) CD4067 16-channel analog switches to select the high- and low-side... you'd put the "high-side" 16-channel from wires 1-16 and the "low-side" from 2-17. High-side would connect to the "+" of the measurement, and low-side would connect to the measurement circuit ground (so the "low-side" / measurement circuit 0V would be at the "top" of the cell "below" the one being measured), and you'd move them one-by-one so that either channels from both would be at the same node of the battery cells (0V) or the high-side would be one higher (single cell voltage). The basic idea is to connect the measurement circuit ground to the negative side of the cell to measure, and leave the rest "floating outside the circuit". BUT, I don't think the inputs of these analog multiplexers are galvanically isolated, probably just a MOSFET? You'd still have up to 15 * 4.2V voltage between the first and last channel, something that I doubt the ICs could take (= I'm a bit drunk, didn't find anything on a minute glance at the datasheet, and first google results for "maximum voltage between cd4067b channels" didn't sound like they answer my question ), but the general idea would be to "step" through the cells one-by-one and check the voltage. Or charge, basically you'd just need a simple CC/CV power source with very low output current and maximum voltage of 4.2V, or if the voltage would be lower, the circuit should be able to also sink (enough) current, in case the cell voltage was above it. I'd need a (lot) more time to think this entire thing through really It might work, but if you get around playing with this idea, or some derivative of it, better test it without an actual battery first, or at least something that can't spew out large currents There are probably some nice balancing ICs available to get away from all the hassle I have a couple of ESP32's, but haven't used them much. If they have a separate AREF (analog reference) -input, you can use a precision voltage reference (for example, there are fixed voltage references with 0.1% tolerance, or even lower, I check my tabletop HP34401A with 0.05% references, although technically it has precision of 0.0035% DC, but hasn't been calibrated in 10 years) to use for ADCs to vastly improve the precision. About the WLAN and such, if you want to do precision ADC-measurements with pretty much any MCU, you need to shut off things anyway, as anything giving ripple / interference will cause problems with the measurement precision. If memory serves, ATMegas have separate power down-states specifically for more precise ADC measurements, where certain clocks are shutdown etc. to minimize "noise" in the circuitry. And memory serves: "AVR® devices have an Analog to Digital Converter (ADC) Noise Reduction mode, that stops the CPU and all I/O modules except asynchronous timer, PTC, and ADC, to minimize switching noise during ADC conversions. It's used when a high-resolution ADC measurement is required." Don't know if the ESP32's have anything similar, but shutting down all the unrelated peripherals probably would at least help.

Have you tried to get her to try to ride one? I bought a used KS16B with the thought I could convince my GF to try it, but she's never even tried... So I ride both the B & S myself. Her father took my "noname" Chinese starter-wheel, and rides it occasionally (with the "extra wheels"), but I think most of the time it just sits on his car trunk and has probably pretty bad batteries by now... the FW has been in pieces for years now, but I still cling on the thought that one day I'll start working on a motor controller to use the motor and batteries for something (which have been sitting for a year or two, probably should dig them up from the basement and check how many cells have been ruined... )

Usually the shells can take quite a beating without cracking, if something breaks, it's the "stands" for screws, if there are such. Or if cracks develop, they're not usually anywhere that long and near the sharp edges, at least from what I've seen. I wonder what material Inmotion/Solowheel uses, I don't know much about plastics, but most wheels seem they're something like ABS, which (by my experience) usually bends rather than breaks, up to a point...

It's a good point, it's easy to get stuck in the smaller details before the entire big picture, but all those small details have to be handled sooner or later. I've been away from the forums for a while, as I currently have my hands full with learning the ropes at a new job and, out of the blue, was made an offer to do some hardware design on a commercial product on the side, so most of my spare time is pretty much full But on the topic, excluding all the bells & whistles of modern wheels (lights, Bluetooth, app etc), here's what I think are the main issues: On the hardware side: Motor: 3-phase PMSM/BLDC seems the "obvious" choice, seeing that all the commercial wheels use those, although it's probably possible to build one with a different kind of motor (I think I saw a seated design that used brushed 1-phase DC motor somewhere, but it was capable of something like 10km/h max and was easy to overlean) don't know if it could work with steppers, maybe with micro-stepping? Still, I'd pick a BLDC. Since the motor control hardware and software are somewhat specific to the kind of motor used (and still likely need to be fine tuned for motors from different manufacturers, even if they all were the same "kind"), the decision is pretty important and has to be done before mainboard motor control (well, you could use 2 of the 3 half-bridges to drive a 1-phase motor, even if the motor driver is originally made for 3-phase motors). Probably no-one or very few people can make their own motor, so likely it has to be a prebuilt one. Batteries: Some people may be able to build their own packs, if they have the equipment (I personally wouldn't trust cells soldered together, needs a battery spot welder), and maybe even design the BMS-board(s), I'd go with premade packs. Packs can be charged through the BMS, so the mainboard doesn't have to have anything related to the battery charging (although it still can). A couple of points on these: -Make sure that the BMS used has separate charging and discharging. I can tell that it's NOT FUN when the overvoltage (overcharge) protection cuts the power because regenerative braking pushes the voltage too high going downhill with full batteries and both the charging and discharging go through same protections... better let the battery soak up a slight overvoltage for some seconds rather than faceplant, ie. usually the BMSs in the EUCs don't have overvoltage protection on the discharge-side -Make sure the rated discharge current is high enough, again you don't want the BMS cutting all power to the wheel during fast acceleration or sudden current surge due to a bump, Gotway BMSs don't have overcurrent protection at all? Shell: Technically, the shell could come from an old (broken) wheel, be 3D-printed (there's at least one design in the forums that has been used in practice with the Microworks -board & -motor) or built from whatever material you have, I made one from flat aluminum bars and leftover floor laminate a few years back using Firewheel mainboard & motor: https://imgur.com/a/orjAz Lesson learned: don't put a mainboard from a commercial wheel much further away from the wheel axle than it is originally (in this case it was something like >2 times farther). In this case, the top-heavy design and the difference in the angular acceleration (which should have been obvious; the further away from the axle the IMU is, the higher the acceleration / angle speed for the same change in angle over the same time), if that's even the correct term, made it like riding a bull heaving back and forth at times, although it did "behave" when riding on flat streets. Hitting a smallish stone on a forest path, the wheel would quickly jerk forwards and then shoot straight very fast, as it tried to correct the error... just not getting thrown off required some acrobatics Again a point where the software may need to be at least somewhat fine-tuned separately for each design? Mainboard: This is the most complex hardware-side thing, and pretty much everything on the board is critical (well, except possible lights, speakers or Bluetooth, but if these break, they can take other things with them), so I broke it down into more "main" issues. A couple of years ago, I traced most of the Firewheel PCB and the circuits there, which might give some ideas: Commercial boards can give good clues at how to do things (or how to not do things ). Designing the board is certainly not an easy task, here's the main issues as I see them and some thoughts (although remember that I'm just a hobbyist): Motor driver: Three half-bridges ("3-phase inverter"?) made with power MOSFETs seems to be what all the wheels use. A good quality 3-phase gate-driver chip is probably a lot better solution than trying to build something from discrete components, as it can handle the needed voltage boosts for high-side N-channels, dead time insertions etc. Power dissipation needs to be carefully considered, it's easy to kill the MOSFETs with overheating by pushing too much current through them or through switching losses. Or by transient voltage spikes. Or gate ringing. Or shoot-through. Or... Read a ton of manufacturer application notes, Electronics Stackexchange and grab a book or two on power electronics. Remember that you're driving inductive loads, which can cause all sorts of hairy issues with peak currents and transient voltages. Depending on the software-side motor drive algorithm picked, the PWM frequency might have to be decided early on..? If you haven't been around the forums for a few years, it might come to you as news that even the commercial manufacturers had a lot of issues with the MOSFETs dying on the wheels, up until a couple of years ago, and it still might happen on occasion (but usually through an abnormal situation, like a crash or wheel stuck tilted against an obstacle). "Over-engineer", use much larger tolerances and worst-case scenarios than you think you need etc., and simulate & test it like hell before even thinking of putting your bones (or life) on the line with it For a seasoned electronics engineer, designing this is probably isn't that much of a hurdle, but some of the finer points are easy to miss. You'd think that you just turn MOSFETs on and off, but scratch the surface, and it's much more complex than that in an application like this. Motor current measurement probably also goes under this topic, but that shouldn't be so much of an issue (sense resistors or current sensors, ADCs). Of course, there are probably at least some ready-made solutions for this, but usually the heavy-duty ones (remember, we're talking several hundreds or kilowatts of power to be controlled) are pretty costly. Plus, what's the fun in getting a ready-made solution in a complex engineering problem like this? MCU: I still doubt that Arduino would work very well if any more complex motor drive algorithm is to be used, but it can certainly do trapezoidal... one of the first things I did when I started getting into electronics a few years back was to build a 3-phase inverter from discrete components (it took 3 breadboards and dozens of jump-wires) and use an Arduino to do trapezoidal control for a small BLDC with hall-sensors. Still, I'd go with an ARM Cortex M<something, 3, 4?>. The most common chip in commercial wheels seems to be (or at least used to be) STM32F103, an ARM Cortex-M3 from ST Microelectronics. It's relatively cheap (something like ~5€ in single pieces? Depends on dealer and Flash size), packs a punch (up to 72MHz core clock), and programming it isn't black magic (take a look at something like CubeMX from ST, you no longer need to remember a ton of registers by heart or dig through a several hundred page datasheet to get things done or calculate the clock multipliers/dividers by hand, the basic setup is pretty easy). It could still use trapezoidal control, but at least the MCU won't be the limiting factor for going into more complex controls. Power supply for the low voltage components: A switching step-down converter needs to be designed and carefully tested, most ready-made controllers are limited to something like 40V max input, but there are models that can handle more. The Firewheel used LM5007, that's rated up to 75V, but it was also the weak point of the board (multiple members here, myself included, have had their board die, and I think the usual culprit was the step-down failing), so probably don't look at the Firewheel design on this. Most MCUs are 3.3V, but even if they were 5V, that's still a large voltage to drop from the batteries, and during regenerative braking it can go higher, so you can probably leave a margin of at least 5V above the maximum battery voltage, if not more, just to be on the safe side. Linear regulators are out the window immediately, the power dissipation will kill them pretty much instantly even if you draw a few tens of mA, although they could still be used to drop the voltage for low amperage loads once the battery voltage is regulated down to something like 5-12V first through a switching mode power supply. Luckily, most datasheets for switching controllers (external power transistor) or switching regulators (internal power transistor) have application examples and step-by-step instructions for calculating the external component values when you know the maximum and minimum input parameters, so it's not that difficult. For example, I've never made a switching power supply with SEPIC-topology (a certain type of step-up/step-down -converter) before, but was able to design something that should work (in theory) for up to 60W of output power at 12V and pick prototype components in a single evening just by following some Analog Devices datasheets and app notes and "oversizing" things, doesn't even seem to need heatsinks. Of course that's just the first prototype and probably needs a lot of testing and tweaking still. Since "only" a buck (step-down) -converter is needed here, it should simpler, but the high input voltages make it more trickier to find suitable components. The Firewheel used a HIP4086 3-phase MOSFET gate driver, which could work directly with the battery voltage (up to 80V): https://www.renesas.com/eu/en/doc/datasheet/hip4086-a.pdf I guess the gate driver might work at a much lower voltage than the full battery, meaning it gets its power from the step-down, even though it needs to push the high-side gates to 10-12V above the motor phase (which might mean over 80V on a "67.2V" -wheel), but I haven't really ever dug up into them that much. That's one more point to dig deep into. I didn't mention the IMU above, because I don't think it really is a hardware "issue" (more of a software-side issue), since there's no point even in debating about the idea of anyone building their own. Just pick a premade one that's commonly available (I didn't know MPU6050 has come to end of its life, better pick something newer). On top of these, there's still of course a lot of design decisions to make with "smaller" issues... On the software side, the main issues are: Motor control algorithm: I won't go back to debating which method should be used, suffice to say that there are multiple options with varying complexities. The more complex algorithms can take a lot of time to get "right". Patience is a virtue Reading and filtering the IMU data: This can get complex with the filtering maths needed, but if ready-made libraries are available somewhere, it could actually be pretty simple. Still probably needs someone strong in mathematics and such, rather than "just a programmer". P(I)D-loop: The feedback control loop isn't complex as a piece of software (it can be done with only a handful of lines of code), but the issue is "finding" the correct factors so that the entire thing is stable at all situations. I don't know if the commercial wheels use something that has dynamic parameters ("auto-PID") or just static constants... There's a big difference with something that can somewhat balance itself (when nobody is standing on it) and the precision of balance the commercial wheels have with pretty much zero over/undershoot, I managed to make a small self-balancing robot some years back, but I searched the PID-constants just by trial and error to get it to balance, I wouldn't trust this method with something that's supposed to keep me from falling : Somebody with a background in control theory (automation engineers, usually) is probably the best person to deal with this. Probably there's a ton of things I forgot and didn't go into even nearly enough detail, but I think is enough of my ramblings for now

The mileage readings on the wheels are hardly trustworthy, but off by a factor of 30 sounds implausible My best guess is that it was tested at the factory and/or by the reseller and the mileage wasn't reset.

Hardly my area of expertise, but based on what I (think I) know, likely this will have very little, if any, effect on the lifetime of the electronic components. Consider this: when your mainboard was made, it went through a reflow oven to solder in the surface mount parts. A typical reflow "profile" might look something like this: During the preheat and soaking, the components are exposed to a temperature somewhere between 175 and 200C (roughly between 350 and 400F) to get the flux "activated" for a couple of minutes. Then the temperature is ramped up to around 260C (500F) for a short period to melt the solder and cooled back down. The limits (like 3C per second max) are there to prevent fast surface tension changes and such that could either cause the components to "pop" off the board or break the component packages. The profile above shows the maximum temperature (260C) for 20-40 seconds, in total the temperature might be above 217C (the melting point of "typical" lead-free solder) for 1-2.5 minutes. Of course they aren't powered during the soldering, and the components are brand new at that point. For example, if the "core" of a mosfet hits around 175C while powered, it will self-destruct (possibly spectacularly, ie. blowing through the package leaving a molten hole on the side)... Some devices also go through "aging" or "break-in/burn-in" periods at the factory where they're exposed to more than normal stress to find out faulty pieces early. Through-hole parts maybe soldered in by hand or with wave-soldering, where the board is taken through a "fountain" of molten solder flowing over it. Wires are likely soldered by hand. Even electronic components do wear out over time, and high temperature wears them out faster. However, for most components were talking so long times that it hardly is an issue over the product lifetime. In "normal" wear, usually the first things to give up are electrolytic capacitors (the big "cylinders" in the mainboard), because they contain liquid electrolyte. Over time, the electrolyte can slowly dry out, or the casing breaks and the electrolyte leaks out. We're still talking long time in normal conditions, but again higher temperatures cause this to happen earlier. Good quality caps should still work for decades. Your batteries will degrade far sooner below the point of being actually useful. Due to the nature of the wheels, it's more likely that your wheel gets destroyed in a single, fast incident (high voltage/current spike) rather than by wearing it out. And even more likely that it's going to happen in a crash of some sort, unfortunately In general, I wouldn't be too worried about the temperatures, of course you can destroy your wheel by overheating it, but it's not likely to happen during "normal" riding. Still, if you keep going back and forth like in your test, or climbing long mountain roads, and won't stop (and the firmware doesn't stop you), yes, you can overheat the components and destroy the board. If the temperature went high, but the board survived it, yes, you likely "aged" it faster, but in the big picture, other issues (like a crash destroying the wheel, battery degrade or switching to another model and selling the old wheel) are likely going to be the reason you stop using the wheel, rather than the components breaking through normal use and intermittent heating. In the early days (for me, that's circa 2015-2016, first Solowheels and such came out even years before that), people were blowing up their boards by stressing them a lot (usually climbing), where either the mosfets or sometimes the wiring might melt. Sometimes it was enough to accelerate really rapidly or hop down or up a curb, hitting a pothole etc. Nowadays it seems that what usually destroys the wheel is a crash, as the components used and design have improved (bigger mosfet packages, better cooling, better connectors etc.). My two desktop computers at home are both from somewhere around 2010. Both of them have seen a lot of use, although I "switched" to using the other one maybe 3 years ago. They both run hot (almost a decade old 3.2GHz 8-core Xeons )and the other one once had temperature problems (turned out to be a heatsink clogged with dust, the CPU was running at close to 70C at idle, hitting 100C during loading and went into thermal shutdown), yet they still run fine. Most likely one day the mainboard electrolytics will give in and I have to get a new one...

I kind of liked the old 18" KS look, although no idea how practical (probably not? ) it was...

My guess would be space issues, board size and how much room is there in the mainboard compartment. The MCM5 board has four 470uF caps in parallel = 1880uF (well, those caps have a tolerance of something like +-20%, but thereabouts ), while the Tesla board has two 1000uF caps = 2000uF. More caps in parallel does drop the ESR (resistance) of the caps , so theoretically more smaller caps in parallel could provide higher amperage, but since no-one's complaining that the wheels don't have enough power, it likely isn't that much of an issue either way AFAIK, the caps are there to provide the high current spikes when the motor coils are being turned on, the momentary (nano/microseconds) amperage can hit very high numbers (100's of A, if not 1000), which couldn't be provided "all the way" from the batteries, because of resistances added by all the wiring and connectors in-between. Also they'll likely take the worst voltage spikes off coming back from the motor(?). Usual symptom of a failed / bad caps in the mainboard is loss of torque (if not outright failure of the board, if they fail in short circuit for example).

Trapezoidal is easy, but my suspicion is that it won't be "accurate" enough (too jerky?) for something like a self-balancing device... but if someone proves me wrong, then why not, at least it's really straightforward to implement. If adjusting the PWM fast enough, it could maybe get "close enough"? Difficult yes, but if the MCU has kick (the Indonesian guy/guys used a Cortex M4, those things have hardware FPU and the M4 I have runs at 180MHz at max clocks), it doesn't really add cost IMHO. ATMega-based Arduino on the other hand probably won't be fast enough for the matrix and vector calculations, even if using fixed point maths (again could be wrong though ) AFAIK, the guy who made VESC gets flown by private jets to help big companies with motor controller design, but then again VESC is open source. Big semiconductor companies offer their own tools, code and development kits for FOC development. @lizardmech built controllers with FOC (as far as I know, btw, are those available somewhere? )... I don't really think that business/financial reasons are a sound justification for not using a more complex control method / not making it open source. The "cost" of workhours put into the project is essentially zero, since open-source software/hardware projects are usually made by volunteers, not paid programmers/hardware designers. Of course there are exceptions and companies that provide software / schematics / PCB designs for free, but sell premade hardware. With good modular design of the firmware and interface to the motor control, the control-module could be replaceable with any type of control, so the method could be changed as needed (ie. balancing algorithm "requests" some certain torque or speed value, and the motor control code acts as a black box, so the actual method is hidden from outside). Of course it will likely need fine-tuning and adjusting between different motors and control methods, but at least leaves open the possibility to "pick and combine" as needed. The big step is making the hardware "cheap enough" (although likely it still won't be cheap, even a smallish 10-14" BLDC/PMSM -motor with shipping and customs from somewhere like Aliexpress is something like ~200€ because of the weight) and easy enough to get/build, plus a solid, well documented and sound software to work with, so that bigger crowd picks up the project.

I'd claim that the package-size / amount of power transistors and size / surface area (/ weight / heat capacity) of the heatsink are more important. Ideally, no fans would be needed at all (and many wheels don't have any), as they add a new failure point (mechanical moving parts) vs. plain passive cooling.

Problem with this might be if the turn signals activate when you're just making a slight adjustment on your trajectory... also they might be illegal in some countries (at least here, the colors for lights/reflectors pointing at different directions are set in law, never checked what the law says if a bike had turning signals). I'd like this, seeing that for the first time I'll have to carry the damn thing upstairs at work when the riding season starts, and then roll it down the hall for a bit. At my last workplace, I could just trolley it in and out of the elevator Again legal issues: red lights pointing sideways are illegal here, don't know about other countries. Light or reflector pointing backwards MUST be red. Don't know how uptight police is with the rules though, never been stopped (EUCs are legal in Finland, they're classified same as bicycles in traffic laws). Not a bad idea, but I'd never leave my wheel out of sight in public spaces, even if it's locked. Someone's going to go poke around it or maybe damage it, locked or not. I'd personally like this, but for an Average Joe, the voltages are meaningless. Most people don't know anything about batteries, and for them the bars / percentage-display are much better. Maybe both / selectable (7-segments or similar showing percentage 0-100 or voltage, adjustable from app or somewhere) Not going to happen, you can't put that much current through any normal button, it would have to be pretty huge. The contacts on the button would either weld shut or melt... All the KS's already have fuses, AFAIK. Of course they should always be the "last line of defense", and in a perfect world, the electronics would never break down.

On a quick glance, I don't think this is going to be really useful. At least a couple of the files seem to be modified from STMicroelectronics examples, the entire source wasn't there (at least I noticed just 4 files in the instructable). They're apparently using a prebuilt motor controller and a rotary encoder instead of hall-sensors. I couldn't make heads or tails how the motor's actually controlled, thanks to no comments and functions and variable names in (I think) Indonesian, but maybe it's somewhere there... I only glanced it over in like 5-10 minutes, so maybe I missed something. The only (maybe) somewhat useful piece could be the Kalman-filter code. After a second look at the Kalman-code, nope, find a better example or study the mathematics behind it and roll your own... The "hard" parts of the firmware are likely reading the IMU with proper filtering (a process control/automation M.Sc -guy at work mentioned the Kalman-filter on a short discussion about IMUs a while back, since he's the maths guru, I trust that it's pretty important ), FOC for motor control and the PD or PID -loop (not coding wise really, but finding the "correct" constants). Projects like this have the additional problem that getting the hardware isn't exactly cheap (motor + controller + batteries), and making the frame can be problematic. And trying to write the software without the actual hardware is pretty much impossible. I do have a Firewheel motor + shell + some batteries (and finally lab power supplies capable of up to 100V) lying around, but I wouldn't trust my electronics design skills so much that I'd actually try to ride something I made Probably should try to design a simple motor controller at some point just to see if I can get the FOC running properly, now that I've dipped my toe in ARM Cortex M3/M4's and get more "exercise" in C programming ECUs at work nowadays. Then again, not sure how much I want to write embedded code at home when I do it all day at work...