I am currently attempting to run a Nanotec DFA68 motor with an ODrive. The ODrive is receiving feedback from hall effect sensors built into the motor and using velocity control. I am following the instructions on the hoverboard page using the torque constant and pole pair values provided by the manufacturer.
I am experiencing an issue where the motor is consistently producing intermittent whining sounds and vibrations when running particularly at higher speeds. Please see the video and screenshot of the graph of the velocity estimate below for an example. I am powering it with 24 volts.
I am using the odrive v3.6 board with the firmware and odrivetool both upgraded to 0.5.4.
Does anyone know what may be causing this behaviour?
link to google drive video
Is the orange line the velocity setpoint? i.e. it is not reaching it?
It’s probably voltage limited, so the controller is saturated trying to reach a velocity that is impossible at 24V. ODrive has a modulation magnitude limit of 80%, which means that it can only apply 80% of the DC bus voltage i.e. 19V.
If you have the 56V ODrive then you can increase the voltage. There’s no risk of damaging the motor by running it at 50V (even though it says 24V is its rated voltage, the real limit is the bearing’s rpm limit) - the only ‘risk’ is that you would be able to exceed its rated speed of 4000 rpm, so you could damage the bearings by over-speed if you do that.
Also I would recommend twisting the motor phase wires together and passing them a few times through a ferrite ring.
Yeah the orange line is the velocity setpoint. It’s not reaching it because we are using very conservative Kp, Ki values (0.01 and 0). Also we have run this motor at up to 42 volts and still see this problem, even at speeds around 2000 rpm so we are not reaching a velocity limit or the bearing’s rpm limit.
Then probably it is caused by electromagnetic noise interfering with the current sensing and/or the Hall sensors.
Order a ferrite choke, and in the meantime you could try reducing
motor.config.current_control_bandwidth which may improve it slightly.
We oscilloscoped the hall lines and the phase lines and both of those signals looked very clean so I’m not sure it’s an EMI problem. What would changing the current control bandwidth do?
Adjusts how fast the current controller will respond.
Is this a 7pp or 14pp motor? 55 rev/s * 14 = 770Hz electrical, which is about the limit that ODrive V3 can handle. We’d expect it to do better than 55rev/s for 7pp.
Trapezoidal vs sinusoidal back-EMF can make a big difference too.
It is 7pp, so it should be able to handle that then definitely, but it’s unable to.
We also tried adding the choke and wrapped it around first once, twice, then 3x and it did not improve performance at all, so we are not sure where to go next from here/what the issue actually is. Here is a link to the google drive video of it with the ferrite choke. We are running it at 40 turns/second at 38 volts
The ferrite should be as close to the ODrive board as possible, and you should keep the motor wires close together, ideally twisted.
Ok we tried putting the ferrite chokes as close as possible and twisting the motor wires together then around the choke, there was still no improvement. When we scoped the lines there was also no noise along them so I don’t think this is the problem/going to solve it.
Are you still running at very low Kp / Ki values? If the velocity is not being regulated by the controller (if it’s not reaching its setpoint) then it could changing based on other factors e.g. torque ripple.
We tuned the control loop according to the hoverboard guide and we got vel_gain = 0.05 and vel_integrator_gain = 0.35. Changing pos_gain did not change performance, so we set it to 0. Tuning the constants did eliminate the steady-state error but did not improve the vibrations.
We tried adjusting the constants when the motor was running at 3k RPM, but that also did not improve the vibrations, and the current draw still rapidly swung between 0.45 and 0.5 amps.
The hoverboard guide is not intended for fast/accurate positioning. Although you do only have Hall sensors, so you can’t expect much better than a hoverboard tbh. What is your application?
Have you read through Control | ODrive
We have looked at the control guide it’s how we tuned the pid loops on the odrive. We aren’t doing positional control our use case is essentially wheels on a robot chassis. We have designed gear boxes and to run this robot at a reasonable speed we planned on running the motors at 5000 rpm with an odrive however at higher speeds —which the odrive should theoretically be capable of— we run into this vibration/current oscillation problem.
Hmm. Actually at 53 rev/s (3180 rpm) and 24V you are very close to the theoretical velocity limit - remember that ODrive 3.6 can only reach a modulation magnitude of 80% - this is to reduce noise in the 2-shunt configuration. So you have to multiply the effective voltage by 0.8 to get the max no-load speed. The datasheet for your motor says that it has a no-load speed of 4000 rpm at 24V, so at 80% modulation, that’s 3200 rpm. Consistent with your graphs. And remember that’s at no-load. Refer to the torque-speed curve for the actual capability, and remember to multiply the voltage by 0.8.
The new ODrive V4 (aka ODrive Pro) has 3 shunts, so it can reach 100% PWM in theory. But I’d still recommend having some voltage headroom for controllability.
A few things --we see the vibrations well below 53 revs. We begin consistently to see them at 34 revs/s, additionally we’ve been running the motor not at 24V but between 36-42V so we are well within the limits even multiplying by 0.8. Additionally, we are unable to run it at 3180 rpm (what you’ve described as close enough to our theoretical no load speed limit) without going well above the no load current the datasheet says we should be able to run the motor at, which is why we think there’s a problem on the odrive side that’s causing the vibrations and excessive current draw.
Is this motor sinusoidal backEMF or trapezoidal? ODrive doesn’t do well with trapezoidal
the back EMF is sinusoidal we checked via an oscilloscope