Introduction to Artificial Intelligence LECTURE 13 : Advanced Planning

1. Introduction to Artificial IntelligenceLECTURE 13: Advanced Planning • Motivation: least commitment principle • Partial-order planning (POP) • Planning with partially instantiated operators • Hierarchical decomposition • Other extensions “An Introduction to Least Commitment Planning” D. Weld, Artificial Intelligence Magazine, Winter 1994, pp 27-61.

2. Least commitment principle • Make choices only when necessary, leaving the decision for the time it is required • variable binding: most-general unifier is a least commitment strategy Prefer buy(Store,drill) to buy(store55,drill) • partial ordering: assume operators can be performed simultaneously unless there is a requirement to do otherwise if S1deletes precondition c and c is needed by S2, perform S2 before S1

3. Example: putting on shoes • Start: {} • Goal: {RightShoeOn, LeftShoeOn} • Operators: • Op(Action: RightShoeOn, • Precond: RightSockOn, • Effect: RightShoeOn) • Op(Action: LeftShoeOn • Precond: LeftSockOn, • Effect: LeftShoeOn) • Op(Action: RightSockOn • Effect: RightSockOn) • Op(Action: LeftSockOn, • Effect: LeftSockOn)

4. Partial vs. total order plans

5. Operator representation • Operator name, precondition, effect (both add and delete lists) Op(Action:action-name, Precond: conjunction of literals (positive) Effect: conjuction of literals (positive and negative) • Graphically p1 p2 .... pn preconditions action-name e1 e2 .... em effects

6. Plan representation (1) • Plan steps: a sequence of operators <S1, S2, …., Sn> • Step ordering constraints: indicate step precedence relations Si < Sj “Si must be executed sometime before Sj” • Variable binding constraints: indicate variable assignments X = a, Y b, etc • Causal links: record the purpose of the step Si -- c --> Sj “Si achieves precondition c forSj”

7. Plan representation (2) • Initially, the plan consists of two steps, Start and Finish, with null actions associated to them, with ordering Start < Finish and with the desired goal (g1/\ g2 /\ … /\ gn) as precondition Plan(Steps:{S1: Op(Action: Start), S2: Op(Action: Finish, Precond: (g1 /\ g2 … /\gn))} Orderings: {Si < Sj }, Bindings: {}, Links: {})

8. Example of plan representation Initial plan Final plan Start links LeftShoeOn /\ RightShoeOn Finish Ordering: Left Sock < Left Shoe Right Sock < Right Shoe Start < all, Finish > “all”

9. Complete plans A plan is complete iff each precondition of each step is achieved by some other step. A step achieves a precondition if the condition is one of the effects of the step and if no other step can cancel out the condition: Siachieves precondition cof Sj iff 1. (Si < Sj) /\ (c inEffects(Si)) 2. ~Sk (~c in Effects(Sk)) /\ (Si < Sk < Sj)

10. Consistent plans A plan is consistent iff there are no contradictions in the ordering or binding constraints. A contradiction occurs when: 1. (Si < Sj) and (Sj < Si) or 2. (X = a) /\ (X = b) or (X=a) /\ (Xa)

11. Solutions as plans • A solution is a complete and consistent plan that achieves the desired goal. • Any linearization of a partial plan is also a solution • Partially ordered plans are better solutions than totally ordered plans because: • no arbitrary choice of ordering • parallel execution of branches • easier to combine plan fragments

12. Partial Order Planner: Overview • Regression planning: work from goal to start • Start from the initial plan, add one step (operator) in each iteration • Add only steps that serve to achieve a precondition that has not been achieved yet. • Keep track of interactions with causal links. When a conflict occurs, resolve it by imposing an order between steps • Keep track of all choice points and backtrack as necessary

13. SM = Supermarket HWS = Hardware Store Example: shopping for groceries Steps: {Start: Op(Action: Start, Effect:At(Home) /\ Sells(HWS,Drill) /\ Sells(SM,Milk) /\ Sells(SM,Banana), Finish: Op(Action: Finish, Precond:At(Home) /\ Have(Drill) /\ Have(Milk) /\ Have(Banana)}

14. At(here) Go(there) At(there) ~At(here) At(store) Sells(store(x) Buy(x) Have(x) Actions: Go and Buy • Op(Action: Go(there) Precond:At(here) Effect:At(there) /\~At(here)) • Op(Action: Buy(x) Precond:At(store) /\ Sells(store,x) Effect:Have(x)

15. Plan to achieve three preconditions At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) Have(Drill) Have(Milk) Have(Ban.) Bold links are causal links Light links are ordering links

16. {s/HWS} {s/SM} {s/SM} Instantiation and causal links At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) Have(Drill) Have(Ban.) Have(Milk) Causal links can be added because there is no conflict! No ordering is necessary

17. Next step: get to the store At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) At(HWS) ~At(x) At(SM) ~At(x) Have(Drill) Have(Milk) Have(Ban.)

18. Conflict! Flawed plan! Causal links conflict: cannot be in two places simultaneously ! Re-ordering is necessary Instantiation and causal links At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) {x/Home} {x/Home} At(HWS) ~At(Home) At(SM) ~At(Home) Have(Drill) Have(Milk) Have(Ban.)

19. promotion c c c conflict demotion Soving causal link conflicts Promotion and demotion sequentialize actions

20. After threat resolution (demotion) At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) At(HWS) At(SM) Have(Drill) Have(Milk) Have(Ban.) At(Home)

