ROGUE's operators rely heavily on Xavier's existing behaviours, including path planning, navigation, vision and speech. ROGUE does not reason, for example, about which path the robot takes to reach a goal.
In Table 4, for example, the robot cannot deliver a particular item unless it (a) has the item in question, and (b) is in the correct location.
(operator DELIVER-ITEM <room> <user> <item> (preconds (and (needs-item <user> <item>) (robot-has-item <user> <item>) (deliver-loc <user> <room>) (robot-in-room <room>))) (effects ((add (has-item <user> <item>)) (del (needs-item <user> <item>)) (del (robot-has-item <user> <item>)) |
If any of the four preconditions are false, it will create a plan to achieve each of the preconditions. It takes the top level goal, (has-item <user> <item>), and selects an operator that will achieve it. It continues building the plan recursively, adding operators for each precondition that is not true in the state, until all of the operators in the leaf nodes have no untrue preconditions, yielding a network of plan steps and goals such as the one shown in Figure 5.
Figure 5:Plan
for a single task problem. Goal nodes are shown in ovals, selected operators are
shown in rectangles.
In Table 5, we show how an operator represents that the robot will not go to a pickup location unless it needs to pickup an item there. It does not matter where the robot's current location is; the variable <old-room> is only instantiated when the robot arrives at the goal location.
(operator GOTO-PICKUP-LOC <user> <room> (preconds (and (needs-item <who> <item>) (not (robot-has-item <who> <item>)) (pickup-loc <who> <room>))) (effects ((<old-room> ROOM)) ((del (robot-in-room <old-room>)) (add (robot-in-room <room>))))) |
Other operators in the domain represent different task actions. By abstracting each request to the robot, such as which path the robot takes, ROGUE can more fully address issues arising from multiple interacting tasks, such as efficiency, resource contention, and reliability.