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?

Views: 12675


T3
Comment by Richard Boyhan on October 22, 2014 at 7:27am

Very cool idea, but as with all things, price is king.  Any ideas on how much they will cost?

Comment by David Locascio on October 22, 2014 at 9:50am

Gerard -

Really cool! I think crowdfunding is a great idea. Definitely post this some other places as well. You could also look at partnering with a manufacturer (like 3DR) for optimal integration, since those features aren't useful unless the FC can utilize them.

Comment by Andreas Gazis on October 22, 2014 at 10:47am

Would I fund it? Yes, because it sounds cool. Would I buy it? Cost is king. How much?

Comment by Jure M on October 22, 2014 at 11:13am

Interesting, I have been working on something similar for last month or so:

- Freescale's DSP for controll

- opto input for PWM

- CAN

- TTL RS232

- support for analog hall sensor input

- FOC control

- 300A MOSFETs

- Driver with integrated protection for MOSFETs

- Voltage up to 50V, 60V max. so could use 12S

- Automotive grade components

size is 100mm x 50mm on a double layered board, with four layers could probably get a few mm less.

By staggering, you can introduce a situation where the bell of the motor is alway under torque (no deadspots between magnets)

With traditional trapezoidal control you divide electrical turn into six steps and consequently you get pulsating torque. With FOC, you are always sensing position of the rotor and setting current in such a way that there is always required torque on the rotor, so the motor runs smoother - no deadspots.

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.

Car manufacturers are using CAN for communication between different subsystems. I see no reason to reinvent the wheel, use protocol like CANOpen and slap it on every piece of electronics. Additional cost is negligible, benefits (three wires that connect every piece of electronics to AP) certanly worth it.

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 FOC you can drive motor in generator mode so you dont have to waste braking energy as heat and you can brake with same torque as you accelerate the motor.

Comment by Michael Ciurescu on October 22, 2014 at 11:24am

AR Drone is doing something like this... it has feedback from the ESCs, and if the drone hits something, all 4 motors stop and the drone just drops. This is nice in some situations, but not others...

Comment by FRANCIS NELSON HENDERSON on October 22, 2014 at 12:42pm

Planes need ESC RPM & Power feedback too.  Plane autopilots need to know motor RPM and Power when flying the plane (takeoff-landing-cruise) and also when analyzing the air frame performance (Lift to drag ratio). The airplane cannot be properly controlled without this feedback.

Recommend using the Pixhawk CAN bus interface.  CAN bus is better suited than I2C for ESC feedback because it's more immune.to electrical noise.  Especially for new advanced ESC designs the correct bus (CAN) should be chosen.

My twin motor plane has two 80 amp ESC's.  I'd buy your product.  Likely, I'd also help fund your "Kick starter" project.

Comment by Jay Bryon on October 22, 2014 at 6:08pm

This sounds like a great project, I might suggest going to an alternate crowdfunding platform like Indiegogo.  Most folks don't care which you use, Dragon innovations is another one that might be appropriate.  

I can't ethically use kickstarter which is a real bummer, because of their business arrangement with Amazon.  

Comment by Austin Suhler on October 23, 2014 at 10:10am

Really impressive work! This could increase efficiency and safety massively, which is everything I've been looking for for a very long time from speed controllers. If you ever make a kickstarter, make a post and let me know! I have a lot of people and groups that would love to have these. I run a research lab at my school in an area with a lot of very restricted and controlled airspace, and reliability and problem detection have been big concerns with the people we have to get approval from, and having failure data would put a lot of people at ease.

For interfacing, I can think of a few things. The most immediate would be I2C with a central board that combines all streams into one stream, similar to PPM, or a CAN bus with something similar. Do you have something figured out? Keep going, this is great work?

Comment by Michael Link on October 24, 2014 at 3:46am

I hope you realize how revolutionary your design concept is. We are still in the early days of developing these aircraft, and your contribution will do much to move things forward.

Could you estimate what the final physical dimensions of the board might be? Thanks, and congratulations. 

Comment by Gil Rosenthal on October 25, 2014 at 2:16am

Hi Gerard,

Seems like this thread is providing you with much encouragement & points for consideration!

Coming back to the topic after several days, these sort of "obvious" extras crossed my

mind:

A. As you are striving for informational feedback from the ESC back to the AP

    (so as to actually monitor what the ESC is telling the motor to do) - why not

    further the reach and allow for actual motor RPM monitoring from the motor

    itself?

    I can think of two basic methods involving monitoring the actual spin of the motor bell:

     -  ElectroMagnetically  (like the little light on the Kirby vacuum cleaner)

     - Optically (as used on old high end Vinyl record turntables)

     I personally think the optical path is easier to achieve, using black-&-white striped tape taped as a

     closed ring around the motor bell, which will be "read" by a small optical sensor/resistor.

     Information regarding the actual motor bell diameter will have to be input somewhere in the

     processing environment, including initial ESC/Optical reader calibration, but now you will

     have a complete power-drive monitoring and feedback setup.

B.  The second extra is kind of dumb, but, I believe these ESC do not include a BEC circuit,

      and shouldn't either.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service