Encoder Frequently-Asked-Questions

Q1: What is an encoder?
A1: An encoder is a sensor of rotational motion that translates information about this motion (shaft angle, speed and direction) into electrical signals that can be interpreted by a computer.

Q2: Are there different kinds of encoders?
A2: Yes, encoders can be broken down into two major classes: mechanical and optical encoders. Mechanical encoders are generally used for low RPM, low duty cycle applications, like the rotary dial on the front panel of audio gear. Optical encoders are designed for higher RPM, continuous duty applications where reliability is important. Encoders can also have different types of electrical interfaces, like binary coded digital and quadrature. Because they are easily the most popular encoder type used in robotics, this FAQ will be limited to optical encoders with quadrature output.

Q3: What kind of encoder do you recommend?
A3: I've used the Grayhill 61K and 63R series encoders with success. As long as you don't use an encoder that will generate a count rate that is too high, just about any optical encoder with quadrature output will work. Other manufacturers include U.S. Digital and CUI.

Q4: Where can I purchase the encoders mentioned above?
A4: Digi-Key carries a wide selection of encoders, including the ones mentioned above.

Q5: What kind of encoders did you use in the 2005 DemoBot?
A5: We used two Grayhill 61K128 encoders, each directly coupled to the the output shaft of their respective gearbox.

Q6: We've found that if we spin the encoder's shaft too fast, your software thinks the shaft is rotating in the opposite direction. What gives?
A6: Yes, this is one of the wacky effects I mentioned in the encoder software readme.txt file. What's happening is that the rising edge of the encoder's phase-A signal causes an interrupt to be generated. In the interrupt service routine, the state of the phase-B signal is interrogated to determine which way the shaft is rotating. If you spin the shaft too fast, the software can't sample the true state of the phase-B signal before it transitions to the opposite state. Here's an illustration that shows what's happing.

Q7: Okay, we're seeing the effect described in Q6, what can we do about it?
A7: You need to do some analysis to determine how bad the problem is. If you're generating thousands of counts per second, you'll need to do something drastic like changing your gearing or getting encoders with a lower CPR rating. If your 'bot works pretty well at lower speeds, but acts erratically at higher speeds, the simplest fix is to just limit the 'bots maximum velocity in software. If this is undesirable, you can use a circuit to stretch phase-B's pulse width to give the interrupt service routine enough time to properly read the state of the phase-B signal. The simplest circuit uses a D-type flip-flop (e.g., 74ACT74, 74HCT74, 74LS74, etc.). The encoder's phase-A signal goes to the the clock input and the RC interrupt input. The phase-B signal goes to the flip-flop's D input and the Q output goes to the RC digital input formally used by the phase-B signal. Here's a 74ACT74 data sheet and a schematic of the circuit.

Q8: We've added encoder.c/.h to our project and call Initialize_Encoders( ) as instructed, but when we spin our encoder we get the red-light-of-death. We can load the included encoder.hex file, which works just fine. What gives?
A7: Well, it seems I forgot to mention that the encoder interrupt routines, Left_Encoder_Int_Handler( ) and Right_Encoder_Int_Handler( ), need to be installed in the user_routines_fast.c/InterruptHandlerLow( ) function. Bad things happen when an interrupt fires off without a service routine to handle it. Anyway, these two functions should be the first in the interrupt handler chain. Have a look at the copy of
user_routines_fast.c included with frc_encoder.zip or edu_encoder.zip to see how this is done.

Last Update: 10/18/2005 at 11:42 PM PDT
Copyright ©2005 R. Kevin Watson