Dual encoders

Technical Programming
1

My team is running a tank drive setup this year, and have added an encoder onto each side. We are also using the NavX for angle measurements. We will have a variety of methods that rely on angle measurements from the NavX and distance measurements using one or both encoders.

However, I am wondering if there is really any benefit to having both encoders. If for distance we just take a raw average of both measurements, we are basically getting slightly more precision in exchange for a doubled failure rate. It seems to me that unless you are using two encoders to sense angles in place of a gyro (or some sort of fusion) there is almost no benefit to having dual encoders.

How does your team integrate dual encoders into the code? Does anyone just mount/use a single encoder?

2

If you play your cards right, you can use the redundancy to reduce the effect of an encoder failure.

3

In industry, we would actually use 3 encoders and then always select the midvalue one.

Just as we say:

  • With 1 sensor, you don’t know that you’re wrong.
  • With 2 sensors, you know you’re wrong but aren’t sure which is correct.
  • With 3 sensors, you always know which one is wrong and which is right

(From a single-fault-tolerance perspective)

4

Does anyone actually do this in FRC? I had played around with the idea of constantly checking both encoders, and if one is consistently outputting zero (possibly indicative of faulty wiring), switch to the other one. Are there any other common failure modes that we could look for?

5

I’m still hoping for answers. If I don’t get any responses, I will assume that everyone just averages the two values.

6

Two encoder are essential for drive straight using encoders. If one gets ahead of the other, you can adjust the direction. It all goes out the window when crossing defenses though.

7

Ok I’ll chime in, we typically end up using just one encoder and the gyro even though we have two encoders.

Some years, we have implemented some code which has some logic like the following “psuedo-code”:

if ((encoder count isn’t changing) && (trying to drive))
{
encoder_is_broken_counter++;
}
else
{
encoder_is_broken_counter = 0;
}

const int ENCODER_MUST_BE_BROKEN_COUNT = 100;
if (encoder_broken_counter > ENCODER_MUST_BE_BROKEN_COUNT)
{
ABORT_AUTONOMOUS_MODE!
}

Maybe one could improve on this logic to switch which encoder you are using, switch from averaging the encoders to ignoring the one that isn’t working?

Typically we run out of time to do all of the fancy stuff we would like to do in autonomous.

8

We use 2 encoders and check if one or the other is where we want, that way we can handle a single encoder failure.

9

^ Same, we typically just check if either is greater than target, and call it good. Close enough for FRC… We use $60 encoders, not wanting to buy another, to know which is broke, as I am broke. . .

10

Having two encoders also helps to ensure driving straight. The way we implement it can be found at https://github.com/FRC1458/turtleshell/blob/master/TurtleBot/src/com/team1458/turtleshell/pid/TurtleStraightDrivePID.java, we combine the gyro data and the difference (left - right) to figure out how much the motors need to drive differently.

11

Can you tell which one is behaving correctly and which one is failing? Or do you just abort if they are different enough?

12

His description suggests that it accounts only for an encoder reporting too few counts. If either of the two reaches the target, the code considers the travel distance satisfied and continues to the next step. Since the typical encoder failure results in it not counting at all, this is highly likely to have the desired result.

13

We have encoders and potentiometers on all of our joints, both for zeroing and fault detection. Last year we correctly e-stopped our elevators when one of the encoders got unplugged. Not the drivetrain, but still a use of redundancy.