DPRG mailing list archives: [DPRG] Handy Board and Encoders

Fri Sep 7 19:45:58 CDT 2001

The issue that I am having is that there are 2950 pulses per wheel
revolution, and that is just too much for the Handy Board to deal with
unless I keep it down to some ridiculous low speed.  I had thought about
using a PIC to read a single encoder, but I'm not sure it can keep up either
and still be able to hand off the count to something else.

Ed Okerson

----- Original Message -----
>From: "Dan Creagan" <dcreagan at bellevue.edu>
To: "'DPRG List'" <dprglist at dprg.org>
Sent: Friday, September 07, 2001 5:46 PM
Subject: RE: [DPRG] Handy Board and Encoders

> After running a series of tests on my two robots, I could not duplicate
> jitter - both 'bots were using Schmitt triggers out of the pattern
> detectors.
>
> If I did accidentally count a stripe when I wasn't supposed to, it got
lost
> in all the other small errors that occur when you actually run a 'bot
across
> a surface.
>
> Stopping did not produce incorrect clicks - I simply slowed down when
> approaching the target and then threw the brakes on and it stopped dead.
>
> I could never duplicate a case where the bot would rock back after a
stop -
> with locked anti-phase it stops on bumps and everything else with good
> repeatability.
>
> So... with my simple encoding scheme I don't see the jitter or detection
> issues. I'm using a dedicated PIC for the motor controller and I'm
sampling
> without interrupts. Is there something different about the HC/Handy Board
> stuff - or the encoder hookups that people are using - that brings out
this
> issue?
>
> Dan
>
> -----Original Message-----
> From: dprglist-admin at dprg.org [mailto:dprglist-admin at dprg.org]On Behalf
> Of Ed Okerson
> Sent: Friday, September 07, 2001 5:22 PM
> To: R. Bickle; 'DPRG List'
> Subject: Re: [DPRG] Handy Board and Encoders
>
>
> I for one would like to see schematics for everything you talked about!
>
> Ed Okerson
>
> ----- Original Message -----
> From: "R. Bickle" <rbickle at swbell.net>
> To: "'DPRG List'" <dprglist at dprg.org>
> Sent: Wednesday, September 05, 2001 10:55 AM
> Subject: RE: [DPRG] Handy Board and Encoders
>
>
> > Jitter is an age old problem with optical encoders. You are right about
> the
> > schmitt trigger Dan. There are two solutions as far as I know. Either
add
> > hysteresis, either with schmitt triggers or manually. (Sometimes,
> depending
> > on the characteristics of the encoders you may need more hysteresis than
a
> > Schmitt trigger has.) The other alternative is of course to use
quadrature
> > encoders. There are several techniques for quadrature encoders which
will
> > totally eliminate jitter. (I have even had trouble with flourescent
> lighting
> > activating the optointerrupters when they are just at the threshold.)
> > Anyway, you can take the two channels of the quadrature signal and feed
a
> SR
> > flip flop. This will reduce the frequency by 1/2, but will ignore
multiple
> > counts from one channel. Also, you can take the quadrature signals and
> feed
> > a D flip flop which is a simple way of indicating direction. I can post
> some
> > schematics for hysteresis circuits if anyone is interested.
> >
> > On my Model 1 robot, I have used quadrature to increase the resolution
of
> > the encoders. I have 125 slot per revolution transmissive encoders. I
> > decided that I would like a higher resolution, so I changed the
> > optointerrupters to quadrature types. I then fed the quadrature signals
> into
> > an exclusive-OR gate which results in the difference between the two
> > channels. (i.e. double the frequency) I then fed the result into a
> > microcontroller interrupt and the inverse of the signal into another
> > interrupt. Since the interrupts fire on the falling edge, I now have an
> > interrupt which fires on the rising and on the falling edge of the
XOR-ed
> > pulse train. In effect, I have increased the resolution of the encoder
> from
> > 125 to 500.
> >
> > Rick Bickle
> >
> > -----Original Message-----
> > From: dprglist-admin at dprg.org [mailto:dprglist-admin at dprg.org]On Behalf
> > Of Dan Creagan
> > Sent: Wednesday, September 05, 2001 9:54 AM
> > To: Kipton Moravec; Dan Miner
> > Cc: DPRG List
> > Subject: RE: [DPRG] Handy Board and Encoders
> >
> >
> > Several have mentioned the case of the motor stopping and the encoder
> being
> > on a line. Thus causing jitter.  I have not observed this in practice
when
> > using a Schmitt triggered detector (like the Hamamatsu has - or adding
my
> > own on when using other detectors).  Is this a real problem when it is
> > properly accounted for?  Generally, I wouldn't think I would be sampling
> if
> > the motor is stopped.
> >
> > I *have* seen it occur when I didn't use a Schmitt.
> >
> > Dan
> >
> > -----Original Message-----
> > From: dprglist-admin at dprg.org [mailto:dprglist-admin at dprg.org]On Behalf
> > Of Kipton Moravec
> > Sent: Wednesday, September 05, 2001 9:09 AM
> > To: Dan Miner
> > Cc: DPRG List
> > Subject: Re: [DPRG] Handy Board and Encoders
> >
> >
> > The other option is to use a CPLD and let the hardware keep track of the
> > counts.  The processor just sees a data register, 8- 16- or 24-bits for
> each
> > channel.
> >
> > If it is only 8 bits you have to sample the data 1 time every 128 clocks
> > encoder steps (or faster).  That means at least every 2.56 milliseconds
> > which is better.  If it is 16 bits, then it is every .65 seconds.  Since
> you
> > should be closing the loop in your controller faster than that which
> should
> > be easier, but I think either 8- or 16- bits will work.
> >
> > We still get back to the jitter problem.  David Anderson says he has not
> > seen it, but I do not see how it can not be there, unless the motor has
> > detents. (Which I doubt).  The concern is what happens when the motor
> stops
> > and the encoder interrupt is on the line.  It is possible that it can
> start
> > to wiggle enough that it starts sending interrupts because it is
switching
> > from black to white or on and off. Even though the motor is not turning.
> > Since the other sensor is still in the middle of its color, the counter
> will
> > count either up or down.
> >
> > To avoid this, you need a state machine.  That can only be done in
> hardware.
> > The microcontroller is not fast enough.
> > The state machine is what the LS7803 and LS7804 are.  Or you can roll
your
> > own with a CPLD.
> >
> >
> > Kip
> >
> > ----- Original Message -----
> > From: "Dan Miner" <miner at centtech.com>
> > To: <dprglist at dprg.org>
> > Sent: Wednesday, September 05, 2001 1:22 AM
> > Subject: RE: [DPRG] Handy Board and Encoders
> >
> >
> > > A slight math typo:
> > >
> > > > ... 50k per second, about 1 pulse every 2 microseconds...
> > >
> > > That should be 1 pulse every 20 microseconds.
> > >
> > > Still way to fast for Interactive C.  You could keep
> > > up with it using VERY finely tuned assembler but you
> > > could only do 1 channel and you'd have no time for
> > > anything else.
> > >
> > > Recommendation is to divide down the frequency of the
> > > signal using a counter chip (as David suggested) or
> > > switch processors to something like a 68332 (Mini Robo
> > > Mind) that has a TPU hardware that will keep track of
> > > the encoders for you.
> > >
> > > - Dan Miner
> > >
> > > > -----Original Message-----
> > > > From: David Peterson [mailto:robologist at yahoo.com]
> > > >
> > > > Hey Ed,
> > > >  Think those motors you've got run about 1000 rpm out the
> > > > gear shaft, which means the encoder end is twirling at about
> > > > 6000 rpm. Times 500 is 3 million per minute or 50k per
> > > > second, about 1 pulse every 2 microseconds possible (in no
> > > > load). A Basic Stamp 2 can pick up a 2 us pulse, but
> > > > probably not consecutively, so I'm guessing that a
> > > > Handyboard could as well. Storing all those pulses might be
> > > > the real problem. Trying to do 4x mode might be a problem
> > > > too, and the HCTL chip Tom mentioned could help, but think
> > > > it's $18+ (x2) unless it can be sampled. Oh, those encoders
> > > > should be HEDS 9100. Other quad encoder chips include the
> > > > LS7083 and 84 ($3 x 2) at
> > > > http://www.usdigital.com/products/ls7083-84/ which then
> > > > interface with a counter logic chip like a 74xx193. Also
> > > > there's the LS7166 ($12 x 2) and 266 ($16 x 1) too, more
> > > > direct to an MCU. I could be wrong about that price too.
> > > > David P
> > > >
> > > > ----- Original Message -----
> > > > From: "Ed Okerson" <eokerson at fw.telenic.net>
> > > >
> > > > > I am working on a robot that has Pittman motors with built
> > > > in encoders.  The
> > > > > encoders appear to be 500 slots per revolution of the
> > > > motor shaft, and the
> > > > > gearbox is 5.9:1.  Is it possible for the handyboard to
> > > > keep up with that
> > > > > pace of pulses?  Or do I need to implement some sort of
> > > > divider to reduce
> > > > > the pulse count?  So far just playing with Interactive C
> > > > and it's encoder
> > > > > routines, it seems to loose many pulses if the motor speed
> > > > is anywhere above
> > > > > the speed of a crippled snail.
> > > > >
> > > > > Ed Okerson
> > > _______________________________________________
> > > 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
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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
>