21. At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) Final Solution At(HWS) Have(Drill) At(SM) Have(Milk) Have(Ban.) At(Home)

22. POP algorithm (1) functionPOP(initial,goal,operators) returns plan plan :=Make-Minimal-Plan(initial,goal) loop do if Solution?(plan) then return plan (S-need,c) := Select-Sub-Goal(plan) Choose-Operator(plan,operators,S-need,c) Resolve-Threats(plan) end functionSelect-Subgoal(plan) returns (S-need,c) pick a plan step S-need from STEPS(plan) with a precondition c that has not been achieved returns (S-need,c)

23. POP algorithm (2) procedureChoose-Operator(plan,operators,S-need,c) choose (a step S-add from operators)or (STEPS(plan) that has c as an effect) if there is no such step then fail add causal link (S-add-- c --> S-need) toLINKS(plan) add ordering constraint S-add < S-need toORDERINGS(plan) if S-addis a newly added step from operators then add S-add to STEPS(plan) add Start < S-add < Finish toORDERINGS(plan) procedureResolve-Threats(plan) for eachS-threat that threatens a link (Si-- c --> Sj) inLINKS(plan) do chooseeither Promotion: add S-threat < Si to ORDERINGS(plan) Demotion:add Sj < S-threat to ORDERINGS(plan) if not Consistent(plan) then fail

24. POP is sound and complete • POP constructs a proof that each precondition of the goal step is achieved: • Choose-Operator selects an action to get subgoal • Resolve-Threats sequentializes to ensure no interference between operations • POP is sound and complete: every plan it returns is a solution, and if there is a solution, it will be found (assuming complete search -- BFS or iterative deepening search) • It is also sound and complete with partially instantiated operators (see next slides)

25. Partially instantiated operators • Resolving conflicts with partially instantiated operators: is At(x) a threat to ~At(Home)? It is a possible threat, which can be dealt with by 1. resolve now with an equality constraint add binding x = HWS 2. resolve now with an inequality constraint add the clause x Home 3. resolve later: do nothing. It is not a threat until x becomes instantiated. When it does, use promotion and demotion to resolve the conflict. Better!

