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

Fri Sep 7 17:46:47 CDT 2001

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