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

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