Ordered Task
Decomposition:
Theory and Practice
Dana S. Nau
Dept. of Computer Science, and
Institute for Systems Research
University of Maryland, College Park, MD
Nau: PLANET, 2000
1
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 to
generate plans automatically
 Much more difficult
Pro
cess
es:
OpnA B
C/WWSet
up R
unti
me LN Desc
ript
ion
001A VMC1 2.
00 0.
00 01 Orie
nt b
oard
02 Clam
p bo
ard
03 Inst
Esta
bll
lis
h da
tdia
umm
poin
t dr
at
bul
lsey
e (0
.25,1.0
0)
001B VMC1 0.
10 0.
43 01
a
0.30
ete
r
ill
bit
02 Roug
h dr
illat (
1.25
, -0
.50)todept
h 1.
00
03 Fini
sh d
rillat(1.2
5, 0.50
) todep
th 1
.00
001C VMC1 0.
10 0.
77 01 Inst
all0.20
-dia
mete
r dr
illbit
02 Roug
h dr
illat (
0.00
, 4.
88)to d
epth1.0
0
03 ]
Fini
sh d
rillat(0.0
0, 4
.88)todept
h 1.
00
[...
001T VMC1 2.
20 1.
20 01 Tota
l ti
me o
n VM
C1
[..
.]
004A VMC1 2.
00 0.
00 01 Orie
nt b
oard
02 Esta
Clam
plis
bo
ard
03
b
h
da
tumpoin
t atbul
lsey
e (0
.25,1.0
0)
004B VMC1 0.
10 0.
34 01 Inst
all0.15
-dia
mete
r si
de-m
illi
ng t
ool
02 Roug
h si
de-m
illpock
et a
t (0.25
, 1.
25)
leng
th 0
.40,wid
th 0
.30,dep
th 0
.50
03 Fini
sh s
idemillpoc
ketat (
-0.2
5, 1
.25)
leng
thsi
.e-m
0
40,
wid
th e
.t
0
30,
t.25
h,
.50
0
04 Roug
h
d
ill
pock
tdep
a
(0
3.
00)
leng
th 0
.40,wid
th 0
.30,dep
th 0
.50
05 Fini
sh s
idemillpoc
ketat (
-0.2
5, 3
.00)
leng
th 0
.40,wid
th 0
.30,dep
th 0
.50
004C VMC1 0.
10 1.
54 01 Inst
all0.08
-dia
mete
r en
d-mi
llin
g to
ol
[...
]
004T VMC1 2.
50 4.
87 01 Tota
l ti
me o
n VM
C1
005A EC1 0.
00 32.
29 01 Preclea
n bo
ard(scr
ub a
nd w
ash)
02 Dryboar
d inove
n at85deg.F
005B EC130.
00 0.
48 01 Setu
p
02 Spre
ad p
hoto
resi
st f
rom1800
0 RP
M sp
inne
r
005C EC130.
00 2.
00 01 Setu
p
02 usin
Phot
olit
htot
ogr
aol
phy
of"
phot
oige
res
i"
st
g
ph
o
o
in
r
eal
.
s
005D EC130.
00 20.
00 01 Setu
p
02 Etch
ingof c
oppe
r
005T EC190.
00 54.
77 01 Tota
l ti
me o
n EC
1
006A MC130.
00
006B MC130.
00
4.
57 01
p
02 Setu
Prep
areboar
d fo
r so
lder
ing
0.
29 01 Setu
p
02 Scre
enpr
intsold
er s
topon b
oard
7.
50 01 Setu
p
02
Depo
er p
asteat(3.3
5,1.
23)on b
oardusi
ng n
ozzl
e
[...
] sitsold
31 Depo
sitsold
er p
asteat(3.5
2,4.
00)on b
oardusi
ng n
ozzl
e
006D MC1 0.
00 5.
71 01 Dryboar
d inove
n at85deg.F t
o so
lidi
fy s
olde
r pa
ste
006T MC190.
00 18.
07 01 Tota
l ti
me o
n MC
1
[..
.]
011B
A TC1
TC1 0.
0.
00
0 29.
35.
07
0 01
01 Perf
Perf
orm
rmfina
post
-cap
tes
tion
ingof
onboar
boar
d
011
0
6
o
l
in
spec
t
d
006C MC130.
00
 Very few successful programs for realistic problems
011T TC1 0.
00 64.
67 01 Tota
l ti
me o
n TC
1
999T
319.
70 403.
37 01 Tota
l ti
me t
o ma
nufa
ctur
e
 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, …
Nau: PLANET, 2000
2
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)
 Theory:
 Practice:
 Symbolic computations
 Complex numeric computations
(STRIPS operators)
(geometry, images, probabilities)
 Single agent (the planner)
 Multiple agents
 Perfect information
 Imperfect information, external
