SPINOUT_DETECTED using high torques

Support ODrive Pro Support
1

Hi,

Context:
Currently working on taking an RC Car and making it autonomous. We’re testing the vehicle on grass, but it appears to have some issues when tracking trajectories. We’re using an ODrive Pro with

  1. An AS5048A communicating via SPI (looking online this has an output sample rate of 10.2 to 12.4 kHz–which seems really high (https://ams.com/documents/20143/36005/AS5048_DS000298_4-00.pdf).
  2. A 2 pole pair, 1275KV high current motor currently we’ve limited at 80A.

Issue:
Large velocity jumps or high torques raise a spin out error while on grass when the controller limit torque is high (around 0.350Nm). But if we use lower torque (.104Nm–the 20% recommendation), the vehicle will stall on grass if it doesn’t already have some momentum.

I’ve looked at similar issues suggesting expanding the spinout thresholds and increasing the controller.encoder_bandwidth.

So for reference, the encoder_bandwidth is set to 1000 and the spinout thresholds are at +/- 50 for electrical/mechanical.

Is this behavior normal when doing high velocity jumps (0rev/s to 170 rev/s)? Do you have any recommendations for how I might configure the ODrive settings to avoid spinout effectively–without introducing significant risk at detecting when an actual spinout occurs?

I think it’s odd that the AS5048A has a sample rate of 11.25kHz typically but the encoder_bandwidth is only 1000 (Hz?). But I could be reading the documentation incorrectly.

2

Hi there,

Encoder bandwidth takes into account noise and latency, which is quite different from the internal sample rate – the AS5048A has about 100us of latency.

False spinouts can be normal with extremely sudden high torque moves, especially with lower resolution encoders. Increasing spinout thresholds will absolutely work – the risk of a spinout here is going to be little to none as long as your encoder magnet is securely fastened to the shaft, it’s more of a risk with through-bore encoders that rely on a friction fit and can slip. However, another thing you can do is just use the VEL_RAMP input mode - so that the velocity ramps up and down instead of instantly slamming from 0 rev/s to 170 rev/s. Even a ~100ms ramp up/down should help, so that the velocity command is feasible and required torque can be followed by the current controller.

1 Like
3

Following up on this, using VEL_RAMP input mode and expanding the spinout thresholds from +/-10 to +/-50 worked.

On VEL_RAMP, we upped the max ramp from 10 rev/s/s to 100 rev/s/s to resemble instant velocity jumps more closely.

4

That’s great to hear! Please let me know if there’s anything else I can help with :slight_smile: