Issues with rebooted ODrive with or without precalibration

Support
1

Hey everyone,

First some context: we use a setup with a BLDC motor inside of what we call a joint. We have one incremental encoder located on the motor and an absolute encoder at the output of the joint (gear ratio of 1:101). We only use the torque control function of the ODrive and do position control externally. We use the incremental encoder for the parameters necessary for the ODrives actuation while simply passing through the absolute encoder data. The output of our mechanical joint has limit freedom of movement (can’t make a full turn) though the motor can due to the gear ratio.

Our initial setup uses pre-calibration settings with the incremental encoder based on the index signal. (Not ideal as the index signal can be found at multiple positions of the output due to the gear box). This generally worked fine but after using our emergency button to cut off the ODrives power, the ODrive produces a multitude of weird behaviour after restarting and trying to actuate. Such as unknown_phase_estimate error, current_sensing_error, or moving in the opposite direction. These issues are generally fixed when we recalibrate. Recalibrating is, however, not an option for our final application. We tried hard coding the parameters found from calibration but to no avail. We also noticed that the phase_offset tends to differ everytime we calibrate.

We also don’t have a crystal clear understanding of how the phase_offset and phase work.

A solution that I could think of is using the absolute encoder instead. Though we’ve had a hard time getting it to calibrate. Probably due to slight margins between movements of the motor and the output.

If anyone has suggestions or insights please let us know :slight_smile:

Thanks

2

I should also mention that we use a slightly modified version of v0.5.2, where we use a combined encoder mode that updates all encoder parameters as incremental, while also updating an absolute encoder at only the pos_abs variable.

(and we added a software CRC and filter to deal with noisy absolute encoder data)

3

Just sounds to me like your index pin isn’t triggering properly. It’s pretty common for it to pick up noise. You can add a 22nF bypass capacitor to the Z pin to help.

Absolute encoder works, but agian noise is a problem and conflicts with the DRV8301 configuration during start-up can be a problem if your encoder doesn’t tri-state properly.

4

Thanks for the response.

We’ve identified a problem that we introduced with our own adjustments. We forgot to add the index search to the startup procedure which caused most of our problems as the incremental counts weren’t properly set to 0 at the index, therefore the offset didn’t make any sense. Normally this wouldn’t be able to happen as the is_ready variable should not have been set to true. Though as we combined functionalities from both the incremental and absolute encoder the usage of SPI triggered a condition to set is_ready to true. It explains how offset calibration fixed our issues everytime as the index and offset would be properly determined.

1 Like