Methods of Correcting the
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.
Look at the examples of output from quadrature
encoder, through a few cycles.