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

1Nau: PLANET, 2000

Ordered Task Decomposition:

Theory and Practice

Dana S. NauDept. of Computer Science, and

Institute for Systems Research

University of Maryland, College Park, MD

2Nau: PLANET, 2000

Generating Plans of Action

Programs to aid human planners Project management (consumer software) Plan storage and retrieval

(e.g., variant process planning) Automatic schedule generation (various OR and AI techniques)

For some problems, really want togenerate plans automatically Much more difficult Very few successful programs for realistic problems

AI planning research is starting to pay off Of the few really good plan generation systems for practical

problems, most involve AI planning techniques However, …

Processes:Opn A BC/WW Setup Runtime LN Description001 A VMC1 2.00 0.00 01 Orient board 02 Clamp board 03 Establish datum point at bullseye (0.25, 1.00)001 B VMC1 0.10 0.43 01 Install 0.30-diameter drill bit 02 Rough drill at (1.25, -0.50) to depth 1.00 03 Finish drill at (1.25, -0.50) to depth 1.00001 C VMC1 0.10 0.77 01 Install 0.20-diameter drill bit 02 Rough drill at (0.00, 4.88) to depth 1.00 03 Finish drill at (0.00, 4.88) to depth 1.00 [...]001 T VMC1 2.20 1.20 01 Total time on VMC1[...] 004 A VMC1 2.00 0.00 01 Orient board 02 Clamp board 03 Establish datum point at bullseye (0.25, 1.00)004 B VMC1 0.10 0.34 01 Install 0.15-diameter side-milling tool 02 Rough side-mill pocket at (-0.25, 1.25) length 0.40, width 0.30, depth 0.50 03 Finish side-mill pocket at (-0.25, 1.25) length 0.40, width 0.30, depth 0.50 04 Rough side-mill pocket at (-0.25, 3.00) length 0.40, width 0.30, depth 0.50 05 Finish side-mill pocket at (-0.25, 3.00) length 0.40, width 0.30, depth 0.50004 C VMC1 0.10 1.54 01 Install 0.08-diameter end-milling tool [...]004 T VMC1 2.50 4.87 01 Total time on VMC1 005 A EC1 0.00 32.29 01 Pre-clean board (scrub and wash) 02 Dry board in oven at 85 deg. F005 B EC1 30.00 0.48 01 Setup 02 Spread photoresist from 18000 RPM spinner005 C EC1 30.00 2.00 01 Setup 02 Photolithography of photoresist using phototool in "real.iges"005 D EC1 30.00 20.00 01 Setup 02 Etching of copper005 T EC1 90.00 54.77 01 Total time on EC1 006 A MC1 30.00 4.57 01 Setup 02 Prepare board for soldering006 B MC1 30.00 0.29 01 Setup 02 Screenprint solder stop on board006 C MC1 30.00 7.50 01 Setup 02 Deposit solder paste at (3.35,1.23) on board using nozzle [...] 31 Deposit solder paste at (3.52,4.00) on board using nozzle006 D MC1 0.00 5.71 01 Dry board in oven at 85 deg. F to solidify solder paste006 T MC1 90.00 18.07 01 Total time on MC1[...] 011 A TC1 0.00 35.00 01 Perform post-cap testing on board011 B TC1 0.00 29.67 01 Perform final inspection of board011 T TC1 0.00 64.67 01 Total time on TC1 999 T 319.70 403.37 01 Total time to manufacture

3Nau: PLANET, 2000

AI Planning Is Different in PracticeThan 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)

Theory: Symbolic computations

(STRIPS operators) Single agent (the planner) Perfect information

Practice: Complex numeric computations

(geometry, images, probabilities) Multiple agents Imperfect information, external

information sources

4Nau: PLANET, 2000

Goal Develop synergy

between theoryand applications

By understanding what worksin practical planning situations,we can develop better theories of planning

Better theories of planningcan lead to better real-world planners

Theory

Applications

5Nau: PLANET, 2000

Approach (and Outline)

Theory

Applications

