Ordered Task Decomposition Theory and Practice Part 2

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

Approach (and Outline) Day 1 Day 2 Theory 1. Principles of HTN planning 2. Computer bridge 4. Ordered Task Decomposition 3. Electronic Design and Manufacturing 5. SHOP 6. Evacuation planning Applications l Very quick review l Comments l Continue where I left off Nau: PLANET, 2000 2

What Activities Should a Planning System Plan? l In AI planning, researchers traditionally have only allowed the planner to plan activities that will have a direct physical effect l Examples: u picking up a block u moving a truck l In human planning, we also plan lots of other activities Nau: PLANET, 2000 3

What Activities Should a Planning System Plan? l In AI planning, researchers traditionally have only allowed the planner to plan activities that will have a direct physical effect l Examples: u picking up a block u moving a truck l In human planning, we also plan lots of other activities l Example 1: u Planning information-gathering operations travel by airport(x, a) airport(y, b) ticket (a, b) travel (x, a) fly(a, b) travel(b, y) Nau: PLANET, 2000 4

What Activities Should a Planning System Plan? l In AI planning, researchers traditionally have only allowed the planner to plan activities that will have a direct physical effect l Examples: u picking up a block u moving a truck l In human planning, we also plan lots of other activities l Example 2: u Planning bookkeeping operations travel by airport(x, a) airport(y, b) ticket (a, b) store some info travel (x, a) fly(a, b) travel(b, y) about the ticket Nau: PLANET, 2000 5

What Activities Should a Planning System Plan? l In AI planning, researchers traditionally have only allowed the planner to plan activities that will have a direct physical effect l Examples: u picking up a block u moving a truck l In human planning, we also plan lots of other activities l Example 3: u Planning when/how to create and retrieve plans travel by air plan how to travel to Cyprus store this plan into the current state Nau: PLANET, 2000 finish work �pack for at the office the trip execute the stored plan 6

Homework Assignment l Yesterday, I asked you to formulate and execute a plan for going to the beach l Analyze that plan, to see if it contains any of the following activities: (1) information-gathering operations (2) bookkeeping operations (3) planning when/how create and retrieve plans Nau: PLANET, 2000 7

Concrete Example l Malik Ghallab and Piergio Bertoli and I plan to go bicycling on Sunday (instead of going to the barbecue) l One part of the plan: u Find a bicycle shop u Find out if they have suitable bicycles u If so, then plan how to go to it l This involves information-gathering, bookkeeping, and planning when to do other planning Nau: PLANET, 2000 8

Concrete Example l Malik Ghallab and Piergio Bertoli and I plan to go bicycling on Sunday (instead of going to the barbecue) l One part of the plan: u Find a bicycle shop u Find out if they have suitable bicycles u If so, then plan how to go to it l This involves information-gathering, bookkeeping, and planning when to do other planning l Another information-gathering part of the plan: u Would you like to join us? u If so, please let us know! Nau: PLANET, 2000 9

Review of 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 … task tm s 0 op 1 s 1 op 2 s 2 … task tn Si– 1 opi … u Thus, we know the current state of the world Nau: PLANET, 2000 1

Answer to a Question from Yesterday task t l Question: Suppose there’s an action b that will come late in the plan and will cause a lot of backtracking. m 1 l In this case we might like to plan a 1 b for b first. Won’t total-order planning preclude us from doing that? Nau: PLANET, 2000 m 2 a 2 m 3 b a 3 m 4 b a 4 1 b

Answer to a Question from Yesterday task t l Question: Suppose there’s an action b that will come late in the plan and will cause a lot of backtracking. m 1 l In this case we might like to plan a 1 b for b first. Won’t total-order planning preclude us from doing that? l Answer: Not necessarily m 2 a 2 m 3 b a 3 m 4 b a 4 b task t l One way to do it: Tell the planner to create a plan for b and retrieve that plan later find a plan p for b m store p m 1 a 1 Nau: PLANET, 2000 do p task t’ m 2 a 2 do p m 3 a 3 m 4 do p a 4 do p 1

