DPRG
DPRG List  



[DPRG] Home-brew encoders for Pittman Motors

Subject: [DPRG] Home-brew encoders for Pittman Motors
From: Dan Miner miner at centtech.com
Date: Wed Aug 22 23:31:46 CDT 2001

I'm not dpa, but I believe the 68332 has built in hardware
for the quadrature encoders.  It's a *VERY* powerful piece
of hardware Motorola calls a TPU.  (Time Processing Unit???)
It will do input capture, output compare, PWM for its
"simple" modes and quadrature encoding (plus LOTS of other
stuff) in more advanced modes.

Regarding PWM resolution - One of my robots had a problem
with that.  At slow speed I really wanted a PWM value of
(let's say) 12.25 but the software chould choose only 12
or 13.  What would happen is the SW would choose 12; the 
motor would slow down too much.  Then the SW would choose 13
and the motor would be too fast.  This happened roughly 
every 1 or 2 seconds - it was annoyingly noticeable.

What I did to get around this is my software would keep
8 integer bits and 8 fraction bits.  I would look at the
upper 3 bits of the fraction and dither the PWM values
at high speed.  

Like this: (for 12.25) 13,13,12,12,12,12,12,12 (repeat)
The PWM hardware was updated at a 1kHz rate.
This is VERY effective and was fairly easy to impliment.

The algorithm is:
1) Convert the upper 3 fraction bits to an integer (by 
 shifting left 3 times) in the range of 0 to 7.  
 Set variable F to this value.

2) Set P to the integer part of the desired PWM value.

3) Output the value P+1 to the hardware F times.
   (Note that F can be 0.)

4) Output the value P to the hardware 8-F times.

Thus, I have an effective 11 bit PWM from 8 bit hardware.
(Actually, I have 8.3 bit PWM - 8 bits of integer and 3
bits of fraction.)

				- Dan


> -----Original Message-----
> From: Kipton Moravec [mailto:kip at kdream.com]
> Sent: Wednesday, August 22, 2001 3:16 PM
> To: David P. Anderson
> Cc: DPRG List
> Subject: Re: [DPRG] Home-brew encoders for Pittman Motors
> 
> 
> 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
> 
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://nimon.ncc.com/mailman/listinfo/dprglist
> 

More information about the DPRG mailing list