26. Extended notion of achieving A step achieves a precondition if the condition is one of the effects of the step, and if no other step can cancel out the condition for all instantiations. Siachieves precondition c of Sj iff 1. (Si < Sj) and Si has an effect c’ thatnecessarily unifies with c 2. ~Sk (Si < Sk < Sj) in some linearization of the plan and Sk has an effect c’ that possibly unifies with~c. Si c’ c Sj

27. Modified Choose-Operator* procedureChoose-Operator(plan,operators,S-need,c) choose (a step S-add from operators)or (STEPS(plan) that has c-add as an effect) such that u = Unify(c,c-add,Bindings(plan)) if there is no such step then fail add u toBindings(plan) add causal link (S-add-- c --> S-need) toLINKS(plan) add ordering constraint S-add < S-need toORDERINGS(plan) if S-addis a newly added step from operators then add S-add to STEPS(plan) add Start < S-add < Finish toORDERINGS(plan) *for resolving later -- least commitment strategy

28. Modified Resolve-Threats* procedureResolve-Threats(plan) for each(Si-- c --> Sj) inLINKS(plan) do for eachS-threat inSTEPS(plan) do for eachc’ inEFFECTS(S-threat) do if Subst(Bindings(plan),c) = Subst(Bindings(plan),~c’) then chooseeither Promotion: add S-threat < Si to ORDERINGS(plan) Demotion:add Sj < S-threat to ORDERINGS(plan) if not Consistent(plan) then fail end end end *for resolving later -- least commitment strategy

29. Blocks world revisited a c b a b c Follow POP on blocks world examples!

30. Advanced planning topics • Hierarchical plans steps at different levels of resolution • More complex conditions universal quantification, conditionals • Dealing with time constraints incorporate time intervals an deadlines • Resources and costs choose the plan that satisfies resource and cost constraints

31. Hierarchical decomposition • POP does not distinguish between different levels of abstraction of operators: go(home,airport) vs. go(bed,living_room) Typical plans usually have many steps! Figure out first how to get to the airport, then find out how to exit the house! • Operators should describe actions at different levels of abstraction, so “big” goals get solved first

32. Example

33. Abstract operators • Decompose operators into a group of more detailed operators that form a plan to implement it. • The decomposition ends with primitive operators which are not decomposed Build(House) is decomposed into Build(Foundation), Build(Floor), Build(Walls), Build(Roof), …..

34. Decomposition methods (1) • Specify that a nonprimitive operator that unifies with it can be decomposed into a plan • Decompose(operation,p)is a new structure akin to a subroutine or a macro for operators: Decompose(Construction, Plan(Steps:{S1: Build(Foundation), S2: Build(Frame), S3: Build(Roof), S4: Build(Walls), S5: Build(Interior)} Orderings:{S1<S2; S2<S3;S2<S4; S3<S5 ; S4<S5, .....}, Bindings: {}, Foundation Frame Frame Roof Walls Links: {S1--->S2, S2 ---->S3, S2 --->S4, S3 --->S5, S4 --->S5}))

35. Decomposition methods (2) • Plan p correctly implements an operator oif it is a complete and consistent plan for the problem of achieving the effects of ogiven the preconditions of o: • p must be consistent (no ordering or assignment contradiction). • every effect of o must be asserted by at least one step of p and not denied by a later step. • every precondition of steps in p must be achieved by a step in p or be one of the preconditions of o.

36. Hierarchical POP algorithm functionHD-POP(plan,operators,methods) returns plan loop do if Solution?(plan) then return plan (S-need,c) := Select-Sub-Goal(plan) Choose-Operator(plan,operators,S-need,c) S-nonprimitive := Select-Nonprimitive(plan) Choose-Decomposition(plan,methods,S-nonprimitive) Resolve-Threats(plan) end

37. HD-POP subroutines • Solution? must check that every step of the plan is primitive • Select-Nonprimitive arbitrarily selects a non-primitive step of the plan (no backtracking) • Choose-Decomposition: when a method ischosen: 1. Steps: add all method steps, remove S-nonprimitive 2. Bindings: add all bindings of method 3. Orderings: place new constraints latest or earliest 4. Links: explicitly add all links Fail if 1 or 2 introduce a contradiction!

