DPRG List  

DPRG: Strategy

Subject: DPRG: Strategy
From: Kevin Ross kevinro at nwlink.com
Date: Thu Jul 31 11:44:48 CDT 1997

- ----------
> From: Eric B. Olsen <robojoc at worldnet.att.net>
> To: dprglist at dprg.org
> Cc: Strategy at horta.ncc.com; opinion at horta.ncc.com
> Subject: Re: DPRG: Strategy
> Date: Wednesday, July 30, 1997 8:09 PM
> Because your encoder gives 1000 pulses per revolution, you can expect a
> one millisecond pulse rate at the slow speed of one revolution per
> second.  If this is also your wheel speed, you'll expect a pulse every
> 200us at five revolutions per second ... a moderate speed for your
> robot, but possibly too fast to want to keep up with using interrupts. 
> Thus, I would suggest you divide down the number of pulses per second
> generated so that you have an acceptable interrupt rate at your highest
> robot speed (say every millisecond), and use your timer to measure the
> time duration between pulses.

5 revs per second on a reasonable sized wheel would be haulin' butt! On a
6" wheel, thats a little over 7.8' per second. (5 mph) Way, way, too fast.
Even at 1 rev per second, it would still be ~18" per second, which is also
much faster than you want. I have found that unless there is a real reason
to go fast, ~12" per second is more than adequate for almost any robot.
Even at that speed (about .7 mph), taking your eye off for just 5 seconds
can put the machine in trouble. Since I heard power window motors, I assume
this is a slightly larger robot?

The 68HC11 is perfect for this application. The TIC channels can be set to
generate an interrupt and to capture the time of the change on the pin. You
can program it to interrupt on rising, falling, or both edges. It captures
the time in a 16-bit register. Its actually pretty easy to implement this
on the HC11. At 8mhz crystal, the clock resolution is 500ns. Assuming you
tone it down to .3 revs per second, you should have plenty of time to deal
with this. 



More information about the DPRG mailing list