1. 1Nau: PLANET, 2000 Ordered Task Decomposition: Theory and Practice Dana S. Nau Dept. of Computer Science, and Institute for Systems Research University of Maryland, College Park, MD

2. 2Nau: PLANET, 2000 Generating Plans of Action l Programs to aid human planners u Project management (consumer software) u Plan storage and retrieval l (e.g., variant process planning) u Automatic schedule generation (various OR and AI techniques) l For some problems, really want to generate plans automatically u Much more difficult u Very few successful programs for realistic problems l AI planning research is starting to pay off u Of the few really good plan generation systems for practical problems, most involve AI planning techniques u However, …

3. 3Nau: PLANET, 2000 AI Planning Is Different in Practice Than it Was in Theory Unstack(x,y) Pre:on(x,y), clear(x), handempty Del:on(x,y), clear(x), handempty Add:holding(x), clear(y) l Theory: u Symbolic computations (STRIPS operators) u Single agent (the planner) u Perfect information l Practice: u Complex numeric computations (geometry, images, probabilities) u Multiple agents u Imperfect information, external information sources

4. 4Nau: PLANET, 2000 Goal l Develop synergy between theory and applications u By understanding what works in practical planning situations, we can develop better theories of planning u Better theories of planning can lead to better real-world planners Theory Applications

5. 5Nau: PLANET, 2000 Approach (and Outline) Theory Applications 6. Evacuation planning 3. Electronic Design and Manufacturing 5. SHOP 1. Principles of HTN planning 2. Computer bridge 4. Ordered Task Decomposition l Mainly I’ll use PowerPoint slides l At two points, I can run demos in Lisp l Please ask questions! Day 1Day 2

6. 6Nau: PLANET, 2000 1. Principles of HTN Planning l Joint work with Kutluhan Erol and Jim Hendler Theory Applications 6. Evacuation planning 3. Electronic Design and Manufacturing 5. SHOP 1. Principles of HTN planning 2. Computer bridge 4. Ordered Task Decomposition

7. 7Nau: PLANET, 2000 What HTN Planning Is method travel(x,y) travel by air get taxiride taxi (x,y)pay driver travel by taxi travel(UMD, MIT) airport(UMD,BWI) airport(MIT,Logan) ticket(BWI, Logan) travel(UMD, BWI) get taxi ride taxi(UMD, BWI) pay driver fly(BWI, Logan) travel(Logan, MIT) get taxi ride taxi(Logan, MIT) pay driver l A type of problem reduction u Decompose tasks into subtasks u Handle constraints (e.g., taxi not good for long distances) u Resolve interactions (e.g., take taxi early enough to catch plane) u If necessary, backtrack and try other decompositions task ticket (a,b)travel (x,a)fly(a,b)travel(b,y)airport(x,a)airport(y,b)

8. 8Nau: PLANET, 2000 Comparison with “Classical” AI Planning l “Classical” AI planning is action-based u Declarative descriptions of actions u Specify declaratively what the operators are capable of doing u Don’t prescribe how to perform complex tasks u The planner must infer that, using trial-and-error search l HTN decomposition u Can represent STRIPS-style declarative operators, but it’s clumsy u Easy to specify “recipes” for how to perform tasks buy-ticket(x,y) pre:airport(x), have-money() del:have-money() add:have-ticket(x,y) fly(x,y) pre:at(x), have-ticket(x,y) del:at(x), have-ticket(x,y) add:at(y) travel by air ticket (a,b)travel (x,a)fly(a,b)travel(b,y)airport(x,a)airport(y,b)

9. 9Nau: PLANET, 2000 History of HTN Planning l Originally developed about 25 years ago l [Sacerdoti 1977; Tate 1977] u Long thought to have better potential for applicability to real- world planning problems than classical STRIPS-style planning u Progress delayed due to lack of theoretical understanding l More recent work: theoretical basis for HTN planning u Formal semantics l HTN’s are strictly more expressive than STRIPS operators [Erol et al., 1994a] u Sound and complete algorithm [Erol et al., 1994b] Implementation available at http://www.cs.umd.edu/projects/plus/umcp/manual/ u Complexity analysis [Erol et al., 1996] u This has helped to spread interest in HTN planning

