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