Redesigning multirotor ESC's

3689622049?profile=original

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?

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • But none has vector control that gives you smoother running, lower current peaks on phases, better torque production, all for a price of an extra current shunt.

  • Though I haven't gone through all the posts, there are ESCs that send back RPM, current etc measurements via I2C or CANBus. These ESCs also do closed loop control of RPM and other variables. For example see ESC32 and PX4ESC. There is a 2014 ICRA paper that was done on one of these ESCs

    https://digitalcollections.anu.edu.au/bitstream/1885/11442/1/Bangur...

  • ESC32 looks pretty tight to me!  The pic at the top doesn't look nearly as well designed.

    You really have to go with a double sided, high density design like the ESC32.  Otherwise it's just going to be way too large.

    The whole filter/PS/cap. block needs to be inline with the cable, or on a small rail board inline with the cable, not on the main board.  Look at the input cap on the blog pic above.  It's way out of place and ruins the whole design dimensions.  You can also lay them flat with longer leads and hang them off the end of the board (basically inline with the input wires).

    Proportions and block designs easily get way off.  You should be rearranging the ESC32 design which is already laid out well.

    It would suck to spend a ton of time laying out the board and then realize you just ended up ripping off the ESC32 design.  Far better to start with the ESC32 design and then make it better or at least different towards a specific end.  You'll be miles ahead that way.

    In any case, an open source project will NOT catch on if you use an oddball processor.  FYI, your choices are pretty simple Atmel, PIC, or STM32.

  • 3701862367?profile=originalHere is a block drawing I made I think this would be good as a stick so that it will fit in thin places, also the way the power is routed, there can be a large amount of capacitors along the side wihch will be away from the heat source and not obstructing a heat sink also. If the design is not final this might be an inspiration or not.

    I saw ESC32 but did not think it was a good design because no capacitor space, akward shape, and fets on both sides is a great idea but don't think sinks on both sides like that...

  • I think going with an off-brand micro is a bad idea.

    The ESC32 project has already done FOC, and even have a clone controller on the market.

    Why not build on that project?  There's already WAY too many crowdfunding projects that sucker people out of their money by promising things that already exist, at inflated prices obviously.

  • I will surely buy a kit. Go on

  • Kickstart!
  • Yesssssssssssssssss

  • Hi guys,

    Thanks for the support and interest. CAN is indeed the preferred method of communication. It's a differential signal very resilient to interference and you can easily hook up 8 controllers with the given bitrate and I think it's a great opportunity to think about new connectors, I've seen servo connectors fail too many times.

    On the new version I have power in and phases coming out at the same side, but I'm not sure that's the best way to hook this up yet. The way how the FETs are laid out have the biggest impact on what the board looks like. You have some that are rectangular, others look more like strips.

  • I too would back this. 

    A dumb question perhaps - would CAN not be a better option than I2C? My understanding is that if I2C does down then there is a high chance that everything breaks which would render the safety of a octa or hex pointless.

    A request if it is not too stupid - could some thought be given in allowing them to be daughter boards? I've got some ESCs which are like that (by accident?) where the input and output are on the edge, on the same side of the board as well as the cap and other input. 

    Having a "standard" like this would allow us to start removing a lot of wires from the rats nest where the baseplate of your UAV is also the main PDB etc.

This reply was deleted.