1) It looks like you are using field oriented control. This is used 99% of the time in industry, but if you really want high torque bandwidth you should check out alternate control techniques. My favorite is an up-and-coming algo developed at UW-Madison called Deadbeat Direct Torque and Flux Control (DB-DTFC when searching for papers). It uses an inverse motor model paired with rotor/stator flux estimators to produce a deadbeat (one timestep later) torque and flux response. I have heard apocryphal stories of people who implement DB-DTFC accidentally snapping motor shafts when they forget to limit the torque slew rate. It is a very high performance algorithm, and beats FOC and DTC hands down at the cost of a bit more complexity.
2) If you are sticking with FOC for now, you can make a few quick improvements that will help a lot. First add qd-axis decoupling on you current loop commands (may have missed them, but I didn't see them in your code). You will want reference frame speed ("omega") decoupling multiplied by current and the transient inductance of the machine, which undoes a lot of the cross coupling that causes issues at high speeds or fast changes in torque. Flux decoupling will help with integrator wind-up, and stator resistance decoupling also helps lessen integrator wind-up at low speeds.
3) Have you considered implementing a sensorless algorithm? It can be done with both FOC or DB-DTFC, although there are some constraints on changing your switching frequency on the fly. If you have a fixed switching frequency a common technique is to superimpose a high frequency carrier on top of your voltage commands and then demodulate the high frequency response in the currents. Since a BLDC has salient poles on the rotor, this technique lets you estimate speed even down to zero! Then you wouldn't need encoder/resolver feedback which would be especially nice for robotics projects.
4) If you really want to get all of the current out of those FETs check out discontinuous PWM strategies. This are especially helpful at low speeds when your applied voltage is low, and can lower your switching losses enough to give you an extra ~40% current rating.
Great work overall. The hardware looks really clean and well designed, and it is easy to tell you put a lot of thought and effort into the site and this project.
1. Thanks for the suggestion, I have DB-DTFC to my motor control theory bookmarks. There are a few reasons I am sticking to FOC for now. The main one is that it is, as you say, the more standard one used, and hence there is more material on it which makes it easier. The other reason is that I read that you need high quality current measurement to get a good flux estimate: if your flux estimators are not high bandwidth, you aren't getting the extra control bandwidth anyway, and there is no point. The ODrive is trying to be as inexpensive as possible, hence the current sensors have a fair bit of noise.
2. Yes the decoupling terms will be added soon, it is something that I know should be there but wasn't a priority to put in once the motor was up and running (there is a thousand of other tasks I have to do to get this product out). The control engineer in me won't rest until all the standard feedforward terms are there ;D
3. Yes, I actually implemented a sensorless estimator based on this paper: http://cas.ensmp.fr/~praly/Telechargement/Journaux/2010-IEEE...
It is a non-linear flux estimator, so it won't work at zero speed. I did look into the high frequency injection techniques as well, but haven't implemented any of them yet.
Right now there is no sensorless estimator in this instance of the code, and I don't think we will need one for the basic demos, since they will all require accurate enocder feedback anyway.
4. Okay, I'll look into it!
Thank you so much! I actually took the liberty of copying your reply over to the ODrive forums: https://discourse.odriverobotics.com/t/control-suggestions/5...
This is so that I can easier refer back to your excellent advice even once this HN topic fizzles out.
Ha, I am the same way with feedforward terms. No rest until the integrators don't budge under the largest command steps!
I will have to keep your site bookmarked. It is rare to see a high quality motor controller in this space. Most others I have seen are pretty underwhelming, so kudos on the cool project!
So if you put a carrier on the power signals, you can potentially sense position, even at zero speed? No need for even Hall sensors? There's a paper from 2001 on that. But it doesn't seem to be a mainstream technique. Are there problems with that approach? If it worked well, you'd expect to see it built into common motor control ICs by now. This paper  indicates some of the problems. Detecting the sensing signals in the presence of noise is reported to be hard, especially for small motors. It's a PhD thesis topic. Looking for info about this, I'm finding academic papers, but not IC data sheets.
It would sure be nice to have motors with full positional feedback and only 3 wires, instead of 16.
I think this technique isn't commonly used in lower performance applications because it is an additional cost both in performance (need a more powerful processor) and complexity.
The big problem with high freq injection is that it requires some kind of saliency on the rotor, which means this only works for interior permanent magnet machines and not induction or surface PM machines unless they are specially constructed. I guess I don't know enough about hobby brushless DC machines to know if they are IPM or SPM, but my guess was IPM because they can be cheaper to build for high speed designs and I know hobby BLDCs can spin at 10s of thousands of rpm. Perhaps someone with more hobbyist know-how can chime in.
For this application (robotics) I think the other typical problems with high freq injection are negligible. For example you need a well-defined switching frequency that stays out of the way of your high frequency carrier. Many inverters pull back on switching frequency at high loads in order to lower switching losses, but if you lower the switching frequency too much you won't have enough voltage bandwidth to synthesize the high frequency carrier required for the self-sensing algorithm. I don't think this would be a big deal for robotics applications.
Larger drone prop motors seem to be mostly permanent magnet brushless. Often the stator is on the inside, and the rotor is a rotating shell carrying permanent magnets that fits over the stator. 12 coils and 14 permanent magnets is a common configuration.
Other drone motors look more like standard motors, with an outside stator and an interior rotor. Some of those are definitely permanent magnet.
Here's a good overview. If you wanted to repurpose such motors for
industrial control, the main problem would be cooling. They're intended for
use with the prop blowing air through them, so they can dissipate much more
heat than most motor configurations. Slow speed, high-torque operation would
probably overheat them.
I suspect that this type of sensorless strategy will become more popular with the rise of GaN and SiC devices, but it is currently implemented with good results today using only standard Si IGBTs and MOSFETs.
Yes, this does look like (from the demo video results), a decent driver design, however quality of the motor DOES matter, and will eventually become a limiting factor if you are lookig for high precision or high power, as you start to run into things like torque digging, motor heating, etc. There are also little things in the driver design that can bite you if you aren't careful, but I'd need to look at the schematics to comment.
I'm not trying to crap on the project or designer. There was clearly some thought and care put into this! I just don't want people to expect magic, or to think that the only difference between an industrial servo and a hobbyist motor is the electronics. That said, you can get VERY far with good electronics and control software!
A hobbyist project will probably do just fine with something like this (or a motor driver reference design from the chip manufacturers), and by the time they run into limits of those designs and hobbyist motors, they'll probably have a pretty good idea of where they need to go as a next step!
I'll take a closer look at this design later, and update if anyone is interested.
Here are the documentation links to get you started:
v3.2 schematic: https://github.com/madcowswe/ODriveHardware/blob/master/v3/v...
PC config and analysis support: https://github.com/madcowswe/ODrive
FPGA: https://github.com/madcowswe/ODriveFPGA "... the FPGA logic and software that runs on the FPGA based ODrive. This is not currently in development, but may be resumed at some later date."
 High-performance foundation line, ARM Cortex-M4 core with DSP and FPU, 1 Mbyte Flash, 168 MHz CPU, ART Accelerator
 DRV8301 Three-Phase Gate Driver With Dual Current Shunt Amplifiers and Buck Regulator
