If the calibration is done with a drivetrain attached (in my case belt driven linear bearings) then this may lead to any stiction in the system also influencing the calibration curve and so give undesired results. Recommended to do calibration without anything attached to the motor.
Agreed.
With anti-cogging turned off the motor will be stable (not vibrate) at any position when the appropriate gains are set.
Your PID just seems to be tuned wrong. Increase the Kd term and decrease Ki?
So the way it works now is that it uses the current encoder position to do the table lookup for cogging torque compensation, effectively adding terms in the feedback path, and as such it can have effects on the stability. Really what we should be doing is using the position setpoint to look up in the table, restricting the cogging compensation to be in the feed-forward path only. I put a task in the roadmap about it.
@madcowswe have you seen the CUI AMT20 encoders? 4096 position absolute and not that expensive. If I’ve understood correctly they are absolute from power on. There is an incremental and index output but I believe that’s just an optional extra. Absolute position is via 12 bit SPI message.
These would be ideal once the startup procedure and anticogging lookup can be kept in non-volatile memory. The ODrive could be fired up with whatever gubbins it is attached to and deliver commutated, anti-cogged torque instantly with no startup proc
They are available on mouser.
Re your comment on using set point for anti-cogging lookup table, obviously it would need to keep using the encoder in torque command mode, so please don’t remove that option!
Yes I saw those, @aksatshah is actually working on a driver to read the absolute position at startup, and run on incremental from then on. They are a fair bit more expensive than the AMT10 series, but if doing the start-dance to find the index pulse is not acceptable, then they seem like a good option.
Yes I see the point. I think we can use the position setpoint during position control mode, and the encoder position for lookup in velocity and current control modes.
Yep correct you are! I am working on that and I believe its all working although I’ve had to change my rig so cant fully test it now. I had some issues with noise on the SPI line but I was only using it to get the absolute position at power on and then using the incremental output for the rest. It also depends how fast you want to read the data. I believe I was only getting the position at a rate of 1kHz but maybe this can be improved with some extra work on overlapping commands. The biggest problem is the encoder isnt always ready to transmit the absolute position straight away and so usually sends 2-3 nop commands and you have to wait, but with overlapping commands we should be able to remove this issue.
Let me know how it goes if you do use it and if you have any problems etc.
This work is awesome. I’m about to start developing for Hangprinter usage, and anti-cogging will make a big difference for that use case.
@tobbelobb Hit me up on the ODrive Discord when you are about to start working with this. The anti-cogging feature is just a proof of concept at the moment, and not really a full feature. So you may need some guidance to get it to run properly. If it turns out it makes a big difference for the hangprinter, we can put some priority in finishing the feature to make it easier to use.
Does the latest main branch of the firmware support the ability to store the anti-cogging config table?
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.
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.
Yeah we should really add the reverse calibration…
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!)