It's been quiet on my front, but that was because I was redesigning ESC's (for multirotors and AP's).
Most of the ESC's for multirotor use the SimonK firmware on a relatively simple Atmel microcontroller. There's a single control wire running from the autopilot to the ESC, which is a signal proportionally dictates how long the mosfets are left open and as such command the torque on the motors.
And that's pretty much all there is to an ESC... No signal/wire coming back to tell the autopilot how that particular motor is doing or what the rpm or current is, it's just a "command wire". That sounds a bit antiquated for 2014.
So this picture is of an ESC dev board I first started on, here using the Allegro A4960 chip for simplicity. Shipping to Brazil takes time, so before it arrived the design already morphed into something new, so that's why the board looks unused. Both the MCU and driver chip changed on the newest development board version and I introduced testing points for oscilloscope readings; this project is about to get serious!
What are the features that I think an ESC for a modern multirotor should have?
1. Send the rpm back to the AP; for logging. I see people posting logs to request help figuring out what went wrong, but the log only states the "pwm out" for each motor, which is in no way a guarantee that the motor actually did that. So we need some feedback that states what the motor was actually doing, not what it was commanded to do.
2. Overload detection; the ESC's know what the current is and warn for overload situations.
3. Current & velocity control; neither current nor rpm is actively controlled as a proportional measure to the input PWM signal. So the control loop for the AP spans the IMU, motors, ESC and props, which is a large loop with lots of variables. This ESC will run one or two 'inner loops' and become responsible for achieving either torque or lift and run at a much higher frequency than 500Hz. What you get is that some variables no longer impact the control loop of the AP directly, which should make the vehicle more stable and likely more responsive.
4. Field Oriented Control; The flyback diodes next to mosfets typically burn energy in trapezoidal drive implementations, which increases the heat on those mosfets. This happens because the mosfets close suddenly. The motor coil wants to resist that change, so you have a current that has nowhere to go except through that diode. In sinusoidal control, there's always one mosfet open for any coil, so the current always has somewhere to go, which means the flyback diodes won't get used, so you don't lose the heat.
5. FOC; better efficiency, because the current is always perpendicular to the magnetic field. This may come at the cost of max. torque (related to motor inductance and then only about 5%).
6. FOC; lower torque ripple (1/2-1/3) vs. trapezoidal drive, so hopefully less vibrations, less whistling.
7. Send current readings back to the AP; another opportunity for precisely logging what goes on near the motors. This could be helpful to detect ESC/motor/prop health (bad bearings, prop drag, etc)
8. Configuration; the AP can reconfigure ESC's prior to flight or when in maintenance to tune it for a specific motor.
9. Motor monitoring; if the motor stopped, shorted or the mosfets misbehaved, the ESC can shut down immediately and advise the AP. The AP can then take additional action.
10. Opportunities for automated ESC tuning specific to the motor/prop in use.
The way I see this ESC make a difference is when abnormal situations occur. The current AP's cannot be informed of failure, so it would simply send a signal to "run faster", which, guaranteed, has a disastrous effect to mosfet or motor and could therefore worsen the situation. Soon as the AP is informed something is wrong, it could sound an alarm, activate a chute, disable the counter motor... you suddenly have options!
To spur innovation in this area, I'm considering to setup a kickstarter and actually manufacture around 1.000 or so at a professional PCB house. Aren't these features indispensable for an ESC made in 2014? Would you back it?
Comments
@Artem: Theoretically 12S is possible, but the power stage will be different, so it would need different mosfets and that drives the price up. For this version I aim for 3-6S (2S most probably also works), but it makes sense to make a different HV version for 6S-12S.
@RCVertt: I think you'd need hall sensors, because these sensorless controller measures electrical angle. If you have multiple poles, it can't tell which pole it's at.
@Jeroen: That's a very nice ESC, I saw the video. Yeah, the sensing resistor will add a bit, but I think weight is a bit more important than form factor for now. You're not using heatsinks either?
Thanks all, looks like I have some planning to do.
Very nice to see an ESC with FOC, only downside is that you need extra sense resistors in the motor phase which makes the ESC physical bigger. And I'm not sure there will be gained much at the cost of size (which can be limited in Quads).
FOC is also not needed for the freewheeling because also with trapezoidal it is possible to switch the FETS in complementary mode than the diodes are not used and you get active braking for free.
With closed loop ESC you will gain much more bandwidth in controlling the quad.
I have been using I2C for a long time now with out any issues in my quadcopter, below picture of 6x 25A esc in 10x10pcb with onboard current sense. Every esc is also current limited (software programmable). And runs closed loop RPM and the ability to measure the frequency behavior presented in bode plot.
Currently busy with a redesign making it smaller (5x5cm) for small FPV racers.
@Randy
Wouldnt i2c be a problem because all esc now need unique ids, if they are on a shared i2c ?
I think you have raised a very interesting idea, namely the antiquated communication/control mechanisms between different rc components. At the heart of everything just about including ESC is PWM/PPM, which are almost analog things and certainly not digital. Improve the communication layer and devices can get smarter and more interactive.
count me in!!
hzl
Looking good. For the interface back tothe AP, I'd recommend UAVCAN or I2C.
I've been wanting to do a project like this for ages, but I'm years away from being at a level to be able to actually do it. MAKE IT HAPPEN YO!! :D
Please add a micro USB port on them also so we can run debugging over a laptop for prop test setups and other not on craft tests possibly.
this is a fantastic idea, I'd love to see these developed to work alongside the AP platforms! it's been quite a while since I've looked at any of the code, but would it be feasible to run a bunch (say up to 12) of these via I2C?
Very interesting.
Would this ESC be able to stop the propeller at a specific point or would I still need hall effect sensors to do that?
And i like the purple from OSHpark!