Current setpoint jumps to maximum when velocity setpoint is above a certain level

Hi all,

So we’ve been using a custom integration of the ODrive v3.5 at work for the past several months and it has worked quite well. Recently we ran into a new issue and I was wondering if I might be able to get some insight from the community as to what the problem might be.

For background our FW version is ODrive FW v0.4.10 with a few minor patches. Our motor selection is the Maxon EC 45 Flat 70W (datasheet) with Hall effect sensors and no encoder. Since this is a lower current motor, we have adjusted the value of the current sense resistors to 15mOhm to try and improve the SNR for current sensing. The firmware has been patched accordingly. We typically run the motor in velocity control mode. We followed the hoverboard motor setup guide initially since that was closest to our application. In particular, we set the following configuration values:

odrv0.axisN.motor.config.pole_pairs = 8
odrv0.axisN.motor.config.current_control_bandwidth = 100
odrv0.axis0.motor.config.requested_current_range = 10
odrv0.axisN.encoder.config.mode = ENCODER_MODE_HALL
odrv0.axisN.encoder.config.cpr = 48
odrv0.axisN.encoder.config.bandwidth = 100
odrv0.axisN.controller.config.vel_limit = 5000

(I can provide more details regarding the configuration later when I have access to the hardware to take a look at it again.)

Up until now we have run the motors at a maximum vel_setpoint of 2500. Today we tried to run the motors at a higher velocity and we got an interesting result. See the attached plots below:

(I had a second image, but I guess new users are only allowed one image per post.)

In both plots, the blue trace is the velocity setpoint, the orange trace is the estimated velocity, and the green trace is the Iq_setpoint in mA. The maximum current has been set to 5.5A. Once the velocity setpoint reaches a certain threshold (somewhere around 3700 counts / rev), the Iq_setpoint jumps to the maximum allowed value and the velocity control loop breaks down. The velocity estimate seemed to drop to the same value each time and motor speed seemed to roughly match the reported estimate. The only way to clear the drive out of this state is to lower the velocity setpoint back down below where it dropped in the failure event. Surprisingly, I haven’t picked up any ODrive error codes during this event. This is very strange behavior, and we only have a few rough guesses as to what the root cause could be.

  • We’ve experience some problems with noise on the current sense lines, so it’s possible that the current control loop or phase current measurement is unstable and causing this problem?

  • It almost looks as if the velocity estimation can’t track velocity beyond a certain value. Maybe we’re hitting some sort of upper bound on the velocity measurement due to the Hall effect sensors / lack of encoder / lower encoder bandwidth?

For what its worth, we tried testing a motor with the ESC sold by Maxon and we were able to get the motor to a much higher RPM, so we know it’s not an inherit limitation in the motor. We’re going to try with an official ODrive board tomorrow to see if the problem is isolated to our custom board, so I’ll report back if we get any information from that testing.

Any thoughts as to what the root cause might be here? Suggestions for things that we should test? I’m intrigued by this problem as I’ve not seen anything quite like it before in working with the ODrive. Thanks for any assistance!

Here’s the second image that was supposed to be in the original post:

It looks to me like there is a limit somewhere that is overruling the current controller. Does changing the velocity limit in the trapezoidal trajectory controller change the behavior?

@Riewert

I checked the trapezoidal trajectory controller velocity limit and it’s still set at the default value of 20000 counts / s, so I don’t think this is the source of the problem. I also looked through the firmware and it doesn’t seem like the trapezoidal trajectory planner should have any impact during velocity control.

One of my coworkers was doing some more research and we found this post: ODrive for PMSM. Can anyone confirm is that the peak line-line voltage for a 24V ODrive would still be 16.6V? I guess the only thing that might have changed would be the amount of modulation time left open for current sensing.

Hmmm, then I have no clue. Try asking on discord. Am interested what the solution is.

So we ruled out the velocity estimation failing. Using a “drill test,” we were able to generate the following plot:

The blue trace is the estimated velocity of the motor. We set the requested state to AXIS_STATE_IDLE before testing so that we would not damage the board. The plot clearly shows the motor tracking velocity well above our desired range, so it seems unlikely that the velocity estimation is failing. The spikes in the graph are due to the fact that we had poor engagement between the motor shaft and the “drill” and so we could not safely sustain a high velocity for very long.

I’m somewhat stumped as to what the problem is here, unless it’s a BEMF issue. We still need to test with a stock ODrive and we also have a slightly different motor on order that may perform better.

Which of the motors in that datasheet do you have? What is your bus voltage?
The most plausible case to me is that you are running into the modulation/voltage limit. A tell-tale sign is if Iq_setpoint and Iq_measured become very different from each other, you can plot them and check.

Bus voltage is 24V. Motor P/N is 411812. We will try that test; thanks for the suggestion! Is there any documentation that discusses the modulation/voltage limit?