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.
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.