Drifting in Position Mode

[tobbelobb]

Describe the bug
The motor doesn't keep its position as it should.

To Reproduce

• Make motors free to spin.
• Make sure it uses ODrive v3.6, 24V, the 330 kv motors and the amt 102 encoders.
• Build ODrivefirmware at commit daa089c and flash it.
• Run odrivetool from the repo: $ ~/repos/ODrive/tools/odrivetool
• In [1]: odrv0.erase_configuration()
• In [2]: exit
• $ ~/repos/ODrive/tools/odrivetool restore-config odrive-config-AB.json, where odrive-config-AB.json is linked here
• $ ~/repos/ODrive/tools/odrivetool
• In [1]: odrv0.config.brake_resistance = your_measured_value

•      odrv0.axis0.requested_state = AXIS_STATE_IDLE
       odrv0.axis1.requested_state = AXIS_STATE_IDLE
       odrv0.save_configuration()
       odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE
       odrv0.axis1.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE
       odrv0.axis0.motor.config.pre_calibrated = True
       odrv0.axis1.motor.config.pre_calibrated = True
       odrv0.axis0.encoder.config.pre_calibrated = True
       odrv0.axis1.encoder.config.pre_calibrated = True
       odrv0.axis0.requested_state = AXIS_STATE_IDLE
       odrv0.axis1.requested_state = AXIS_STATE_IDLE
       odrv0.save_configuration()```

• Attach a constant load mechanism to motor0.
• Put a slight constant load on motor0. 1-2 Ncm or something. This is not strictly neccesary, the bug appears without it as well, but the load makes the drift much larger.
• Observe and note down motor0's pos_estimate. For me it was 0.0057.
• While under slight load, move motor0 backwards ca 1 revolution with step/dir signals. For me this moved pos_setpoint from 0.899 to 99.83.
• Still under slight load, step motor0 forwards again by the exact same amount. For me this mover pos_setpoint from 99.83 to 0.899 as expected.
• Observe your pos_estimate again. For me it was 0.03457.

Expected behavior
I expected the pos_estimate to be the same as before (0.0057) after I stepped pos_setpoint back to its original value.

Instead, the motor has drifted away from it's initial position by ca 1.65 degrees, according to the new pos_estimate (0.03457).

The drift in pos_estimate is also observed in physical reality. During a real 3d-print with Hangprinter, similar drift happens several times per second, and the print quickly go haywire. When using 0.5.1 this doesn't happen.

I think the drift happens as the moment when we're crossing down through pos_setpoint = 0

Desktop (please complete the following information):

• OS: Ubuntu 20.04
• odrivetool Version v0.5.4.dev (commit daa089c)

Additional context
I was asked on Discord if this happens even if I disconnect the step signal and hard-wire it to GND or 3.3V.
I failed at testing this, since I don't know any other way to move the motor than with the step/dir signals.
The ODrive in the current (linked) configuration doesn't respond properly to input_pos changes.
I tried

In [56]: odrv0.axis1.controller.input_pos = 0.1

... but motor remained still, and odrv0.axis1.controller.input_pos kept its old value.

Signal noise on the step/dir signals is not the problem since the machine has been running long prints with 0.5.1 showing no drift. With v0.5.5 (devel) substantial drift is visible within a few seconds of starting a print.

[Wetmelon]

Did #680 fix this issue?

[tobbelobb]

TLDR; No. The config combination step/dir + circular range is still broken. It won't get fixed. Instead, the config combination step/dir + linear range was fixed and used as a workaround.

Long answer

No, #680 was not related to this issue.

Pardon me for digging deep in my memories about this issue, haven't thought about it since May 5.

@madcowswe and I had a separate debugging session about this issue.
I don't have my notes at hand but can look at my odrivetool history.

We found a discrepancy between counters two counters: axis0.encoder.shadow_count and axis0.encoder.count_in_cpr.

This issue was never fixed as far as I remember.
Looking at my config history, it looks like I worked around this bug by disabling circular range.

I also found this commit on ODrive's main branch: c5017f4, which says:
"Making circular_setpoints optional in step/dir mode because circular_setpoints was broken beyond repair." I think that's how this issue was worked around.

Under the Additional Context I also mention an issue where the motor remained still although I told it to move via a input_pos change. That issue was resolved in these commits: fa144cf, 6444197, and 4ca99a6.

[Wetmelon]

We found a discrepancy between counters two counters: axis0.encoder.shadow_count and axis0.encoder.count_in_cpr.

Doesn't sound right. Only way that happens is if you're using an absolute encoder.