Robust Planning using Constraint Satisfaction Techniques Daniel Buettner and Berthe Y. Choueiry Constraint Systems Laboratory Department of Computer Science and Engineering, University of Nebraska-Lincoln Abstract: We investigate the automatic conversion of a planning problem to a binary constraint satisfaction problem (CSP). This conversion allows us to use standard constraint processing (CP) techniques to find solutions to the planning problem. Of particular interest is the detection of dynamic symmetry during solution extraction on the CSP. This will allow bundles of solutions to be found, where each bundled solutions has interchangeable values for one or more variables in the CSP. Modern Planning Systems: The fastest of today’s planners are nonsystematic and rely on some type of stochastic search. There are other planners that can guarantee completeness and some form of optimality, and these planners descend from GraphPlan. This work is in the latter camp, as we wish are interested in optimal solutions. Methodology: We are developing new CSP techniques to solve planning problems that: 1.Exploit the structure of planning graphs 2.Exploit interchangeability in planning problems Goals: Our work has two main objectives: 1.Find robust plans which make use of interchangability 2.Improve the performance of solution extraction in planning problems Definitions: A Constraint Satisfaction Problem (CSP) is a triple P = ( V, D, C ), where V = {V 1, V 2,..., V n }, a set of variables. D = {D V 1, D V 2,..., D V n }, the set of variable domains. C = {C i, C j,k,..., C i,j,...,m,..., C n }, a set of constraints on variables in V. A Planning Problem is a problem in which an agent capable of performing certain actions finds itself in some known world, needing to achieve certain goals. More formally, a planning problem should specify: The initial state of the world (as a set of facts). A description of the agent’s goals (as a set of facts). A description of the actions that the agent can carry out. Actions are described by their preconditions and effects. The preconditions of an action are a set of facts that must be true before an action can be performed. The effects can be divided into an add list and a delete list, where the add list contains facts made true by the action and the delete list contains facts that are made false by the action. Variables: Each fact present in the planning graph for a particular planning problem is converted to a CSP variable. Domains: The set of actions supporting each fact becomes the domain, with the addition of a special value called NOTHING. Constraints: Activity Constraints: When a particular action is chosen to support some fact, the preconditions of that action must be true. The activity constraints force the variables representing each precondition to take some value other than NOTHING. Fact Mutex Constraints: These simple constraints are placed between facts that GraphPlan has marked as mutex. These constraints say that at least one of the variables must have the value NOTHING. These constraints prevent the planner from, for example, trying make (FACT) and (NOT FACT) true at the same time. Mutex Constraints: These constraints are used to model mutexes that exist between pairs of actions. As actions are the domain values in this formulation, the constraints must exist between facts which have mutex actions supporting them. The constraints explicitly forbid particular pairs of actions from being simultaneously assigned to the fact variables involved in the constraint. Problem Reformulation: The conversion of a planning problem to a CSP is completely automated. The planning graph generated by the GraphPlan algorithm is used as the basis for this conversion. Early attempts at using CP techniques with planning required that each planning problem be hand encoded, a complex and sometimes difficult task. Constraints: Mutexes between facts and actions must be enforced, as well as activity constraints that are used to model the preconditions of actions. In detail: References: 1.Minh  Binh  Do  and  Subbarao  Kambhampati  Planning  as  constraint  satisfaction  Solving  the  planning  graph  by  compiling  it  into  CSP  Artificial  Intelligence  - . 2.Avrim  Blum  and  Merrick  Furst  Fast  planning  through  planning  graph  analysis  In  Proceedings  of  the  th  International  Joint  Conference  on  Artificial  Intelligence   IJCAI  pages  -  This work is supported by the CAREER Award # from the National Science Foundation. This illustrates the planning graph as constructed by GraphPlan. A planning graph consists of alternating layers of facts and actions. The first entries in a planning graph are the facts found in the initial state of the planning problem. The next layer is the set of actions whose preconditions exist in the initial state (thus making the actions applicable). Of note is a pseudo-action called a noop that has one fact as its precondition and that same fact as an effect. These noop actions ensure that once a fact becomes true, it is present at all future levels in the planning graph. To extend the planning graph from a given fact layer, all applicable actions are generated and they form the next action layer. The effects of these actions form the next fact layer. GraphPlan starts with the initial conditions and extends the planning graph until all goal are found (and are non-mutex) at the highest fact layer. At this point, a search is launched to see if a valid plan exists in the planning graph. If a solution is found, it is output. Otherwise the planning graph is extended one more layer and a search is again launched. This continues until a valid plan is found or the problem is found to be unsolveable. Experience: Summer intern at Honeywell where I worked on an industrial scheduling system. Summer intern at NASA Ames where I worked on a GraphPlan based planning system.