10. 1010 Nau: PLANET, 2000 What is Expressivity? l Expressivity of languages u A language L is as expressive as expressive as another language M iff any expression in L can be translated into an expression with the same meaning in M l Possible ways to define “meaning” 1. based on computational complexity 2. based on model theory 3. based on operational semantics l HTN planning is more expressive than state-based planning according to all three of these definitions u Will summarize all three

11. 1 Nau: PLANET, 2000 1. Complexity-Based Expressivity l Transformation must preserve answer (“yes” or “no”) l Transformation must be computable/polynomial l Affected by the conciseness of the language Language LLanguage M transformation “yes” instances “yes” instances “no” instances “no” instances

12. 1212 Nau: PLANET, 2000 HTN Language Versus STRIPS Language l STRIPS-style planning is a special case of HTN planning u Erol [1995] presents two polynomial transformations from the STRIPS planning language to the HTN planning language l There is no computable transformation from the HTN language to the STRIPS language, because HTNs can represent harder problems than the STRIPS language l Example problem: u Given two context-free languages L1 and L2, do they have a non-empty intersection? u This problem is undecidable u It can’t be represented as a STRIPS-style planning problem (not unless you augment the STRIPS formalism to include function symbols!)

13. 1313 Nau: PLANET, 2000 Representing the Problem using HTNs u Given two context-free languages L1 and L2, do they have a non-empty intersection? l This problem can be represented as an HTN planning problem u You don’t need to use function symbols u You don’t even need to use any variable symbols! u However, you need to make use of l cycles in methods l interleaving among subtasks m1 m2 m1 t1 t11t12t13 t2 t21t22t23

14. 1414 Nau: PLANET, 2000 2. Model-Theoretic Expressivity l Erol [1995] extended the work of Baader on knowledge representation languages to planning languages u The transformation must preserve meaning l The set of models satisfying a sentence and the set of models satisfying its tranformation must be equivalent u No restrictions on the computational aspects of the translation l Not affected by the conciseness of the languages l Result u Erol’s transformations from STRIPS to HTN (mentioned earlier) preserve the set of models u No transformations in the other direction, because HTN models have richer structure u Thus the HTN language is more expressive than the STRIPS language

15. 1515 Nau: PLANET, 2000 3. Operational-Semantic Expressivity l Transformation must preserve the set of solutions (plans) l Result: u Solutions to STRIPS problems are regular sets u Solutions to HTN problems can be arbitrary context-free sets u Thus HTN’s are more expressive than STRIPS

16. 1616 Nau: PLANET, 2000 Related Publications [Sacerdoti, 1977]E. Sacerdoti. "A Structure for Plans and Behavior." American Elsevier Publishing Company, 1977. [Tate, 1977]A. Tate. Generating Project Networks. IJCAI-77, 1977, 888-893. [Erol et al., 1994]K. Erol, J. Hendler and D. S. Nau. Semantics for Hierarchical Task-Network Planning. Tech. Report CS TR-3239, Univ. of Md., March, 1994. [Erol et al., 1994a]K. Erol, J. Hendler and D. S. Nau. HTN Planning: Complexity and Expressivity. In AAAI-94, 1994. [Erol et al., 1994b]Erol, Hendler and Nau. UMCP: A Sound and Complete Procedure for Hierarchical Task-Network Planning. In AIPS-94, pp. 249- 254. [Erol, 1995]Erol. Hierarchical Task-Network Planning Systems: Formalization, Analysis, and Implementation. Ph.D. Dissertation, U. of Maryland, 1995. [Erol et al., 1996]K. Erol, J. Hendler and D. Nau. Complexity Results for Hierarchical Task-Network Planning. Annals of Mathematics and AI, 18:69- 93, 1996.

