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: Thu Aug 23 16:27:50 CDT 2001






> Hi DPRG and Kip,
>
> Kip wrote:
>
> > 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
>
> I did run into this problem with the legobot, but have not seen it on
SR04.
> This may be because I clip small PWM values to 0, effectively turning the
> motor off and providing a "dead-band" around the motor stopped position.

No this is independent of the PWM.  It is the sensor reading.  If your motor
stops on the line of the encoder, then anything (vibration, wind, etc) could
wiggle it between seeing white and black. The second encoder since it is 90
deg. out of phase will stay on it's current position, unless the wiggle is
big compared to the resolution of the emcoder.  This could cause you to
increment or decrement your counter many times (once for each wiggle) when
in fact the wheel is not turning.

>
> > 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.
>
> As Dan Miner wrote, the 68332 also has hardware functions built into the
> Timer Processor Unit (TPU) to read high speed quadrature encoders.  So
interrupts
> are not needed.  Seems like the more counts the better, in general.
>
> > 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?
>
> A very good question.  My current crop of 'bots use only 100 separate PWM
divisions,
> however, they are not evenly spaced.  Clay has demonstrated that the motor
> response to DC voltage changes are linear.  So a motor that gives X rpm
for
> Y voltage will give X/2 rpm for Y/2 voltage, etc.  The response of the PWM
> signals however is not linear.  I think this is because a linear change in
> pulse width does not represent a linear change in RMS voltage.  The pulse
height
> remains the same, and the RMS voltage can be thought of as the area under
the
> curve, in this case, width*height.
>
> So the pulse widths must be spread out to produce a linear speed response.
Even
> though it only takes 7 or 8 bits to specify the required number of speeds.
I do
> the translation with a lookup table.  The table has 100 entries, so it can
be
> accessed with an 8 bit index.  But the table values themselves are 16
bits.  In the
> case of the HC11, these represent "E-Clock" cycles, which are at 2 MHz.
The shape
> of the curve in this table represents the non-linear response of the PWM
function
> and also the friction and efficiency of the particular motor/geartrain.
Here is the
> table that does the translation on SR04, which runs the PWM at 120 Hz:
>

Looking more closely at the numbers your maximum number is 0x3F00 so it
means that your maximum PWM on time is 0x3F00/0xFFFF and not 1?  If it is 16
bits it is approximately 25% of maximum.  That strikes me as odd.  Why is
your maximum speed only about 24% of full on?

Of course the other side, is it could only be 14-bits, and that represents
about 95% full on.  Even so, why not 100% for maximum?

Am I misunderstanding something subtle here?

Kip






>
; --------------------------------------------------------------------------
--
> ; pwm120hz.dat linear pwm table for srat04 motors.
> ; 09 Feb 98 dpa
> ;
> ; This file converted from Motorola asm11 to Baldwin assembly
> ; Mon Feb 9 18:14:04 CST 1998  by 'ascnv' from
../srat03/include/m120hz.asm
> ;
> m7_table:
> .word 100 ; table length
>
>                                 ; index hex_value
> .word 0000 ; 0 600
> .word 1543 ; 1 607
> .word 1564 ; 2 61c
> .word 1597 ; 3 63d
> .word 1640 ; 4 668
> .word 1690 ; 5 69a
> .word 1746 ; 6 6d2
> .word 1805 ; 7 70d
> .word 1867 ; 8 74b
> .word 1928 ; 9 788
> .word 1987 ; 10 7c3
> .word 2042 ; 11 7fa
> .word 2091 ; 12 82b
> .word 2134 ; 13 856
> .word 2173 ; 14 87d
> .word 2207 ; 15 89f
> .word 2239 ; 16 8bf
> .word 2270 ; 17 8de
> .word 2299 ; 18 8fb
> .word 2328 ; 19 918
> .word 2358 ; 20 936
> .word 2389 ; 21 955
> .word 2423 ; 22 977
> .word 2461 ; 23 99d
> .word 2502 ; 24 9c6
> .word 2546 ; 25 9f2
> .word 2592 ; 26 a20
> .word 2640 ; 27 a50
> .word 2689 ; 28 a81
> .word 2738 ; 29 ab2
> .word 2787 ; 30 ae3
> .word 2836 ; 31 b14
> .word 2883 ; 32 b43
> .word 2929 ; 33 b71
> .word 2972 ; 34 b9c
> .word 3013 ; 35 bc5
> .word 3053 ; 36 bed
> .word 3093 ; 37 c15
> .word 3133 ; 38 c3d
> .word 3174 ; 39 c66
> .word 3217 ; 40 c91
> .word 3263 ; 41 cbf
> .word 3313 ; 42 cf1
> .word 3367 ; 43 d27
> .word 3427 ; 44 d63
> .word 3493 ; 45 da5
> .word 3564 ; 46 dec
> .word 3641 ; 47 e39
> .word 3721 ; 48 e89
> .word 3805 ; 49 edd
> .word 3890 ; 50 f32
> .word 3976 ; 51 f88
> .word 4062 ; 52 fde
> .word 4147 ; 53 1033
> .word 4230 ; 54 1086
> .word 4309 ; 55 10d5
> .word 4384 ; 56 1120
> .word 4456 ; 57 1168
> .word 4525 ; 58 11ad
> .word 4593 ; 59 11f1
> .word 4661 ; 60 1235
> .word 4732 ; 61 127c
> .word 4806 ; 62 12c6
> .word 4886 ; 63 1316
> .word 4972 ; 64 136c
> .word 5067 ; 65 13cb
> .word 5171 ; 66 1433
> .word 5288 ; 67 14a8
> .word 5415 ; 68 1527
> .word 5553 ; 69 15b1
> .word 5699 ; 70 1643
> .word 5852 ; 71 16dc
> .word 6009 ; 72 1779
> .word 6168 ; 73 1818
> .word 6329 ; 74 18b9
> .word 6489 ; 75 1959
> .word 6645 ; 76 19f5
> .word 6798 ; 77 1a8e
> .word 6943 ; 78 1b1f
> .word 7084 ; 79 1bac
> .word 7227 ; 80 1c3b
> .word 7381 ; 81 1cd5
> .word 7555 ; 82 1d83
> .word 7758 ; 83 1e4e
> .word 7997 ; 84 1f3d
> .word 8282 ; 85 205a
> .word 8621 ; 86 21ad
> .word 9023 ; 87 233f
> .word 9496 ; 88 2518
> .word 10049 ; 89 2741
> .word 10683 ; 90 29bb
> .word 11377 ; 91 2c71
> .word 12104 ; 92 2f48
> .word 12841 ; 93 3229
> .word 13561 ; 94 34f9
> .word 14240 ; 95 37a0
> .word 14852 ; 96 3a04
> .word 15372 ; 97 3c0c
> .word 15775 ; 98 3d9f
> .word 16035 ; 99 3f00
> m7_end:
>
> ; --------------------------------------------
> ; eof
>
> >
> >
> >
> >
> >
> > ----- 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