Torque Ripple Characterization and Position/Impedance Control

I promised more science, so here it is.  I took some measurements of my motor's torque ripple  - its variation in torque with rotor position - at different current levels, to see how bad the ripple is, how easy it would be to compensate, and get a sense for how well my motor control is working.

The basic idea for this experiment was apply constant current to the q axis, and measure the torque out of the motor as a function of rotor position by slowly rotating the rotor through a single mechanical rotation.

The setup, from left to right:
Indexing head, a rewound 80-100 motor acting as a shaft, an S. Himmelstein rotary torque transducer, my Multistar Elite motor, and an optical encoder.

At the center of this setup is the the in-progress motor dynamometer I've slowly been working on, which will get documented in its own set of posts later.  The absorber (the 80-100 sized motor) is unused in this setup, and just acting like a shaft between the torque transducer and the indexing head.  The indexing head was used to slowly rotate the rotor.

I made an ER-32 spindle for the torque transducer, for ease of coupling to arbitrary motor shafts.  For these measurements, I used my test-motor setup with optical encoder, because coupling my motor module  pre-gearbox would have been difficult.

Here's the data out of the setup.  Turned out surprisingly well, I think.  Cogging torque shows some ripple at 2x electrical frequency as well as a higher frequency component.  Total cogging amplitude is plus or minus .025 N-m.  Bumping up the Q-amps, overall amplitude of torque ripple doesn't change too much over cogging torque, but becomes noticeably spikier.   I think some cogging torque compensation (which should be easy to implement via a  lookup table) would smooth things out pretty effectively.  But that's an exercise for a later date.  Straight lines in the plots are sections where I'm missing part of a rotation.

For the higher-current tests, I pointed a big fan at my motor and inverter setup.  Thanks to the wonders of modern FETs, the wires going to the motor were the hottest part of the setup at 24 amps, followed by the electrolytic capacitors, then the motor itself.

I wrapped some position and impedance control around my FOC scheme.  For the sake of running robots, high performance position control isn't particularly desireable - instead you often want to control leg stiffness and damping, so the position control is just a PD controller.  The proportional term corresponds to spring-stiffness of the joint, while the derivative corresponds to damping (both ignoring rotor inertia).  Here's what some different levels of springiness and damping look like:

Getting good damping performance is dependent on good velocity measurement, which is not trivial.  The gist of the problem is that differentiating your position signal sucks.  By the time you can filter the differentiated signal enough to have a nice looking velocity, the phase lag caused by the filter ruins your signal.  Fortunately, the MA700 sensor I'm using for position sensing has an encoder output as well as an absolute position output.  I'm able to use the encoder output to my advantage for velocity measurement.  By configuring one timer on the STM32F4 in encoder mode to keep track of encoder count, and then configuring another free-running timer as a slave which resets whenever the count changes, I'm able to automatically capture the time between encoder edges.  This gives a value inversely proportional to the motor speed, which gives good results for velocity measurement when combined with some logic to handle the zero-speed case where the count isn't changing.

With dumb differentiation (at my encoder resolution and sample rate), here's what a velocity output would look like.  Most of the time velocity is zero (because encoder position doesn't change during one sample period), and for samples where the value has changed, the velocity is 1 encoder line width divided by the sample period.  You can try to filter this signal, but the results are not at all satisfactory.

With the encoder period measuring scheme, here's what velocity estimate looks like, both using the raw period value and with some simple 1st order extrapolation to estimate between edges.  Much better.

It's a simple concept, but took about 4 days of staring at the STM32F4 reference and ST forum to figure out how to get this implemented natively.  And now that I have this code, I can stick it on my closed-loop subwoofer for improved performance there.

Next step is to build up another motor module, and cram two of these into a 2 degree of freedom leg.  And go copy and paste my blog into a latex document write my thesis, which is due in three weeks....