Absolute Mag encoders values aren't consistent

I have 2 mag encoders on 2 different systems, both LED’s are green and both are configured as absolute encoders.

Last year we used the same encoder setup with no problems, this year however the encoder reading often changes from around 2000 at the top to 6000, so if the motion range was from 2000 to around 3000 it would change to from 6000 to 7000.

We kept checking the encoder after each time the value changed however there were no apparent problems, we switched encoders, talon and the wiring however the value jump kept happening.

We’re desperate to solve this problem so we would appreciate any kind of help.

Not sure what you meant – does this happen while the encoder isn’t rotating?

1 Like

I have a feeder arm in my robot, during it’s movement the encoder values vary from 2000 to around 3000, after some time the values would change to from 6000 to 7000 for no apparent reason.
The change happens both when the arm is rotating and when it isn’t.

Pls explain this… Since when can you config an encoder?

Is it jumping by 4096?

This is what I suspect. It may be that the jump is across the wrap point of the encoder (where it goes 4094, 4095, 0, 1, 2, …) and your calibration is missing it. If so, an
encoder_value = math.IEEEremainder(encoder_value, 4096);
line should be able to help.

I’m pretty certain @M3ri means that they are using the absolute PWM output rather than the quadrature pins.

What does it change?

I’ll assume the SRX encoder; the concepts will be the same, but the numbers different for other encoders.
Quadrature requires two data pins. During one revolution, each goes up 1024 times and down 1024 times; these transitions are staggered so that (if you keep track), you can always tell where the encoder is to within 1/4096 revolutions relative to where it started. The answer is updated each tick, which may be once a microsecond if the encoder is spinning at about 15,000 rpm.
The absolute PWM output works through a single data pin. Every ~4ms, the signal goes high, and remains high for a number of microseconds from 1 to 4096, telling you where the encoder was in absolute terms somewhere around where the signal went high. If you don’t need an update more than every 4ms, this is often a good way to go because it uses fewer resources. If you need more up-to-the microsecond stuff, you will want to use the quadrature. (You can also use both, as the Talon SRX encoder does.)

Thanks for the explanation, it would seem I have initially misinterpreted “absolute” as that it has a mechanical “zero point”.

Will this math be done onboard? because I’m running my control loop on the srx.

Which math? The IEEEremainder() would be done on the RIO. The rest would be either on the the controller or within the controller library.

Why would you use IEEE instead of modulo?

It’s more consistent with the range of outputs.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.