I sure hope the ODrive staff and community do not get tired of helping me out! The error i am getting is ENCODER_ERROR_CPR_POLEPAIRS_MISMATCH. I am trying to use M1 (axis1) on the odrive using the same settings and configurations that M0 is using. The motors and encoders are both the same, turnigy aerodrive sk3’s and the encoders are AMT102-V’s set to 8192 cpr. I have tried doing the easy fixes already ie swapping cables and encoders. M0 runs through its calibration sequence no problem and M1 does not. M1 will rotate to the midpoint of the test and then stop and does not return to its original position. I have read the other two posts which mention ENCODER_ERROR_CPR_POLEPAIRS_MISMATCH and in one it is mentioned updating firmware worked which i did but to no avail and the other one it looked like someone bought a clone board which didnt work from the start. I have the 24V odrive Version 3.6 running the 5.1 release of the firmware not 5.1-dev.I tried looking for the error in the python programs in the odrive devel to see what might trigger that specific error but im also brand new to python so a lot of what i see outside of logic and basic math is foreign to me. Hopefully i have included enough info to help out, im continuing to troubleshoot and if i figure somthing out before there is another post i will be sure to revisit this post! Thanks in advance for the help!!
Maybe a dumb answer, but i am trying to help because i just now had the same problem: after setting CPR and Pole pairs, i needed to save configuration and reboot, otherwise i got the same mismatch error…
I’ll see if that works because I’ve been saving and rebooting but usually after a few changes maybe I accidently missed saving the pole pairs and cpr. Once I test that I’ll get back to you here.
Just as a quick sanity check for encoder operation, does odrv0.axis1.encoder.shadow_count change by roughly 8192 counts if you manually turn axis1 by 1 revolution by hand? shadow_count should change even without a calibrated motor or closed loop control working.
so i tried the save configuration and reboot again and no success still failing. which doesnt really surprise me because the integers i had set originally did save because i was able to print them and they output the correct number i had set.
that is a handy little command there! After running we can see that the encoder is counting and i just did it twice to see how close i could get it to 8192. and that physically was about 1 rotation as reflected by the shadow_count output.
that was the same on my odrive, nevertheless the changes weren’t taken into account until i rebootet. I am actually not the only one having experienced this “bug”.
Good luck with your search!
In my limited time between work and school i was gathering some more info about my problem and i think it comes down to the encoder offset. I tried going through some of the encoder documentation on this using the section called ‘Encoder with index signal.’ however when i try to run odrv0.axis1.requested_state = AXIS_STATE_ENCODER_INDEX_SEARCH it immediatley comes up with an axis_error_encoder_failed. But this error also confuses me because ive changed the physical encoder out with two others just to see if it was a device problem. I will continue trying to figure this one out and if i find out more i will report back in this discussion.
another weird detail, just ran the same process again and this time it rotated after i gave it the axis state (it did not rotate the first time) command but it comes up with the same cpr_polepairs_mismatch error
I have a very similar problem.
When I connect 5-pole pair motor, it works perfectly.
But when I connect an 11-pole pair motor it always ends up with such an error.
Isn’t there any limitation on the number of pole pairs?
No, there is no limit as such. But as you increase the pole-count, the effective encoder resolution reduces. If you have a low cpr encoder, this could be the problem.
The standard 8192 cpr encoder from the shop works for me with 11 pole-pair motors.
If you have a 1024 cpr encoder for example, then you will have 1024/21 = 48 counts per pole, so it becomes difficult to achieve the 5% precision required to pass calibration.
We’re getting these errors now instead of the CONTROL_DEADLINE_MISSED.
We’ve had odrv0.axis1.encoder.config.pre_calibrated = False and start with encoder_index_search and encoder_offset_calibration every time, is that wise?
You can only do that if there is no load on the motor at start-up. If you cannot disconnect the load, then encoder offset calibration will produce wrong results.
You could try increasing motor.config.calibration_current, but in general if you have a permanently attached load then you should be using either an index pulse or an absolute encoder.
I figured it out! For anyone else struggling with this issue:
I have a SK3 Aerodrive 5065 320 with a AMT 102 encoder. My theory is the encoder was not lined up enough with the motor when running through the calibration sequence and so would occasionally bind and skip.
I made a proper mounting system to attach the encoder to the motor and it worked perfectly.
Hi, guys! I’m so excited that I have figured it out ! My method is enlarging the “motor_calibration_current”.
I can’t promise it works for everyone but it did work to me! Hope you all will solve this problem soon!
By the way, before I figured it out I had find a weird phenomenon that the rate of successful calibration is 50%, which means if motor calibrates successfully this time it absolutely fails the next time. So funny!
