lizardmech

That looks pretty decent, the drone board is only $15, I'm going to make a new VESC board using the DRV8350RH it has a 100V limit and eliminates the need for gate resistors and diodes, it should be easy to make an extremely compact PCB. It would probably be easier to control the VESC over UART than PPM.

I tried a few years ago, had plenty of prototype hardware running but I could never find anyone who could code in C that was willing to work on it.

This is the MCU I have been mostly using, the dev board has a debugger on it. Ti has there own eclipse IDE and gcc fork so it's easy to develop for them these days, you just download their code composer studio thing off the Ti website and it's more or less ready to use with all the needed debug and compiler settings configured. http://mouser.com/ProductDetail/Texas-Instruments/LAUNCHXL-F28069M?qs=%2fha2pyFaduiQ7Z42YDZKD5QyyhA%2bSpny8iXDynuyzWmTbS83j4JizA%3d%3d You can plug it directly into this, the voltage and current limit is a bit low to ride an EUC but it spins the motor and is enough for basic testing. http://mouser.com/ProductDetail/Texas-Instruments/BOOSTXL-DRV8301?qs=sGAEpiMZZMtjWZqwEMjY%2f2%2f690yOn8Q3JTTEZ%2fhpAs8%3d I was just using the MPU6050 as it was common, most code examples I have seen don't end up even using the processing on the mpu6050, they usually just use a kalman filter on the main MCU to combine gyro + accel. The mpu6050 looks like its close to EOL though there's still plenty of stock around and there's more or less a drop in replacement, it's probably fine to keep using it, I had someone write drivers for it on a STM32 mcu when I was trying to get the VESC to work, it shouldn't be hard to move it to the Ti MCUs. For the inverter section it's pretty much gate driver + 2 mosfets and current sense for each phase. The chinese boards tend to use gate drivers with only one PWM signal per gate driver, the gate driver is responsible for deadtime and it can't be adjusted in software, all the ones, all the ones I built have separate high and low side PWM inputs so you can set the deadtime in firmware. Generally the gate driver to mosfet gate pin traces are the most sensitive part, they need to be as close as possible and you have to avoid making large ground loops. Another few tricks is putting a diode in parallel to the gate resistor to speed up turn off since you don't have to worry about ringing, another is to place a ferrite bead near the mosfet gate, they basically look like a very large resistor to high frequency AC but allow the PWM signal to travel through. Generally a small resistor + ferrite bead is better than increasing gate resistor resistance. The only other thing I can think of is you need phase voltage sense which isn't on the microworks boards, you just use a simple resistor divider to scale the voltage for the MCU to read, it must however have a low pass filter to reject PWM signals, this part drove me crazy only the instaspin controllers rely heavily on it so I never noticed the need for the filters on early designs and was constantly looking for other problems which didn't exist. Another trick I found from some of the instaspin reference designs is to protect the MCU analogue inputs with TVS diodes, that way the non-isolated voltage senses won't kill the MCU in the event of an unexpected voltage spike.

There's not much to those microworks boards, they use older components that be replaced, some of the solutions on them are convoluted and add many components. For example they use a 5v allegro current sense that doesn't have enough sensing range so they try and use either PCB fill or a resistor to divide the current, then they take the 5v signal and have to use a voltage divider to convert it to 3.3v signal for the MCU. Now allegro make a small SMD current sensor with 100A+/- range and 3.3v output. Software wise all that really needs to be done is add IMU support to existing motor control options, I played around with VESC, Ti instaspin, STM FOC and NXP FOC software. VESC is the most open but difficulty when it comes to modifying it is extreme due to no real documentation and it is quite complex due to the amount of features. Texas instruments Instaspin seemed the best of the commercial options, it almost completely open, there's a small motor control library on the MCU you can't access but anyone can edit and build the rest without any restriction. STM software was similar but a little behind the Ti option in features and performance while not having as much documentation or convenient cheap dev kits to use.

Does microworks do the software development and hardware design for the unicycle components? Many people here would like an adaptable controller that can be reprogrammed for different wheels, we are fairly close to getting a few designs working but it would be much easier if we had an ODM/OEM company that had experience with balancing vehicles to work with.

I built a bunch of different motor controllers, after various explosions and fires I got enough practice that I can design and build them without much effort so there's not really any need for microworks or chinese controllers in general. EVL was hostile towards use of any open source hardware and stopped working on anything EUC related when microworks stopped selling EUC boards. I managed to get most of the code needed to make an EUC, it really just needs different parts to be assembled into one firmware. I still haven't been able to find anyone to help with software development though, I don't think anyone was willing to contribute even a single line of code over the last 2 years.

