The arbiter module accepts path evaluations from various processes and chooses the best steering angle based on those evaluations. This provides a straightforward way to incorporate information from various sources (such as user interface, obstacle avoidance planners, route planner) in a modular and asynchronous fashion.

Here is a screen shot of a typical arbiter window:

Each path evaluation consists of a steering angle, value, and speed. If the value is "veto" (= red) then that steering angle is eliminated from consideration. Otherwise, recommendations for that steering angle from all sources are combined using a weighted sum. The arbiter then finds the largest contiguous set of steering angles whose values are all within 90% of the maximum value, and chooses the midpoint of that set as the commanded steering angle (= green) to be sent to the controller module (the speed chosen is the minimum speed recommended by all the sources). The idea is to prefer wide, easily traversable areas over directions that might be a bit more traversable, but have less leeway for error if the rover fails to track the path precisely. We have found this to be very important in practice, as the robot's dead reckoning and path tracking ability are only fair, at best.

The path evaluations are also tagged with a robot pose. If the tagged pose differs significantly from the rover's current pose (as determined by the off-board controller), then those path evaluations are ignored. If the evaluations from all the processes are invalidated in this way, then the arbiter issues a command to halt the rover. In this way, the arbiter safeguards against other modules crashing, or otherwise failing to provide timely inputs. Similarly, we guard against a crash of the arbiter module by having it send commands of the form "steer in this direction for X meters." If the controller does not receive a new command before the Ratler has traversed that distance, then it stops the robot.

When operating in autonomous mode, the obstacle avoidance planner occasionally cannot find any acceptable path. This often occurs when the stereo data has been noisy for a while, or when the robot turns and finds itself facing another, unexpected obstacle. To handle such situations, if the arbiter receives several consecutive path evaluations that are all "vetoed," then it will command the rover to turn in place by fifteen degrees. This behavior continues until the planner starts sending valid path evaluations again.

LRD Navigation Group - (last updated in March 1995)
Comments? Suggestions? Requests? Please send e-mail to!