Here is how it works at 0.03 turns/s right now:
Gotcha, thanks. Does the motor move more smoothly at higher speeds, say 1 rev/s?
Yes, it’s smoother and it doesn’t stop completely while moving as it does at low speed.
I think it’s because the absolute value of velocity fluctuations is the same but with respect to the higher set speed, this is not so noticeable.
I think this is due to the cogging torque in your gimbal motor - if you can switch the AS5047P over to using SPI so that it’s an absolute encoder, you could try anticogging.
Thank you, looks like I have no other options but to try it out 
Am I right that anti-cogging can be used with relative encoder as well if there is no reboot after the anti-cogging calibration? Just to test the idea without re-wiring…
Hm, I honestly don’t know. Worth a shot!
Hi!
Tried lots of different options and experiments, but unfortunately without satisfactory results…
To be more precise I’ve tried anticogging with different combinations of vel_gain, vel_integrator_gain and pos_gain values. The calibration flow is of course a bit different with different coefficients, but the result is about the same. It moves a bit smoother but there are some additional vibrations, I’m attaching a video as it can better show the resulting process.
Video: DropMeFiles – free one-click file sharing service
Estimated velocity (input_vel = 0.01):
Maybe the motor with type MOTOR_TYPE_GIMBAL is just not well suited for this board?
I think this is really just a fundamental issue with the high cogging torque of the motor, the low resolution / high noise of the AS5047P, and your velocity requirements = 0.01 rev/s is tiny, that’s 3.6 degrees per second, or 0.6 revolutions per minute. With the AS5047P’s noise and resolution, there’s likely just not enough information for the ODrive to go off of.
Can I ask some more information about this application? Why do you have to move the motor so slowly, and can you instead use a gear reduction? Is it an option to use a higher precision encoder?
If the disturbances are low, and the speeds stay low: you can drop the encoder estimator bandwidth to 100.
Thank you, I’ll try it.
We wanted to avoid extra reduction in this project…
I’ll think about replacing the encoder with another one, one more question - is there any sense of migrating from quadrature output mode to SPI? If the signal itself is noisy and causes all the problems.
Unfortunately the noise itself is coming from the encoder’s position measurement, not the exact interface used. I’d consider moving to a higher resolution and lower noise encoder – something >=16bit should help a lot - maybe even an 18-20 bit encoder. RLS and Renishaw both make things worth looking at for this use case. In the short term, the 20480 CPR encoder sold in the shop would present an easy improvement if you don’t want to immediately move to a much higher resolution (and more expensive) encoder like an RLS or Renishaw.
Hi!
I’ve migrated to AS5048 for test, it has 14 bits in SPI mode instead of 12 bits with AS5047 - with anticogging calibration rotation has become much smoother, but not ideal yet.
Am I right that I should continue increasing encoder cpr (with another encoder types)?
Sorry for the delay in my reply.
The thing with magnetic encoders is that their noise isn’t directly correlated with the number of bits – so even with a 14-bit encoder vs a 12-bit encoder, it’s their RMS noise that matters. There’s really not too much more performance you can squeeze out of a cheap magnetic encoder like that – I’d definitely recommend going for something lower noise and higher CPR.
Just looked at supported encoders list. It seems that there are no compatible absolute encoders with CPR > 16384…
Do you strictly require an absolute encoder? Is an index search on startup unacceptable for your use case? Incremental offerings from Renishaw may be worth looking at, or you could try the 20480 CPR encoder for now.
We’re working on adding AksIM-II support to the ODrive S1/Pro/Micro, which can go up to 20 bits (1048576 CPR) – that may be something to consider.