Wheel Odometry and Dead Reconning
The following page attempts to give meaningful answers to some of your motor, shaft encoder, and CPU questions regarding odometry. This is a rather difficult set of questions, so let's take it one step at a time.

Motors are typically Direct Current (DC), and are fairly small. Torque is a measurement of how much weight a given motor can move. Current Draw is a measurement of how much power a given motor requires to move with a given torque a given weight. The more current draw, the faster your batteries discharge, the larger the control circuitry you have to have, and (typically) the heavier the motor.

Shaft encoders are a way to measure angular changes in output shafts, such as the one coming out of your motor. In the discussion that follows, modern optical shaft encoders are the primary thing discussed, but there are other, more mechanical (or audio things) that can be used.

A given shaft encoder, attached to the direct output wheel of a robot, generates a train of pulses to the CPU that indicates that the given wheel moved a number of degrees of rotation. When you turn on your motor to move in a given direction, the shaft encoders, in returning the information to the CPU, give the robot a sense of how much distance it is covering.

Odometry is the engineering task of using this type of feedback to ESTIMATE where the robot is in its physical environment. It is strictly an estimate because of a number of physical limitations on the motors, gear boxes, interconnections, etc. that are involved, along with inertia, vary so greatly.

Let's face it, the size of most modern wheels is a bit of a guess. Perfect no load wheel diameter (i.e., no deformation due to weight) is different than when the same wheel is under load. Some production wheels are not perfectly circular, even under no load.

In summary, here are a few of the questions that need to be discussed to determine what is best for a given physical system.

  1. How big your wheels are. The bigger the wheel, the more pie shaped light and dark spots you can put on them.
  2. What kind of sensor do you have? Slot encoder? Reflective object? Mechanical? This is drives a couple of other things:
    1. What kind of clearances, linkages, etc. do you have to have between the motor and the wheel? This will affect the physical construction of your robot, something not covered here.
    2. What is the smallest diameter thing your sensors can detect? This controls how many pie shaped segments you can put on your wheels to control travel.
    3. How close to the axle can you place your sensor? One half inch axle implies your sensor can be no closer than that one half inch.
  3. How fast do the wheels turn? This gives rise to amount of time it takes for each one of these segments to go flying by the sensor (as well as how long you have before the next one comes by that you then have to service via your CPU).

Knowing the answers to these questions, you can then go about creating a wheel encoder. This web page/form helps you see a narrow range of results using different values.

Hence, what this page attempts to do is just to give you some idea of how much travel your wheel will make given one pulse back on your shaft encoders.

Go to the top...

Generate a Reflective Shaft Encoder

Given that you want to determine some specs on your motors, here is a tool that might well help you out. Once you insert the values for your physical constraints, this tool will give you various bits of information that you will hopefully find useful.

Enter the diameter of your wheels
(input units will match output)
Enter the radius where your
encoder will sit.
Enter the smallest resolution your
shaft encoders can see (same units please)
Enter your motor's RPM.
Enter your shaft radius (same units please)
Enter your units.