Was just wondering the exact same thing, and whether or not the information could be persisted over powercycles.
It persists in the RazorsEdge branch. Will be included in the next major firmware release.
When is it scheduled?
No hard schedule but we’re making progress testing
Can I help?
I can offer to reflash my odrive to your beta firmware and tell you if I encounter any issue. It’s a corexy design where position control is streamed to the odrive from Arduino mega over serial using the default ASCII protocol
That would be in Feb at best though
No idea about the status / current implementation of this feature and I still have to connect my first Odrive. So don’t shoot me when I’m completely off 
, I just respond to what I read in this thread…
I think to understand the whole anti-cog table is currently stored. But the data in it can be fitted with a couple of harmonics only very well already.
If memory is an issue and some additional computations don’t bother (/ and take roughly the same time) than one can reduce the table (for any encoder with any cpr) to 2 parameters per harmonic only. Does require an (order) FFT on the table though of course.
Looking at the graph from Madcowswe with the fitted data it feels like little error would be made?
You are almost certainly right, it would take just a few terms, and this may iron out transients during measurement that should not be part of the anticogging. It could also make interpolation much better where the encoder resolution is bigger than the current table length, and save quite a bit of memory.
But it is not implemented that way. Feel free to suggest an implementation 
Cool @towen, my first not so stupid / noob remark on this forum ;-). I thought that writing the post would be a suggestion for implementation actually… haha.
But you mean on Github probably? My Pi is yet to arrive but once set I want to have a look at the second order filter on the Step/Dir code anyways as it’s not completely clear to me what this filter is and how it is implemented. So by then I’ll make sure to also request the implementation above.
I want to ask anyways where I can read more on the details of the software implementation. Where do you get all this knowledge; from the code itself?
First of all, thank you very much for this great feature. Anti-cogging calibration improves the performance significantly.
However, a problem has arisen during our tests. The calibration leads to a directional torque offset. After calibration, a higher torque is applied along the calibration direction than in the opposite direction for the same torque/current setpoint.
Without having an exact idea of how the algorithm works, I think the reason for our problem is that the current needed to turn the motors during calibration is not deducted for the cogging correction table.
We use the ODrive 150kv motors with the current firmware version 0.5.1. For the calibration to work we are using the following parameters
pos_gain = 70
vel_integrator = 1,5
calib_pos_threshold = 3
calib_vel threshold = 5
Is it possible to change the direction of the calibration or to normalize the correction table so that over one revolution the correction factor remains 0 on average.
1 Like
Normally, you would calibrate in both directions a number of times (with the same number of runs forward as back) and then co-average all of the results, so that any friction is cancelled out, and any random measurement errors are reduced.
ODrive only does a single pass, in one direction. So if your motor has any static drag torque, this will be seen in the calibration as a directional torque offset, which is not desirable.
I did try ages ago to make a version that does what I want, but it just borked the calibration process completely, and I gave up. Maybe one of the devs has a better idea of how to do it.
2 Likes
Yeah we should really add the reverse calibration…
2 Likes
Yeah - add my vote for bidirectional cogging calibration. There is a torque bias in the positive direction right now - reasonably significant for fine torque control operations. (Pos and Vel control look great, though!)
3 Likes