DPRG List  

[DPRG] Home-brew encoders for Pittman Motors

Subject: [DPRG] Home-brew encoders for Pittman Motors
From: Dan Creagan dcreagan at bellevue.edu
Date: Wed Aug 22 13:17:54 CDT 2001

I'm not doing quadrature. My PID scheme knows if the motor is going
forward or backward so quadrature is not needed for my layout.

I put a 4 segment disk on the back. 4 x ~60 ~= 240 steps per wheel
revolution.  With 3" wheels, that is pretty fine grained. pi * 3/240(~)
= .039 inches surface movement per click; much more accurate than needed
since other factors such as wheel slip and gear lash will negate such
precision in the long run.

The tubing from the top rail of a chain link fence is just about right
for a back cover. Cut the tubing shorter, of course. ;-}  The necked
down portion is about the same size as the Pittman body and the
un-necked part just fits over the body.

-----Original Message-----
>From: dprglist-admin at dprg.org [mailto:dprglist-admin at dprg.org] On Behalf
Of David P. Anderson
Sent: Wednesday, August 22, 2001 12:52 PM
To: dprglist at dprg.org
Subject: [DPRG] Home-brew encoders for Pittman Motors


I've been playing some with my new Pittman motors, and my new MRM 68332
board, (more on that to come).  I've come up with two schemes for
home-brew quadrature encoders for these motors.  Both schemes use paper
encoder wheels printed on a laser printer and super glued to the rear
motor shaft, like on SR04 and my LegoBot.

I'm planning to run these motors off 12 NMH cells, which works out to
about 15 volts fully charged.  I bought a 12 cell charger from Mike's
Hobby that's intended to charge R/C airplane batteries, (those guys
often use 10 and 12 cell packs), and a 15 volt 3 amp DC supply from
Tanner's to power the charger.

Motor speed:

Working backward, the gearhead is spec'd at 128 rpm at 19.1 volts, we
measure about 70 rpm at 12 volts.  That's something like 6 rpm per volt,
if the response is linear.  So,

	15 volts * 6 rpm/volt = 90 rpm

The gearhead has a 60:1 ratio, so the motor speed at 15 volts would be

	90 rpm * 60 = 5400 rpm motor speed

Or to put it another way

	5400 rpm / 60 seconds/minute = 90 revolutions per second.

My last generation of robots had a read-sensor-write-output cycle time
of 10 hz, or 100 milsec.  The current generation I increased the rate to
20 hz, or 50 milsecs.  Same as the Space Shuttle.  This allows the robot
to respond more quickly and also more smoothly.  For the new robot I'd
like to increase that again to 50 hz, a 20 milsec period.  I think the
25 mHz 68332 will be plenty fast enough to handle this update rate.

Encoder segments:

This number is needed to know how many encoder ticks are required for
smooth speed control.  SR04 returns 1000 ticks per second per wheel at
full speed. Since it's update rate is 20 hz, that means 

	SR04 = 1000 ticks per second per wheel
	1000 ticks / 20 hz sample rate = 50 ticks per sample at full

Slow speed is defined as full speed / 10,  so

	50 ticks per sample full speed / 10 = 5 ticks per sample, slow

5 ticks is close to a minimum number required to do smooth speed

To have the same granularity on the new bot will require 

	50 ticks/sample * 50 samples/second = 2500 ticks per second,
full speed. and
	2500 ticks per sec / 90 revs per second = 27.78 ~ 28 ticks per

So I need paper encoder wheels printed with 28 black and white
divisions.  I have a postscript program that can print encoder disks of
arbitrary size with arbitrary number of divisions, which I can post for
anyone who is interested.

These encoders are read very robustly by the Hammamatsu IR
emitter/detector unit sold by Acroname and Zargos as previously
discussed on this list.  A single unit can be used to count encoder
divisions for velocity information.  That's all SR04 has.  Two are
required to read both velocity and direction.  This is what I'm planning
to implement for the new robot.

Quadrature Encoding:

Quadrature encoder is actually pretty simple in this case.  The two
Hamamatsu's are mounted such that when one is "seeing" the edge between
a black and white segment, the other is centered in a segment.  In the
example below of a 6 segment encoder, B = black, W = white, and the
Hammamatsu's are labeled {1} and {2}.

                            \   B   /
                             \     /
                        W    {1}  /     W
                               \ /
                               / \
                         B    /   \     B 
                             / {2} \    
                            /   W   \

Assume the disk is spinning clockwise.  Detector {1} in this example is
seeing a 
falling edge, (a white to black transition) and detector {2} is centered
in a white segment.  When detector {1} sees the next rising edge (black
to white) then detector {2} will be centered in a black segment.

Now assume the disk is spinning counter-clock-wise.  Detector {1} is
seeing a rising edge (black to white) with detector {2} centered in a
white segment. When detector {1} sees the next falling edge (white to
black) then detector {2} will be centered in a black segment.

All the microprocessor has to do is to detect when {1} has encountered a
rising or falling edge and then read the state of {2} to know the
direction.  The HC11 and similar processor have builtin hardware for
detecting edges and generating interrupts.  The 68332 can do all of this
in hardware with "TPU" channels.

Encoder mounting:

My first scheme for mounting the Hamamatsu encoders was to make a PC
board disk with a hole in the middle that mounts directly to the back of
the motor.  The encoder disk will be glued to the motor shaft with the
pattern facing "down" toward the PC disk, after the board is mounted.
But it doesn't look like there is enough room between the back of the
motor and the end of the shaft.

The second scheme is to glue the encoder disk to the motor shaft "face
up" and mount the Hammamatsu's in something like a plastic film canister
which would slip 
over the motor from the back.  This would have the advantage that the
detector-to- disk distance could be adjusted by sliding the canister in
and out.  It would also protect the paper disk from clumsy hands and
shield it from other light sources.  The canister could probably be held
in place with something like a cable-tie.  Of course handy light-proof
black plastic film canisters don't happen to be the right size, but you
get the idea.

Eric, Barry, anything to report?


DPRGlist mailing list
DPRGlist at dprg.org http://nimon.ncc.com/mailman/listinfo/dprglist

More information about the DPRG mailing list