17. 1717 Nau: PLANET, 2000 2. Computer Bridge l Joint work with Stephen J. Smith and Tom Throop Theory Applications 6. Evacuation planning 3. Electronic Design and Manufacturing 5. SHOP 1. Principles of HTN planning 2. Computer bridge 4. Ordered Task Decomposition

18. 1818 Nau: PLANET, 2000 Computer Programs for Games of Strategy l Fundamental technique: minimax game-tree search u Largely “brute force” l Can prune off portions of the tree u cutoff depth, u alpha-beta pruning, u hash tables, … l Even then, it still examines thousands of game positions l This is very different from how humans think u Even the best human chess players examine at most a few dozen game positions to make their moves 10-359-2-723 109-23 9

19. 1919 Nau: PLANET, 2000 Connect Four:solved Go-Moku:solved Qubic:solved Nine Men’s Morris:solved Othello:better than humans Checkers:better than any living human Backgammon:better than all but about 10 humans Chess:certainly better than all but about 250 humans; possibly even better than that Bridge:probably worse than the best player at your local bridge club Performance of Game-Playing Computer Programs

20. 2020 Nau: PLANET, 2000 l Four players; 52 playing cards dealt equally among them l Bidding to determine the trump suit u Declarer: whoever makes highest bid u Dummy: declarer’s partner l The basic unit of play is the trick u One player leads; the others must follow suit if possible u Trick won by highest card of the suit led, unless someone plays a trump u Keep playing tricks until all cards have been played l Scoring based on how many tricks were bid and how many were taken West North East South 6 2 8 Q Q  J 6  5  9  7  A K 5 3 A  9   How Bridge Works

21. 2121 Nau: PLANET, 2000 l Bridge is an imperfect information game u Don’t know what cards the others have (except the dummy) u Many possible card distributions, so many possible moves l If we encode the additional moves as additional branches in the game tree, this increases the number of nodes exponentially u worst case: about 6x10 44 leaf nodes u average case: about 10 24 leaf nodes Why Bridge is Difficult for Computers Not enough time to search the game tree

22. 2 Nau: PLANET, 2000 How to Reduce the Size of the Game Tree? l Bridge is a game of planning u The declarer plans how to play the hand u The plan combines various strategies (ruffing, finessing, etc.) u If a move doesn’t fit into a sensible strategy, it probably doesn’t need to be considered l Our approach for declarer play u Adaptation of an Hierarchical Task-Network (HTN) planning u Generate a game tree in which each move corresponds to a different strategy, not a different card Our approach Worst case Average case Brute-force search ≈ 10 24 leaf nodes≈ 26,000 leaf nodes ≈ 305,000 leaf nodes≈ 6x10 44 leaf nodes

23. 2323 Nau: PLANET, 2000 (North—  Q) …… Task Network for Finessing PlayCard(P 3 ; S, R 3 )PlayCard(P 2 ; S, R 2 )PlayCard(P 4 ; S, R 4 ) FinesseFour(P 4 ; S) PlayCard(P; S, R 1 ) StandardFinesseTwo(P 2 ; S) LeadLow(P; S) PlayCard(P 4 ; S, R 4 ’) StandardFinesseThree(P 3 ; S) EasyFinesse(P 2 ; S)BustedFinesse(P 2 ; S) FinesseTwo(P 2 ; S) StandardFinesse(P 2 ; S) Finesse(P; S) Us:East declarer, West dummy Opponents:defenders, South & North Contract:East – 3NT On lead:West at trick 3 East:  KJ74 West:  A2 Out:  QT98653 (North—  3) East—  J West—  2 North—  3South—  5South—  Q primitive action by us task method primitive action by opponent

