Geared motors with Hall and encoders not spinning in encoder mode

[towen]

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!

[Hartner]

yeah, i always do reboot before calibration, I just strictly followed commands that @Wetmelon asked to perform.
Yes, it’s geared motor and here’s the encoder

on the cap there’s line on which that pink square slides.

[Wetmelon]

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

[towen]

@Hartner

on the cap there’s line on which that pink square slides.

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.

[towen]

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.

[Hartner]

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 ).

[towen]

@Hartner

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.

[Hartner]

@towen

Do you know what the actual gear ratio is supposed to be?

No, there’s no mentioning of this, but according to this

@Hartner

I also have performed another test taking into account what you told about calib_range - decreased the cpr = 1024 and it was able to calibrate with calib_range = 0.09

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…

Adding/subtracting two encoder inputs to control a single motor

using coreXY to run a CNC machine has a similar effect, if you run the motors in one direction you get vertical movement, if you move in opposite directions you get horizontal movement. There are two ways to handle this situation know how much each motor has moved, and calculate the sum/difference of them to figure the position know the movement and reverse the calculation to figure out how much each motor has moved. the vast majority of people take the first approach, it works with op…

and

ODrive for 4 axis CNC w/ linear scale encoders

We call this dual-encoder or “load encoder” mode, where commutation of the motor is achieved through one encoder and motion control is achieved via a second encoder (usually on the far side of any backlash or gearing). This is a planned feature, and a very rudimentary version is working in a feature branch, but the way it’s currently written you lose access to one of the two motor channels. Currently ODrive only has the software to support 2 encoders (one per axis) but this will change so tha…

[towen]

@Hartner

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.

No, to use the Hall sensor you do NOT divide by the gear ratio. It should always be magnet_pole_pairs * 6 i.e. 60. The Hall sensor is on the other side, and reads the motor magnets directly.