Hi!
But, it runs pretty rough, at low speeds there’s significant cogging and at higher speeds there’s a pretty loud rumble that I guess is also cogging? It’s a bit strange in that the cogging feels like a “heart beat” i.e. as it’s rotating there’s a duh-duh … duh-duh … almost like just two of the poles are binding or something. I’m running this with basically no load at this time, it’s spinning a little fan to have something to look at.
I’m assuming you’re only using hall sensors? Those are super low resolution, and makes velocity control very very difficult, since the ODrive is essentially unable to actually measure the velocity when the motor’s between hall states – so I wouldn’t expect any sort of good control under a hundred RPM or so. For comparison, hall sensors have six states per pole pair * seven pole pairs = effectively 42 CPR (encoder counts per revolution). I would consider a “fairly low resolution but usable” encoder to be 500-1000 CPR.
Typically, the higher the encoder resolution, the smoother the velocity and position control can be. I’d strongly recommend sticking on an external encoder if you need good low-speed position/velocity control.
higher speeds there’s a pretty loud rumble that I guess is also cogging?
Possibly. Could also be some issue in the hall calibration (when the ODrive spins the motor for a minute or so during calibration). In the GUI, I’d recommend cranking up the lock-in spin current (on the motor config page) – this way, the motor’s cogging torque has less of an effect on the calibration. Usually I say to do this around 75% of the motor’s max continuous current – the Flipsky says 70A continuous, so that would be about 50-55A – that’ll get the S1 a bit hot, make sure it’s attached to the heatspreader plate and not just sitting bare on your desk.
I noticed that there is an “experimental” anti-cogging routine but it’s not clear if I can run that from the web gui, is that possible or do I need to go for the local python app?
The web GUI inspector tab has full coverage / identical functionality to the stuff you can do in ODrivetool, you just gotta search for the parameters you want to read/edit.
Note though that anticogging won’t work if you’re only using hall sensors – you need some sort of other encoder (either absolute encoder, or incremental with an index line).
It was listed as experimental at least several years ago, has this been improved at all or even is it already included in the calibration?
“Experimental” just means that (A) it’s not included in our automated firmware testing, and (B) our docs for it kinda suck
we have plenty of customers using anticogging in production applications.
It’s not included in the calibration both because (A) it relies on good/stable velocity gain tuning (and there’s another parameter or two you may have to tune, depending on the motor), and (B) anticogging calibration takes six minutes 
Have people had good luck with this and a similar type of high current motor?
Absolutely! It’ll work on everything from a giant traction motor to a small gimbal motor.
Is this just an unsuitable motor and I get a pancake one instead?
Nope! Put an encoder on it though. The simplest thing would be to just use the S1’s onboard encoder or an OA1 (since the motor doesn’t have a backshaft that makes it easy to attach a through-bore encoder like this one). If you go for a magnetic encoder (like the S1’s onboard or the OA1), make sure to give this a thorough read first: Designing for Magnetic Encoders — ODrive Documentation 0.6.11 documentation
I was hoping that this thing would be virtually silent
That is a harder question. It’ll be a whole lot quieter with an actual encoder on it, but this sort of outrunner motor will never be purely silent – mostly just because the rotor will disturb ambient air and cause sound that way.
smooth velocity control with reasonable torque and RPMs around 2000
This is also a very very interesting question!
- How much torque do you need?
- How precise and smooth does the velocity control need to be? Like, are you building a record player?