To calculate uncertainty is to model the way the robot’s odometry accumulates error.
For the purposes of this discussion, I am going to assume a platform that can turn in place. If you are working with a drive system that cannot do this, such as an Acker- man system, then you will need to interpret some of these concepts to allow for the coupling between driving and steering.
Figure 10.1. Correcting multiple axes
(Courtesy of Cybermotion, Inc.)
Uncertainty is most easily calculated relative to the vehicle’s frame of reference. The reasons for keeping uncertainty in a relative reference are several. Most importantly, errors will occur for different reasons along the vehicle’s lateral and longitudinal axes. Heading errors will occur for different reasons yet, and it will induce lateral error as the robot drives.
Figure 10.2 shows a diagnostic display for monitoring uncertainty. The ellipse indi- cates the lateral and longitudinal uncertainty, while the intersecting lines indicate the heading uncertainty. In this case, the uncertainty represents the absolute bound- ary for correction data that is received. Data outside of this boundary will be ignored, but this does not mean that a correction of slightly less than this magnitude would be used to correct the position estimates directly. More will be said about this in the coming chapters.
Azimuth (heading) uncertainty
A robot that is not moving generally accumulates no error1. Heading uncertainty is therefore caused primarily by the acts of turning or driving. Like other forms of un- certainty, this one has both an inherent platform component and a surface component.
Figure 10.2. Uncertainty diagnostic display
(Courtesy of Cybermotion, Inc.)
1 Actually, it can falsely accumulate uncertainty if an encoder repeatedly registers forward and backward ticks as the result of Servo-hunting or edge jitter on an encoder. Therefore, it is a good policy to incorporate hysteresis on all such signal inputs.
If a robot is attempting to turn in place on a loose throw rug, the error may be worse than on a tile floor. Generally, the platform component of heading uncertainty for steering can be calculated by simply multiplying the cumulative magnitude of a turning action by an error factor (in units of degrees of error per degree of turning). It is desirable that this factor be readily changed by the robot. It may be changed in the initialization sequence, a path program, or a learning program of the platform as neces- sary. These error factors are a prime example of a good use of blackboard variables.
If the mobile platform has a steering encoder that causes tick interrupts, the calcula- tion becomes nothing more than adding the error factor to the accumulated
uncertainty in a register.
If the mobile platform does not have an interrupt for steering, then it is necessary to do this calculation during the drive interrupts. This can be done by noting the amount that the steering angle has changed since the previous interrupt. This calculation must be done before the lateral uncertainty can be calculated.
Similarly, the heading uncertainty generated by driving is a factor of the distance moved. Every time the odometry advances the robot’s position estimate by one tick, it can add an appropriate amount to the heading uncertainty accumulator.
Generally, the error factors are quite small numbers, so it is convenient for the uncertainty accumulator to be two or more words. The incremental increases are then added to the lower word with carry to the higher register(s). The higher register(s) are the only ones accessed by consuming tasks. In this way, the math for these calculations can stay in integers and therefore execute very fast.
Heading errors related to driving, and thus uncertainty, are generally symmetric.
Turning errors are, however, not generally symmetric. A turn is much more likely to come up short than long. The ideal model would take this into account, but very decent performance can be accomplished by treating the uncertainty as if it were symmetric by using its worst case factor.
Note that while we are performing uncertainty calculations using simple multiplica- tion and addition, the effect of doing this iteratively is to produce the integral of these functions.
Longitudinal uncertainty
Longitudinal error accumulates primarily from slippage, wheel wear, and improper tire inflation. There are again two elements to be taken into account: errors from
the mobile platform itself, and those from the surface it is running on. A robot run- ning in snow will likely under-run the distance it thinks it has traveled.
Longitudinal uncertainty is thus nothing more than the distance traveled, multiplied by an error factor. Longitudinal uncertainty is not generally symmetric. On level ground, a robot may tend to underrun the path but will seldom overrun it. On an uphill slope, this tendency is more significant yet. On a downhill slope, the robot will tend to overrun its path if slippage occurs during braking. Again, reasonable results can be gained with a symmetric assumption about longitudinal uncertainty, but the advan- tage of keeping separate values for the two directions is fairly strong.
As the robot turns, the accumulated lateral and longitudinal uncertainty are simply converted into a vector, rotated, and converted back into lateral and longitudinal components. If a robot turns 90 degrees, then the lateral uncertainty will become the longitudinal uncertainty and vice versa.
Lateral uncertainty
Lateral error is predominantly accumulated as the result of driving with a heading error. Thus, lateral uncertainty is accumulated by multiplying the distance traveled by the sine of the heading error. If this accumulation is done frequently, the fact that the heading error is not constant can be ignored. Since heading can be approximated as being symmetric, so can the accumulated increments of lateral uncertainty.