To calculate the turn angle of robot using interrupts.

I am unfamiliar with the Z8 (having worked mostly with Atmel AVR's),
but I am assuming that you have support for two separate
I/O interrupts on two different pins,
one for each wheel.  I would think that the Z8 probably implements
some kind of queing mechanism for interrupts so that if one arrives
while your controller is servicing the other, you can be sure that
the second one will be handled when the controller is ready
to do so.

If so, then there really isn't any problem. The orientation
computation for a differentially steered robot is cummulative.
As long as you have some way of knowing what direction your
wheels are turning, you're fine. For example, if your robot
is traveling in a nearly straight line, it will probably receive the
signal from one encoder before it receives the signal from the
second.  So for a short time your robot will think that it is turning
to the left, but ultimately the second signal will arrive and
it will correct that to back to a straight line.  The key is
to integrate the readings over time.

The computation for orientation (theta) is simply

theta = (Sr-Sl)/W

were Sr is the displacement of the right wheel, Sl of the left,
and W is the width of your wheel track (distance from wheel to wheel).
Note that whatever distances you measure all drop out, so that
the computation is unitless.  Working with simple controllers
in the past, I have been able to simplify my computations
(and eliminate messy conversion factors), by treating all distances
as "encoder clicks".  Thus if one encoder click represents
0.25 centimeters of displacement, and the robots wheel track is
10 centimers wide, then I define Sr and Sl as simple counts and
treat W = (10/0.25) or 40.  It doesn't matter if you treat the
worlds in terms of meters, feet, furlongs, or lightyears, as
long as you apply a consistent metric.

If you perform a Google search on

  "differential steering" equations

you will find a number of useful references giving equations
for differential steering.  You can also try

   "differential steering" odometry

Hope this helps.

                                     gary



amr wrote:

The only problem might be that if the encoder is of sufficiently high
resolution and/or the wheels are spinning at sufficiently high speed
that two or more interrupts would occur before they could be serviced,
and thus encoder counts could be lost.  This can happen, even when
using a fast processor and tight interrupt routines given a
combination of sufficiently high resolution encoders and fast motors.

It's necessarily the end of the world, but it is another source of
error in your calculations.

-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/