Answer to a Question from Yesterday task t l Question: Suppose there’s an action b that will come late in the plan and will cause a lot of backtracking. m 1 l In this case we might like to plan a 1 b for b first. Won’t total-order planning preclude us from doing that? l Answer: Not necessarily m 2 a 2 b a 3 m 4 b a 4 b task t l Another way to do it: Tell the planner to start by checking m b’s preconditions, without check b’s preconditions actually planning for b m 1 a 1 Nau: PLANET, 2000 m 3 task t’ m 2 b a 2 m 3 b a 3 m 4 b a 4 b 1

Answer to Another Question l Question: With total-order planning, task t can we interleave subgoals? m 1 load a Nau: PLANET, 2000 load b m 2 deliver a deliver b 1

Answer to Another Question l Question: With total-order planning, task t can we interleave subgoals? l Answer: m 1 m 2 u Not in SHOP, because all of the subtasks will be totally ordered load a load b deliver a deliver b u Sometimes we can circumvent this, by using methods that put task t the subtasks into a different order load all deliver all l In some cases this is natural; in other cases it is clumsy load a load b deliver a deliver b u We have an extension to the SHOP algorithm called M-SHOP [Nau et al. , TR, 2000], in which some of the subtasks can be unordered Nau: PLANET, 2000 1

Answer (Continued) two different task lists l Basic idea for M-SHOP: load and deliver a u When we have several task m 1 m 2 lists without an ordering between them, do this: load a deliver a load b deliver b loop if all of the task lists are empty, then exit remove the first item from one of the task lists decompose it, and put its subtasks at the front of the task list repeat u Need a way to handle protected conditions l How we do this is described in [Nau et al. , 2000] u M-SHOP is available at http: //www. cs. umd. edu/projects/shop as part of the latest software distribution for SHOP l Currently they are separate programs In the next release, they’ll be merged into a single program 1 Nau: PLANET, l 2000

Answer (Continued) l M-SHOP doesn’t fully implement partially ordered task lists u It can take multiple task lists load and deliver a m 1 load a deliver a load and deliver a m 2 load b deliver b as part of its input u It doesn’t allow methods to have subtasks that are partially ordered l However u To allow methods to have partially ordered subtasks is an easy generalization u We’ve written down the algorithm, but haven’t implemented it yet Nau: PLANET, 2000 1

Review of the SHOP Algorithm state S; task list T=( t , …) 1 2 procedure SHOP (state S, task-list T, domain D) operator instance o 1. if T = nil then return nil 2. t 1 = the first task in T state o(S) ; task list T=(t 2, …) 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) nondeterministic choice 6. if P = FAIL then return FAIL among all methods m 7. return cons(o, P) whose preconditions can 8. else if t is non-primitive be inferred from S & 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 task list T=( t 1 , t 2, …) 11. return FAIL method instance m 12. end if end SHOP task list T=( u 1, …, uk , t 2, …) Nau: PLANET, 2000 1

Encoding the Blocks World Algorithm into SHOP loop if there is a clear block x such that x or a block beneath x is in a location inconsistent with the goal and x can be moved to a location such that x and all blocks beneath x will be in locations consistent with the goal then move x to that location else if there is a clear block x such that x or a block beneath x is in a location inconsistent with the goal then move x to the table else exit endif repeat Nau: PLANET, 2000 1

How to Encode “x or a block beneath it is in a location inconsistent with the goal” (: - (need-to-move ? x) ; ; need to move x if x needs to go from one block to another ((on ? x ? y) (goal (on ? x ? z)) (different ? y ? z)) ; ; need to move x if x needs to go from table to block ((on-table ? x) (goal (on ? x ? z))) ; ; need to move x if x needs to go from block to table ((on ? x ? y) (goal (on-table ? x))) ; ; need to move x if x is on y and y needs to be clear ((on ? x ? y) (goal (clear ? y))) ; ; need to move x if x is on z and something else needs to be on z ((on ? x ? z) (goal (on ? y ? z)) (different ? x ? y)) ; ; need to move x if x is on something else that needs to be moved ((on ? x ? w) (need-to-move ? w))) Nau: PLANET, 2000 2

