I’m using a ODrive 3.6-12v modified with smaller shunt resistors for low current applications [yes, i re-flashed the board with appropriate shunt resistor values and everything worked fine with odrivetool 4.12]. Now, using odrivetool 5.1, i have a strange issue where i give a position setpoint (let’s say 25 turns) at speed 7 turns per second (it’s not too fast), and after a few turns, the motor stops turning. When i try to turn it by hand, it’s soft. When i use dump_errors(odrv0, True), there is no error. This means that the motor is still in closed loop.
Here’s a video demonstrating this issue.
What seems to be the issue? The encoder is 600PPR (thus the CPR is 2400), and it worked fine with odrivetool 4.12.
Can you check if the motor is still driving current while soft?
If yes, then there is likely some slip on the encoder, or electrical noise on the encoder, or the encoder CPR is wrong by a small amount.
I checked the iq_measured in this following video. When the motor gets soft, it says that the Iq measured is around 8 amps. There is no split on the encoder because its shaft is pressfitted to the 3D printed roller attached to the motor. When i turn the shaft manually, on the liveplotter we can see the amount i turned, and it seems to correspond accordingly.
Is there a D shaft or shaft key that registers the shaft to the roller? Otherwise it can “walk” around when turning especially when there is a slight misalignment.
I am not sure what you mean by “D shaft” or “walk around when turning”, but here’s a screenshot from the CAD design of the encoder and a picture of a similar encoder from Aliexpress (not exactly the same, but quite similar in appearance). The encoder axis is quite sturdy with ball bearings inside.
A “D shaft” has a flat on it:
Thank you for your quick reply. I checked and on my model there is no flat on the shaft, but i put locktite to keep it tight. Also, the torque applied by the motor is quite low (under 0.2Nm) because the setup deals with really small force measurements. Do you think this strange behaviour could be caused by something software related?
Overall the issue looks like “encoder CPR slightly wrong”. Can you look at the encoder counts, then turn the roller 1 turn exactly (use a mark on the roller to check) and then read the encoder counts again. Does it increment something very close to 2400? Or is it more than 2% off?
You can do this experiment with like 5 turns to get a more exact measurement.
So i tried your experiment and used the liveplotter to show the encoder.count_in_cpr values and something very interresting happens as shown in this video (i don’t know if that’s the way it’s supposed to work, i thought maybe the CPR count was incremental, and not resetting back to zero after 2399). I did the same experiment again, but using the encoder.pos_estimate instead, as shown in this video. Everything seems to be working as it should (after 6 turns, with a slight offset, the position estimate corresponds pretty much to 6 turns).
Ok I see. Yeah in that case I can only imagine that there is encoder slip. Either mechanically (maybe your locktite isn’t working well), or electrical: meaning there may be electrical noise that interrupts counting of some pulses.
I tried the same test, but on another system (another bldc motor using an amt102-v encoder), and the same thing happens. On that setup, the raspberry pi runs odrivetool 0.4.12 instead of 0.5.1.