Rotary Encoders

With my upcoming robot arm project in mind, I bought a couple of these cheap Keyes KY-040 rotary encoders. Guess they may come handy for manually controlling servos with greater precision than potentiometers, especially in combination with the 12 bit resolution PWM controller that will drive the arm’s servos.

First I wanted to check that all encoders were OK (they could be Chinese clones of Chinese clones…), so I grabbed some sketches from the Internet. All sketches – with or without the use of interrupts – worked fine on all encoders, but I noticed that they would only count every second click of the encoder. As my encoders have 30 clicks (‘detents’) per revolution, using the technique from these sketches would reduce the resolution to only 15 steps per revolution of the shaft.

So, in order to find out what exactly happens with each click, I wrote this simple sketch:

Rotary encoders have two switches, A and B, that will be switched on and off when you turn the shaft, resulting in binary pulses on their CLK and DT connectors. Since the pulse sequence of  the switches are 90 degrees out of phase, you can not only count the pulses, but also detect whether the shaft is being rotated clockwise (CW) or counter clockwise (CWW).


The output of the above sketch showed that my type of encoder will click on every blue and every red marked event within the pulse sequence, whereas all sketches I’ve seen so far will count either the blue or the red events (i.e. full pulse cycles).

Once I understood why the sketches I found on the Internet ignored every second click of my decoders, it was time to write a sketch that would count every click, and tell me the direction as well. As the picture clearly illustrates, the values of A and B will be the same after every click. The direction is defined by which of them arrived at that value first. If it was A, then rotation is CW; if it was B, then rotation is CCW.

In order to detect every click of my decoder, I decided to attach a ‘CHANGE’ interrupt to switch A (marked CLK on the encoder). Note that attaching ‘CHANGE’ interrupts to both CLK and DT is useless.

A nice bonus of the encoder is that it has a third switch (marked SW), that is pulled to GND when you push the shaft. I decided to use this feature for cycling through different incremental step sizes, offering different resolutions for sending a servo to a desired position (coarse-, medium- and fine tuning).

Time to put it to work. The following sketch controls a two-servo pan/tilt module by reading two rotary encoders. It uses a 16 channel 12 bit PWM Servo breakout to drive the servos, but the sketch can easily be simplified if you drive them directly from Arduino PWM pins. The ‘step size per encoder click’ will cycle through values 1, 5 and 10  with each push of the shaft. Parameter values for debouncing were optimized after some testing.

In the end, this setup turned out to work remarkably well for controlling my pan/tilt module with two KY-040 encoders connected to an Arduino UNO.

Note that the code within interrupt routines ProcA1 and ProcA2 has been reduced to calculating the new servo position and setting an alert flag, while the overhead of polling within loop() is limited to checking these two alert flags. In sketches where single loop sequences can take long, one could improve responsiveness to encoder events by having the interrupt routines do all the work (including the actual servo control), although in general, that’s not recommended.

This approach will be used for my robot arm project, although I will have to drop the interrupt technique for some of the decoders because the UNO only has two pins for external interrupts.