Executing Actions

 

Each action that PRODIGY4.0 selects must be translated into a form that Xavier will understand. ROGUE translates the high-level abstract action into a command sequence appropriate for execution.

PRODIGY4.0 allows arbitrary procedural attachments that are called during the operator application phase of the planning cycle [Stone & Veloso1996]. Typically, we use these functions to give the planner additional information about the state of the world that might not be accurately predictable from the model of the environment. For example, this new information might show resource consumption or action outcomes.

ROGUE extends this information-gathering capability because, instead of simulating operator effects, ROGUE actually sends the commands to the robot for real world execution. Actually executing the planner's actions in this way increases system reliability and efficiency because the system can respond quickly to unexpected events such as failures and side effects, and combined planning and execution effort is reduced since actions are interleaved, and the planner knows the exact outcome of uncertain events.

In general, these procedures:

1. verify the preconditions of the operator,
2. execute the associated actions, and
3. verify the postconditions of the operator.

Some of these procedures also contain simple failure recovery procedures, particularly for actions that have common and known failures. For example, an action might simply be repeated, as in the navigateToGoal command. These procedures resemble schemas [Georgeff & Ingrand1989, Hormann, Meier, & Schloen1991] or RAPs [Firby1989, Gat1992, Pell et al. 1997], in that they specify how to execute the action, what to monitor in the environment, and some recovery procedures. ROGUE's procedures, however, do not contain complex recovery or monitoring procedures, such as when they have different costs or probabilities, since we feel that it is more appropriate for the planner to reason about when they should be used.

These command sequences may be executed directly by ROGUE (e.g. a command like finger to determine an office location), or sent via the TCA interface to the Xavier module designed to handle the command. The action (ACQUIRE-ITEM <room> <user> <item>), for example, is mapped to a sequence of commands that allows the robot to interact with a human. The action (GOTO-PICKUP-LOC <user> <room>) is mapped to the commands shown in Table 6, extracted from an actual trace: (1) Announce intended action, (2) Ask Xavier's path planner to find the coordinates of a door near the room, (3) Navigate to those coordinates, and (4) Verify the outcome.

 

Table 6: The set of actions taken for executing the PRODIGY4.0 operator <GOTO-DELIVER-LOC mitchell r-5309>.

In the following section, we explain in more detail how ROGUE monitors the outcome of the action, and how failures may cause replanning or affect plans of interrupted tasks.