You could just as well say STM32 or STM32F4 and that is pretty much 99.9% of the information you need to know :)
Brushless servo motors offer the potential for much higher torque and speed in a small package, but require a different form of electronic control, and the gist of this project is that such controls haven't been available for hobbyists. So it's a matter of finding a gap in the existing project / product space, and filling it.
Note that e-bikes use brushless servo motors, so somebody has done the math on what motor technology is most efficient. I also think these motors are in electric cars, and even appliances such as washing machines.
I will be reading with interest. I'll also start keeping an eye out for what kinds of motors are available.
As for "industrial level," I'd say that it's a matter of pushing machine speeds up to a level similar to what you might see in a factory. Often, with stepper motor driven gadgets, you accept the fact that your machine will take a long time to do anything, but who cares, it's a hobby.
On the industrial side, you very quickly run into the situation where your motor is no longer the limiting factor affecting speed and precision, but the design and assembly of the mechanism is.
As for torque, servos again have the edge, but there are pretty large steppers too (1" shaft...).
If you drive steppers with a standard H-bridge you will never get close to what that stepper can do, driving stepper motors to their potential is a black art where at some point during the operational domain you'll be taking energy out of the motor rather than putting it in in order to get past the resonance point. There are companies that specialize in such high speed drivers (Berger-Lahr and RTA for instance), they're not cheap and by the time you're done making this work you might as well install a servo system.
One place where I did see this used frequently is in certain consumer electronics, such as inkjet printers. (Ever wonder why companies like Allegro sell weird combos like a chip for driving 2 steppers, a DC motor and a Buck converter....this is why)...When you are shipping a million printers a year, you save pennies using the cheap actuator and fix it in the controls, but for most projects, yeah totally not worth the hassle!
Steppers do consume full power when not moving, of course, so they're not favored for battery powered systems.
You can take a copy of the spreadsheet and enter in your own motors that you find. Also do note there is a second tab on the sheet that lets you explore cycle times on trapezoidal trajectories.
There are caveats related to long term durability, but you said "for hobbyists" who I think are less concerned with that aspect. As far as up front performance the answer is yes. Others have explained the details so I'm just adding to the "yes" camp.
Brushless D.C. Motors are the way to go for robotics in many actuation situations for the near to medium term (next decade at least) and the lack of suitable
low cost controllers (this is "low cost") has been a major issue, so this product is excellent.
Source: am robotics engineer in Silicon Valley building my own brushless powered robot arm as a hobby and I'm an alpha contributor to the Odrive project. I've also designed my own brushless controllers  and built brushless linear motors.
The encoder is what "closes the loop" and allows you to get the accuracy you need. If you have a way to relate the position of the thing being controlled to the motor position, then you can use any motor.
So, it's a nice driver, but it doesn't make the encoder any cheaper.
You are absolutely right that the encoder is a BIG part of your system design, but the motor quality will make a difference. If you are doing something like a robotic arm, or slow speed motor control, you don't just care about encoder ticks, you also start caring about things like torque ripple in the motor if you want decent motion quality, regardless of how good your encoder is!
So, it would likely work, but have a shorter lifetime. The barrier to using them was having a low voltage / high current controller. This fills that gap.
So, not a bad idea, but there's almost surely a durability tradeoff. And maybe that's fine for a hobbyist cnc application.
There are two things that matter: accuracy and repeatability. Most of the time accuracy is not a problem. But repeatability is. For example when you move something heavy a motor can loose a step. When you don't know this the rest of the accurate moves are out of control.
That's why industrial controllers have good feedback systems. They know a step was performed. If not, you can act on it.
So it's more about control than about motors.
But cheap motors wear out faster.
And reliability. Making driver electronics that will live long term is not that simple, sudden stops and overload conditions are tricky to deal with in an effective way without risk to the attached electronics.
> They know a step was performed. If not, you can act on it.
Servo's don't 'step', current is applied to the motor in a continuously varying manner and the delta between the desired movement and the observed movement determines how that current will change over time.
This leads to all kinds of nasty side effects: overshoot, undershoot, runaway in case of a failing feedback mechanism and so on. Steppers are much simpler to interface to in principle (but to drive them at speed is remarkably hard due to all kinds of resonance issues) but much harder to get performance and reliability out of, almost all larger scale industrial control is done with servo motors tightly coupled to their driver electronics.
Edit: as other point out 'controlled' is not the best word here. Maybe 'positioned' would have been better.
There is no reference based on a 'step' or a 'pulse', there is only the desired position and the actual position and the difference between the two can be quite large, much larger than with a stepper which can by definition be at most one step ahead or behind or it is game over.
This gets very interesting once you start to combine servos on multiple axis and you want to limit your maximum error compared to some desired trajectory.
But I totaly agree with you, they are completely different. Maybe in this case it was not very clever to oversimplify the problem.
By the way: you point out what I think is great about this business. So much work has been done to control motors very accurate. It's amazing what CNC machines can do today. And also how software optimized motion paths (gcode). And now this hardware. Great stuff!
(Unless you are referring to block commutation of the BLDC phases, which can look sort of similar to step wise control, but I would rebut that in precision servos drives, we would also look at doing non stepwise commutation (sinusoidal, FOC, etc.))
Question: I could not find information on what kind of control modes are supported- position, velocity, current/force?
Aside: I have previously used another similar product: VESC, which was born as a driver for electric skateboard motors (Odrive was not available yet). I used two of them in current control mode with feedback from magnetic encoders. Since motor current is proportional to torque, it's quite useful control scheme if the motion equations of the system can be expressed in terms of force/torque (which most of them are, if you think about it).
One such example is car's accelerator pedal: it controls the torque exerted by motor, which exerts force against road, which makes mass to accelerate.
The acceleration in turn increases velocity of the car, which in turn changes the car's position.
While this looks obvious after one has thought about it, it actually means that the common linear control methods (e.g. PID) won't work optimally (if at all) if you try to control position by changing acceleration.
Coming soon will also be go-to commands which track 3-rd order polynomial position trajectories.
In regeneration the motor is actively slowing down the speed (creating negative torque) by pushing energy into the battery. This is achieved in software by regulating a "negative" current, which causes the inverter to produce a voltage that is lower on average than the back EMF generated by the motor. Because the motor is effectively at a higher voltage than the inverter in this condition, current will flow from high voltage to low voltage and therefore flows back through the MOSFETs (and MOSFET body diodes) into the battery.
This is a bit of an over-simplification as brushless DC motors are actually excited by an AC waveform so the current is constantly reversing each half cycle, but the principle remains the same.
As a clarification -- is "back EMF" related to the open-circuit voltage that the motor generates when it's forcibly spun?
In principle it works by just putting a high charge current capable battery on the DC bus, and simply dumping the regeneration current onto the bus, and the battery will eat it, as the bus voltage rises.
The "Architecture" heading, a bit down on this page explains more: https://hackaday.io/project/11583-odrive-high-performance-mo...
Do you know how this (dumping regenerative current on the supply bus) would work if there are multiple motor channels on the same bus that are simultaneously regenerating at the same time?