Identifying Executable Plans

Identifying executable plans Tania Bedrax-Weiss∗ Jeremy D. Frank Ari K. Jónssony Conor McGann∗ NASA Ames Research Center, MS 269-2 Moffett Field, CA 94035-1000, ftania,frank,jonsson,[email protected] Abstract AI solutions for planning and plan execution often use declarative models to describe the domain of interest. Generating plans for execution imposes a different set The planning system typically uses an abstract, long- of requirements on the planning process than those im- term model and the execution system typically uses a posed by planning alone. In highly unpredictable execution environments, a fully-grounded plan may be- concrete, short-term model. In most systems that deal come inconsistent frequently when the world fails to with planning and execution, the language used in the behave as expected. Intelligent execution permits mak- declarative model for planning is different than the lan- ing decisions when the most up-to-date information guage used in the execution model. This approach en- is available, ensuring fewer failures. Planning should forces a rigid separation between the planning model acknowledge the capabilities of the execution system, and the execution model. The execution system and the both to ensure robust execution in the face of uncer- planning system have to agree on the semantics of the tainty, which also relieves the planner of the burden plan, and having two separate models requires the sys- of making premature commitments. We present Plan tem designer to replicate the information contained in Identification Functions (PIFs), which formalize what the planning model in the execution model. Since much it means for a plan to be executable, and are used in conjunction with a complete model of system behavior of the knowledge may be shared between the planning to halt the planning process when an executable plan is and execution systems, this produces a model synchro- found. We describe the implementation of plan identifi- nization problem. Furthermore, if the execution system cation functions for a temporal, constraint-based plan- wants to relay information back to the planner, in this ner. This particular implementation allows the descrip- scenario, the information has to be translated. Not us- tion of many different plan identification functions. ing the same language may be detrimental because syn- chronization and translation may introduce errors and Introduction increase model engineering effort. If both the execution and planning systems have a Planning has been an important problem in Artifcial common language, then information from and to the Intelligence, but plan execution is a problem that AI executive can flow seamlessly. Furthermore, changes has often overlooked. In fairly simplistic and highly- in the planning model are then automatically propa- predictable environments, the planning system can gated to the execution model. In addition, it is easier hand a fully-grounded plan to the execution system and to modify the boundary between planning and execu- the execution system will be able to execute it flaw- tion systems in such systems. Even if a single model for lessly. However, in unpredictable environments, a fully planning and execution is not available, there are still grounded plan will often result in execution failures. good reasons for making it easy to vary the boundary Additionally, it is inefficient for the planning process between planning and execution systems using a single to commit to decisions in advance that are likely to be model of system behavior. Many candidate execution invalidated during execution. One way to avoid these systems may be available; identifying the right one re- problems is to have an intelligent execution system that quires a planning model that can be used with any one is able to “fill in the blanks" given a plan that is not of the possible execution systems. fully grounded. Intelligent execution may range in com- executable plan plexity from fairly simple computations to a process re- An is a plan that the execution sys- sembling full-blown planning. Depending on the char- tem can make any remaining decisions and then trans- acteristics of the execution environment, the best plan late the result into commands that can be sent to the to hand to the execution system will contain more or hardware with which the system is interacting. Based less commitment and information. on this notion, the \executability" of a plan depends directly on the capabilities of the execution system. For 1QSS Group, Inc. a general model of system behavior, we would like to 2Research Institute for Advanced Computer Science specify which parts of that model describe the commitments that should be made by the execution system. Models of System Behavior In this paper we provide the formalism and implemen- The system model defines the set of possible states tation of Plan Identification Functions PIFs . These and actions, along with rules that specify allowed functions exactly characterize the executable plans in and forbidden relations between actions and states. a model that is shared between the planner and the The states and actions are defined by predicates like executive. Thus, they serve to separate the duties of pointingAt(object) and slewFromTo(obj1, obj2). planning by partitioning the planning problem into a We define a partial plan as a collection of temporal pred- set of commitments that are made in advance, and a icate statements, based on a given model. We assume set that are interleaved with plan execution. that the parameter set for each predicate doesn't have We will proceed by presenting a simple example to to be fully grounded. This notion naturally supports clarify some of these notions. more flexible planning paradigms such as those used in constraint-based planning systems. A Simple Example The rules in the system model specify, directly or To examine the issues involved in generating plans for indirectly, the conditions for a state or action being in execution, let us consider a simple spacecraft that can the plan: slew (i.e, turn to different orientations), take pictures, • which instantiations of state/action predicates are and download pictures to Earth. valid A plan request for this spacecraft might consist of a set of picture requests, and then a request for down- • for each action/state, what other states or actions loading some or all of these pictures to Earth. The must exist in the plan to support it planning process would generate an \executable plan" • the temporal and parametric relations between states that achieved those goals. The execution agent would and actions then execute the plan by thrusting to rotate the spacecraft, activating camera components, and transmitting For example, a model for our simple spacecraft data. would state that the predicates include pointingAt, slewingFromTo, takePicture, download A traditional approach to this problem would be . Legal in- based on separating the planning from execution at stantiations of slewingFromTo are limited to those some specific level of abstraction. For example, the where the origin and destinations are not the same, and takePicture planning process might involve generating slew ac- instantiations are limited to objects and tions, orientation maintenance actions, picture-taking times where an overly bright object, like the sun, is not actions, and download actions. The complete plan, at in the frame. There are a number of relations between takePicture that level of abstraction, would then be executed by predicates in this model; for example, a breaking each high-level action down into specific com- must be done within a period where the spacecraft is mands that together perform the action. The slew ac- pointing at the object in question. This means that pointingAt tions, for example, would be broken down into engine there must be a predicate in the plan, and warmup, thruster firing, wait, opposite thruster firing, that furthermore, the appropriate pointingAt must takePicture and then stabilization. The sequence of execution com- have the same object value as the , must takePicture mands would have to fit within the time allocated to start no later than the and must end no the slew action. earlier than the takePicture. If the execution system is sophisticated, it could de- It should be noted that this core approach covers ba- termine how fast to slew, since the slewing rate is con- sic STRIPS-like descriptions, where states are preserved trolled by the time spent firing the engines at the start by the frame axioms and action definitions define state and end of the slew. Slower slew rates typically save changes. It also covers constraint-based approaches, fuel. The execution system might also be able to deter- with and without an explicit representation of time or mine when to start activities that have some temporal resources. Furthermore, in STRIPS, the initial state flexibility. Rather than waiting until the next action and goal statements are simply part of a partial plan start time, which is bound to be later rather than ear- that must be extended to include the actions necessary lier, to provide a safety margin, the execution system to go from the initial state to a goal state. Since both could determine that all earlier actions have been com- planning and execution use the same model, the plan is semantically meaningful to both the planner and the pleted, that the action in question can start as early as 1 a given time, and then start that action at that time. executive . In the Remote Agent Experiment (JMM+00; The rest of the paper is organized as follows. We MNP+98), the planning process built a partial plan first provide a formal definition of PIFs and character- where certain temporal decisions were left to the ex- ize some useful properties of PIFs . We then describe ecution engine.

Load more