so my motor control is all working and quite good, but I’m trying to get very low velocity control to be smooth. It’s a 15 pole pair motor, and I’m using the AMS 5048A. One caveat, is that the ODrive encoder interpolator is not well suited to low velocity, so I knock the lowest 3 bits off the signal (as it’s pure noise) and have halved the encoder bandwidth to 500Hz, this performs much better. I also modified the current sense resistors to 0.01 Ohms, so the range is about 10Amps now, also much better.
I’ve worked through the steps from the forums with regards to anti-cogging, enter into closed loop position control, and run anti cogging and it just starts running away (does about 5 full revolutions in half a second) and then stops suddenly. It claims there is no valid anti cogging, and there are no errors. Looking at the implementation, I’m confused. I’ve tried with my pos/vel gains all divided by 10 and multiplied by 10, the outcome is the same in any case. I’m working off the fw 0.5.4 tag.
It feels to me that either the large pole pair motor or the absolute encoder do not play well with cogging, although I can’t see any reason in the code. It either seems that is has a predetermination of direction to which my magnetic encoder is not adhering, or that given it cannot achieve individual incremental CPR (it never will with such a noisey encoder). I would have thought the ‘direction’ from the encoder offset calibration to ensure the direction is not the issue…
Uhh, don’t knock the lower bits off, you need that for the observer to work properly. If you knock the noise off, you end up with a lot of hysteresis.
Hmm, what firmware version are you running? Absolute encoders are the best for anticogging, and the new(er) anticogging that’s present in 0.5.1 and beyond should only be asking for 0.1 degree accuracy. Additionally, anticogging does nothing but set input_pos so if it’s running away that’s very strange.
The interpolator doesn’t work well with white noise that’s high frequency, traditionally have used hysteresis filters and quadratic interpolation rather than the state space approach of ODrive, however that runs with a position loop direct feeding the torque, so not great for industrial applications. For now just need to proof of concept with this lovely ODrive ecosystem before doing our own hardware/software.
That aside, yes I agree my understanding of the cogging is just that! So I’m confused why it’s running away, when it works fine during normal operation (just coggy at low speed!). Guess I’ll just have to keep digging and see what I can’t learn.
if you have some more information about the interpolator / observer / filter and high frequency noise, we should have a separate discussion about it (feel free to join our Discord! )
Since you’re dealing with anticogging and absolute encoders, and you are building your own hardware anyway, the ODrive Pro may be appropriate for you. It has a built-in magnetic encoder (MA702 or similar) and a significantly more advanced (proprietary) anticogging algorithm. We’d have to do a batch with lower current shunts ofc, but that can be arranged for large enough orders Let me know if that’s something that interests you.
yeah, after my first runaway I followed that video line for line, same outcome. I erased my configuration and restarted just to make sure, same outcome, with all of my gains way up or down, same outcome, so it’s definitely something weird. I’ll let you know what I find as I debug further through code tweaks, as if it truly is just incrementing one position at a time, it should runaway slowly, whereas mine just takes off. I had it in circular position mode at one point, but couldn’t get it to move in that mode, so turned it off.
Will hop on the discord! I do feel there is room for improvement for ODrives ultra low velocity performance.
ok so just an update, after resetting things and looking a new and properly datalogging, I do indeed see anticogging is working, I think I thought it was not as when …config.cogging.calib_cogging = True was set, I waited a few minutes and saw no movement, however today with proper datalogging, I do indeed see it’s moving, but given it’s a high resolution encoder, it’s going to take a very very long time to finish one revolution, but I’ll wait it out and report back! The runaway it seems was something else not being happy, but if I try the calibration after a fresh boot and ensure input_mode == PASSTHROUGH, it’s now very slowly cycling through.
Encoder resolution doesn’t matter unless you’re on an old firmware. And if your firmware’s that old, you can’t save the anticogging map You can adjust the “velocity threshold” and “error threshold” to make it run quicker, or you can tweak your gains for it to work a bit better.
The Pro firmware doesn’t have this problem, the calibration is way smarter
if you have some more information about the interpolator / observer / filter and high frequency noise, we should have a separate discussion about it (feel free to join our Discord! 
)
Let me know if that’s something that interests you.
You can adjust the “velocity threshold” and “error threshold” to make it run quicker, or you can tweak your gains for it to work a bit better.