CSC2542 Planning-Graph Techniques The lecture in 2 weeks will be - PDF document

Administrative Announcements � Tutorial Time: If you’re taking the course for credit, please (re)vist the doodle poll and see whether you can work towards finding a time when we can all meet. We’re at an impass! � I will be posting a schedule with project milestone dates and the due date for the assignment. CSC2542 Planning-Graph Techniques The lecture in 2 weeks will be given by our TA, Christian Muise. � � Suggested readings for next week: Sheila McIlraith � Part III introduction of GNT Department of Computer Science � Chapter 9 of GNT University of Toronto Fall 2010 � A review paper that I will post on our web page. � Other Issues? 1 2 Acknowledgements A number of the slides used in this course are modifications of Dana Nau’s lecture slides for the textbook Automated Planning, licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License: http://creativecommons.org/licenses/by-nc-sa/2.0/ Other slides are modifications of slides developed by Malte Helmert, END of Bernhard Nebel, and Jussi Rintanen. Administrative Announcements I have also used some material prepared by Dan Weld, P@trick Haslum and Rao Kambhampati. I would like to gratefully acknowledge the contributions of these researchers, and thank them for generously permitting me to use aspects of their presentation material. 3 4

History History GraphPlan (Blum & Furst, 1995) was the first planner to use planning- But most importantly… � graph techniques GraphPlan’s place in history is secured by its critical role in the � development of reachability heuristics* for heuristic search planners � Before GraphPlan came out, most planning researchers were working by approximating the search tree rooted at a given state on partial order planners (plan space planners *) Heuristic search planners have dominated the “satisficing planner” � � POP, SNLP, UCPOP, etc. track of IPC planning competitions for the last 8 years. � GraphPlan caused a sensation because it was so much faster * Reachability heuristics aim to estimate the cost of a plan between the current search state and a goal state. We will talk about these more in the weeks to come. � Many subsequent planning systems have used ideas from it either directly as close decendants of GraphPlan or by using the Planning Graph representation in some guise to improve the encoding of the planning problem most notably for SAT-based planning. * Sometimes referred to as “PSP” planners, but “PSP” used for “partial satisfaction planners”, nowadays 5 6 Outline Motivation � A big source of inefficiency in search algorithms is the � Motivation branching factor � The Graphplan algorithm � the number of children of each node � Planning graphs � example E.g., a backward search may try lots of actions � Mutual exclusion g 1 a 1 that can’t be reached from the initial state a 4 g 4 � example (continued) g 2 g 0 s 0 a 2 � Solution extraction a 5 g 5 � example (continued) a 3 s 1 a 1 g 3 s 4 a 4 � Discussion Similarly, a forward search s 0 s g s 2 a 2 may generate lots of s 5 a 5 … actions that do not reach a 3 s 3 to the goal 7 8

Graphplan One way to reduce branching factor procedure Graphplan: � for k = 0, 1, 2, … � First create a relaxed problem � Graph Expansion: � Remove some restrictions of the original problem � create a “planning graph” that contains k “levels” � Want the relaxed problem to be easy to solve relaxed (polynomial time) � IMPORTANT problem � Check whether the planning graph satisfies a necessary (but insufficient) condition for plan � The solutions to the relaxed problem will include all existence solutions to the original problem � If it does, then possible possible literals actions � do Solution Extraction: in state s i in state s i � Then do a modified version of the original search � backward search, � Restrict its search space to include only those actions that modified to consider occur in solutions to the relaxed problem only the actions in the planning graph � if we find a solution, then return it 9 10 The Planning Graph Example Search space for a relaxed version of the planning problem: � Due to Dan Weld, Univ. Washington [Weld, AIM-09] � Alternating layers of ground literals and actions � Nodes at action-level i : actions that might be possible to execute at Suppose you want to prepare dinner as a surprise for your sweetheart � time i* (who is asleep) � Nodes at state-level i: literals that might possibly be true at time i s 0 = {garbage, cleanHands, quiet} � Edges: preconditions and effects g = {dinner, present, ¬ garbage} state-level i -1 action-level i state-level i Action Preconditions Effects state-level 0 (the literals true in s 0 ) cook() cleanHands dinner wrap() quiet present ¬ garbage, ¬ cleanHands preconditions carry() none ¬ garbage, ¬ quiet dolly() none effects Also have the maintenance actions: one for each literal A maintenance action for a literal l. It represents what happens if we don’t change l . * This is terminology from GNT and refers to the graph. The numbering is at odds with conventional numbering for action representations. Here, an action is possible to execute in i if it’s preconditions are true in state level i-1 (as opposed to i)s. Its 11 12 effects are reflected in the propositions of state level i (as opposed to i+1)

