At its lowest level, odometry is almost always accomplished by encoders on the drive and/or steering systems. Occasionally, platforms will use encoders on nondriven idler wheels that contact the ground below the vehicle. These configurations are usually an attempt to eliminate the odometry errors resulting from drive-steering coupling.
Unfortunately, these configurations tend to be overly complex and unreliable, and have not generally found widespread usage.
An encoder tick is a change of a drive encoder by the amount of its smallest increment.
A position change smaller than a tick will not be detected, and the motion associ- X
Y
Figure 8.2. Absolute Cartesian and relative polar coordinate systems
ated with a tick will normally be approximated as a straight tick vector to be added to the platform’s position estimate. The higher the resolution of an encoder, the smal- ler the errors produced by these approximations will be.
Encoders are usually binary in nature, so their resolutions can be any power of two.
Typical resolutions range from 32 to 4096. Signals associated with the act of driving generally cause a tick interrupt to the navigation computer. Thus, for drive encoders, the important issue is the amount of travel represented by a single tick. If the tick distance is made too large, the odometry calculation will be inaccurate because it will be incapable of tracking fluctuations in the vehicle’s course during the tick interval.
On the other hand, if the resolution is needlessly small, the encoder will cause an excessive overhead for the computer it is interrupting. As a rule of thumb, the tick distance should be about one thousandth of the distance between the wheels or treads of the vehicle.
For those systems with steering encoders, the angle of the tick vector will be trun- cated (not rounded) to the resolution of the encoder. It is highly desirable that the steering encoder be mounted as close to the steered wheel(s) as possible, so that it is not affected by the mechanical backlash of the steering mechanism. The resolution of the steering encoder should be about a factor of three smaller than the backlash between it and the actual wheels. Typical resolutions will range from 1024 and up.
Figure 8.3 demonstrates many of the issues just discussed. In this case, the right tread has remained stationary while the tread on the left has driven one tick of distance d as represented by the large arrow.
D
Motors, Encoders,
& Gearboxes
d W
Left Tread Right
Tread
Bottom View
Figure 8.3. Odometry tick of skid-steered platform (seen from below)
First, we must determine the relative movement of the platform that probably resulted from the drive tick. This action has two effects; it both drives and turns the platform.
We will assume that traction is evenly distributed across both treads, so the platform pivots about the center of the stationary (right) tread. The center of the platform moves forward by the distance D, which is equal to half the motion of the driven tread:
D = d / 2
Note that D is actually an arc, but if the tick distance is small enough it can be as- sumed to be a straight forward move. By approximating all moves as minute straight vectors at a single heading, we are able to track any complex maneuver.
Because of this action, the platform steers clockwise by the angle α (remember we are looking from below). This angle is simply the arcsine of the tick distance that the right tread moved, divided by W, the distance between the treads. If the traction across the treads is not even, then the platform may not pivot as shown, further demon- strating the difficulty with skid steered odometry.
α = + Arcsine (d/W) for the left tread α = – Arcsine (d/W) for the right tread
If this action by the left tread is followed by a tick of forward motion by the right tread, then the angular changes will cancel and the platform will have moved straight forward by the distance of a tread tick.
If instead, the forward movement of the left tread is followed by a reverse move of the right tread, then the angular components will add while the linear motion elements will cancel. In other words, the platform will turn on center (hopefully).
The next step is to add this relative motion to the vehicle’s current position and heading estimate. The relative platform motion is a vector of D magnitude at the current heading (θ) of the platform. This vector must be summed with the position of the vehicle to produce the new Cartesian position estimate. The angle α is then added to the heading of the platform to obtain the new heading.
For a platform operating on a flat surface, the vector calculation is:
x = x + (D * sine (θ)) y = y + (D * cosine (θ)) θ = θ + α
Where x and y are the Cartesian coordinates of the platform position and θ is its heading.
Note that the direction of a positive angle in navigation is usually clockwise, the opposite convention of that used in geometry. It is not important which system is used, or along which axis the zero heading is assumed, as long as these are used con- sistently. I prefer the “map” system, with zero heading being up the positive y-axis, and positive angles being clockwise.
If the platform is operating over uneven terrain, it may be necessary to take into ac- count the pitch angle of the platform. In this case, the vector distance D would be multiplied by the cosine of the pitch
ρ
. The y-axis (altitude) position estimate of the platform would be changed by the sine of the pitch multiplied by the distance D.x = x + (D * sine (θ) * cosine (
ρ
))y = y + (D * cosine (θ) * cosine (
ρ
))z = z + (D * sine (
ρ
))The above calculations are valid for most skid-steered and differential drive platforms.
With Synchro-drive vehicles, the process is even simpler, as the drive system is in- herently a polar coordinate system by nature. The angle of the steering encoder plus an offset angle yields the heading of the vehicle directly. Since these calculations may need to be executed many thousands of times per second, it is important to consider a number of factors.
The tick interrupt
If the interrupt is not processed quickly, it may overrun, or the next interrupt may not get processed. Therefore, the tick interrupt(s) should normally be the highest priority interrupts on the processor. This interrupt should never be masked for more than a few cycles at a time, and it should itself be uninterruptible. It is, however, important that this interrupt never occur when another process is accessing the position or heading estimates, as this may cause erroneous values to be used. Pro- cesses that must access this data should do so in a block move if possible.
If an interrupt is not available, it may be tempting to poll the encoder. This is a really bad idea, as it will consume enormous resources from the CPU, but it can be done if such resources are available. A better solution may be to place a small, dedicated micro- processor between the encoders and the main CPU, and to program it to perform the calculations. Processors are available for a few dollars that can handle this process.
Speeding up calculations
The first thing we need to know is how fast our processor can perform these calcula- tions. If this is not known explicitly, then we can devise a test that will exercise the CPU and determine the amount required to perform, say, one million such calcula- tions. Next, determine the highest rate that the interrupts could occur, and make sure that the time is well more than an order of magnitude shorter than the shortest period for the interrupt.
The two most common ways to increase the speed of such calculations are by adding a coprocessor, or by using lookup tables for the geometric functions. In the calcula- tions above, notice that the arcsine function is always called with the same value (d/W).
It is silly to ask our processor to do this arcsine calculation over and over. The obvious solution is to pre-calculate this constant, and then just manipulate its sign.