Hi, I tried to set up my Odrive 3.5 48V with my motor, but I can’t get the internal ABI encoder’s offset calibration to work (encoder.is_ready=False)
Motor calibration and index search works (motor.is_calibrated=true, use_index=True, index_found=True), but I always get encoder.error = ERROR_CPR_OUT_OF_RANGE. I understand this means that given the motor and encoder configurations, encoder counts don’t match with electrical motor rotation.
Counts per rotation are 2500 ppr *4 => cpr = 10000. I verified this from the motor’s datasheet and from manually turning the motor and watching the pulse count reported with odrivetool.
I verified the number of motor pole pairs to be 8 via this method.
I also unmounted the attached 1:25 worm gearbox, but it didn’t help.
The encoder is built-in, so I cannot re-align if that was really the cause (which I doubt since manual turning shows correct counts).
I tried calib_range = 0.05 and calibration_current = 30 as suggested in Encoder error 0x0002 questions
I even built and flashed new firmware from the Connect Hall and incremental encoder topic where hall sensor is used as index pulse. But is has the same ERROR_CPR_OUT_OF_RANGE problem.
Is there anything else I can set or try to make this work?
Can you link to the motor datasheet? So you used a bench power supply over two wires with third disconnected and felt 8 detent positions per revolution? Do you think your counting could have been off by one? 7 pole pairs is a common value.
So you used a bench power supply over two wires with third disconnected and felt 8 detent positions per revolution?
Yes I used a Lab power supply. I tried with 800mA, but at 2A it was really distinct. I did try to set 7 pole pairs (and 16), but it had the same result.
What I observed is that during the offset search the motor doesn’t rotate continuously, but jerks back a little in a cyclic way (maybe after each electrical revolution?). Would that pose a problem? Any way to fix that?
Yes that’s a problem. It likely means that phase B or phase C is disconnected. Check your phase wiring to the ODrive. If that doesn’t reveal anything, try disconnecting the motor and measuring the 3 phase pairs with a multimeter: they should have the same value.
The thing is that index search and sensorless operation work well without any jerking. The motor runs well with a Vesc controller, both via hall and ABI.
For comparison, here is the motor configuration XML that the Vesc uses. I don’t think that all of those fields are used, e.g. it says 14 motor poles. (But as I said earlier, I tried just setting 7 pole pairs and got the same error)
The VESC measured 10 mohm, and ODrive measured 34 mohm. Someone is wrong, or they are not measuring the same things.
Hm I don’t see why there should be jerking on encoder calibration but not index search. Can you upload a video showing index search, and showing the encoder offset calibration? Also let us know what firmware version you are using.
Because lalten was not here, we tried to continue investigate the issue. After looking into it, we got smoother offset calibration movement by simply increasing the allowed current.
But we now found out, that on the one hand, the index search fails for us (no error code, but every time different location). Furthermore, the offset calibration sill says an error (makes sense).
Strange is, that when we manually turn the motor eaxtly 1 round, we get a nice plot of exactly 10k steps. But when we do the plot while the ecoder offset or index search is done, we get way more steps. This is really weired.
In the linked gist you can see our script and the plots.
Important to know is, that the index search and offset search both took about 0.9 real turns (but not 5 like it seems on the plot).
We use the current branch of https://github.com/madcowswe/ODrive/tree/preroll, although we actually do not use the index signal of a hall sensor, but the index signal of the encoder built in. We also validated the index signal of the encoder with an oszi, which is normally low but high on a reproducible position.
using lib at /tmp/ODrive/tools/odrive/__init__.py
Finding an odrive...
Calibrating motor {}...
Checking motor {} direction...
checking for index
count in cpr 9978
shadow count -22
checking for encoder offset
Axis Error at : 0x100
OFFSET CALIB FAILED
After index search, shadow is e.g. -22, but count_in_cpr is 9989. This line mentioned above might lead to a wrong index offset cound, because the acutal encoder count is never reset, only after the first pulse, but then we add in our case 9989 to many pulses…
9978, which is shown in your paste, is the equivalent of -22 if you have a 10000 cpr encoder. In a single revolution, the motor goes from 0 to 9999. Then in the next count, it wraps back around to 0.
@Wetmelon. Thanks for your response. We already know that, thats also totally fine. The above was only to hilight a potential bug in the firmware. There, it makes a difference if you set the shadow_count to 9989 or almost zero on the next encoder update (becaue then the diff of current count - last shadow count is used to increment the count_in_cpr)
But our main question is:
When turning manually and plotting encoder ticks, we get for 360 degrees physically turning 10.000 ticks
Why does the index search after turning about 360degrees physically plot that it got about 50.000 ticks when it only should be 10.000?
Why does the index search successfully finish, but every time on a different position? (We validated that the Index signal is working correctly and only sending a signal at the excat same physical position the same time, therefore it seems the software/board does register somethign else)
The two above points would explain, why the encoder offset always fails, because we every time count a seemingly random number of encoder ticks (encoder is A/B signal and was verified to work when motor was turned by hand)
Andy ideas? Especially why during index search the encoder count is way off?
We gave up on integrated ABI encoders for now and switched to hall sensors (both are integrated into the motor). Initially this also didn’t work (ERROR_CPR_OUT_OF_RANGE), but increasing encoder.config.calib_range to 0.04 did the trick.
Now that both motors are spinning we have a new problem, but I will open a new thread for this.
Curious. I still don’t understand why you’re having all sorts of issues with the ABI encoders. You may just have a lot of electronic noise being picked up when the drives are active, especially if the encoders have very weak drive outputs. It looks like they actually use differential outputs for the encoder - you may want to try my PCBs here designed to convert from differential to single-ended output https://github.com/Wetmelon/Differential-Encoder-Adapter (admittedly untested)
Where are you located? If you’re near Stuttgart, Germany I may be able to drop by to help.
Aha! So depending on how the differential output works, it may not be driving the ODrive inputs correctly and as soon as you turn on the motor drivers they start triggering. I strongly recommend using the differential adapters in this case.
Why would you connect the unused differential encoder OUTPUTS to ground?
Depending on the specs of your encoder, these are likely being driven high and low as the encoder moves. Any time these signals are high, this is shorting the output driver. Not at all surprised you have issues.
At the very least leave them floating, better yet is to use a differential adapter as Wetmelon suggested.
I expected the output to be floating if I left the inverted ones unconnected. It did work with the inverted signals connected to ground, but it also works when they’re left floating. So I left them floating in the end
Hello
I can observe the same behaviour in my setup while offset search. The motor does not run smoothly and returns the error: cpr out of range. Index search worked so far. I use an incremental encoder with 8192 cpr and t-motor u13 85kv. I checked the wiring of my phases of my motor and my encoder. Have you solved the issue yet?
I could increase the calibration range of the encoder but I would need to increase it to 0.9. That seems to me pretty high. The offset is not failing anymore but still the motor does not run smoothly in the offset search.
