Very unexpected behaviour with velocity controller (sudden inverse current setpoint)

I have an ODrive3.6 with v0.5.4 connected to a DB59S024035 brushless DC motor, powered using a 6S LiPo and connected to a AMT102-V encoder.

I am running the ‘INPUT_MODE_TUNING’ mode to produce a velocity sinewave to control the motor (not connected to any load, with the encoder firmly attached to the motor shaft).

The first image below shows everything running smoothly as I would expect:

Legend for charts below
0 - odrv0.axis0.encoder.vel_estimate 
1 - odrv0.axis0.controller.vel_setpoint
2 - odrv0.axis0.motor.current_control.Iq_measured 
3 - odrv0.axis0.motor.current_control.Iq_setpoint

< unable to embed image as new users can only embed a single image per post >
[image 1]

However after around 20s, the target current suddenly jumps from ~-1A to +10A (see the second image below).

My controller gains are as follows:

  pos_gain: 0.0 (float)
  vel_gain: 0.019999999552965164 (float)
  vel_integrator_gain: 0.0 (float)
  vel_limit: 100.0 (float)

This issue is very repeatable and requires a reboot in order for the motor to move and get back to the control seen in the first image (the control will fail after about 20s again).

To me it seems like an integrator is winding up somewhere and suddenly flipping, but I haven’t been able to find any documentation about any other integrators other than the velocity integrator (of which the gain is set to 0).

Any ideas?

See image 1 below (unable to embed in the original message)

Legend
0 - odrv0.axis0.encoder.vel_estimate 
1 - odrv0.axis0.controller.vel_setpoint
2 - odrv0.axis0.motor.current_control.Iq_measured 
3 - odrv0.axis0.motor.current_control.Iq_setpoint

Can you please also plot encoder.pos_estimate?
Maybe the encoder starts to send garbage or resets due to z-index.

To start, why does the vel_setpoint look terrible? It should be a nice smooth sine wave… sampling issues?

Second, I agree with grahameth - pos_estimate or shadow_count would be interesting here. Looks like either encoder slip or noise.

The below chart is the running the INPUT_MODE_TUNING using the same tuning parameters as the above (freq: 0.1Hz, vel: 40rev/s).

Legend
0 - odrv0.axis0.encoder.vel_estimate 
1 - odrv0.axis0.controller.vel_setpoint
2 - odrv0.axis0.motor.current_control.Iq_measured 
3 - odrv0.axis0.motor.current_control.Iq_setpoint
4 - dev0.axis0.encoder.pos_estimate
5 - dev0.axis0.controller.pos_setpoint

I agree that the sinewave generation looks a bit choppy, however this is generated within the ODrive firmware and it looks like I can only adjust the frequency and amplitude. (https://docs.odriverobotics.com/api/odrive.controller.autotuning)

Is it possible that something physically stops the motor from moving?

SOLVED

Upon further investigation, there appeared to be too much capacitance on the encoder signal pins on the ODrive (see image below).

After removing these (~22nF) capacitors, the encoder signal appears to be much better (see image in the post below as I’m unable to attach 2 images to a single post).

Furthermore, each encoder signal uses a pull-up to 3.3V, however we were originally powering our encoder with 5V. Therefore we changed our encoder to be powered from 3.3V instead (this may have also helped solve the issue).

Thanks for pointing us in the right direction regarding encoder/position input.

1 Like

2 Likes

Sweet!

How do you like the INPUT_MODE_TUNING? We haven’t had a whole lot of people try it so far, so any feedback is nice :slight_smile:

I found the INPUT_MODE_TUNING to be really useful, however it took some time to get up and running due to the lack of documentation.

I think it would be great to add some information about the INPUT_MODE_TUNING in both the Control Modes and the Tuning sections.

Furthermore, in the ODrive.Controller.InputMode section of the API reference, it shows all InputMode commands as ‘UPPERCASE’, whereas the Tuning command is depicted as ‘Sentence case’ (I may be wrong, but I think I could only get the TUNING command to work when it was UPPERCASE).

And finally, in the above screenshots it shows that the sine-wave generation wasn’t perfectly smooth. I don’t know if this was due to my encoder issue, or whether there is an underlying issue with the sinewave generation.