information sources
Nau: PLANET, 2000
3
Goal
 Develop synergy
between theory
and applications
Theory
Applications
 By understanding what works
in practical planning situations,
we can develop better theories of planning
 Better theories of planning
can lead to better real-world planners
Nau: PLANET, 2000
4
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
 Mainly I’ll use PowerPoint slides
 At two points, I can run demos in Lisp
 Please ask questions!
Nau: PLANET, 2000
5
1. Principles of HTN 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
 Joint work with Kutluhan Erol and Jim Hendler
Nau: PLANET, 2000
6
What HTN Planning Is
task
method
travel(x,y)
travel by air
travel by taxi
get taxi ride taxi (x,y) pay driver
airport(x,a) airport(y,b) ticket (a,b) travel (x,a) fly(a,b) travel(b,y)
 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
Nau: PLANET, 2000
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
7
Comparison with “Classical” AI Planning
 “Classical” AI planning is action-based
 Declarative descriptions of actions
 Specify declaratively what the
buy-ticket(x,y)
operators are capable of doing
pre: airport(x), have-money()
 Don’t prescribe how to
del: have-money()
add: have-ticket(x,y)
perform complex tasks
 The planner must infer that,
fly(x,y)
using trial-and-error search
pre: at(x), have-ticket(x,y)
 HTN decomposition
 Can represent STRIPS-style
declarative operators, but it’s clumsy
 Easy to specify “recipes”
for how to perform tasks
del: at(x), have-ticket(x,y)
add: at(y)
travel by air
airport(x,a) airport(y,b) ticket (a,b) travel (x,a) fly(a,b) travel(b,y)
Nau: PLANET, 2000
8
History of HTN Planning
 Originally developed about 25 years ago
 [Sacerdoti 1977; Tate 1977]
 Long thought to have better potential for applicability to realworld 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
Nau: PLANET, 2000
9
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
Nau: PLANET, 2000
1
1. Complexity-Based Expressivity
transformation
“yes”
instances
“yes”
instances
“no”
instances
“no”
instances
Language L
Language M
 Transformation must preserve answer (“yes” or “no”)
 Transformation must be computable/polynomial
 Affected by the conciseness of the language
Nau: PLANET, 2000
1
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!)
Nau: PLANET, 2000
1
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
m1
 You don’t need to use function symbols
 You don’t even need to use any variable symbols!
m2
 However, you need to make use of


cycles in methods
interleaving among subtasks
m1
t1
t11
Nau: PLANET, 2000
t21
t12
t2
t22
t13
t23
1
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
Nau: PLANET, 2000
1
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
Nau: PLANET, 2000
1
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:6993, 1996. <http://www.cs.umd.edu/users/kutluhan/Papers/AMAI.ps>
Nau: PLANET, 2000
1
2. Computer Bridge
Theory
1. Principles of
HTN planning
2. Computer
bridge
4. Ordered Task
Decomposition
3. Electronic Design
and Manufacturing
5. SHOP
6. Evacuation
planning
Applications
 Joint work with Stephen J. Smith and Tom Throop
Nau: PLANET, 2000
1
Computer Programs for
Games of Strategy
 Fundamental technique: minimax game-tree search
 Largely “brute force”
 Can prune off portions of the tree
 cutoff depth,
9
-2
 alpha-beta pruning,
 hash tables, …
10
9
-2
3
 Even then, it still examines
thousands of game positions
10 -3 5 9 -2 -7 2 3
 This is very different from how humans think
 Even the best human chess players
examine at most a few dozen
game positions to make their moves
Nau: PLANET, 2000
1
Performance of Game-Playing Computer
Programs
Connect Four:
Go-Moku:
Qubic:
Nine Men’s Morris:
Othello:
Checkers:
Backgammon:
Chess:
solved
solved
solved
solved
better than humans
better than any living human
better than all but about 10 humans
certainly better than all but about 250 humans;
possibly even better than that
•
•
•
Bridge:
Nau: PLANET, 2000
probably worse than the best player
at your local bridge club
1
How Bridge Works
 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
West
of the suit led, unless
someone plays a trump
 Keep playing tricks until all
cards have been played
 Scoring based on how many tricks
were bid and how many were taken
Nau: PLANET, 2000
North
Q 9 A A
J 7 K 9
6
5
5
3
6
East
2
Q
8
South
2
Why Bridge is Difficult
for Computers
 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 increases
the number of nodes exponentially
 worst case: about 6x1044 leaf nodes
 average case: about 1024 leaf nodes