Example (continued) Mutual Exclusion state-level 0: � {all atoms in s 0 } U state-level 0 action-level 1 state-level 1 {negations of all atoms not in s 0 } action-level 1: � {all actions whose preconditions are satisfied and non-mutex in s 0 } state-level 1: � {all effects of all of the actions in action-level 1 � Two actions at the same action-level are mutex if (including maintenance actions)} � Inconsistent effects: an effect of one negates an effect of the other Action Preconditions Effects � Interference: one deletes a precondition of the other cook() cleanHands dinner � Competing needs: they have mutually exclusive preconditions wrap() quiet present Otherwise they don’t interfere with each other � ¬ garbage, ¬ cleanHands carry() none � Both may appear in a solution plan Recursive ¬ garbage, ¬ quiet dolly() none � Two literals at the same state-level are mutex if propagation ¬ dinner ¬ dinner of mutexes Also have the maintenance actions � Inconsistent support: one is the negation of the other, ¬ present ¬ present or all ways of achieving them are pairwise mutex 13 14 Example (continued) Example (continued) state-level 0 action-level 1 state-level 1 � Augment the graph to indicate mutexes state-level 0 action-level 1 state-level 1 carry is mutex with the maintenance � action for garbage (inconsistent effects) Check to see whether there’s a � dolly is mutex with wrap � possible solution � interference � Recall that the goal is ¬ quiet is mutex with present � { ¬ garbage, dinner, present } � inconsistent support Note that in state-level 1, � � each of cook and wrap is mutex with � All of them are there a maintenance operation � None are mutex with each other Thus, there’s a chance that a plan � Action Preconditions Effects exists cook() cleanHands dinner � Try to find it wrap() quiet present � Solution extraction ¬ garbage, ¬ cleanHands ¬ dinner ¬ dinner carry() none ¬ garbage, ¬ quiet dolly() none ¬ present ¬ present ¬ dinner ¬ dinner Also have the maintenance actions ¬ present ¬ present 15 16

Solution Extraction Recall what the algorithm does The set of goals we procedure Graphplan: The level of the state s i are trying to achieve � for k = 0, 1, 2, … � Graph Expansion: procedure Solution-extraction( g,i ) A real action or a maintenance action � create a “planning graph” that contains k “levels” if i =0 then return the solution � Check whether the planning graph satisfies a necessary for each literal l in g (but insufficient) condition for plan existence nondeterministically choose an action � If it does, then to use in state s i– 1 to achieve l state- action- state- � do Solution Extraction: level level level if any pair of chosen actions are mutex � backward search, i -1 i i then backtrack modified to consider g’ := {the preconditions of only the actions in the chosen actions} the planning graph Solution-extraction( g’, i –1) � if we find a solution, end Solution-extraction then return it 17 18 Recall what the algorithm does Example (continued) procedure Graphplan: state-level 0 action-level 1 state-level 1 � for k = 0, 1, 2, … � Recall that the goal is � Graph Expansion: { ¬ garbage, dinner, present } � create a “planning graph” that contains k “levels” � Check whether the planning graph satisfies a necessary (but insufficient) condition for plan existence Two sets of actions for the goals at � state-level 1 � If it does, then � do Solution Extraction: � Neither of them works � backward search, modified to consider � Both sets contain actions that only the actions in are mutex the planning graph � if we find a solution, then return it ¬ dinner ¬ dinner ¬ present ¬ present 19 20