Servo - July 2008

Methods of Correcting the Problem

There are a few different methods of fixing this problem. In a nutshell, we just need to reduce the number of transitions of the encoder per revolution. Obviously, the encoder itself could be swapped out with a lower resolution one. If feasible, it may be possible to replace just the encoder disk with one that has a fewer number of holes. Another option is to change the physical placement of the encoder within the drive train. When it is directly attached to the armature of the motor, it may send out too many pulses. If it was moved downstream to the wheels themselves or at some point in the gear train, it would slow down the speed of the encoder. It will still be sending the same number of pulses per revolution of the encoder but it will be rotating slower so we get the effect we’re after. Instead of altering the mechanics of the encoder — which isn’t always an option — we can look into electronic means of scaling the values. At first, I considered making something up with standard logic ICs but an easier and more flexible option was to use a small microcontroller to help match up the readings. Whatever method is selected, we would like the encoder to supply as high as possible a resolution without sending them too fast for the controller to handle.

Microcontroller to the Rescue

I’ve run into this problem with other encoders and controllers. I wanted a flexible solution so I decided to use a small microcontroller to scale the encoder readings. This ended up being an excellent solution that can be used for other projects, as well. I selected an SX28 processor and wrote all the code in SX/B. This development went really fast. I started building the encoder scaling board one evening and had a working prototype with the core functionality the next day. Everything is handled by the

Encoder assembly on robot base.

40 SERVO 07.2008

single SX28 chip which costs under $3. A few more features were then added and the code cleaned up to make it more presentable.

One of the extra features is the ability to allow a host controller to change the scaling factor on the fly. Since it will accept commands via serial connection, I also added a resonator for the clock timing to ensure the serial communications would be reliable. This microcontroller will be installed in between the existing encoder and the controller. This way, it can monitor the encoder, condition the signal, and output a virtual encoder signal to the host controller.

Quadrature Encoders 101

Many of you already know how tachometers and quadrature encoders work, but for those who don’t, here is a quick review. A tachometer signal only has one signal and therefore only provides speed information and not any directional information. It will only tell how fast something moved but not any details about the direction of travel. It can be used to get an estimate on distance traveled as long as the direction is known ahead of time. However, a problem can come up if the tachometer stops at a transition (edge). If there are any vibrations, it can toggle state back and forth and mistakenly give the impression that it is moving. It is more suited to regulate the speed of a motor where distance /direction are not important; just the speed is critical.

Adding a second channel makes all the difference! A quadrature sensor will have two signals 90 degrees out of phase. These two signals are commonly referred to as Channel A and Channel B. With these, both position and direction can be determined. The direction is determined by comparing if Channel A is leading Channel B or if Channel B leads Channel A. The distance can be computed by keeping track of the counts and factoring in the direction of movement. Velocity can be calculated by counting the number of pulses per second. I’ve seen some references to encoders that state: “If A leads B, for example, the disk is rotating in a clockwise direction. If B leads A, then the disk is rotating in a counter-clockwise direction.”

That may be true for some encoders, but needs to be verified for the particular encoder being used. I prefer to just think of them as two channels of information and look at which one is leading, then match that to the actual direction of how it is installed in the robot. The clockwise/ counter-clockwise description isn’t something that lends itself well to straight quadrature encoders, so keeping it generic works out well. After all, it shouldn’t matter if it is clockwise/counter-clockwise, right/left, up/down, forward/back, etc. The important part is that two distinct directions can be determined; the rest is relative.