Not enough time to search the game tree
Nau: PLANET, 2000
2
How to Reduce the Size
of 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
Brute-force search
Our approach
Worst case ≈ 6x1044 leaf nodes ≈ 305,000 leaf nodes
Average case
≈ 1024 leaf nodes
≈ 26,000 leaf nodes
Nau: PLANET, 2000
2
Task Network for Finessing
primitive
action by
us
task
Finesse(P; S)
method
LeadLow(P; S)
PlayCard(P; S, R1)
Us:
East declarer, West dummy
Opponents: defenders, South & North
Contract: East – 3NT
On lead: West at trick 3 East: KJ74
West: A2
Out: QT98653
FinesseTwo(P2; S)
EasyFinesse(P2; S)
West— 2
StandardFinesse(P2; S)
…
…
(North— Q)
StandardFinesseTwo(P2; S)
PlayCard(P2; S, R2)
(North— 3)
StandardFinesseThree(P3; S)
PlayCard(P3; S, R3)
North— 3
East— J
primitive action by opponent
Nau: PLANET, 2000
BustedFinesse(P2; S)
FinesseFour(P4; S)
PlayCard(P4; S, R4)
PlayCard(P4; S, R4’)
South— 5
South— Q
2
Game Tree Generated from
the Task Network
...later strategies...
FINESSE
N—3
0.9854
W—2
+270.73
N—Q
0.0078
N—3
0.0078
+600
S—Q
0.5
–100
+265 S—5
0.5
+630
S—3
+630
E— J
+265
E— K
+630
+630
E— K
+600
S—3
+600
+600
CASH OUT
N— 3
W—A
+600
Nau: PLANET, 2000
E— 4
+600
S—5
+600
+600
2
Implementation
 We incorporated our code for declarer play
into 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
Nau: PLANET, 2000
2
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>
Nau: PLANET, 2000
2
3. Electronic Design and Manufacturing
Theory
1. Principles of
HTN planning
2. Computer
bridge
4. Ordered Task
Decomposition
3. Electronic Design
and Manufacturing
5. SHOP
6. Evacuation
planning
Applications
 Joint work with Stephen J. Smith, Kiran Hebbar, and
Ioannis Minis
Nau: PLANET, 2000
2
Integrated Product and Process Design
(IPPD)
Preliminary design
Engineering and
functionality
analysis
Product
modeling
verify
parameters
Manufacturability
analysis
Modify design
Acceptable design
 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
Nau: PLANET, 2000
2
Microwave Transmit/Receive Modules
 1-20 GHz frequency range (radars, satellite communications, etc.)
 Difficult and expensive to design and manufacture
Nau: PLANET, 2000
2
EDAPS: Electro-mechanical Design And
Planning System
Design,
Constraints
Designer
Information about manufacturability
User Interface (Tcl/Tk)
Circuit Schematic,
Component Selection
Substrate Design
& 3-D Layout
Process Planning
& Plan Evaluation
EEsof
Microstation
AEL Routines
MDL Routines
HTN Planner
(C++)
Routines in C++
Product and Process Data Files
Nau: PLANET, 2000
- Commercial
- Developed by us
3
EDAPS’s Process Planner
Make the artwork
A portion of
the task network:
(one possible method)
Preclean for artwork
Spindling
Apply photoresist
Spraying
Spreading
Photolithography
Painting
Etching
(alternative
methods)
 Can express planning using “recipes” that fit well into
HTN methods
 Generate and evaluate multiple process plans
 Estimate times and costs
 Display results graphically
Nau: PLANET, 2000
3
Examples
from
EDAPS
Substrate
Dimensions: 7,4,1
Ground Material: Aluminum
Material: Teflon
Substrate thickness: 30 mils
Metallized thickness: 7 mils
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
001 T VMC1
…
2.20
1.20
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
01 Total time on VMC1
006 A PLAT1 1.00
0.60
007 A ETR1
0.60
0.50
008 A ETC1 0.20
Nau:
… PLANET, 2000
0.30
02 Dip in bath for 2 minutes
Temperature:100C, Conc:1000ppm
01 Etch plate for 1 minute
01 Etch board for 2 minutes
Temperature:100C, Conc:1000ppm
3
Status
 EDAPS completed under NSF funding
 Follow-up project with Northrop Grumman
 Combine AI planning with Integer Programming optimization
Electronic CAD
Initial component
selection
Database lookup
Alternative
components
HTN planning
Alternative
plans
A11
P111
Pareto-optimal
Multi-objective
Integer Programming combinations
Interactive display
Nau: PLANET, 2000
C1 … Ci
User exploration
and selection
…
…
Aij
Pijk
… Cp
…
…
Apq
Ppqr
A1xx … Apxx … A1xx … Apxx
3
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.
<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>
Nau: PLANET, 2000
3
4. Ordered Task Decomposition
Theory
1. Principles of
HTN planning
2. Computer
bridge
4. Ordered Task
Decomposition
3. Electronic Design
and Manufacturing
5. SHOP
6. Evacuation
planning
Applications
 Joint work with Kutluhan Erol, Naresh Gupta, and