Example (Continued) loop if there is a clear block x such that x or a block beneath x is in a location inconsistent with the goal and x can be moved to a location such that x and all blocks beneath it will be in locations consistent with the goal then move x to that location else if there is a clear block x such that x or a block beneath x is in a location inconsistent with the goal then move x to the table else exit endif repeat Nau: PLANET, 2000 2

Operators for Moving Blocks (: operator (!pickup ? x) ((clear ? x) (on-table ? x)) ((holding ? x))) (: operator (!putdown ? x) ((holding ? x)) ((on-table ? x) (clear ? x))) (: operator (!stack ? x ? y) ((holding ? x) (clear ? y)) ((on ? x ? y) (clear ? x))) (: operator (!unstack ? x ? y) ((clear ? x) (on ? x ? y)) ((holding ? x) (clear ? y))) Nau: PLANET, 2000 c a b a a b c 2

Example (Continued) loop if there is a clear block x such that x or a block beneath x is in a location inconsistent with the goal and x can be moved to a location such that x and all blocks beneath it will be in locations consistent with the goal then move x to that location else if there is a clear block x such that x or a block beneath x is in a location inconsistent with the goal then move x to the table else exit endif repeat Nau: PLANET, 2000 2

Representing Tasks Initial state: (clear c) (clear b) (on c a) (ontable b) (ontable a) (handempty) c a b Goals: a (on a b) b (on b c) c l Suppose we use the task list u ((achieve (on a b)) (achieve (on b c))) l This won’t do what we want u First it will perform the task (achieve (on a b)) u Then it will perform the task (achieve (on b c)) l Instead, we need a task list something like u ((achieve (on a b) (on b c))) l Need to keep track of u which goals we have achieved and need to preserve u which goals remain to be achieved l How to do this? Nau: PLANET, 2000 2

Bookkeeping l Keeping track of what the goals are u Insert information about this into the current state u This is convenient because it lets us use precondition-matching to match methods to goals l Keeping track of the goals that we have achieved and need to preserve u Insert information about this into the task list u Could also have put this into the current state instead l That’s what we do in other domains, such as the logistics domain [Nau et al. , 2000] Nau: PLANET, 2000 2

