DPRG
DPRG List  



[DPRG] Home-brew encoders for Pittman Motors

Subject: [DPRG] Home-brew encoders for Pittman Motors
From: Kipton Moravec kip at kdream.com
Date: Wed Aug 22 15:15:56 CDT 2001

Good analysis.  I am also looking at shooting for 50 to 100 Hz loop closure.
However I plan to do the quadrature in a FPGA or more specifically a Xilinx
CPLD.

You may experience a problem when you are on the line with your technique.
If the motor stops and your "interrupt" signal lands on the line vibration
could cause the interrupt to fire multiple times.  The solution around it is
to build a state machine.  A good one that has already been reduced can be
found on the Xilinx web site.  I have it implemented in a macro in my Xilinx
SW.

The write-up is at: http://www.xilinx.com/xapp/xapp012.pdf

I am looking at a dual 16-bit counter with quadrature decoder in a 44 pin
PLCC.  It will be able to handle pulses as fast as 5 MHz.

The only reason not to have higher resolution is the number of interrupts.
By putting this in hardware, it no longer matters. You just read the
registers every time you need a sample. (100, 50 or 20Hz) Then the issue
becomes how many divisions can you reliably do.

If you can make an encoder do 5,000,000 ticks per second, then you need to
close the loop at least 77 times per second, or the counters will roll
over....  I don't think that will be a problem though. :)

Based on your years (and years) of experience, is 256 PWM divisions enough?
I have seen a few PWM generators that are 10 bits or 1024 divisions.  Is the
extra two bits worthwhile?





----- Original Message -----
>From: "David P. Anderson" <dpa at io.isem.smu.edu>
To: <dprglist at dprg.org>
Sent: Wednesday, August 22, 2001 12:52 PM
Subject: [DPRG] Home-brew encoders for Pittman Motors


>
> Hi
>
> 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 speed
>
> Slow speed is defined as full speed / 10,  so
>
> 50 ticks per sample full speed / 10 = 5 ticks per sample, slow speed.
>
> 5 ticks is close to a minimum number required to do smooth speed control.
>
> 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 revolution
>
> 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?
>
> cheers,
> dpa
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://nimon.ncc.com/mailman/listinfo/dprglist


More information about the DPRG mailing list