Encoder falling behind

Programming Support VEXcode Pro V5 Text Tech Support
1

I’m trying to implement tracking wheels on my robot an I ran into an issue with my encoders. The right encoder seems to always be a bit behind the left one. For example, if I push the bot straight forward, the left encoder might read 300 while the right would read closer to 150. It’s almost like the right encoder is skipping every other frame. Anyone know why this might be?

Code:

LPos = LTrack.rotation(rotationUnits::deg);
RPos = RTrack.rotation(rotationUnits::deg);

Brain.Screen.setCursor(1, 1);
Brain.Screen.print("Left Encoder: %f", LPos);
Brain.Screen.setCursor(2, 1);
Brain.Screen.print("Right Encoder: %f", RPos);
2

Is it consistently off by a factor of 2 from the right side to the left side? If so, to troubleshoot this problem, I would suggest swapping the ports you’re using between left and right sides without changing any code to compensate. If the right encoder is now ahead of the left encoder, then you have a problem with the physical sensors. If the left encoder is still reading ahead of the right encoder, then something is going wrong with your code.

4 Likes
3

Make sure you have both cables connected and configured properly in your code. Quad encoders drop to half resolution and lose direction sensing when they only have one cable plugged in.

6 Likes
4

The port the sensor is plugged into does matter. If I’m not mistaken, you can only plug the quad encoders into ports A&B, C&D, E&F, and G&H(respectively). The grouping of these ports is relevant to the output of the sensor. I’m not sure why (at least that’s how it’s done in PROS to get proper readings). The order of the cables simply changes the sign of the encoder.

If you troubleshoot after doing these things, one of your encoders might be broken.

It is odd that it’s off by a particular factor. This could also lead me to believe something is wrong with your code.

5 Likes
5

The factor by which it is off is not consistent. Sometimes it will be almost correct and sometimes it falls up to 3x behind

1 Like
6

The code I posted above is the only code that affects the value of LPos, so I don’t see how the code could be a problem.

1 Like
7

I believe you have your ports assigned incorrectly; however it may be beneficial to open up the case and check for dust or debris.

1 Like
8

The way in which you define the encoders could impact the values the encoder returns. You did not include that in the code above.

1 Like
9

I just used the config window. LTrack is assigned to ports AB, and RTrack has CD

10

Oh okay, in that case, triple check to make sure the ports are connected properly (all those cables bunched together could get confusing). Also, I’ve had a similar problem to this in the past so try different port groups.

For some reason, (could be exclusive to the brain I had on hand) when I grouped the cables from port to port with no gaps in between, one of the return values was skewed. So try that. If all else fails, it is probable that something is wrong with the encoder itself, and has nothing to do with user error.

3 Likes
11

Ok so I took the lid off of the encoder like @2775Josh said and i’ve noticed that going over a certain part of the disk causes the encoder value to just hover up and down by a degree rather than reading the correct value. this makes me think I have a physical problem. However, I don’t see anything wrong with the disk when I spin it around. Any ideas?