I can't work out what they meant by dual core and redundancy, looking at the ecodrift teardown there's the usual STM32 controlling the motor and possibly a second MCU up the other end of the board doing BMS functions or other non motor tasks but I can't see anything overly different.

I'm guessing they have a 7th mosfet acting as a on off switch for each motor inverter since mosfets fail open. As I said a few times in discussions about EU proposed regulations, I'm uncertain if it actually works, aerospace, defense, automotive and medical systems have trended towards having one highly reliable system rather than multiples. If it can actually prevent a faceplant due to a fet failure while moving it's a good idea if it can't and only means you can still ride home after the faceplant it's a bad idea as you have effectively doubled the probability of a failure with no increase in safety. I was never able to find any sort of demonstration of the dual motor windings on the segway working during a hardware failure. Did inmotion say if they had tested if it works in the event of a failure while in use?

It should work provided communication between the balance controller and motor controller is possible, the only thing that could become an issue is latency and timings on the various MCUs. I found this the other day, it was quite similar in function to colton code you adapted for your ebike stuff. Runs 2 BLDC + motors + balancing algo but the motor code and balance code were quite closely coupled as torque compensation was required. Still I think this is the only arduino balancing robot using 3 phase brushless motors I have seen that works quite well. The others I have seen always use DC or stepper motors, the brushless attempts were always very wobbly or only manage to work at 1kmh presumably due to torque compensation issues. Another thing I found interesting from some open gimbal stuff is apparently 6 step BLDC is not viable for gimbals or balancing vehicles theres just too much cogging unless you build a motor with hundreds of poles. http://www.instructables.com/id/Brushless-Gimbal-Balancing-Robot/ Though this robot looks pretty good I imagine there's a few things balancing vehicles would have to deal with, the robot has overwhelming amounts of torque for its weight so running openloop motor control is viable as there's no real chance of it de syncing. Secondly the faster EUCs may have to manage phase lag due to higher RPM. This matches up with EUC hardware. The early models are most likely running sensored LUT based sinewave controllers, while the addition of ACS current sense on 2 phases would make sense if they needed to switch to FOC to mitigate hall sensor issues and phase lag. It would be more obvious on EUCs as they have smaller wheels than ebikes but the same number of pole pairs resulting in higher ERPM, this would explain why they didn't just reuse existing ebike controllers. Even with high RPM middrive motors for ebikes they have far fewer pole pairs so electrical RPM is likely still quite low.

Also why are you suddenly angry at me, you ask if the open ebike firmware has reverse (which it doesn't) and you said the existing controllers you own aren't viable, I don't quite get how trying to suggest cheaper and easier options as you wanted is somehow calling you an idiot?

All I'm suggesting if you want a quick and easy motor control solution arduino + chinese ebike controllers is perhaps the most difficult and time consuming way to go about doing it. Even for small little projects balancing or not. I have seen a decent arduino balancing robot but it had the arduino directly controlling the the power stage using LUTs to generate sinewave control as it was controlling the motors it was able to compensate for torque changes across motor RPM.

I get what you want to do but arduino + controllers should be more work and time not less than the other options. Assuming you use an arduino + generic ebike controllers you will have to run the balancing code, output 2 PWM signals and somehow level shift them to the voltage the range the controller expects, then you have to convert it into an analogue signal via a filter which likely introduces latency. Then rework the balance code to compensate for any latency or quirks with the controller inputs. Then even after all that is done the balance controller has no idea how fast the motors are turning and as torque and difficulty in remaining upright varies with speed I'm uncertain if the control loop can function reliably as an open loop system. In comparison to doing it with MCUs that already have motor control code ready to go, all you need to do is get an IMU working via I2C, write the balance control loop and have it set the required torque value. If any compensation needs to be done for motor variables you have access to everything already.

The Ti dev kit + 2 motor drivers is cheaper though, even two chinese vesc clones are only marginally more than those. I don't really get why people think arduino + generic chinese controllers are easier doing it that way means no access to ERPM, current or duty cycle data for the balancing code. Multiple MCUs controllers could work if you write the firmware for everything so they can communicate with each other but operating the motor controllers as dumb components in an open loop makes no sense.

To put it into perspective, 500 x $65 is $32,500 USD, you could easily hire developers to write open EUC firmware, design a custom board and do a 500 unit batch for that much money.

500 units minimum order though. Looks like they aren't making them unless someone orders a large batch.