The last week or so I’ve been looking into implementing a basic version of an anti-cogging / torque ripple suppression algorithm. If you’re not familiar with “cogging torque”, check out this short explanation (be sure to watch the video!).
I’m happy to announce a basic but functional anti-cogging algorithm has now been implemented in the Development Branch. Please help us test the feature and the branch!
The way it works is that it goes to each encoder position from 0 to ENCODER_CPR-1, and measures the holding torque required to maintain the position. It then uses that as a feedforward term in the control loop. The resulting map looks something like this (courtesy of @madcowswe) :
The results are pretty good. There’s some more things we can do to improve it, such as reverse-mapping, scaling the feedforward based on speed, better memory usage, etc, but it’s serviceable.
To enable anti-cogging, you wait until the motors have finished their startup calibration, then send the command “t” over USB. This enables the anti-cogging calibration, which will run for 5-10 minutes. You may find you need to greatly increase your position gain for this to work reasonably well. I use a
200.0f as a
pos_gain with N5065 motors, and it takes ~ 5 minutes to run the calibration. You do not need to keep the high gains when calibration is finished.
Note: The algorithm creates a large array of floats for each encoder, with length ENCODER_CPR. That means using a 600ppr encoder (2400 cpr), it uses 32 * 2400 / 8 = 9600 bytes, or ~ 5% of the RAM per motor. Thus I wouldn’t use TOO high of an encoder count when using Anti-cogging because you’ll quickly be using a significant portion of the RAM.