24. 2424 Nau: PLANET, 2000 Game Tree Generated from the Task Network N— QQ E— KK FINESSE N— 33 E— JJ N— 33 W— 22 E— KK S— 33 QQ 55 33 W— AA 33 E— 44 55 +600 CASH OUT N—S— +630 +600 +265 +600 +270.73 0.0078 0.9854 0.5 +630 –100 +630 +600...later strategies...

25. 2525 Nau: PLANET, 2000 l We incorporated our code for declarer play into Bridge Baron (an existing commercial program) l Using our code, Bridge Baron won the 1997 World Bridge Computer Challenge l Our code has been used in all versions of Bridge Baron since October 1997 u Has sold many thousands of copies Implementation

26. 2626 Nau: PLANET, 2000 Related Publications [Smith et al., 1996] S.J.J. Smith, D.S. Nau, and T. Throop. A Planning Approach to Declarer Play in Contract Bridge. Computational Intelligence, 1996. 12(1): p. 106-130. [Smith et al., 1998] S.J.J. Smith, D.S. Nau, and T. Throop. Computer Bridge: A Big Win for AI Planning. AI Magazine, 1998. 19(2): p. 93-105.

27. 2727 Nau: PLANET, 2000 3. Electronic Design and Manufacturing l Joint work with Stephen J. Smith, Kiran Hebbar, and Ioannis Minis Theory Applications 6. Evacuation planning 3. Electronic Design and Manufacturing 5. SHOP 1. Principles of HTN planning 2. Computer bridge 4. Ordered Task Decomposition

28. 2828 Nau: PLANET, 2000 Integrated Product and Process Design (IPPD) l Augment the traditional “engineering design” loop u Plan and evaluate what manufacturing processes will be needed u Predict cost, time, quality, manufacturing problems u Modify the design to improve its manufacturability Product modeling Engineering and functionality analysis Manufacturability analysis verify parameters Preliminary design Modify design Acceptable design

29. 2929 Nau: PLANET, 2000 Microwave Transmit/Receive Modules l 1-20 GHz frequency range (radars, satellite communications, etc.) l Difficult and expensive to design and manufacture

30. 3030 Nau: PLANET, 2000 EDAPS: Electro-mechanical Design And Planning System Circuit Schematic, Component Selection Routines in C++ Product and Process Data Files EEsof - Developed by us Microstation HTN Planner (C++) Substrate Design & 3-D Layout Process Planning & Plan Evaluation User Interface (Tcl/Tk) Information about manufacturability Designer AEL Routines - Commercial MDL Routines Design, Constraints

31. 3131 Nau: PLANET, 2000 EDAPS’s Process Planner l Can express planning using “recipes” that fit well into HTN methods u Generate and evaluate multiple process plans u Estimate times and costs u Display results graphically (alternative methods) A portion of the task network: SpindlingSpraying SpreadingPainting PhotolithographyApply photoresistPreclean for artwork Etching (one possible method) Make the artwork

