Very impressive! I love to see this kind of thing on HN. I scanned through your code a bit on mobile, and here are a few quick suggestions:
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.
Cheers!
Fair point about the quality of the current measurement. I probably take that for granted because I usually don't have to hit low cost targets! But that being said, a flux observer is inherently doing some kind of integration which tends to add a filtering effect. So noisy current sensors may still give you OK results, especially if comparing FOC with noisy sensors vs DB-DTFC with noisy sensors.
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!
3) is interesting. Sensorless operation is common for running motors, but usually doesn't sense position when the motor is stopped, or being moved by external forces.
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.[1] 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 [2] 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.[3] 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.
It is not easy per-se, and yes it is used in many dissertations, but most of the limitations up to now have been more related to the performance required to implement a demodulator that runs at high enough frequencies in a low cost microcontroller or FPGA. This is becoming less of a problem with more powerful chips. I don't know if I'd call it a mainstream technique, but it is widely used in high performance IPM motor drives for servo applications.
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.
How high a frequency do you have to inject for sensing? Much higher than the power chopping frequency, presumably. Megahertz? Harmonics from the PWM drive are going to interfere. I can see why separating signal from noise is a problem, and why mating a motor and a controller isn't going to be plug and play.
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.[1] 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.
The high freq signal has to be lower than the switching frequency - otherwise you end up with harmonic interference from the PWM like you mentioned. For high performance servo control in the 5-200kW range with switching frequencies up to 20kHz I typically see high frequency injection in the 1-4kHz range. This is high enough to produce negligible torque ripple and minimal estimation error, but low enough to be synthesizable without an ultra high PWM frequency. Of course for smaller systems switching at 100s of kHz or even MHz a higher high frequency signal could be injected.
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.
Can someone more familiar with embedded design explain a bit more on this? Can this really turn cheap motors into industrial level motors suitable for hobbyists?
I'm on a cell phone, so I'll be brief, but can add more detail later. I've been doing motor drivers and embedded work (software and electronics) for robotics for a while, and did work on motor driver ICs before that, so this is kind of my wheelhouse!
Briefly: I can tell you that the electronics and software are only a few parts of the overall equation here.
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.
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."
----
The hardware is based on a STM32F405RGT6[1] driving two TI DRV8301 brushless motor controller chips[2] and a bunch of MOSFETs to handle the power switching. I/O is a USB, CAN with driver chip, and SPI unbuffered on headers.
It packs a lot of information in. STM32F4 is ST Micro's range of high-performance ARM Cortex-M4 microcontrollers with FPU, STM32F405 is a particular family of devices in that range differing mainly in package and memory size, R specifies that it's the 64-pin variant, G indicates that it's the version with 1024KB of flash, T is the LQFP package, and 6 is for -40 to 85 °C temperature range. Most of this is shared across the entire STM32 range of devices.
Historically, hobbyists have chosen stepping motors because they can be controlled with a fairly simplistic controller, and there are lots of solutions out there... check out some of the step motor drive boards at Pololu Electronics. But stepping motors have limitations, namely speed and torque per unit motor size. Note that as a hobbyist, I'm still living in the stepper motor world, so I'm interested in this project.
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.
Stepper speed can be quite impressive with the right driver, still not up to servo levels but much higher than you might think possible, it is all about getting to and past the resonance points in the motor and the whole dynamic assembly. Once you can do that steppers can run quite fast.
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.
Pretty much this! People definitely do work some black magic here. (See for a simple example microstepping drivers, where the current profile isn't sinusoidal, but specfically tuned to match the motor profile).
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!
I do motor design and research for a robotics and automation firm. In my experience, steppers often can provide significantly higher torque than a similarly sized BLDC. Their reputation comes from their use in low cost applications, where they are run open-loop and so the load torque must be kept well below what the motor is actually capable of providing, to avoid missing steps. Close the loop with an encoder and stepper performance is more like a geared BLDC. It was a big surprise to me when I first noticed this, because it didn't align with the reputation that stepper motors had.
ShopBots, the big CNC routers, use big steppers with closed loop control, and get considerable power and speed out of a small motor without missing steps. Tormach CNC mills are stepper-driven without feedback; the motor is powerful enough and geared down enough that missing steps isn't a problem.
Steppers do consume full power when not moving, of course, so they're not favored for battery powered systems.
Shopbot has a closed loop stepper on some models [1], but Tormach says they don't.[2] Tormach just has a big enough stepper and enough gear reduction to avoid missed steps by brute force.
It's parametric, once you know the math it will transfer. There are (or were, not sure if they are still in use) 5 and 7 phase stepper motors to help combat these resonance problems.
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.
Yeah, brushless is definitely the way to go for efficiency, and good smooth motion. Stepper for an e-bike or washing machine (Not a BLDC either, but...) would be nuts, and in general steppers are really for cheap semi-decent control, not for anything where precision is really needed.
My colleague had a motor from a newer washing machine out on his desk, and it did appear to be a BLDC. Alternating magnets with three phases of coils as you'd expect. Driven from rectified 120V AC!
Very cool! So I should perhaps qualify my comment to say that some newer appliances may be moving that way. (I've done work on motor drives for consumer electronics, robots and some industrial devices in the semiconductor world...no appliances, but it's cool to hear some of them are going that way!)
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 [1] and built brushless linear motors.
Sure, the issue with brushless motors isn't the motor, it's the encoder.
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.
That's a bit of an over simplification, but for a hobbyist application, sure.
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!
I suspect there's no free lunch here. If they are designed for hobby r/c aircraft, they are designed for shorter runs with lots of free prop-driven fan cooling. Not for sustained runs without a prop cooling it.
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.
Cooling can be an issue if you drive them near their rated power without adequate cooling. And absolutely they won't have the same quality of construction as true industrial devices. However they are sufficiently powerful to be useful and cost effective at continuous duty levels below their max rated power.
One thing to keep in mind is that for many robotics applications, the duty cycle for high torque (i.e. acceleration) is often quite low. So they may still run fairly cool.
Most industrial motors are also 'cheap', but controlling them is expensive.
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.
"Losing a step" makes me think you are thinking about stepper motors, which can be a problem, but for brushless motors it's a bit more complicated than that, since we don't drive them in the same stepwise fashion.
No, they are not, servos simply do not step, and whatever pulse there is is PWM to control the torque without overheating the driver in an analogue domain.
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.
I know servos don't step, but doesn't the decoder 'count' steps?
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!
Encoders (not decoders) typically contain a glass disc which contains two 90 degree out-of-phase sinusoidal patterns of light/dark, these are digitized to some arbitrary precision to give you a number of 'steps' around one revolution of the encoder axis. The 90 degree out-of-phase signal is used to be able to determine the direction of motion.
So the term "losing a step" is used on stepper motors, which can be mechanically overpowered to lose positioning. Encoders however will typically always measure the position accurately even if you overcome motor torque and disturb the motor. So in that sense "lose a step" simply does not apply here. Steppers can lose positioning by being pushed beyond their holding torque, while brushless servos will not lose their positioning in the same situation.
Hmmm, not sure I follow you there, care to explain?
(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.))
I have been following this project since it was published on hackaday.io. Congratulations to Oskar and the rest of the contributors for getting it to at least alpha production.
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.
Yes, somebody should scan all the links on YC for autoplaying videos and ads, rate the severity and provide the results via an API so that one can use a greasemobkeyscript/browser extension to highlight all the shitty links.
When you mention BLHeli, don't forget BLHeli_S, and (soon) BLHeli_32 which is a re-implementation written in C (before it was assembler) built to run on 32-bit hardware (before it was 8-bit), but sadly the project is closed source :-(
Not more expensive than high power servo-motors! Hard to get low-RPM and position control from most drone motor controllers for robotics. I think it's mostly just different use-cases :)
The website mentions "supports power regeneration" but I couldn't find any reference to it inside the code. Can someone who knows about this explain how it works, both in the hardware and in the software? I'm super curious to be honest, I know some basic electronics but have never designed a circuit this complex before.
The power electronics are built using MOSFET half-bridges, which naturally support the ability to flow current in either direction. This allows current to flow from battery to motor or from motor to battery (regeneration).
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.
Ah, so the circuit with the MOSFET bridges is symmetric and can convert in both directions, and the software is capable of making that happen. That makes sense, thank you for answering my question in a detailed manner.
As a clarification -- is "back EMF" related to the open-circuit voltage that the motor generates when it's forcibly spun?
So this product is still in development. Hence the hardware is ready for regeneration, but right now the firmware doesn't support it yet.
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.
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?
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.