When I go through the calibration process, the rotor vibrates a bit while rotating (idk if this is normal), when I check the Dashboard, the position and velocity are noiseless and they seem to give proper values when I move manually the rotor. When I turn on the Velocity Control Mode in the Dashboard, the current measurements are a bit noisy (±0.1A), but the measured position and velocity stay constant as long as the velocity setpoint remains equals to zero. When I try to give a low setpoint of velocity (e.g., 2 rev/s), the rotor rotates but with very high vibrations (See pic.)
As you can see, I tried just using just a velocity gain with zero integral term still giving the same behavior (with k_v = 0.01 the rotor doesn’t move, with 0.02 it moves slowly but very choppy).
Do you have ideas on what can be causing this behavior? Thanks in advance.
I think this is an intrinsic issue of using hall sensors – they’re so low resolution that there’s just mathematically not enough fidelity in the velocity data for the ODrive to work with, so you need to really turn down your velocity gains – especially for small motors like these. I’d try keeping your vel gain at that 0.1 figure and then try slowly increasing the velocity integrator gain.
We generally recommend only using torque control with hall-based motors for this reason; if you need low speed velocity control, I’d strongly recommend adding an incremental encoder to your motor, and configuring that as the load encoder – that’ll give the ODrive some much-needed high-res velocity data, and is also great for dealing with gearbox backlash (if you add the encoder to the gearbox output).
I managed to find a low enough set of gains that minimize the choppiness at low speeds, though I still have cogging from 0 to ~7rev/s; this is with the integrated three-phase hall effect sensors in the motor. I will now try to use the magnetic encoder included in the ODrive Pro board together with the anti-cogging calibration.
I need to have the ability to control at low speeds as I am giving as reference to the board trapezoidal velocity profiles.
Can you confirm that the only way to do the anti-cogging calibration is through the odrivetool (i.e., not though the GUI) ?
You can do it in the GUI – the inspector tab has feature parity with ODrivetool. You just need to use the search bar for the relevant properties – e.g. axis0.requested_state, etc etc
You absolutely need a higher resolution encoder than the hall sensors for anticogging (it’s not mathematically possible w/ hall sensors), and note that you need the higher-res encoder to be directly on the motor – can’t be on the gearbox shaft unfortunately.
All this being said, when you say “cogging”, I’m guessing it’s not actually what we’d consider cogging torque (e.g. caused by passive iron-magnet interactions in the motor, compensated for by anticogging) – I think unless you’re trying to do some extremely smooth/precise low speed control (in which case anticogging would be helpful), this is sounding like an issue that’s just fundamentally driven by the hall sensors’ low resolution.
I can understand why with 3-phase hall effect sensors it won’t work due to low resolution, but this shouldn’t be the case with the integrated magnetic encoder on the board (MA702), which detects the absolute angular position of the magnet and if I’m not wrong outputs a signal of 12 bits, so it should have a similar resolution of an optical encoder of 4095 PPR, right? (assuming the board’s ADC is also 12 bits).
Here are the velocity profiles I need the motor to follow and the estimated velocity using the internal magnetic encoder of the ODrive Pro (these are the tuned gains for this motor: 0.01 vel_gain, 0.05 vel_integral_gain):
Note: I changed the encoder bandwidth from 1000 to 200 because it was too noisy the vel_estimate.
From these figures, isn’t it cogging what is making the controller be unable to follow the profiles at low speed? (dwells at low speeds, start of incremental ramp, end of decreasing ramp)
Here are the velocity profiles I need the motor to follow and the estimated velocity using the internal magnetic encoder of the ODrive Pro (these are the tuned gains for this motor: 0.01 vel_gain, 0.05 vel_integral_gain):
Note: I changed the encoder bandwidth from 1000 to 200 because it was too noisy the vel_estimate.
From these figures, isn’t it cogging what is making the controller be unable to follow the profiles at low speed? (dwells at low speeds, start of incremental ramp, end of decreasing ramp)
Probably static friction, unless that’s a crazy high cogging torque motor. I’d definitely increase the encoder bandwidth back up to 1000. What does onboard_encoder0.get_field_strength() return? And can you share your whole config?