32. 3232 Nau: PLANET, 2000 Processes: Opn A BC/WW Setup Runtime LNDescription 001 A VMC1 2.00 0.00 01Orient board vertically 02Clamp board at (1,1,1) 03Establish datum point 001 B VMC1 0.10 0.43 01Tool: 0.30-diameter drill bit 02Drill at (1.25,-0.50 d:1.00,f:50,s:30 03Drill at(1.25,-0.50) d:1.00,f:20,s:60 001 C VMC1 0.10 0.77 01Tool: 0.20-diameter slot miller 02MiII start (0.044, 4.88) l: 0.5, w: 0.5, d: 1.00, f: 50, s: 40 001 T VMC1 2.20 1.20 01Total time on VMC1 … 006 A PLAT1 1.00 0.60 007 A ETR1 0.50 0.60 008 A ETC1 0.20 0.30 … 02Dip in bath for 2 minutes Temperature:100C, Conc:1000ppm 01Etch plate for 1 minute Substrate Dimensions: 7,4,1 Ground Material: Aluminum Material: Teflon Substrate thickness: 30 mils Metallized thickness: 7 mils 01Etch board for 2 minutes Temperature:100C, Conc:1000ppm Examples from EDAPS

33. 3 Nau: PLANET, 2000 Alternative components Pareto-optimal combinations Multi-objective Integer Programming Database lookup Status l EDAPS completed under NSF funding l Follow-up project with Northrop Grumman u Combine AI planning with Integer Programming optimization …… …… …… HTN planning Alternative plans Interactive display User exploration and selection C1C1 CiCi CpCp A ij P ijk A pq A 11 P 111 P pqr A 1xx … A pxx … Electronic CAD Initial component selection

34. 3434 Nau: PLANET, 2000 Related Publications [Hebbar et al., 1996]K. Hebbar, S. J. Smith, I. Minis and D. Nau. Plan-Based Evaluation of Designs for Microwave Modules. In Proc. ASME Design Technical Conference, August, 1996. [Smith et al., 1997]S.J. Smith, K. Hebbar, D. Nau, and I. Minis. Integrating Electrical and Mechanical Design and Process Planning. In Knowledge Intensive CAD, Volume 2, M. Mantyla, S. Finger, and T. Tomiyama, Editors. 1997, Chapman and Hall, pp. 269-288. [Nau et al., 2000]D. Nau, J. Meyer, M. Ball, J. Baras, A. Chowdhury, E. Lin, R. Rajamani and V. Trichur. Integrated Product and Process Design of Microwave Modules Using AI Planning and Integer Programming. In Fourth Workshop on Knowledge Intensive CAD (KIC-4), 2000, pages 186-196. Parma, Italy: IFIP Working Group 5.2.

35. 3535 Nau: PLANET, 2000 4. Ordered Task Decomposition l Joint work with Kutluhan Erol, Naresh Gupta, and Stephen J. Smith Theory Applications 6. Evacuation planning 3. Electronic Design and Manufacturing 5. SHOP 1. Principles of HTN planning 2. Computer bridge 4. Ordered Task Decomposition

36. 3636 Nau: PLANET, 2000 Discussion l For both Bridge Baron and EDAPS u We used the same approach u Even some of the same code! l Ordered Task Decomposition u Adaptation of HTN planning l Linear ordering on the subtasks of each method l Expand the subtasks in the same order in which they will be executed later on l Compare and contrast with “classical” AI planning 1. Search strategy 2. Data representation method subtask 3subtask 2subtask 1subtask 4 task

37. 3737 Nau: PLANET, 2000 Search Strategy l Ordered task decomposition u Adaptation of HTN planning u Require the subtasks of each method to be totally ordered u Decompose these tasks left-to-right l The same order that they’ll later be executed l Analogous to PROLOG’s search strategy SpindlingSprayingSpreadingPainting PhotolithographyApply photoresistPreclean for artwork Etching Make the artwork for a PC board

38. 3838 Nau: PLANET, 2000 Search Strategy (Continued) l With action-based planning, you have an either/or choice: u goal-directed search (backward from the goal) u forward search (forward from the initial state) l In contrast, ordered task decomposition is both forward and goal-directed at the same time C AB A B C Pick up C Put C on the table Pick up A Put A on B Pick up B Put B on C

39. 3939 Nau: PLANET, 2000 Example l STRIPS operator to stack a block l Translate it into an HTN method u If we expand the subtasks in left-to-right order, then we are searching forward from the initial state l Always know the current state u However, it’s also a goal-directed search l The task is the goal l Invoke only those methods that match the task stack(x,y) Pre:holding(x), clear(y) Del:holding(x), clear(y) Add:on(x,y), clear(x), handempty stack(x,y) Achieve on(x,y) Achieve clear(y)Achieve holding(x)Put x on y c ab c ab

40. 4040 Nau: PLANET, 2000 l The operators aren’t totally ordered u How do we we know what the states are? u Represent states as sets of logical atoms l Partially instantiate them to represent what we know about them u protected conditions in POP, mutex conditions in Graphplan u This works (it leads to sound and complete planners) u Since the states aren’t totally instantiated, it’s hard to reason about them in all of the ways we might like l E.g., can’t call a CAD package to reason about the geometry of a machined part if some of the geometry is uninstantiated State Representation for Partial-Order Planning C AB A B C Pick up C Put C on the table Pick up A Put A on B Pick up B Put B on C

41. 4141 Nau: PLANET, 2000 State Representation for Ordered Task Decomposition l Goal-directed, but generates actions in the same order in which they will later be executed l Whenever we want to plan the next task u we’ve already planned everything that comes before it u Thus, we know the current state of the world s0s0 s1s1 s2s2 … task t m … … task t n op 1 op 2 op i S i–1

42. 4242 Nau: PLANET, 2000 Increased Expressivity l If we know what the current state is, then we can do complex reasoning about it u Logical inferences u Numeric and probabilistic computations u Interactions with external programs l Example u In computer bridge, by knowing the current state, can decide which of nineteen finesse situations are applicable u With partial-order planning, it would be hard to decide which of them can be made applicable l Can do lots of pruning u Often only one or two consistent “next steps” l Bridge declarer play: complete plans in about 1 1 / 2 minutes l Process plans for microwave modules: a few seconds

43. 4343 Nau: PLANET, 2000 Example: Blocks-World Planning l The blocks world l On the next page is the best blocks-world planning algorithm I know of u [Gupta & Nau, 1992] u It finds near-optimal plans in low-order polynomial time l In this section, I’ll describe the algorithm l In the next section, I’ll explain how to implement it using Ordered Task Decomposition move b from the table to a move c from b to the table c ab cab b ac

44. 4 Nau: PLANET, 2000 Initial state: clear(a), on(a,b), ontable(b), clear(c), ontable(c), handempty a bc Goal: on(a,b), on(b,c) c a b The Algorithm l loop u if there is a clear block x such that l x or a block beneath x is in a location inconsistent with the goal and l x can be moved to a location such that x and all blocks beneath it will be in locations consistent with the goal u then move x to that location u else if there is a clear block x such that l x or a block beneath x is in a location inconsistent with the goal u then move x to the table u else exit u endif l repeat

45. 4545 Nau: PLANET, 2000 Running the Algorithm l Running the algorithm on the Sussman anomaly Initial state: clear(c), on(c,a), ontable(a), clear(b), ontable(b), handempty c ab Goal: on(a,b), on(b,c) c a b c ab cabca b c a b

46. 4646 Nau: PLANET, 2000 Encoding the Algorithm l loop u if there is a clear block x such that l x or a block beneath x is in a location inconsistent with the goal and l x can be moved to a location such that x and all blocks beneath it will be in locations consistent with the goal u then move x to that location u else if there is a clear block x such that l x or a block beneath x is in a location inconsistent with the goal u then move x to the table u else exit u endif l repeat Can’t write these preconditions using STRIPS-style operators Can write them as Horn clauses If we know the current state, we can infer whether they hold Thus, we can write the algorithm using ordered task decomposition. In the next section, I’ll show how to do that

47. 4747 Nau: PLANET, 2000 Related Publications [Nau et al., 1998] D.S. Nau, S.J.J. Smith, and K. Erol. Control Strategies in HTN Planning: Theory versus Practice. in AAAI-98/IAAI-98 Proceedings. 1998. [Gupta & Nau, 1992] N. Gupta and D. S. Nau. On the Complexity of Blocks-World Planning. Artificial Intelligence, 56(2-3):223-254, August, 1992.

48. 4848 Nau: PLANET, 2000 5. SHOP l Joint work with Yue Cao, Amnon Lotem, and Héctor Muñoz-Avila Theory Applications 6. Evacuation planning 3. Electronic Design and Manufacturing 5. SHOP 1. Principles of HTN planning 2. Computer bridge 4. Ordered Task Decomposition

49. 4949 Nau: PLANET, 2000 SHOP (Simple Hierarchical Ordered Planner) l Domain-independent algorithm for Ordered Task Decomposition u Sound/complete across a large number of planning domains l Implementation u Common-Lisp implementation available at http://www.cs.umd.edu/projects/shop u Developing a Java implementation

50. 5050 Nau: PLANET, 2000 Input and Output l Input: u State: a set of ground atoms u Task List: a linear list of tasks u Domain: methods, operators, axioms l Output: one or more plans u depending on what we tell SHOP to look for, it can return l the first plan it finds l all possible plans l a least-cost plan l all least-cost plans l etc.

51. 5151 Nau: PLANET, 2000 Elements of the Input l State: collection of ground atoms (in Lisp notation)  ((at home) (have-cash 50.43) (distance home downtown 10)) l Task list: linear list of tasks to perform  ((travel home downtown) (buy book)) l Each method: task, preconditions and decomposition l Preconditions to be established using logical inference l Decomposition is a task list l Each axiom: Horn clause u Extensions: may contain negations and calls to the Lisp evaluator l Each primitive operator: task, delete list, add list u Like a STRIPS operator, but without the preconditions u Performs a primitive task

52. 5252 Nau: PLANET, 2000 Initial task list: ((travel home park)) Initial state: ((at home) (cash 20) (distance home park 8)) l Methods (task, preconditions, subtasks): u (:method (travel ?x ?y) ((at x) (walking-distance ?x ?y)) ' ((!walk ?x ?y)) 1) u (:method (travel ?x ?y) ((at ?x) (have-taxi-fare ?x ?y)) ' ((!call-taxi ?x) (!ride ?x ?y) (!pay-driver ?x ?y)) 1) l Axioms: u (:- (walking-dist ?x ?y) ((distance ?x ?y ?d) (eval (<= ?d 5)))) u (:- (have-taxi-fare ?x ?y) ((have-cash ?c) (distance ?x ?y ?d) (eval (>= ?c (+ 1.50 ?d)))) l Primitive operators (task, delete list, add list) u (:operator (!walk ?x ?y) ((at ?x)) ((at ?y))) u … Simple Example Optional cost; default is 1

53. 5353 Nau: PLANET, 2000 The SHOP Algorithm procedure SHOP (state S, task-list T, domain D) 1.if T = nil then return nil 2.t 1 = the first task in T 3.U = the remaining tasks in T 4.if t is primitive & an operator instance o matches t 1 then 5.P = SHOP (o(S), U, D) 6.if P = FAIL then return FAIL 7.return cons(o,P) 8.else if t is non-primitive & a method instance m matches t 1 in S & m’s preconditions can be inferred from S then 9.return SHOP (S, append (m(t 1 ), U), D) 10.else 11.return FAIL 12. end if end SHOP state S; task list T=( t 1,t 2,…) operator instance o state o(S) ; task list T=(t 2, …) task list T=( t 1,t 2,…) method instance m task list T=( u 1,…,u k,t 2,…) nondeterministic choice among all methods m whose preconditions can be inferred from S

54. 5454 Nau: PLANET, 2000 Precond: (travel home park) (!walk home park) (!call-taxi home)(!ride home park)(!pay-driver home park) Fail (distance > 5) Succeed (we have $20, and the fare is only $9.50) Succeed (at home)(walking-distance Home park) (have-taxi-fare home park) (at park) (cash 10.50) (distance home park 8) Simple Example (Continued) (at home) Initial state: Final state: (at home) (cash 20) (distance home park 8)

55. 5 Nau: PLANET, 2000 Question l I can run SHOP for you right now, on a slightly more complicated version of the example. l Would you like me to do so?

56. 5656 Nau: PLANET, 2000 Homework Assignment l Formulate a plan for going to the beach l Execute the plan