Bookkeeping Operator and Methods (: operator (!assert ? atoms) ; ? atoms is a list of atoms to assert () ; no preconditions ? atoms ; put the list of atoms into the current state 0) ; this operator has no cost (: method (assert-goals (? first. ? rest) ? atoms) () '((assert-goals ? rest ((goal ? first). ? atoms)))) ; recursively build a list ; of atoms to assert into ; the current state (: method (assert-goals nil ? atoms) ; we’ve built the entire list, so assert it () '((!assert ? atoms))) (: method (achieve-goals ? goals) ; assert all the goals into the current state, () ; then call move-block to achieve them '((assert-goals ? goals nil) (move-block nil))) Nau: PLANET, 2000 2

and - x can be moved to a location such that x and all blocks beneath it will be in locations consistent with the goal then move x to that location (: method (move-block ? nomove) ; ; method for moving x from y to z (: first (clear ? x) (eval (not (member '? x '? nomove))) (on ? x ? y) (goal (on ? x ? z)) (different ? x ? z) (clear ? z) (not (need-to-move ? z))) '((!unstack ? x ? y) (!stack ? x ? z) (move-block (? x. ? nomove))) ; ; method for moving x from y to table (: first (clear ? x) (eval (not (member '? x '? nomove))) (on ? x ? y) (goal (on-table ? x))) '((!unstack ? x ? y) (!putdown ? x) (move-block (? x. ? nomove))) ; ; method for moving x from table to y (: first (clear ? x) (eval (not (member '? x '? nomove))) (on-table ? x) (goal (on ? x ? y)) (clear ? y) (not (need-to-move ? y))) '((!pickup ? x) (!stack ? x ? y) (move-block (? x. ? nomove))) … Nau: PLANET, 2000 2

else if there is a clear block x such that x or a block beneath x is in a location inconsistent with the goal then move x to the table else exit endif (: method (move-block ? nomove) … ; ; method for moving x out of the way ((clear ? x) (eval (not (member '? x '? nomove))) (on ? x ? y) (need-to-move ? x)) '((!unstack ? x ? y) (!putdown ? x) (move-block ? nomove)) ; ; if none of the above preconditions were satisfied, then we're done nil) Nau: PLANET, 2000 2

Question l I can run SHOP on the blocks world for you right now. l Would you like me to do so? Nau: PLANET, 2000 2

Experimental Comparison l Experimental comparison u Planning domains: l Blocks world l Logistics l UM Translog u Planning systems compared: l Blackbox - Graphplan plus satisfiability l IPP - Graphplan plus ADL l TLplan - forward search with modal-logic pruning rules l UMCP - “classical” HTN planning l SHOP- Ordered Task Decomposition Nau: PLANET, 2000 3

Blocks World Time l 100 randomly generated problems l 167 -MHz Sun Ultra with 64 MB of RAM l Blackbox and IPP could not solve any of these problems l TLplan’s running time was only slightly worse than SHOP’s Number of actions in plan u TLplan’s pruning rules [Bacchus et al. , 2000] have expressive power similar to SHOP’s u Using its pruning rules, they encoded a blockstacking algorithm similar to ours Nau: PLANET, 2000 3

Logistics l 110 randomly generated problems l Same machine as before l As before, Blackbox and IPP could not solve any of these problems l TLplan ran somewhat slower than SHOP (about an order of magnitude on large problems) Nau: PLANET, 2000 Time Number of actions in plan 3

Logistics (Continued) l 30 problems from l l the Blackbox distribution SHOP and TLplan on the same machine as before Blackbox on a faster machine, with 8 GB of RAM SHOP was about an order of magnitude faster than TLplan was about two orders of magnitude faster than Blackbox Nau: PLANET, 2000 Time Number of actions in plan 3

UM Translog l HTN planning domain [Andrews et al. , 1995] u Inspired by the logistics domain, but about an order of magnitude larger u Several different kinds of packages, vehicles, and procedures for handling the packages l e. g. , hazardous materials need special handling u Several dozen primitive operators u Several dozen methods u Typical problems: dozens of vehicles, dozens of packages l SHOP versus UMCP u UMCP [Erol, 1994] is our “classical” HTN planner l Couldn’t test the other planners u Difficult to translate this domain into an action-based format l Will say more about this later Nau: PLANET, 2000 3

UM Translog (Continued) l 100 randomly Time generated problems l Same machine as before l UMCP did much worse than SHOP Number of actions in plan Nau: PLANET, 2000 3

Digression: Translating HTN Problems into Action-Based Planning Problems l Can we compare these results with those of action-based planners (IPP, Blackbox, etc. )? l Problem: u HTN planning is strictly more expressive then STRIPS-style planning (Erol et al. 1994) u HTN problems from domains that include unbounded recursion among their methods cannot be expressed in STRIPS l However: u UM-Translog does not include recursive methods at all u For such cases, Amnon Lotem [Lotem & Nau, 2000] has defined an algorithm that translates an HTN domain into a STRIPS domain Nau: PLANET, 2000 m 1 m 1 . . . 3

HTN-to-STRIPS Algorithm HTN Operator Preconditions STRIPS Operator Add Effects p 1 Load p 2 e 1 Preconditions Add Effects p 1 Load p 2 e 1 Load-completed Artificial predicate Nau: PLANET, 2000 3

HTN-to-STRIPS Algorithm HTN Method STRIPS Operator Preconditions Load-top (? p, ? t, ? o) m Door-open Load Door-closed (? t) (? p, ? t, ? o) (? t) Add Effects Door-opencompleted (? t) Load-completed (? p, ? t, ? o) op-m Artificial operator Load-topcompleted (? p, ? t, ? o) Door-closedcompleted (? t) Nau: PLANET, 2000 3

Translating UM-Translog into STRIPS l Lotem used the algorithm to translate a subset of the UM -Translog domain into a STRIPS-style representation l There were several problems with that approach: u Poor readability of the resulting domain(artificial operators and predicates) u The artificial operators can be filtered out from the final solution, but we cannot guarantee minimal parallel length of the reported plan u A huge number of instantiated actions. Only very simplified versions of the test problems could be solved using Blackbox and IPP. Nau: PLANET, 2000 3

Manual Encoding of UM-Translog Specs Manual HTN Encoding STRIPS-Style Encoding Translation Algorithm operators methods + operators l Guidelines: u Do not create artificial operators u Keep the domain compact (smaller number of instantiated actions) l Findings: u It was difficult to express such a spec by using only operators. u Many operators became context-specific to preserve order constraints u Domain was still large, although more compact then the previous one l Could run IPP on some simple UM Translog problems, but not Blackbox Nau: PLANET, 2000 4

AIPS-2000 Planning Competition l Two tracks: u Track 1: STRIPS and PDDL planners u Track 2: “hand tailored” planners l many more problems, much harder problems l We entered SHOP in Track 2 l We didn’t do much preparation for the competition u We felt very confident that SHOP would perform best l We were wrong! u SHOP ran much faster than the Track-1 planners, but it wasn’t the best planner in Track 2 l In two domains, we got incorrect results on a few problems l In the other problem domains, a new planner called TALplanner was faster Nau: PLANET, 2000 4

AIPS-2000 Planning Competition (Continued) l Why we got the errors u We had to translate from PDDL to SHOP by hand l In two domains, we didn’t do the translation correctly l The errors were minor, but caused incorrect results u For next time, we are writing an PDDL-to-SHOP translator l Why TALplanner was faster (we think) u Like TLplan, TALplanner does forward search guided by pruning rules written in modal logic l many of the same advantages as the SHOP algorithm u TALplanner uses highly optimized data structures u For next time, we intend to do the same for SHOP l Example: by making a simple modification to SHOP’s state representation, we made SHOP more than an order of magnitude faster Nau: PLANET, 2000 4

Related Publications [Andrews et al. , 1995] Andrews, Kettler, Erol, and Hendler. UM Translog: A Planning Domain for the Development and Benchmarking of Planning Systems. Tech. Report CS-TR-3487, Dept. of Computer Science, U. of MD. [Bacchus et al. 2000] Bacchus and Kabanza. Using Temporal Logics to Express Search Control Knowledge for Planning. Artificial Intelligence, 116(1 -2): 123 -191. [Erol et al. , 1994]Erol, Hendler, and Nau. UMCP: A Sound and Complete Procedure for Hierarchical Task-Network Planning. AIPS-94, 249 -254. [Lotem & Nau, 2000] A. Lotem and D. Nau. N� ew Advances in Graph. HTN: Identifying Independent Subproblems in Large HTN Domains. In Proc. Fifth International Conference on Artificial Intelligence Planning and Scheduling (AIPS-2000), April 14 -17, 2000, pages 206 -215. Breckenridge, CO. <http: //www. cs. umd. edu/~nau/papers/AIPS-2000. pdf> [Nau et al. , 1999] D. Nau, Y. Cao, A. Lotem, and H. Munoz-Avila. SHOP: Simple Hierarchical Ordered Planner. IJCAI-99, August 1999, pp. 968 -973. <http: //www. cs. umd. edu/~nau/papers/shop-ijcai 99. pdf> [Nau et al. , 2000] D. S. Nau, Y. Cao, A. Lotem, and H. Muñoz-Avila. SHOP and M-SHOP: Planning with Ordered Task Decomposition. Tech. Report CS TR 4157, University of Maryland: College Park, MD, 2000. <http: //www. cs. umd. edu/~nau/papers/shop-ijcai 99. pdf> Nau: PLANET, 2000 4

6. Evacuation Planning Theory 1. Principles of HTN planning 2. Computer bridge 4. Ordered Task Decomposition 3. Electronic Design and Manufacturing 5. SHOP 6. Evacuation planning Applications l Joint work with David Aha, Leonard Breslow, and Héctor Muñoz-Avila Nau: PLANET, 2000 4

Noncombatant Evacuation Operations (NEOs) l Goal: u Assist the US Dept. of State to evacuate people whose lives are in danger l noncombatants, nonessential military personnel, host-nation citizens, thirdcountry nationals l Characteristics: u Joint task force - geographically distributed, often multi-national u Uncertainty u Complexity (200+ tasks) u US Ambassador is senior authority l More than ten NEOs were conducted within the past decade Nau: PLANET, 2000 4

HICAP: Hierarchical Interactive Case-based Architecture for Planning U S E R IDS Requests Elicited plan Plan HICAP Scenario l Motivation u Interactive decision support tool - user in control u Guided by military doctrine u Provide access to previous experiences l Plan elicitation by reusing cases l Plan revision by reusing lessons learned u Inferencing on standard procedures u Perform bookkeeping l Reduce the chances of error l Help secure accountability Nau: PLANET, 2000 4

Why HTN Planning? l Hierarchical planning is natural for military organizations Strategic National Strategic Theater Operational JCS / NCA CINC JTF Tactical Nau: PLANET, 2000 4

HICAP: Hierarchical Interactive Case-based Architecture for Planning U S E R IDS Requests Plan Scenario Elicited plan Lessons Deliverer HICAP Hierarchical Task Editor (HTE) Na. Co. DAE/HTN CCBR Tool SHOP Generative Planner Dec. TS Decision Tracker Mixed-initiative planner u Interactive case retrieval: Select among alternative task decompositions u Generative planning: Automated task component u Resource conflict identification and resolution Input: Doctrine & resources, cases, methods, lessons u HTN representation Output: Elicited plan Nau: PLANET, 2000 4

Hierarchical Task Editor HTE (i. e. , manual) U S E R Task 1. Apply Doctrine 2. Manual Edits Na. Co. DAE/HTN 3. Apply Cases SHOP 4. Apply Methods Task Decomposition Nau: PLANET, 2000 4

Example SHOP Methods Select Helicopter Launching Base Establish Base within Flying Distance alternative Launch from methods Carrier Battle Transport helicopters available (H) Security force available (F) Group Transport helicopters available (H) Helicopters have air refuel. capability (H) Select Helicopter Launching Base Select possible area (A) Transport sec. force (F, A, H) Embark sec. force (F, H) Fly(H, A) Disembark (F, H, A) Position security force (F, A) Transport fuel to (A). . . l Decompose tasks into (more tactical) subtasks l Consider restrictions (e. g. , transport helicopters available) l Resolve interactions (e. g. , deploy security force first) l If necessary, backtrack and try other methods Nau: PLANET, 2000 5

Na. Co. DAE/HTN: Navy Conversational Decision Aids Environment - Na. Co. DAE/HTN implements Conversational Case Based Reasoning User - Na. Co. DAE/HTN allows interactive elicitation of situations from the user Alternative decompositions (cases) for the task ranked according to the user’s answers Nau: PLANET, 2000 <Q, A> process … selects case System’s Situation Knowledge 5

Methods Versus Cases SHOP Methods denote generic task decompositions and conditions for selecting those decompositions: Task: travel(From, To) Decomposition: travel. C(From, Station 1) travel. IC(Station 1, Station 2) travel. C(Station 2, To) Conditions: in(To, City 1) in(To, City 2) train. Station(Station 1, City 1) train. Station(Station 2, City 2) Nau: PLANET, 2000 Na. Co. DAE/HTN Cases denote concrete task decompositions (taken from previous plans) and preferences for selecting those decompositions: Task: travel. C(Penn ST. , Downtn NYC) Decomposition: take(taxi, Penn St. , Downtn NYC) Questions: Is it raining hard in NYC? No Is the passenger carrying luggage? No 5

Using Na. Co. DAE/HTN Planning tasks World State Nau: PLANET, 2000 5

Si. N: SHOP integrated with Na. Co. DAE/HTN In a mixed-initiative manner either SHOP or Na. Co. DAE/HTN has control over the decomposition process and cedes control to the other if it cannot proceed In control System’s Situation Knowledge SHOP … Na. Co. DAE/HTN SHOP Nau: PLANET, 2000 … 5

Si. N: Algorithm l Let t be the task currently being decomposed l If t is primitive return a success l Else if SHOP is in control u SHOP decomposes t if possible. If SHOP cannot decompose t but Na. Co. DAE/HTN can, then cede control to Na. Co. DAE/HTN. l Else if Na. Co. DAE/HTN is in control u Na. Co. DAE/HTN decomposes t if possible. If Na. CODAE/HTN cannot decompose t but SHOP can, then cede control to SHOP. l Else if neither SHOP nor Na. Co. DAE/HTN can decompose t u Backtrack if possible. If it is not possible, then return a failure. Nau: PLANET, 2000 5

Si. N: Example – Mixed Initiative SHOP Methods denote generic task decompositions and conditions for selecting those decompositions: Task: travel(From, To) Decomposition: travel. C(From, Station 1) travel. IC(Station 1, Station 2) travel. C(Station 2, To) Conditions: in(To, City 1) in(To, City 2) train. Station(Station 1, City 1) train. Station(Station 2, City 2) Nau: PLANET, 2000 Na. Co. DAE/HTN Cases denote concrete task decompositions and preferences for selecting those decompositions: Task: travel. C(Penn ST. , Downtn NYC) Decomposition: take(taxi, Penn St. , Downtn NYC) Questions: Is it raining hard in NYC? No Is the passenger carrying luggage? No 5

Si. N: Example – Mixed Initiative In control SHOP Travel(Greenbelt, NYC) Travel(Greenbelt, Union St. ) Taxi(Greenbelt, Greenbelt. M) Metro(Greenbelt. M, Union St. ) Na. Co. DAE/HTN Train(Union St. , Penn St. ) Travel(Penn St. , Downtn NYC) Taxi(Penn St. , Downtn NYC) Nau: PLANET, 2000 5

Evaluating HICAP l Use HICAP to plan a NEO subtasks u compare performance with other approaches l How to evaluate? Can’t actually carry out a NEO u Mod. SAF - simulation program developed by the US Army l Simulates real-world military scenarios l Finite state simulation with modular components that represent individual entities and parts of entities u Example: simulated tank Ô Physical components (turret, etc. ) and behavioral components (move, attack, target, react to fire, etc. ) l Certain 3 D aspects are also represented that can affect sensory and movement behavior u terrain elevation, trees, vegetation, rivers, oceans, atmospheric conditions, etc. l Realism is sufficient for training exercises Nau: PLANET, 2000 5

Snapshot of the Mo. DSAF Simulator Nau: PLANET, 2000 5

Evaluation: Empirical Methodology Blind study: HICAP user did not know the simulated scenario NEO Subtask: Transport 64 evacuees from meeting site to embassy • Meeting site at forested crossroads outside of city • Terrain database from Camp Lejeune Transport by Land Air Selection Method: 1. HICAP 2. Most frequently used plan 3. Heuristic Choice (escort avg. ) 4. Random Nau: PLANET, 2000 Escorted? No Yes (tanks) No Yes (attack helicopters) We used the same performance measures used by the US armed forces: • Casualties (Evacuees, friendlies, hostiles) 6

Two Scenarios and Average Results (Mod. SAF is non-deterministic 10 Runs) Evacuees Saved: 64 54 49 44 39 1 Nau: PLANET, 2000 2 Hostile Casualties: 9 8 7 6 5 4 3 2 1 0 59 HICAP: Most Frequent: Heuristic: Random: Friendly Casualties: 1 2 Scenarios: 8 2 -person dismounted hostile teams: 1. Anti-tank missiles, or 2. Anti-aircraft missiles 6

Related Work System SHOP Generative Case-based Mixed-initiative X CHEF X Prodigy/Analogy X SIPE II X Na. Co. DAE/HTN X X MI-CBP X X X Si. N X X X Nau: PLANET, 2000 Interleaved X 6

Job Announcement l We want to hire a full-time research scientist to work on extensions to HICAP u Research areas: mixed-initiative planning, case-based reasoning, generative planning, knowledge management, and machine learning u The work will be joint between the University of Maryland NRL's Intelligent Decision Aids Group u Ideal applicants will have some relevant research experience/interest, and Java software development expertise l Experience with simulators, military applications, and/or Smalltalk would also be welcome u The position is available now l l If you’re interested, please let me know! Nau: PLANET, 2000 6

Related Publications [Muñoz-Avila et al. , 1999 a] H. Muñoz-Avila, D. Mc. Farlane, D. Aha, J. Ballas, L. Breslow and D. Nau. Using guidelines to constrain interactive case-based HTN planning. In Proceedings of the Third International Conference on Case-Based Reasoning (ICCBR-99), 1999. Finalist for the best paper award. <http: //www. aic. nrl. navy. mil/papers/1999/AIC-99 -004. ps. Z> [Muñoz-Avila et al. , 1999 b] H. Muñoz-Avila, D. Aha, L. Breslow and D. Nau. HICAP: an interactive case-based planning architecture and its application to noncombatant evacuation operations. In IAAI-99, 1999, pages 870875. <http: //www. aic. nrl. navy. mil/papers/1999/AIC-99 -002. ps. Z> [Muñoz-Avila et al. , 2000] H. Muñoz-Avila, D. W. Aha, L. A. Breslow, D. S. Nau and R. Weber. Integrating Conversational Case Retrieval with Generative Planning. In EWCBR-2000, 2000. Trento, Italy: Springer-Verlag. Nau: PLANET, 2000 6

Summary Theory 1. Principles of HTN planning 2. Computer bridge 4. Ordered Task Decomposition 3. Electronic Design and Manufacturing 5. SHOP 6. Evacuation planning Applications l Ordered task decomposition is an adaptation of HTN planning u Prolog-style left-to-right search; high degree of expressivity l Grew out of our work in two application domains: u manufacturing planning and the game of bridge l SHOP: domain-independent planning algorithm u Sound and complete over a wide class of problems u Powerful enough for use in complex applications l Evacuation planning Nau: PLANET, 2000 6

Conclusions l For a long time, AI planning researchers thought that forward search was not a good way to generate plans u Recent results (SHOP, TLplan, FF) strongly suggest otherwise l AI planning is becoming capable enough to be used in real-world applications l Synergy between theory and applications u Understanding what works in practical planning situations can produce better planning theories u This will lead to better real-world planners Nau: PLANET, 2000 Theory Practice 6

Future Work l Improvements to SHOP u optimize the data structures u PDDL-to-SHOP translator l Planning with incomplete information u Contingency plans, evaluation of alternatives l Somewhat like the game-tree search we did in Bridge Baron l Semi-automated knowledge acquisition u Case-based reasoning to synthesize HTN methods in HICAP, by observing what plans the human user creates in what situations l Multi-agent planning u Integrate SHOP with the IMPACT multi-agent environment Nau: PLANET, 2000 6

Acknowledgements, and Where to Get More Information l Sponsors u Government: NSF, NRL, ARL, DARPA u Industry: Great Game Products, Northrop Grumman l Where to get more information u Computer Bridge http: //www. cs. umd. edu/~nau/bridge. html u EDAPS http: //www. cs. umd. edu/~nau/projects/edaps. pdf u SHOP http: //www. cs. umd. edu/projects/shop/ u HICAP http: //www. aic. nrl. navy. mil: 80/hicap/ Nau: PLANET, 2000 6