Map-Based Planning Interface

Last update 02/16/99 (revision history)

Questions

Can path marking be implemented by directly drawing on the OCU's map buffer, or do the paths taken and planned need to be implemented some other way? It seems that especially with planned routes, they will need to be repositioned, and we don't want to have destroyed the underlying map data in drawing those lines. How do you implement this?
What about map scale setting? How important is this? It seems like it would be valuable for maintaining orientation given the limited screen real estate, since the operator could zoom out to get the big picture and then zoom in to get some useful detail. However It seems that to provide a useful scale setting capability, it would need to be managed on the OCU, since we can't afford to wait for the rescaled map to be transmitted over the freewave. The OCU could fairly straightforwardly reduce the map resolution in factors of 2 by discarding pixels. Alternatively we could separately incrementally maintain two different scale map buffers on the OCU in a similar manner to how we maintain the different cost maps that aren't necessarily being displayed.

Overview

Map-based planning uses map information to drive the robot from the current location to a destination location in the map. Pre-known map information is downloaded to the robot, and is used as an input to the planner.

The map is also dynamically updated according to robot sensor input, incrementally building up traversability information in the map. This allows the planner to function when there is not a precomputed complete traversability map. The planner is still useful when there is no precomputed traversability information, since it can use the obstacle and navigation sensors to build a map of what it has seen so far.

Precomputed Map Structure

The complete map download is in general composed of several maps which can be thought of as cost overlays on the world map. Each map represents a different sort of cost of traversing a particular map cell. Though these layers can be thought of as forming a single composite map, they are referred to as separate maps: the visibility map, etc. The planner is extremely flexible in terms of the map structures is can use. We may want to make some decisions about what sort of maps are in fact going to be used so that the OCU interface can be better adapted.

Map Downloading

There is no plan to enter map information on the OCU. Maps will be precompiled offline, and then somehow downloaded onto the robot. Operationally it would make some sense for this to be done via some sort of removable media like a flash card, but for demo purposes using a net connection to download to the onboard disk is probably good enough.

Cost Weighting Function

The aggregate cost for a cell is determined by applying a weighting function to the cost values for that cell in all of the maps. This establishes a tradeoff between the various costs, and does make sense to dynamically configure from the OCU. For example, given physical traversability and visibility (risk of being seen) information, we can choose either the direct route or the stealthy route. The user interface would probably be a set of sliders, one for each map, establishing a weight for each type of cost.

Local Map Access

The planner requires access to the local obstacle map in order to build its global traversability map. The planner doesn't impose any strong requirements on this map, however, a traversability cost is preferred to a binary obstacle/no obstacle indication. The planner should be given access to every local map generated so as to maximize the overlap between the local maps so that they can be registered into a mosaic.

Navigation

Although the planner is designed to tolerate navigation error, better position estimates are of course better. The planner also makes use of position uncertainty information.

Since the precompiled maps are in world coordinates, it is necessary to establish the world position of the starting point. We must extract the world location from the output of pose estimation, so pose estimation must at some point be initialized to an absolute location.

Map Display on OCU

Here are the basic OCU requirements for map-based planning:

Display map information on the OCU.
Dynamic update of displayed maps as new sensor information becomes available.
Display iconic marks on the map to mark locations such as the robot and the goal.
Display planned and traveled routes on the map as poly-lines. Planned and traveled routes are displayed in different colors.
Ability to designate a goal location on a displayed map, sending the location to the planner on the robot.
Ability to scroll maps too large to fit in the display window, and to switch between display of the various different maps.

In the context of the proposed OCU screen layout, we probably want to display map info in the top, effectively treating the map display as another video feed. The map display may be able to operate even when driving is not being directed toward a map goal point (e.g. we are not in the map-based driving mode.)

Although map-based planning will clearly require more OCU support than the other driving modes, it is not quite as bad as it might sound, since maps are basically images. The OCU needs to manage an image buffer for each map, and to implement scrolling of these images across the display window.

Planner to OCU Communication Scenario

At the start of the mission, static map information is synchronized between the OCU and planner. Which way info flows on the freewave depends on how we decide to introduce map data into the system. It is probably slightly easier to push data from the robot to the OCU, since we already need this capability for incremental updates.
Regardless of driving mode, the map can be displayed in the top window, can be scrolled, and the different maps can be selected for display.
Regardless of driving mode, the planner will instruct the OCU to grow the map buffers if the robot moves out of the map area.
Regardless of driving mode, the planner frequently updates the robot position marker in the map, and this marker is shown in the appropriate location when the map is displayed.
Regardless of driving mode, the planner frequently updates small rectangles in the maps to reflect new sensor information. This update rectangle is normally the immediate vicinity of the robot, though there doesn't seem to be any reason to require this.
Regardless of driving mode, the path taken by the robot is recorded on the map.
When in the map-based driving mode, the operator can bring up the cost weight configuration sliders to set the planning tradeoffs. It is preferable to configure the weights before designating the target, but it can be done at any time, at the cost of a pause to reinitialize the planner.
If at some point it is desired to designate a map goal, the operator selects the map-based driving mode, brings up the map display, scrolls in it to make the goal visible, and designates the goal using the pointing device. The goal is then marked by an icon on the map, and the location is sent to the planner.
A route will be planned based on available information. The route is displayed as a line on the map, and is updated whenever the planned route is changed due to new obstacle information.
The planner starts giving driving commands to the robot. When the planner determines that the robot has arrived at the goal or that the goal is unreachable, it notifies the OCU. We may also want a max travel distance similar to in waypoint following, where the operator can confirm to continue according to the current plan.
When driving to a map goal, the operator can stop the robot at any time. They can then either continue as before or designate a new map goal. The operator can suspend map based driving at any time by switching to another driving mode. The last designated map goal is remembered, and course to the map goal can be resumed at any time by switching back to map-based driving and resuming.

Home | Mail to CMU TMR-members