Motor vibrates while holding position

Support
1

Hi there - new owner here, just trying to get my feet wet with a new v3.6 24V ODrive trying to control a (cheap) FlyCat iRotor 5010-360KV motor. I’ve had some limited success, but feel like I’ve hit an impasse…

My test setup:
24V ODrive v3.6 - not certain of the firmware version, but I assume 0.5.1 as this was purchased in the last week…
FlyCat iRotot 5010-360KV motor - note, this is a very cheap motor and possibly part of my issues?
AS5147P-TS_EK_AB encoder - AMS evaluation board. Using ABI interface. Board has been configured to run off 3.3V.
Bench Power supply set to 16V as main power to ODrive
Windows10 host computer, connected via USB, running freshly installed anaconda3 to run odrivetool

What I’ve done so far:
I ran through the Getting Started procedure in the documentation. I made the following changes as suggested in that procedure:
odrv0.axis0.motor.config.torque_constant=0.022972222 (arrived at by 8.27/360)
odrv0.axis0.encoder.config.cpr=4096
odrv0.axis0.controller.config.vel_limit=20 (this was originally 2, but through my testing I’ve bumped this up as I was receiving controller overspeed errors)

odrv0.axis0.requested_state=AXIS_STATE_FULL_CALIBRATION_SEQUENCE completes without errors.
odrv0.axis0.requested_state=AXIS_STATE_CLOSED_LOOP_CONTROL caused the motor to oscillate, vibrating horribly (and noisily).

After that I went through the Tuning procedure.
This left me with the following changes:
odvr0.axis0.controller.config.vel_gain = 0.04 (this “seems” quite low to me, but I had to go this low to get rid of the violent oscillation)
odrv0.axis0.controller.config.pos_gain=30
odrv0.axis0.controller.config.vel_integrator_gain=0.08 (I just did 2*vel_gain)

Now when I enter CLOSED_LOOP_CONTROL the motor doesn’t vibrate nearly as bad, but it still has some vibration (and hum) to it. I can send position commands to the motor and it’s responding reasonably. I’ve found that if I put a finger on the motor I can dampen out the vibration quite easily. I did start_liveplotter(lambda:[odrv0.axis0.encoder.pos_estimate, odrv0.axis0.controller.pos_setpoint]) to see if that told me anything, and I think it does…

It seems that the motor oscillation I’m seeing (in pos_estimate) is about +/- 0.0015 (of a turn). With my finger on the motor the swing drops to +/-0.0005 (which seems to be one or two encoder steps). Even with the motor powered I can easily rotate it +/-0.002 before I start to encounter the motor ‘fighting back’ in any way.

This leads me to think that the motor can’t really “hold” position better than +/-0.002 (of a turn, or about +/- 0.7degrees), the encoder is sensitive enough to detect this, and the controller is trying to compensate, but since the motor isn’t that precise, the controller ends up driving the motor too far to compensate, then has to drive it back the other way - resulting in the oscillation I’m seeing.

Just to be clear – I’m not worried (at this point) about the accuracy of the motor position - but in the powered-oscillation I’m seeing that is causing the (relatively) loud vibrations.

So - what am I doing wrong? What should I try to address the symptoms I’m seeing?
Thanks in advance for taking the time to read this far!

2

Yeah, a vibration of about +/- 2-5 encoder steps is normal depending on gains. It’s called “hunting”. You can try the gain scheduling (undocumented) feature if you want, but the odrive has current sensing noise and the encoders (especially those magnetic encoders) are noisy. So sounds pretty normal to me. Higher resolution encoder, stiffer gains, anticogging, and gain scheduling (anti hunt) can all help

You can measure encoder.shadoe_count to get the position estimate in raw encoder counts

3

Thanks for the feedback!
I’ll try to dig into the topics you mentioned to see if I can get better results.

The encoder actually seems to be generating nice clean signals (as viewed with an O’Scope) and it seems to be quite stable when the motor isn’t actually moving. So I suspect it’s more related to the error introduced by the “free” motion of the motor itself (as opposed to error introduced by the encoder).

I’m fairly certain that the behavior I’m seeing wouldn’t be considered normal – but I base this entirely on the numerous youtube videos I’ve seen of others using ODrive to control similar (although, likely “better”) motors. I’m pretty sure that if folks were seeing (and hearing) what I’m seeing they would have mentioned it…

In any case, I will pursue the suggestions you made - once again thanks for the pointers!

4

If that’s the case, you should take a video or some data and we can check it. What’s the frequency of oscillation?

5

I’m not actually having a ton of success trying to track down info on the anticogging an gain scheduling. The documentation on these capabilities seems very light… I haven’t delved into the source for the firmware yet, but I guess that’s the next step.

Anyway, here is a short video of where it’s at right now:

I haven’t found a decent way to measure the frequency of the vibration yet.

6

Yeah they’re not well documented.

That behaviour you show is normal with an AS5xxx series magnetic encoder. You can try adjusting your encoder bandwidth to 2000 instead of 1000 (odrv0.axis0.encoder.config.bandwidth = 1000), helps a bit.

1 Like
7

That helped quite a bit! The vibration is reduced to the point of no longer annoying me (which I consider a huge success).
Thanks so much for taking the time to help me out!

1 Like