This reminds me of a very weird bug I saw when using a Hall sensor.
The “effective” CPR of the Hall sensor would be different if I had set it without first rebooting the drive.
I could get it to calibrate (by doing a binary search on WTF the CPR should be) but then I rebooted and it wouldn’t commutate, and my calibration worked at a different value.
I’d recommend to always reboot after save_configuration.
BTW, these are geared motors, right? Is the Hall sensor on the motor side, and the encoder on the wheel side (ie after the gearbox?)
If so, then you need to divide the CPR by the gear ratio!
Hmmm. I have the same question as @towen. If you turn the motor by hand 1 revolution, what does shadow_count read? If it reads 4096 then you are going to have trouble controlling this motor because 4096/10 is not a whole number
I can see what looks like an IR proximity sensor, perhaps designed to read an optical track on the inside of the wheel.
So yes, the encoder is on the Wheel side of the gearbox, NOT the motor. That explains all the trouble you’ve been having!
This actuator will be designed to use the Hall sensors for motor commutation and velocity feedback, and the encoder for position feedback ONLY.
This would need the “dual encoders” feature of ODrive that currently ties up both axes. You could try it, but it would only work for one wheel per ODrive.
Your only other option would be to divide your motor CPR by the gear ratio, but you could run into problems, e.g. if you have a 10:1 gear ratio, you’ll need to set a non-integer CPR i.e. 409.6. I don’t know if that will work, and any backlash or elasticity in the gearbox could still screw up your commutation.
I suppose there are just about enough GPIOs that you could hack the firmware to take Hall commutation input from GPIO instead, and then take position and velocity from a single encoder input.
But it would be quite a lot of work I’d expect.
Wow, that’s cool, thanks for your help with investigation, you rock
Is there any guide about this “dual encoders” feature?
P.S. tried to check that stuff with 409.6 CPR and cpr accepts only integer values, so it would require code changes. Also it couldn’t calibrate with cpr 409 at all, even with calib_range = 1 ( part after dot shouldn’t play big role in this case i believe, but i might mistaken ).
Ok, that’s surprising. If it fails with calib_range=1 then it means it was more than 100% out e.g. if it was expecting to move by 400 counts and it moved by more than 800.
Do you know what the actual gear ratio is supposed to be? (10:1 was just an assumption) It could be 2:1, 3:1 as far as I know (and I’d guess from your video it’s closer to 3:1, because the wheel moved about a third of the way it normally does on calibration)
But as we’ve said, trying to control this motor using an encoder on the wrong side of a gearbox as your sole feedback device isn’t going to end well anyway.
If I were you, I’d try to get Hall sensor operation working using the Hoverboard guide. Because you have a geared motor, you will get much better performance than a hoverboard motor anyway, even without using the wheel encoder.
No, there’s no mentioning of this, but according to this
it looks like ratio is 4:1.
Yeah, we already been performing tests with hall mode, even though it’s not working with correct CPR, which is 256 ( should it also be divided accordingly to gear ratio? ), but works from scratch with all params from Hoverboard guide.
But my boss asked to check “double encoder” feature, so i need to check this…
Haven’t found any guides about it through google, only 2 related topics here…