Graphplan Adapted from slides by José Luis Ambite* [* based in part on slides by Jim Blythe and Dan Weld] 1 GraphPlan Many Planning Systems now use these Ideas: GraphPlan IPP STAN SGP Blackbox Medic Runs orders of magnitude faster than partial order planners (as POP, SNLP, UFPOP, etc.) 2 Basic idea Construct a graph that encodes constraints on possible plans Use this “planning graph” to constrain search for a valid plan: If valid plan exists, it’s a subgraph of the planning graph Planning graph can be built for each problem in polynomial time 3 Problem handled by GraphPlan* Pure STRIPS operators: conjunctive preconditions no negated preconditions no conditional effects no universal effects Finds “shortest parallel plan” Sound, complete and will terminate with failure if there is no plan. *Version in [Blum& Furst IJCAI 95, AIJ 97], later extended to handle all these restrictions [Koehler et al 97] 4 Planning graph Directed, leveled graph 2 types of nodes: Proposition: P Action: A 3 types of edges (between levels) Precondition: P -> A Add: A -> P Delete: A -> P Proposition and action levels alternate Action level includes actions whose preconditions are satisfied in previous level plus no-op actions (to solve frame problem). 5 The Planning Graph Alternating layers of ground literals and actions (ground instances of operators) representing the literals and actions that might occur at each time step 0 < i < N literals that might be true at time t = (i-1)/2 literals that are true at the initial state 0 i-1 ... i i+1 ... preconditions literals that might be true at time t = (i+1)/2 effects ... operators ... Maintenance: NoOps 6 Rocket domain 7 Constructing the planning graph Level P1: all literals from the initial state Add an action in level Ai if all its preconditions are present in level Pi Add a precondition in level Pi if it is the effect of some action in level Ai-1 (including no-ops) Maintain a set of exclusion relations to eliminate incompatible propositions and actions (thus reducing the graph size) P1 A1 P2 A2 … Pn-1 An-1 Pn 9 Mutual Exclusion relations Two actions (or literals) are mutually exclusive (mutex) at some stage if no valid plan could contain both. Two actions are mutex if: Inconsistent effects: an effect of one negates an effect of the other Interference: one clobbers others’ effect or precondition (deletes other’s precondition) Competing needs: mutex preconditions Two propositions are mutex if: Inconsistent support: One is the negation of the other, or all ways of achieving them are mutex 10 Mutual Exclusion relations Inconsistent Effects Interference (prec-effect) Competing Needs Inconsistent Support 11 Dinner Date example Initial Conditions: (and (garbage) (cleanHands) (quiet)) Goal: (and (dinner) (present) (not (garbage)) Actions: Cook :precondition (cleanHands) :effect (dinner) Wrap :precondition (quiet) :effect (present) Carry :precondition :effect (and (not (garbage)) (not (cleanHands)) Dolly :precondition :effect (and (not (garbage)) (not (quiet))) 12 Dinner Date example 13 Dinner Date example 14 Observation 1 p ¬q ¬r p A q p A ¬q q A ¬q B ¬r p r q ¬q B ¬r r ¬r Propositions monotonically increase (always carried forward by no-ops) 15 Observation 2 p ¬q ¬r p A q p A ¬q q A ¬q B ¬r p r q ¬q B ¬r r ¬r Actions monotonically increase 16 Observation 3 p p p q q q r r r … … … A Proposition mutex relationships monotonically decrease 17 Observation 4 A A A p p p p q q q q … B C r s … B C r s … B C r s … Action mutex relationships monotonically decrease 18 Observation 5 Planning Graph ‘levels off’. After some time k all levels are identical Because it’s a finite space, the set of literals never decreases and mutexes don’t reappear. 19 Valid plan A valid plan is a planning graph where: Actions at the same level don’t interfere Each action’s preconditions are made true by the plan Goals are satisfied 20 GraphPlan algorithm Grow the planning graph (PG) until all goals are reachable and not mutex. (If PG levels off first, fail) Search the PG for a valid plan If non found, add a level to the PG and try again 21 The Algorithm function GRAPHPLAN(problem) returns solution or failure graph INITIAL-PLANNING-GRAPH(problem) goals GOALS[problem] loop do solution EXTRACT-SOLUTION (graph, goals, LENGTH(graph)) if goals all non-mutex in last level of graph then do if solution failure then return solution else if NO-SOLUTION-POSSIBLE(graph) then return failure graph EXPAND-GRAPH(graph, problem) 22 Searching for a solution plan Backward chain on the planning graph Achieve goals level by level At level k, pick a subset of non-mutex actions to achieve current goals. Their preconditions become the goals for k-1 level. Build goal subset by picking each goal and choosing an action to add. Use one already selected if possible. Do forward checking on remaining goals (backtrack if can’t pick non-mutex action) 23 Solution Extraction: The Algorithm procedure SOLUTION-EXTRACTION(goal_set, graphlevel) if graphlevel = 0 we have found a solution for each goal in goal_set choose (nondeterministically) an action at level graphlevel–1 that achieves it Level of the graph we are at if any pair of chosen actions are mutex, then backtrack precondition_set:= {the precondition of the chosen actions} SOLUTION-EXTRACTION(precondition_set, graphlevel-2) 24 Plan Graph Search If goals are present & non-mutex: Choose action to achieve each goal Add preconditions to next goal set 25 Termination for unsolvable problems Graphplan records (memoizes) sets of unsolvable goals: U(i,t) = unsolvable goals at level i after stage t. More efficient: early backtracking Also provides necessary and sufficient conditions for termination: Assume plan graph levels off at level n, stage t > n If U(n, t-1) = U(n, t) then we know we’re in a loop and can terminate safely. 26 Dinner Date example Initial Conditions: (and (garbage) (cleanHands) (quiet)) Goal: (and (dinner) (present) (not (garbage)) Actions: Cook :precondition (cleanHands) :effect (dinner) Wrap :precondition (quiet) :effect (present) Carry :precondition :effect (and (not (garbage)) (not (cleanHands)) Dolly :precondition :effect (and (not (garbage)) (not (quiet))) 27 Solution Extraction for the Example (2): Two sets of actions for the goals at level 2 Neither works: both sets contain actions that are mutex 0 garb 1 carry 2 garb 0 garb carry garb dolly cleanH 1 cleanH cleanH cleanH cleanH cook cook quiet wrap garb dolly cleanH quiet 2 garb quiet quiet quiet wrap quiet dinner dinner present present 28 Solution Extraction Example (3) Go back and do more graph extension: generate two more levels 0 garb 1 carry 2 garb garb garb dolly cleanH cleanH cleanH cleanH cook quiet cook quiet wrap 4 garb carry dolly cleanH 3 quiet quiet wrap quiet dinner dinner present present 29 Example: Solution extraction (4) 0 garb 1 carry 2 garb garb garb dolly cleanH cleanH cleanH cleanH cook quiet cook quiet wrap 4 garb carry dolly cleanH 3 quiet quiet wrap quiet dinner dinner present present Twelve combinations at level 4 • Tree ways to archive “garb” • Two ways to archive “dinner” • Two ways to archive “present” 30 Example: Solution extraction (5) Several of the combinations look OK at level 2. Here is one of them: 0 garb 1 carry 2 garb garb garb dolly cleanH cleanH cleanH cleanH cook quiet cook quiet wrap 4 garb carry dolly cleanH 3 quiet quiet wrap quiet dinner dinner present present 31 Example: Solution extraction (6) Call Solution-Extraction recursively at level 2; one combination works, so we have got a plan 0 garb 1 carry 2 garb garb garb dolly cleanH cleanH cleanH cleanH cook quiet cook quiet wrap 4 garb carry dolly cleanH 3 quiet quiet wrap quiet dinner dinner present present 32 Planning Graph Example Rocket problem 37 Plan Graph creation is Polynomial Theorem 1: The size of the t-level PG and the time to create it are polynomial in t = number of levels n = number of objects m = number of operators p = propositions in the initial state Max nodes proposition level: O(p+mlnk) Max nodes action level: O(mnk) k = largest number of action parameters, constant! 38 Compare with POP Graphplan will examine fewer actions than POP, because it will only look at actions in the planning graph However (like POP), Graphplan may examine the same actions more than once if it finds multiple plans to achieve them Look at ways to make Graphplan more efficient 39 Ways to improve GraphPlan Techniques from Constraint satisfaction Problems (CSP) Forward checking Memorization Variable ordering Handling the closed-world assumption Action schemata, type analysis, and simplification Not reachable states (because of domain theory) e.g. impossible: at(car1 Washington, t) at(car1 Philadelphia, t) 40 In-place plan graph expansion q2 A1 B3 r4 7 C3 s4 D5 … … p 0 6 start time end level end time Props & actions: start level Mutex relations: 41 Perverting Graphplan Graphplan ADL Graphplan Uncertainty Rao Gazen & Knoblock Koehler Anderson, Smith & Weld Boutilier Conformant PGP Smith & Weld Blum & Langford Time Smith & Weld Koehler ? ? Sensory/Contingent Weld, Anderson & Smith 42 Expressive Languages Negated preconditions Disjunctive preconditions Universally quantified preconditions, effects Conditional effects 43 Negated Preconditions Graph expansion P, P mutex Action deleting P must add P at next level Solution extraction 44 Disjunctive Preconditions Convert precondition to DNF Disjunction of conjunctions Graph expansion Add action if any disjunct is present, nonmutex Solution extraction Consider all disjuncts 45 Universal Quantification Graph Expansion Solution Extraction 46 Universal Quantification Graph Expansion Expand action with Herbrand universe replace block x P(x) with P(o17) P(o74) … P(o126) Solution Extraction No changes necessary 47 Conditional Effects 48 Full Expansion in-keys in-pay in-keys in-pay in-keys in-pay in-keys in-pay 49 Factored Expansion Treat conditional effects as primitive “component” = <antecendant, consequent> pair STRIPS action has one component Consider action A Precond: p Effect: e (when q (f g)) (when (r s) q) A has three components: antecedent p pq prs consequent e f g q 50 Changes to Expansion Components C1 and C2 are mutex at level I if The antecedants of C1 and C2 are mutex at I-1 C1, C2 come from different action instances, and the consequent of C1 deletes the antecedant of C2, or vice versa C, C1 induces C and C is mutex with C2 Intuitively, C1 induces C if it is impossible to execute C1 without executing C. C1 and C are parts of same action instance C1 and C aren’t mutex (antecedants not inconsistent) The negation of C’s antecedant can’t be satisfied at level I-1 51 Induced Mutex 52 Revised Backchaining Confrontation Subgoaling on negation of something 53