I just got an email talking about anti-cogging improvements that are coming, is this something for the newer ODrives or will the 3.6 hardware be able to use it too?
Hi there,
These updates are for the latest firmware, which is only compatible with the new generation of ODrive products - ODrive v3.6 is NRND and likely won’t receive further software updates past maintenance and bug fixes. Anticogging on the v3.6 should be functional as-is, please let us know if you’re experiencing any difficulties with it!
It isn’t but I suspect it’s because I’m using velocity mode, I was hoping this may improve matters for hoverboard motors. I think I may just have to write off the ODrives for this project sadly as I can’t dump any more time in to this, hopefully I’ll find another use for them.
I’m using anticogging on ODrive 3 with velocity mode myself, and it’s working just fine 
Do you use encoders or hallsensors?
Hall effect sensors. Are you using hoverboard motors too?
That’s the problem then. Hall sensors are very imprecice. Unless you know the exact angle, anticogging cannot work.
No, I’m not using hoverboard motors. But maybe you can try to attach an encoder to it?
My bot is designed to be used in all weather, the sensors being inside the wheels are a massive bonus for this so adding encoders isn’t an option.
Sadly the ODrive isn’t the right controller for my use case it seems. I’ll find another use for them, I just wish I knew of these caveats before I bought three of them. A shame as they are brilliant motor controllers and seemed ideal to start with.
I am planning on adding steering for my v2 of this bot, turning a pair of brushless motors in to servos for that will be a better use for sure.
Ah gotcha - if the only thing you have is hall sensors, then yeah it’s pretty much impossible to get good anticogging - just from a wheel position/velocity observability standpoint. From a controls standpoint, I’m not sure how it would be feasible to get better velocity control based just on halls - but if you end up finding a different controller that works better for your application, I’d love to hear what it is!
One thing to note - you could check out the new Botwheels - they have an integrated hall + incremental encoder, in order to make low-speed velocity control possible. Only compatible with Pro/S1 due to the dual encoder feedback, but they work great and they’re IP54 rated.
1 Like
When one of my odrives blew up I replaced it with a pair of VESCs I have for a skateboard project, they seemed much happier at lower speeds. I need to revisit them with the knowledge I have now to see if they’re a better option. If nothing else the Hoverboard controllers themselves seem to manage, I have one of those I keep meaning to hack. I’m not sure if the hall sensors are digital or not, if they’re analogue the other controllers may be able to use the relative differences in values to get a greater set of interim values beyond the 90 CPR the ODrive uses?
Sadly, the Botwheels just aren’t an option. Six of them and matching ODrive S1 boards come in at $1701, I love the accidental Trek reference but I just can’t justify the expense to replace something I just expected to work. They’re also much thinner than the offroad hoverboard wheels I’m using, I’m not sure they’d be a good match for my need.
The Hoverboard setup guide really needs the slow speed/low “encoder” resolution behaviour adding as a caveat. Had I known, I wouldn’t have gone this route, there may not be better options but if I can’t avoid cogging at low speeds I’d have certainly preferred to use cheaper controllers. It’s an expensive lesson to have learned this way. 
1 Like