Spinout move in wrong direction?

Odrive pro, T-motor MN1005, AMT212B-V encoder.
Calibration of motor and encoder offset run fine.
Put the motor into closed loop control, position (passthrough) mode, and within a few seconds it spins out of control (without any input change) and errors out as SPINOUT_DETECTED. If the motor gains are higher, this happens faster.
If I put it in closed loop control and (before it goes whacky on its own) nudge it with a manual disturbance, it takes off in the direction I nudged it, NOT in the direction to restore position accuracy. And likewise, if I give it a step in the input_pos, it jumps in the wrong direction and reports the spinout.
image

I have tried:
replacing the encoder
gluing the encoder hub to the shaft to eliminate slipping
reverting all the drive settings to factory (then reapply motor specs and encoder setup)

Other ideas??

First off, make sure your firmware is up to date with odrivetool dfu. Then, try increasing calib_scan_distance to get a more accurate encoder offset calibration.

fw is v0.6.4
I increased calib_scan_distance to 16, then 20 (it is a 21 pp motor) and no improvement.

This seems like it points at the issue: even when in an idle state, the vel_integrator_torque is a steadily increasing value.

I’ve tried setting the vel_integrator_limit, but that didn’t get me a useable system. Still SPINOUT or VEL_LIMIT errors when I disturb it by hand or change the input_position.

It seems like the system is generating torque in the wrong direction when I put it in CLOSED_LOOP_CONTROL, PASSTHROUGH input POSITION_CONTROL and then disturb it by hand with no change to the input_pos. So I erased all configurations and started over with the config tab of the GUI thinking I might have messed up a parameter’s sign, but no luck.

Well, after all that head scratching, it looks like an odrive hardware failure. Put a known good drive into the system and it works fine.

Any guesses at what would kill it? Do hot plugs/unplugs on the encoder cable have a bad history?

Hmm. Interesting, no, hot plugs on encoder shouldn’t have any effect. Do you see pos_vel_mapper.pos_rel or pos_vel_mapper.vel moving in idle?

IDLE state, mechanically stationary: pos_rel noise band is ~30E-6, vel noise band is ~12E-3.

IDLE state, manually turning motor: behave nominally (get 0.5 delta in pos_rel if i turn the motor ~180 deg)

I have quite a few of these drive/motor/encoder combinations to bring up, so even though I solved the initial one by swapping out the (apparently failed) odrive controllers in that system, it is still an active issue for me.
I now have another system with 3 each of OdrivePro + T-motor MN1005 (21pp, Kv=90, 32A) + AMT212B-V encoder all running on a 48VDC supply, and I have the same behavior. SPINOUT_DETECTED on all three systems after initial configuration, then disturbing motor in position_control mode by hand. And it is quite apparent that the restoration torque that should be resisting the manual disturbance is applied in the wrong direction (same direction as manual disturbance).
This time, however, I have verified that I can disconnect one of these odrives, connect it instead to a motor with 7pp, Kv=1150 (btw, why is this out of range in the GUI configuration??), w/ AMT212B-V encoder, and it runs it just fine after redoing the motor calib and encoder offset calib.

Leads me to wonder if there is something buggy with the high pole-count operation. ? But I would think such a bug would be all or nothing failure, not sometimes-depending-on-the-specimen failure.

All of these instanced have been with fw 0.6.4. Using tuning parameters carried over from the system I got working at the beginning of this thread.
And I have tried bumping the calib_scan_distance up to 23 for the high pole-count motors (then reboot, recalibrate), but that did not solve it.

I do notice that the encoder_offset_calibration move is fairly jittery from the cogging torque. Is that a possible connection?

We found a bug with the encoder direction find in Pro / S1 with high pp motors. Please try updating to the devel channel build, or use a higher calibration velocity