Stephen J. Smith
Nau: PLANET, 2000
3
Discussion
 For both Bridge Baron and EDAPS
 We used the same approach
 Even some of the same code!
subtask 1
task
method
subtask 2
subtask 3
subtask 4
 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 planning
1. Search strategy
2. Data representation
Nau: PLANET, 2000
3
Search Strategy
Make the artwork for a PC board
Preclean for artwork
Spindling
Apply photoresist
Spraying
Spreading
Photolithography
Etching
Painting
 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
Nau: PLANET, 2000
3
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)
Pick up C
C
A
B
Put C on
the table
Pick up A
Pick up B
Put B
on C
Put A
on B
A
B
C
 In contrast, ordered task decomposition is both forward
and goal-directed at the same time
Nau: PLANET, 2000
3
Example
 STRIPS operator to stack a block
stack(x,y)
Pre: holding(x), clear(y)
Del: holding(x), clear(y)
Add: on(x,y), clear(x), handempty
c
a
b
c
a
b
 Translate it into an HTN method
 If we expand the subtasks in left-to-right
order, then we are searching
Achieve on(x,y)
forward from the initial state
 Always know the current state
stack(x,y)
 However, it’s also a
goal-directed search
Achieve clear(y) Achieve holding(x) Put x on y
 The task is the goal
 Invoke only those methods that match the task
Nau: PLANET, 2000
3
State Representation
for Partial-Order Planning
Pick up C
C
A
B
Put C on
the table
Pick up A
Pick up B
Put B
on C
Put A
on B
A
B
C
 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
Nau: PLANET, 2000
4
State Representation for
Ordered 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
…
task tm
s0
op1
s1
op2
s2
…
task tn
Si–1
opi
…
 Thus, we know the current state of the world
Nau: PLANET, 2000
4
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
Nau: PLANET, 2000
4
Example: Blocks-World Planning
 The blocks world
c
a
b
move c
from b to
the table
c
a
b
move b
from the
table to a
c
b
a
 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
Nau: PLANET, 2000
Task Decomposition
4
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
Initial state:
clear(a),
 else exit
a
on(a,b),
Goal:
 endif
ontable(b),
on(a,b), b
a
clear(c),
on(b,c)
 repeat
b
c
c
ontable(c),
handempty
Nau: PLANET, 2000
4
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
Nau: PLANET, 2000
a
c
a
b
b
c
a
Goal:
on(a,b), b
on(b,c)
c
a
b
c
a
b
c
4
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 • Can’t write these preconditions using STRIPS-style operators






 repeat
Nau: PLANET, 2000
• 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
4
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. <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>
Nau: PLANET, 2000
4
5. SHOP
Theory
1. Principles of
HTN planning
2. Computer
bridge
4. Ordered Task
Decomposition
3. Electronic Design
and Manufacturing
5. SHOP
6. Evacuation
planning
Applications
 Joint work with Yue Cao, Amnon Lotem, and Héctor
Muñoz-Avila
Nau: PLANET, 2000
4
SHOP (Simple Hierarchical Ordered
Planner)
 Domain-independent algorithm for
Ordered 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
Nau: PLANET, 2000
4
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.
Nau: PLANET, 2000
5
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
Nau: PLANET, 2000
5
Simple Example
 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)
Optional cost;
 (:method (travel ?x ?y)
default is 1
((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)))
…
Nau: PLANET, 2000
5
The SHOP Algorithm
state S; task list T=( t ,t ,…)
1 2
procedure SHOP (state S, task-list T, domain D)
operator instance o
1.
if T = nil then return nil
2.
t1 = the first task in T
state o(S) ; task list T=(t2, …)
3.
U = the remaining tasks in T
4.
if t is primitive & an operator instance o matches t1 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
8.
else if t is non-primitive
can be inferred from S
& a method instance m matches t1 in S
& m’s preconditions can be inferred from S then
9.
return SHOP (S, append (m(t1), U), D)
10. else
task list T=( t1 ,t2,…)
11.
return FAIL
method instance m
12.
end if
end SHOP
task list T=( u1,…,uk ,t2,…)
Nau: PLANET, 2000
5
Simple Example
(Continued)
Initial state:
(at home)
(cash 20)
(distance home park 8)
(travel home park)
Precond:
(at home)
Succeed
Precond:
(walking-distance
Home park)
Fail (distance > 5)
(!call-taxi home)
(!walk home park)
Nau: PLANET, 2000
(at home)
(have-taxi-fare home park)
Succeed
Succeed (we have $20,
and the fare is only $9.50)
(!ride home park)
(!pay-driver home park)
Final state: (at park)
(cash 10.50)
(distance home park 8)
5
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?
Nau: PLANET, 2000
5
Homework Assignment
 Formulate a plan for going to the beach
 Execute the plan
Nau: PLANET, 2000
5