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

Wed Sep 5 10:14:23 CDT 2001

It depends on the rise of the signal.

If the transition from one level to the other is slow then the hysteresis of
using a schmitt trigger will allow some movement without changing the signal
level.  That is good. But it limits your resolution.

However, if the transition is fast, then you can have a higher resolution,
but you also have more likelihood of seeing the effects of jitter.

Kip

----- Original Message -----
>From: "Dan Creagan" <dcreagan at bellevue.edu>
To: "Kipton Moravec" <kip at kdream.com>; "Dan Miner" <miner at centtech.com>
Cc: "DPRG List" <dprglist at dprg.org>
Sent: Wednesday, September 05, 2001 9:54 AM
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