6. Evacuationplanning

3. Electronic Designand Manufacturing

5. SHOP1. Principles ofHTN planning

2. Computerbridge

4. Ordered TaskDecomposition

Mainly I’ll use PowerPoint slides At two points, I can run demos in Lisp Please ask questions!

Day 1 Day 2

6Nau: PLANET, 2000

1. Principles of HTN Planning

Joint work with Kutluhan Erol and Jim Hendler

Theory

Applications




2. Computerbridge


7Nau: PLANET, 2000

What HTN Planning Is

method

travel(x,y)

travel by air get taxi ride taxi (x,y) pay driver

travel by taxi

travel(UMD, MIT)airport(UMD,BWI)airport(MIT,Logan)ticket(BWI, Logan)travel(UMD, BWI)

get taxiride taxi(UMD, BWI)pay driver

fly(BWI, Logan)travel(Logan, MIT)

get taxiride taxi(Logan, MIT)pay driver

A type of problem reduction Decompose tasks into subtasks Handle constraints (e.g., taxi not

good for long distances) Resolve interactions (e.g., take

taxi early enough to catch plane) 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)

8Nau: PLANET, 2000

Comparison with “Classical” AI Planning “Classical” AI planning is action-based

Declarative descriptions of actions Specify declaratively what the

operators are capable of doing Don’t prescribe how to

perform complex tasks The planner must infer that,

using trial-and-error search

HTN decomposition Can represent STRIPS-style

declarative operators, but it’s clumsy 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)

9Nau: PLANET, 2000

History of HTN Planning Originally developed about 25 years ago

[Sacerdoti 1977; Tate 1977] Long thought to have better potential for applicability to real-

world planning problems than classical STRIPS-style planning Progress delayed due to lack of theoretical understanding

More recent work: theoretical basis for HTN planning Formal semantics

HTN’s are strictly more expressive than STRIPS operators[Erol et al., 1994a]

Sound and complete algorithm [Erol et al., 1994b]Implementation available at http://www.cs.umd.edu/projects/plus/umcp/manual/

Complexity analysis [Erol et al., 1996] This has helped to spread interest in HTN planning

10

Nau: PLANET, 2000

What is Expressivity? Expressivity of languages

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

Possible ways to define “meaning”1. based on computational complexity

2. based on model theory

3. based on operational semantics

HTN planning is more expressive than state-based planning according to all three of these definitions Will summarize all three

11

Nau: PLANET, 2000

1. Complexity-Based Expressivity

Transformation must preserve answer (“yes” or “no”) Transformation must be computable/polynomial Affected by the conciseness of the language

Language L Language M

transformation

“yes”instances

“yes”instances

“no”instances

“no”instances

12

Nau: PLANET, 2000

HTN Language Versus STRIPS Language STRIPS-style planning is a special case of HTN planning

Erol [1995] presents two polynomial transformations from the STRIPS planning language to the HTN planning language

There is no computable transformation from the HTN language to the STRIPS language, because HTNs can represent harder problems than the STRIPS language

Example problem: Given two context-free languages L1 and L2, do they have a

non-empty intersection? This problem is undecidable It can’t be represented as a STRIPS-style planning problem

(not unless you augment the STRIPS formalism to include function symbols!)

13

Nau: PLANET, 2000

Representing the Problem using HTNs Given two context-free languages L1 and L2, do they have a

non-empty intersection?

This problem can be represented as an HTN planning problem You don’t need to use function symbols You don’t even need to use any variable symbols! However, you need to make use of

cycles in methods interleaving among subtasks

m1

m2

m1

t1

t11 t12 t13

t2

t21 t22 t23

14

Nau: PLANET, 2000

2. Model-Theoretic Expressivity Erol [1995] extended the work of Baader on knowledge

representation languages to planning languages The transformation must preserve meaning

The set of models satisfying a sentence and the set of models satisfying its tranformation must be equivalent

No restrictions on the computational aspects of the translation Not affected by the conciseness of the languages

Result Erol’s transformations from STRIPS to HTN (mentioned earlier)

