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
Davey, have you checked TC's AfroESC he dont mind someone building it, its opensoruced but not based on STM32 ARM but rather the normal ATMega8. no one had it yet except TC but the good thing is it supports Simonk's custom firmware.
On the other hand Bill said they are doing beta test in a couple of weeks and hope to get good feedback. Hopefully this project will not stop
@ThomasB
Is that based on information or hope???? :)
Hopefully the Open Pilot ESC will be available in the near future. The first result are very impressive.
@agibbons1
I don't think these are going to be commercially available, and unfortunately the design files etc aren't open source. A real shame as I would love to build a few myself!
Any updates on this, I want to buy some :)
hello Tom,
I have read that you have managed to make altitude hold function using LV EZ4 could you please let me know what problems you've faced during your sonar testing and how you've solved them. Did you tweak the code? if so how?
We are using 2.1.0 alpha code and a mega 2560, apm 1.1 with same sonar. Our sonar is working erratically, the quad keeps on rising to a higher altitude(i am working along with srinath http://diydrones.com/profile/srinathreddy?xg_source=activity). Please give us suggestions.
Does any one no if these are going to be sold and if so where and how long please let us no thanks tom
I measure the bus voltage of the through the BEMF when a certain phase is active, and divide it. This works oke.
Also tried analog filters, but the problem with filtering the PWM out of the BEMF is the phase delay caused by the filter which has to be compensated. The dsPIC33FJ16GS504 I use also has two ADC's
Indeed at very high RPM the reaction time has to be fast, that is why I increased the PWM to 32kHz.
When my ESC work I haven't changed and start working on the IMU/controlboard. At the moment no time for the quad. But next year I want to improve the hardware/software with idea's from your hardware.
Photo of my 100x100mm 4x BLDC controller.
A lot has been written on the subject of BLDC ZC detection. I've tired a lot of things, but what I find works well is using the dual ADCs on the STM32 to sample the three phase voltages continuously and filtering using a time varying averaging window. The average of the three filtered values is the zero point. This way you remove the uncertainty of voltage and other calculations. It also reduces the parts count.
Since commutation events can happen in much less than 100us at high RPMs, your samples need to be as often as possible and as short as possible. The averaging window must be shortened as RPM goes up and lengthened as it reduces. Using this technique, you actually find out about the ZC some time after the event, but this is ok as you still have a little bit of time left before the commutation must be triggered if your window is sized properly.
Bill,
Can you tell more about the zero crossing detection ?
Is it done with comparators and filterd BEMF signal or with the ADC. I measure the BEMF voltage during the on period of the PWM with the ADC (200ksps ADC), and when the value is greater or equal on half the DC-bus voltage it is detected as a zero crossing. It also counts the number of PWM pulses before zero crossing and uses that number to wait for the next commutation. It is based on a algoritm of ST.
The problem is that the BEMF voltage on a scope has high "jitter" and that also causes noisy RPM readings.
So I'm curious how you detected the zero crossing.
-
2
-
3
-
4
-
5
-
6
of 9 Next