Hi, I have a motor attached to a slider mechanism, where the whole transmission consists of:
Motor → Pulley D1 → Timing Belt → Pulley D2=D1 → Endless Screw → Screw nut mounted on a cart (55kg-61kg) supported by linear rails. All parts are relatively high quality and mounted with high precision. I calibrated the ODrive Pro connected to the motor and did also the anti-cogging calibration. Also, the ODrive is powered through a regen clamp. When I try to accelerate the slider too fast (controlled in TRAP_TRAJ position), either by giving a input_pos step too large or using high gains, I get the SPINOUT_DETECTED error. I already checked the proper (secure) mounting of the magnet in the motor shaft and re-did the ENCODER_OFFSET_CALIBRATION. I still haven’t tried increasing the current_bandwidth as another post suggested. Here are some plots of the spinout estimated powers:
This is the behavior when the gains are low:
I increased the current_control_bandwidth (up to 10000) and still get the error.
To add some information, here are some plots of when the slider moves in small steps:
From these plots, it makes sense to me that for one step, the mechanical power is first positive and then negative symmetrically (as the torque needs to have this behavior in order to accelerate and decelerate). The thing I don’t understand is why the electrical power doesn’t go negative? if sum of the current in the phases indeed goes negative sometimes? If the estimated electrical power doesn’t go negative, then for sure there will be a difference between the estimated electrical and mechanical power and thus throw the SPINOUT_DETECTED error.
Hi! Sometimes just with lower resolution encoders (like magnetic encoders, at least relative to a high-resolution AMT21), you’ll have those spinout errors with the default spinout thresholds during high acceleration. It doesn’t mean anything’s necessarily wrong with the system, it’s just a combination of estimator/encoder lag with the high accelerations. You can try decreasing spinout_mechanical_power_threshold and increasing spinout_electrical_power_threshold – I think they’re -20 and +20 respectively by default, you can change that to -100 and +100 and see if that helps.
I’m using the on-board magnetic encoder, then shouldn’t have that much encoder lag, right? At the end it started to behave better by increasing the spinout_electrical_power_bandwidth, with this, the electrical_power would go negative as the mechanical_power:
I’m using the on-board magnetic encoder, then shouldn’t have that much encoder lag, right?
It’s mostly the estimator lag as a result of that lower resolution – you can think of it as the ODrive having less “information” from the encoder as it accelerates, resulting in more error between the estimated and actual velocity. Yes, the encoder only has a few tens of microseconds of internal latency, but the resolution is lower and noise is higher than e.g. the 16384 CPR RS485 encoder.
Internally, spinout detection is done by checking if spinout_mechanical_power is less than spinout_mechanical_power_threshold and spinout_electrical_power is greater spinout_electrical_power_threshold (where spinout_mechanical/electrical_power is the filtered number). If that condition is true, we raise a spinout error.
To elaborate, if mechanical power is negative (braking) and measured power is positive, this indicates that the controller is trying to stop, but torque is being produced (or vice versa), which usually indicates an encoder error. Or, as you can see in your case, it can be just caused by very high accelerations with the default conservative bandwidth – we have our defaults as safe as we can get them.
Generally if you’re not concerned about your encoder mounting / encoder slipping, you can just raise the spinout thresholds as high as you want.
