Jump to content


Full Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

671 Excellent


About lizardmech

  • Rank
    Advanced Member

Profile Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Sucks that they had to pay solowheel 1.1m but they didn't have much choice, dealing with patent troll lawsuits in the US is something like $10m minimum and if you win you don't get anything back if you win. Though the marketing people sound like they were even more painful. I don't think the solowheel brand has a future, the patent trolling made their brand toxic among enthusiasts and they blew any mainstream appeal by failing to release newer models or reducing prices to be competitive despite having a headstart. The solowheel brand is worth $0 in my opinion.
  9. I just use these mostly. They come with a MCU and debugger on one board, you can get 3 phase inverter add one boards for about $50 as well. Compiler and IDE is free these days, Ti have their code composer studio thing which is a modified version of eclipse and GCC configured for their MCUs. https://mouser.com/ProductDetail/Texas-Instruments/LAUNCHXL-F28069M STM boards are similar with on board debugging, there's many options for compiling for those since they are just 32bit ARM code, IDEs I think you can chose between eclipse or various others. Most of the time I just build straight out of linux via GCC for the STM ARM MCUs. Pretty much any of the STM32F4 variants are fine. This is the closest example I have found to code suitable for a unicycle this one uses brushless gimbal motors, the motor code is different but still closer than the more common slow moving geared brushed DC motor balancing robots, the TLDR more or less is you need to add compensation for reduction of torque as RPM increases, the code is pretty lightweight so any of the 32bit motor control MCUs should handle FOC + balancing without any issues. http://www.instructables.com/id/Brushless-Gimbal-Balancing-Robot/
  10. 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?
  11. The main thing is picking a MCU with robust motor control software ready to go, the unicycles need a decent FOC motor controller to run well. Texas instruments and ST micro both have decent motor control options, they aren't 100% open source as the sensorless motor observers are in compiled libraries but you can still have the rest completely open you can still upload it to github and anyone can build it. They're fairly barebones they can detect motor parameters and spin the motor in debug but there's a few things you would ideally need to add such as separate current limits for motor current and battery etc. There's the open source VESC software which is quite good the downside is it's extremely complex and not really documented, the person who made it was going to add support for 6 axis IMUs but he doesn't have much time to work on it so it may not happen for 12 months or something. I found the texas instruments motor control to be the best of the commercial options I tried, to get it working all you would need to do is get the IMU working over I2C and have the balance code set the motor torque value in the provided torque control loop. There's not too much code needed for the balancing, besides filtering you need to have offsets for the gyro as it won't be perfectly level and the balancing code needs to compensate for the decrease in torque as speed increases.
  12. I actually made a whole bunch of motor controllers I was hoping to use for an open source unicycle, I completely designed all the 3 phase inverter and hardware needed for motor control. I had it running the unicycle motors with no issue but I could never find anyone to help finish the software, I don't have enough embedded programming experience to do it. I more or less know what has to be done but getting it all together into working firmware is difficult.
  13. Could be it's just raw motor phase current and the other brands are calculating the battery current being used instead.
  14. It may not draw more than 40A from the battery but the motor is capable of transforming it to very high currents at low speed, at 20% speed it's capable of converting 40A into 200A. The load does get shared around however at one point one phase and associated components will take the peak current in the cycle. It looks like the high side fet is blown here though, maybe the motor phase hit the mosfet driver as it came loose and shorted it. A motor phase coming loose while under load can also potentially generate hundreds if not thousands of volts if it were the one connected to ground, motor inductance resists changes in current so voltage will go up or down depending on the condition.
  15. Those mosfets are package limited to 120A even though the silicon is rated for 300A or so. Gotway didn't read the datasheet I suppose.
  • Create New...