Details on the Navigation System

The overall navigation software system is divided into on-board and off-board components, communicating via two radio links for video and data (eventually, many of the off-board processes will be moved on-board). The basic data flow is that the stereo process produces terrain elevation maps which are passed to the obstacle avoidance planner which uses them to evaluate the efficacy of traveling along different paths. These recommendations are merged (in semi-autonomous mode) with the desires of a human operator to choose the best path to traverse (in autonomous mode, there is typically no operator input). The command arbiter then forwards steering and velocity commands to the off-board controller, which packages them up and ships them, using the RCP protocol developed at Sandia Laboratories, to the on-board controller which then executes the commands and returns status and sensor information.

Concurrency is very important in achieving the levels of performance needed (1-2 Hz cycle time is desirable). In particular, perception and planning functions run simultaneously: while the obstacle avoidance planner is using one stereo elevation map to evaluate paths, the stereo system is processing another image. When stereo completes, it asynchronously sends the image to the planner. Likewise, the arbiter is getting asynchronous path evaluations from the planner and user interface, combining the most recent information to produce steering commands. Meanwhile, the controller module is receiving asynchronous commands and requests for pose information from different modules. While it is admittedly more difficult to develop and debug distributed, concurrent systems, they have great advantages in terms of real-time performance and modularity in design and implementation.

LRD Navigation Group - skoenig@cs.cmu.edu (last updated in March 1995)
Comments? Suggestions? Requests? Please send e-mail to lri-feedback+@cs.cmu.edu!