Walking Encoder Values

[JoeyPass]

We have two active Encoders on our robot that read the positions of our arm and wrist. After a couple of movements and bringing the arm and wrist back to starting position we are getting increasing values. It should be reading near zero each time we return to the initial positions but on the arm we get increasing or "walking values" in increments of about 4 - 6 per iteration. Has any one encountered this and do you have any suggestions.

Thanks,

[MagiChau]

I would have limit switches that when hit, reset the encoder.

[Chris27]

A properly working encoder shouldn't drift very much. Are you sure that the encoder isn't slipping?

[JoeyPass]

Absolutely positive that it is not slipping. This encoder (the hat) is set on very tightly.

[DonRotolo]

What kind of encoder?

[JoeyPass]

Optical encoder.

[Teched3]

Is the encoder connected directly to an axle? If that is the case, then possibly the axle is slipping. We use reinforced rubber fuel line between our encoders and axles, and then tighten safety wire around each shaft, us well as file a flat on the axle to ensure no radial creep occurs between them. Enlighten us further on how it is set up and maybe we can help you solve the problem.

[plnyyanks]

Is there the possibility of any EMI with the encoder. We had a bad motor interfering with an encoder, causing the values to be dramatically different than what they should be

[DonRotolo]

Two common reasons for an optical encoder to slip are:

Mechanical: There is mechanical slippage. Check this carefully, don't assume anything.

Computational: Your input circuit is missing some of the encoder's output pulses. If you are using a hardware interrupt, then your encoder resolution (pulses per revolution) may be higher than the hardware can manage. If you are not using a hardware interrupt, that could be your problem.

[apalrd]

Originally Posted by DonRotolo

Computational: Your input circuit is missing some of the encoder's output pulses. If you are using a hardware interrupt, then your encoder resolution (pulses per revolution) may be higher than the hardware can manage. If you are not using a hardware interrupt, that could be your problem.

If you are using the cRio's Encoder or Counter modules, they are handled with dedicated hardware in the FPGA, and should never drop counts in any reasonable encoder.

[Teched3]

what is your encoder pulse rate/ rev? When we First starting using them years ago, the pulse rate was too high for the software/computer to keep up. As Don noted earlier, eliminate mechanical slip, and then triple check software code. Have you marked the connector, encoder, and axle to visually see if it creeps?

[Kingofl337]

Can you use a multi-turn POT instead?