38. Detailed decomposition of a step

39. Analysis of hierarchical decomposition • HD helps prune branches in the search tree. Two useful properties of solutions are: • Downward solution property: if p is an abstract solution, then there is a primitive solution of which p is an abstraction. Once an abstract solution is found, all other branches can be pruned! • Upward solution property: if p is an inconsistent abstract plan, then there is no primitive solution of which it is an abstraction Prune away all descendants of inconsistent plans!

40. Solution space properties abstract plan primitive Bold boxes are solutions Dotted boxes are inconsistent Boxes marked with “X” can be pruned

41. Complexity of hierarchical decomp. • For a plan with n steps and an average of b choices at each step (branching factor), the complexity of search is O(bn) • Let d be the depth of the hierarchical plan, and s average number of decomposition steps. When only searching for abstract solutions, one of every b decompositions is a solution. If each decomposition has s steps, the planner looks at bsi steps at depth d =i. The complexity is O(bsd) << O(bn)

42. Quantitative example abstract primitive

43. Is completeness preserved? • The upward and downward solution properties are not necessary correctness conditions for decompositions! • To avoid loosing completeness, no pruning can take place -- still can be used to guide search • There is an abstract solution that is inconsistent, but the decomposition solves the problem. “a couple has two possesions: he a gold watch and her beautiful hair. They each plan to buy presents to make each other happy. He wants to trade the watch for a comb, she wants to trade her hair for a watch chain. Can they execute their plans?

44. Ex: no upward solution property Cannot be ordered!

45. Solution: unique main subaction • To guarantee the upward solution property, require that there is one step of the decomposed plan to which all preconditions and effects of the abstract operator are attached • In the previous example, the unique main subaction condition does not hold!

46. Approximation • Another way of guiding the search is to rank goals by order of importance (criticality level). Op(Action:Buy(x) Effect: Have(x) /\ Have(MoneyAmount) Precond:1. Sells(store,x) /\ 2. At(store) /\ 3. Have(MoneyAmount) • Solve the problem by considering ONLY preconditions with criticality less or equal than 1, than 2, etc.

47. Other extensions • More expressive operator descriptions • conditional effects: add when conditions • universal quantification: preconditions with “forall” quantifier • Resource constraints: consider costs of each action -- leads to optimization problems • Time constraints: can be handled as resources

48. Conditional effects • Previous scheme sometimes forces premature commitment that can lead to inefficiencies • Solution: extend the operator language to include conditional effects: “condition c must hold when p holds”. Such type of clauses will be added to the effects of an action. • If later p appears, the condition c will be added and handled. • Extend Select-SubGoal and Resolve-Threats to deal with this new type of conditionals

49. Conditionals: example • Two different actions for picking a block: Op(Action: move(B,X,Y), Precond:on(B,X) /\ clear(B) /\ clear(Y) Effect: on(B,Y) /\ ~on(B,X) /\ clear(X) /\ clear(B) /\~clear(Y)) Op(Action: movetotable(B,X), Precond:on(B,X) /\ clear(B) Effect: on(B,table) /\ ~on(B,X) /\ clear(X) /\ clear(B) • Start: on(a,b) • Goal: clear(b) • Problem:two operators for the same type of action!

50. Conditionals: solution • One operator with conditional effect: Op(Action: move(B,X,Y), Precond:on(B,X) /\ clear(X) /\ clear(Y) Effect: on(B,Y) /\ ~on(B,X) /\ clear(X) /\ clear(B) /\ (~clear(Y)) when Y table) • When Y gets instantiated, the condition ~clear(Y) will be added if appropriate. • To resolve threats: if a step has the effect (~c’ when p)is a possible threat to the causal linkSi -- c --> Sj when c’ and c unify. Resolve threat by confrontation: ensuring that p does not hold.