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

  • Jure: That IC is what I ended up using now I think, which then would also allow voltages up to 12S. I have 4W shunts and 0.004 to improve measurement results, because the voltage over the shunt at 20A is only 20mV.

    NPQ: 20A =~ 0.4W . And indeed, the footprint of the shunts are relatively large compared to other components.

    The board dimensions of the newest board are 75mmx18mm, as the intention is to install these on normal size quads, preferably inside the arms outside of view.

  • Best is to use a shunt and operational amplifier. You can get IC with six integrated MOSFET drivers, two opamps for current measurement and a buck converter that can handle input voltages up to 60V. You use 0.001 Ohm shunt rated for 7W power so you can have ~80A RMS phase currents. Or you can go with 0.0005 Ohm shunt and double that.

  • Best is to use a shunt and operational amplifier. You can get IC with six integrated MOSFET drivers, two opamps for current measurement and a buck converter that can handle input voltages up to 60V. You use 0.001 Ohm shunt rated for 7W power so you can have ~80A RMS phase currents. Or you can go with 0.0005 Ohm shunt and double that.

  • From what I was taught in school shunt means a shunt resistor from power to ground, wouldn't that short out the battery? Do you mean series?

    I though people use a small value series resistor, and measure the voltage across it using the micro controller's onboard ADC. Although at 0.1 Ohm, 20A would produce 0.2W, which is still quite sizable give how small the ESC PCB area and associated copper volume is...

  • The easiest method to measure current is to use a shunt, which usually ends up being a simple resistor, or for the adventurous types a carefully calculated length of PCB trace. Two of those in parallel to measure the currents on two phases. The total current through all phases is always 0, so you can calculate the third. CAN is getting more common as time goes along, the uavcan project is an opensource project that's quite far advanced and it makes sense to follow a common pattern, so we don't end up with hardwares only capable to work on one single platform. The px4esc is another ESC that should be capable of feeding back this kind of information, there's a video where you can see it in action.

  • Just coming across this project, sounds very interesting.

    Can I ask what you are planning to use to measure current?

    And yes I would be interested in it, although I have no idea how to talk to a CAN ESC right now, will have to learn. I have a Pixhawk.

  • Tim, most hardware is not compatible exactly because it can't communicate data back to the AP. For communication, I think it's best to use CAN for a couple of reasons; it handles the bitrate, doesn't need to share a common ground with the AP and has an addressing scheme. For can you'd need a transceiver chip or get a cpu that has this built in.

    If FOC is to be used, there need to be at least two current sensors measuring the current through 2 phases.

    I've gone through this devboard and two prototypes in the meantime and have now purchased six esc's for some more serious testing. No plans to opensource this at the moment.

  • Gerard, are the beta design files for this board available on github or similar? I'm wondering if it would be feasible to achieve most of the design objectives you discuss on current hardware.

    Most SimonK ESCs can be updated through the PWM cable, and so a software fix would be preferable to a whole new hardware system. In the future, I think you hardware could become the status quo, but people are going to want to update their current software before buying a new system.

    I want to develop a system to transfer the control data, RPM, Current, Battery, etc. through the same 3-wire connection used by standard ESCs. I think this will require a custom serial protocol to handle 2-way communication over a single data wire. It needs to handle 400hz speed data, and by-request (2hz) upstream data packets with temperature, current, voltage, RPM, overload etc.

    Thoughts?

  • mikrocopters ESC, sends back RPM and also temperature of the motors. Info from a couple of sensors to send back to the autopilot would be great to improve reliability.
  • 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.

This reply was deleted.