preserve the set of models No transformations in the other direction, because HTN models

have richer structure Thus the HTN language is more expressive than the STRIPS

language

15

Nau: PLANET, 2000

3. Operational-Semantic Expressivity Transformation must preserve the set of solutions

(plans) Result:

Solutions to STRIPS problems are regular sets Solutions to HTN problems can be arbitrary context-free sets Thus HTN’s are more expressive than STRIPS

16

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. <http://www.cs.umd.edu/~kutluhan/Papers/htn-sem.ps>

[Erol et al., 1994a] K. Erol, J. Hendler and D. S. Nau. HTN Planning: Complexity and Expressivity. In AAAI-94, 1994. <http://www.cs.umd.edu/users/kutluhan/Papers/AAAI-94.ps>

[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. <http://www.cs.umd.edu/users/kutluhan/Papers/AIPS-94.ps>

[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. <http://www.cs.umd.edu/users/kutluhan/Papers/AMAI.ps>

17

Nau: PLANET, 2000

2. Computer Bridge

Joint work with Stephen J. Smith and Tom Throop

Theory

Applications




2. Computerbridge


18

Nau: PLANET, 2000

Computer Programs forGames of Strategy

Fundamental technique: minimax game-tree search Largely “brute force”

Can prune off portions of the tree cutoff depth, alpha-beta pruning, hash tables, …

Even then, it still examinesthousands of game positions

This is very different from how humans think Even the best human chess players

examine at most a few dozengame positions to make their moves

10 -3 5 9 -2 -7 2 3

10 9 -2 3

9 -2

19

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 playerat your local bridge club

Performance of Game-Playing Computer Programs

20

Nau: PLANET, 2000

Four players; 52 playing cards dealt equally among them Bidding to determine the trump suit

Declarer: whoever makes highest bid Dummy: declarer’s partner

The basic unit of play is the trick One player leads; the others

must follow suit if possible Trick won by highest card

of the suit led, unlesssomeone plays a trump

Keep playing tricks until allcards have been played

Scoring based on how many trickswere bid and how many were taken

West

North

East

South

62

8Q

QJ65

97

AK53

A9

How Bridge Works

21

Nau: PLANET, 2000

Bridge is an imperfect information game Don’t know what cards the others have (except the dummy) Many possible card distributions, so many possible moves

If we encode the additional moves as additional branches in the game tree, this increasesthe number of nodes exponentially worst case: about 6x1044 leaf nodes average case: about 1024 leaf nodes

Why Bridge is Difficultfor Computers

Not enough time to search the game tree

22

Nau: PLANET, 2000

How to Reduce the Sizeof the Game Tree?

Bridge is a game of planning The declarer plans how to play the hand The plan combines various strategies (ruffing, finessing, etc.) If a move doesn’t fit into a sensible strategy, it probably doesn’t

need to be considered

Our approach for declarer play Adaptation of an Hierarchical Task-Network (HTN) planning 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

≈ 1024 leaf nodes ≈ 26,000 leaf nodes

≈ 305,000 leaf nodes≈ 6x1044 leaf nodes

23

Nau: PLANET, 2000

(North— Q)… …

Task Network for Finessing

PlayCard(P3; S, R3)PlayCard(P2; S, R2) PlayCard(P4; S, R4)

FinesseFour(P4; S)

PlayCard(P; S, R1)

StandardFinesseTwo(P2; S)

LeadLow(P; S)

PlayCard(P4; S, R4’)

StandardFinesseThree(P3; S)

EasyFinesse(P2; S) BustedFinesse(P2; S)

FinesseTwo(P2; S)

StandardFinesse(P2; S)

Finesse(P; S)

Us: East declarer, West dummyOpponents: defenders, South & NorthContract: East – 3NTOn lead: West at trick 3 East: KJ74

West: A2Out: QT98653

(North— 3)

East— J

West— 2

North— 3 South— 5 South— Q

primitive action by

us

task

method

primitive action by opponent

24

Nau: PLANET, 2000

Game Tree Generated fromthe Task Network

N—Q E—K

FINESSE

N—3 E—J

N—3

W—2

E—K

S—3

S—Q

S—5

S—3

W—A 3 E—4 5

+600 CASH OUT

N— S—

+630+630

+600+600

+265+265

+600+600+600

+600

+270.730.0078

0.0078

0.9854

0.5

0.5

+630

–100

+630

+600

+600

...later strategies...

25

Nau: PLANET, 2000

We incorporated our code for declarer playinto Bridge Baron (an existing commercial program)

Using our code, Bridge Baron won the 1997 World Bridge Computer Challenge

Our code has been used in all versions of Bridge Baron since October 1997 Has sold many thousands of copies

Implementation

26

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. <ftp://ftp.cs.umd.edu/pub/papers/papers/ncstrl.umcp/CS-TR-3513/>

[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. <http://www.cs.umd.edu/~nau/papers/bridge-aimag98.pdf>

27

Nau: PLANET, 2000

3. Electronic Design and Manufacturing

Joint work with Stephen J. Smith, Kiran Hebbar, and Ioannis Minis

Theory

Applications




2. Computerbridge


28

Nau: PLANET, 2000

Integrated Product and Process Design (IPPD)

Augment the traditional “engineering design” loop Plan and evaluate what manufacturing processes will be needed Predict cost, time, quality, manufacturing problems Modify the design to improve its manufacturability

Productmodeling

Engineering andfunctionality

analysis

Manufacturabilityanalysis

verifyparameters

Preliminary design

Modify design Acceptable design

29

Nau: PLANET, 2000

Microwave Transmit/Receive Modules 1-20 GHz frequency range (radars, satellite communications, etc.) Difficult and expensive to design and manufacture

30

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 manufacturabilityDesigner

AEL Routines

- Commercial

MDL Routines

Design,Constraints

31

Nau: PLANET, 2000

EDAPS’s Process Planner

Can express planning using “recipes” that fit well into HTN methods Generate and evaluate multiple process plans Estimate times and costs Display results graphically

(alternative methods)

A portion of the task network:

Spindling Spraying Spreading Painting

PhotolithographyApply photoresistPreclean for artwork Etching

(one possible method)

Make the artwork

32

Nau: PLANET, 2000

Processes:

Opn A BC/WW Setup Runtime LN Description 001 A VMC1 2.00 0.00 01 Orient board vertically 02 Clamp board at (1,1,1) 03 Establish datum point

001 B VMC1 0.10 0.43 01 Tool: 0.30-diameter drill bit 02 Drill at (1.25,-0.50 d:1.00,f:50,s:30

03 Drill at(1.25,-0.50) d:1.00,f:20,s:60

001 C VMC1 0.10 0.77 01 Tool: 0.20-diameter slot miller 02 MiII 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 01 Total time on VMC1…

006 A PLAT1 1.00 0.60

007 A ETR1 0.50 0.60

008 A ETC1 0.20 0.30…

02 Dip in bath for 2 minutes Temperature:100C, Conc:1000ppm

01 Etch plate for 1 minute

Substrate

Dimensions: 7,4,1 Ground Material: AluminumMaterial: Teflon

Substrate thickness: 30 mils Metallized thickness: 7 mils

01 Etch board for 2 minutes Temperature:100C, Conc:1000ppm

Examplesfrom

EDAPS

33

Nau: PLANET, 2000

Alternativecomponents

Pareto-optimalcombinations

Multi-objectiveInteger Programming

Database lookup

Status EDAPS completed under NSF funding Follow-up project with Northrop Grumman

Combine AI planning with Integer Programming optimization

… …

… …

… …

HTN planningAlternativeplans

Interactive displayUser exploration and selection

C1 Ci Cp

Aij

Pijk

ApqA11

P111 Ppqr

A1xx … Apxx A1xx … Apxx…

Electronic CAD Initial componentselection

34

Nau: PLANET, 2000


[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. <http://www.cs.umd.edu/~nau/papers/edaps-asme96.pdf>

[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. <http://www.cs.umd.edu/~nau/papers/kicad97.ps>

[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. <http://www.cs.umd.edu/~nau/papers/kic-2000.pdf>

35

Nau: PLANET, 2000

4. Ordered Task Decomposition

Joint work with Kutluhan Erol, Naresh Gupta, and Stephen J. Smith

Theory

Applications




2. Computerbridge


36

Nau: PLANET, 2000

Discussion For both Bridge Baron and EDAPS

We used the same approach Even some of the same code!

Ordered Task Decomposition Adaptation of HTN planning

Linear ordering on the subtasks of each method Expand the subtasks in the same order in which they will be

executed later on

Compare and contrast with “classical” AI planning1. Search strategy

2. Data representation

method

subtask 3subtask 2subtask 1 subtask 4

task

37

Nau: PLANET, 2000

Search Strategy

Ordered task decomposition Adaptation of HTN planning Require the subtasks of each method to be totally ordered Decompose these tasks left-to-right

The same order that they’ll later be executed Analogous to PROLOG’s search strategy

Spindling Spraying Spreading Painting

PhotolithographyApply photoresistPreclean for artwork Etching

Make the artwork for a PC board

38

Nau: PLANET, 2000

Search Strategy (Continued)

With action-based planning, you have an either/or choice: goal-directed search (backward from the goal) forward search (forward from the initial state)

In contrast, ordered task decomposition is both forward and goal-directed at the same time

C

A B

A

B

C

Pick up CPut C on the table

Pick up APut A on B

Pick up BPut B on C

39

Nau: PLANET, 2000

Example STRIPS operator to stack a block

Translate it into an HTN method If we expand the subtasks in left-to-right

order, then we are searchingforward from the initial state

Always know the current state However, it’s also a

goal-directed search The task is the goal 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

ca b

c

a b

40

Nau: PLANET, 2000

The operators aren’t totally ordered How do we we know what the states are? Represent states as sets of logical atoms

Partially instantiate them to represent what we know about them protected conditions in POP, mutex conditions in Graphplan

This works (it leads to sound and complete planners) Since the states aren’t totally instantiated, it’s hard to reason about

them in all of the ways we might like 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 Representationfor Partial-Order Planning

C

A B

A

B

C

Pick up CPut C on the table

Pick up APut A on B

Pick up BPut B on C

41

Nau: PLANET, 2000

State Representation forOrdered Task Decomposition

Goal-directed, but generates actions in the same order in which they will later be executed

Whenever we want to plan the next task we’ve already planned everything that comes before it

Thus, we know the current state of the world

s0 s1 s2 …

task tm …

…

task tn

op1 op2 opiSi–1

42

Nau: PLANET, 2000

Increased Expressivity If we know what the current state is, then we can do

complex reasoning about it Logical inferences Numeric and probabilistic computations Interactions with external programs

Example In computer bridge, by knowing the current state, can decide

which of nineteen finesse situations are applicable With partial-order planning, it would be hard to decide which of

them can be made applicable

Can do lots of pruning Often only one or two consistent “next steps”

Bridge declarer play: complete plans in about 11/2 minutes Process plans for microwave modules: a few seconds

43

Nau: PLANET, 2000

Example: Blocks-World Planning The blocks world

On the next page is the best blocks-world planning algorithm I know of [Gupta & Nau, 1992] It finds near-optimal plans in low-order polynomial time

In this section, I’ll describe the algorithm In the next section, I’ll explain how to implement it using

Ordered Task Decomposition

move bfrom thetable to a

move cfrom b tothe table

c

a b c a b

b

ac

44

Nau: PLANET, 2000

Initial state:clear(a),on(a,b),ontable(b),clear(c),ontable(c),handempty

a

b c

Goal:on(a,b),on(b,c) c

a

b

The Algorithm 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

45

Nau: PLANET, 2000

Running the Algorithm Running the algorithm on the Sussman anomaly

Initial state:clear(c),on(c,a),ontable(a),clear(b),ontable(b),handempty

c

a b

Goal:on(a,b),on(b,c) c

a

b

c

a b ca b ca

b

c

a

b

46

Nau: PLANET, 2000

Encoding the Algorithm 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• 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

Nau: PLANET, 2000


[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. <http://www.cs.umd.edu/~nau/papers/planning-iaai98.pdf>

[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. <http://www.cs.umd.edu/~nau/papers/blocks-aij92.ps>

48

Nau: PLANET, 2000

5. SHOP

Joint work with Yue Cao, Amnon Lotem, and Héctor Muñoz-Avila

Theory

Applications




2. Computerbridge


49

Nau: PLANET, 2000

SHOP (Simple Hierarchical Ordered Planner)

Domain-independent algorithm forOrdered Task Decomposition Sound/complete across a large number of planning domains

Implementation Common-Lisp implementation available at

http://www.cs.umd.edu/projects/shop Developing a Java implementation

50

Nau: PLANET, 2000

Input and Output Input:

State: a set of ground atoms Task List: a linear list of tasks Domain: methods, operators, axioms

Output: one or more plans depending on what we tell SHOP to look for, it can return

the first plan it finds all possible plans a least-cost plan all least-cost plans etc.

51

Nau: PLANET, 2000

Elements of the Input State: collection of ground atoms (in Lisp notation)

((at home) (have-cash 50.43) (distance home downtown 10))

Task list: linear list of tasks to perform ((travel home downtown) (buy book))

Each method: task, preconditions and decomposition Preconditions to be established using logical inference Decomposition is a task list

Each axiom: Horn clause Extensions: may contain negations and calls to the Lisp

evaluator

Each primitive operator: task, delete list, add list Like a STRIPS operator, but without the preconditions Performs a primitive task

52

Nau: PLANET, 2000

Initial task list: ((travel home park)) Initial state: ((at home) (cash 20) (distance home park 8)) Methods (task, preconditions, subtasks):

(:method (travel ?x ?y)((at x) (walking-distance ?x ?y)) ' ((!walk ?x ?y)) 1)

(:method (travel ?x ?y)((at ?x) (have-taxi-fare ?x ?y))' ((!call-taxi ?x) (!ride ?x ?y) (!pay-driver ?x ?y)) 1)

Axioms: (:- (walking-dist ?x ?y) ((distance ?x ?y ?d) (eval (<= ?d 5)))) (:- (have-taxi-fare ?x ?y)

((have-cash ?c) (distance ?x ?y ?d) (eval (>= ?c (+ 1.50 ?d))))

Primitive operators (task, delete list, add list) (:operator (!walk ?x ?y) ((at ?x)) ((at ?y))) …

Simple Example

Optional cost;default is 1

53

Nau: PLANET, 2000

The SHOP Algorithm

procedure SHOP (state S, task-list T, domain D) 1. if T = nil then return nil2. t1 = the first task in T3. U = the remaining tasks in T4. if t is primitive & an operator instance o matches t1 then5. P = SHOP (o(S), U, D)6. if P = FAIL then return FAIL7. return cons(o,P)8. else if t is non-primitive & a method instance m matches t1 in S & m’s preconditions can be inferred from S then9. return SHOP (S, append (m(t1), U), D)10. else11. return FAIL12. end ifend SHOP

state S; task list T=( t1 ,t2,…)

operator instance o

state o(S) ; task list T=(t2, …)

task list T=( t1 ,t2,…)

method instance m

task list T=( u1,…,uk ,t2,…)

nondeterministic choice among all methods m whose preconditions can be inferred from S

54

Nau: PLANET, 2000

Precond: 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

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

Nau: PLANET, 2000

Question I can run SHOP for you right now, on a slightly more

complicated version of the example. Would you like me to do so?

56

Nau: PLANET, 2000

Homework Assignment Formulate a plan for going to the beach Execute the plan

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

Documents

applications u

u dont

difficult u

plane u

ai planning techniques

htn decomposition u

complex tasks u

clumsy u easy