Recently the Chinese ESC design utilizing the ATMEGA which we have been flashing with Bernard Konze's firmware has been disappearing from the market. This was the push I needed to finally decide to design and build a replacement. Collaborating with a friend, we worked on it over the summer. It is finished and I think it came out pretty well. I call it ESC32:
Design goals:
- Extremely fast implementation of requested throttle setting
- Ability to take high rate input
- Multiple input protocols
- Ease of programming, real-time debugging
- Efficient
- Inexpensive
The final specifications read:
- STM32F103 72Mhz MCU - 32bit ARM
- Firmware written in straight C
- SWD connector for real-time debugging
- Input via PWM IN / UART / I2C
- 1KHz PWM update rate capable
- All N-FET design with gate drivers
- At least 40A continuous with proper cooling, maybe much more
- 2S => 5S battery
- Option to power logic side via UART or PWM IN +5v
- Command Line Interface for testing / parameter modification / back channel
- 8KHz => 64KHz PWM out
- Current sensing / limiting
- Regenerative braking capable
- Closed loop control mode - experimental
- Lots of RAM and CPU cycles available for advanced control techniques
- BOM cost < $20 at quantity
* image courtesy of TC Pictures, LLC.
It is a drop-in replacement for the ESC's that I have been running with AutoQuad and will take standard PWM input up to 450Hz. I will eventually design new high rate PWM timing which will bring this rate up to 1KHz. It is a definite improvement over the ATMEGA design. Your flight controller can ask for large, quick changes in throttle and it is able to implement them very fast. This allows PID output to be tuned to be more aggressive and results in much smoother control.
Start ups are very smooth and I have not yet found a motor it could not start. It uses oversampling techniques which allow it to accurately control a BLDC motor down to 200RPM. Early indications based on some initial head to head testing with other ESC's show the it is very power efficient. This comes from the fast switching of the N-FETs due to the use of gate drivers. Less time is spent in the on-off / off-on transitions, so less power is used, less heat generated. No special heat sinks or cooling should be necessary for typical 10 to 20 amp usage. This also means that you can use higher PWM output rates without too much of a hit to efficiency.
* image courtesy of TC Pictures, LLC.
As the ESC is an extremely important component of multi-rotor UAV's, it is critical that it keeps running, no matter what. So you can imagine the amount of testing necessary before you can start to trust a new design with your expensive machine. There are a handful of people flying the ESC32 now and I myself have perhaps 10 hours without incident so far. There may still be problems, but I am fairly confident that it is trustworthy. It's all I fly now.
Comments
Very nice. An opto version, or a version with a reliable field bus would be great.
The regenerative braking seems very interesting for multicopter use.
Awesome. This would be great - The off the shelf RC escs are definitely now becoming the obvious weak point in the system, especially WRT quads.
Will firmware update be possible in situ? ie via the i2c?
Hi Bill,
Nice done. The Open Pilot group just published a similar STM32 ESC but your design looks a little bit more compact. On XKopter Konstantin is still busy with his canBLC (STM32 too) , so at the end it would be interesting to compare the solutions to learn from each other.
If there will be some ESC32 available some day, I'm really interested to buy one/some!
best
Thomas
Where can we buy them ?
compatibility with Ardupilot suite? I am sure it seems like a "simple" replacement... please confirm...
also how do we order? hehe Quite interested in testing these new babies! and if works well stock them up at the store!
From what I can see this is a great piece of work!
Dany
Very interesting. PWM is cool but unidirectional. I2C is ok but seems unreliable in case of hardware issues (highlighted by recent reports on arduino's TWI library that locks up in case of hardware issues with the ground). UART (=Serial right?) is ok but there are very limited UART ports on most micros. How about an SPI interface?
I'll take 8 plus plus 2 autoquads please Bill