1"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

This"work"is"licensed"under"a"CreaCve"Commons"AFribuConHNonCommercialHShareAlike"4.0"InternaConal"License."

Chapter(3((Delibera.on(with(Refinement(Methods(

(Planning((Sec.on(3.4)(

Dana S. Nau and Vikas Shivashankar

University of Maryland

2"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

ungrasp

graspknob

turnknob

maintainmove back

pull

monitor

identifytype of

doorpull

monitor

move close

to knob

open door

……

get out close door

respond to user requests

… …bring o7 to room2

go to hallway

deliver o7

…… … …

…

move to door

fetch o7

navigate to room2

navigate to room1

Mo.va.on(●  Actor is hierarchically organized ●  Suppose a node of the tree contains

an action a ●  At the next level down, a is a task

that needs to be performed !  Recursively refine

tasks into subtasks ●  Dashed blue lines:

!  CSV planner can do the refinement

●  Solid red lines: !  need other techniques

●  A refinement method is

an operational model !  A program to compute

a refinement !  Actor can use it online

3"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Nota.on(and(Terminology(●  Recall from Chapter 2 that the actor’s state ξ may differ from the state s that the

actor gives to the planner !  ξ is the actor’s current state

•  the execution platform keeps it up-to-date !  Ξ = {all possible states}

●  Fact: an atom that’s true in the current state ●  Task: an activity that the actor needs to carry out

●  State variables are like CSV state variables, but more flexible: !  If x is a state variable, Range(x) can be anything you want

•  integers, real numbers, vectors, matrices, other data structures ●  Assignments are like the ones in CSV operators

!  x ← v ●  Simple test: x = v, x ≠ v, x > v, x < v ●  Compound test: conjunction, disjunction, or negation of simple tests

4"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

State(Variables(●  Like CSV state variables, but more general

!  Range(x) can be anything you want •  integers, real numbers, vectors, matrices, other data structures

●  Used in assignments and tests !  Assignments are a generalization of the ones in CSV operators

•  x ← expression !  Simple tests: x = v, x ≠ v, x > v, x < v !  Compound tests:

•  conjunctions, disjunctions, negations of simple (and compound?) tests

5"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(●  Objects

!  Robots = {rbt}, Containers = {c1, c2, …}, Locations = {loc1, loc2, …}. ●  State variables

!  loc(r) ∈ Locations !  load(r) ∈ Containers ⋃ {nil} !  pos(c) ∈ Locations ⋃ Robots ⋃ {unknown} !  view(l) ∈ {T, F}

•  whether the robot has looked at location l or not •  If view(l)=T then for every container c in l, pos(c) = l

●  Commands to the execution platform: !  goto(r,l): robot r goes to location l !  take(r,o): r takes object o !  put(r,o): r puts o !  perceive(r,l): robot r perceives what objects are at a location l

6"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Refinement(Methods(●  Refinement method: a triple (task or event, precondition, body)

!  a task or event that the method can be used for !  precondition that needs to be true for the method to be applicable !  body: a program

●  Write in the following format: •  method-name(arg1, …, argk)

task: task or event: event pre: precondition body: body

●  body: sequence of steps !  assignments, commands, tasks !  control constructs: if-then-else, while, loop, etc.

7"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

Con.nue(Previous(Example(●  Task: fetch container c ●  Method: if you know c’s location, then go get it; else search

mHfetch(r,c) task: fetch(r,c) pre: body: if pos(c) = unknown then search(r,c) else if loc(r) = pos(c) then take(r,c) else do goto(pos(c)) take(r,c)

mHsearch(r,c) task: search(r,c) pre: pos(c) = unknown body: if ∃l (view(l)=F) then

goto(l) perceive(l) if pos(c)=l then take(r,c) else search(r,c) else fail

8"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Con.nue(Previous(Example(

●  Event: emergency call !  Stop current activity, go where the emergency is

●  Another state variable !  emergencyHhandling(r) ∈ {T, F}

•  whether r is handling an emergency

●  Method: mHemergency(r,l,i)

task: emergency(l,i) pre: emergencyHhandling=F body: emergencyHhandling ← T

if loaded(r) ≠ nil"then " "put(r,load(r)) goto(l) addressHemergency(l,i)

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

9"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Con.nue(Previous(Example(

●  Commands used for opening a door !  moveHclose(r,o): r moves to a position

where reachable(r,o)=T"!  moveHby(r,λ): r moves with magnitude and

direction given by vector λ !  grasp(r,o): r grasps object o !  ungrasp(r,o): r release grasp on o !  turn(r,o,α): r turns a grasped object

o by angle α ∈ [−π,+π] !  pull(r,λ): r pulls its arm by vector λ !  push(r,λ): r pushes its arm by λ !  monitorHstatus(r,d):

r focuses its perception to keep doorHstatus"updated (starts a process)

!  endHmonitorHstatus(r,d): r stops monitoring d (terminates a process)

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

10"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Con.nue(Previous(Example(

●  Task: open the door mHopendoor(r,d,l,o)""

task: opendoor(r,d)"" pre: loc(r)"="l"∧"adjacent(l,d)"∧"handle(d,o)"""body: while ¬reachable(r,o)"do " " "moveHclose(r,o)""" "monitorHstatus(r,d)""" "if doorHstatus(d)=closed"then unlatch(r,d) "" "throwHwide(r,d) " "endHmonitorHstatus(r,d)

"

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

11"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Con.nue(Previous(Example(m1Hunlatch(r,d,l,o)

task: unlatch(r,d) pre: loc(r,l) ∧ towardHside(l,d) ∧ side(d,leX) ∧ type(d,rotate) ∧ handle(d,o) body: grasp(r,o) turn(r,o,alpha1) pull(r,val1) if doorHstatus(d)=cracked"then ungrasp(r,o) else fail

"

"

m1-throw-wide(r,d,l,o) task: throwHwide(r,d) pre: loc(r,l) ∧ towardHside(l,d) ∧ side(d,leX) ∧ type(d,rotate) ∧ handle(d,o) ∧ doorHstatus(d)=cracked" body: grasp(r,o) pull(r,val1) moveHby(r,val2)"

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

12"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Acting

tasks

Execution Platform

Environment

eventscommands

!M Refinement(Ac.ng(Engine(

(RAE)(

●  Perform external tasks and events in parallel !  For each, an

execution stack ●  Agenda =

{current stacks}

●  Based on OpenPRS !  Programming language, open source software !  Used widely used in robotics

●  Input: facts, external tasks, events ●  Output: commands to execution platform

13"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

●  An execution stack corresponds to the current path in a search tree

●  Each element: !  Task or event τ !  Current method m for τ !  Execution pointer i for body(m)

•  τ[i] = current instruction !  Methods that were

previously tried for m

Acting

tasks

Execution Platform

Environment

eventscommands

!M Execu.on(Stacks(in(RAE(

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

14"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Progressing(a(Stack(

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

15"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

If(a(Method(Fails(●  Similar to backtracking

!  If one method fails, then try another !  If no more applicable methods, then fail

●  But not identical to backtracking !  ξ may have changed during the previous refinement

•  Because of something the actor did •  Because the world may change dynamically

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

16"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Goals(in(RAE(●  Special kind of task: achieve(condition) ●  Like other tasks, except that it includes monitoring

•  Can easily modify the Progress procedure to do this !  If condition becomes true during execution, stop execution early !  If condition isn’t true after execution, then fail (triggers a Retry)

!  mHfetch(r,c) task: fetch(r,c) pre: body: achieve(pos(c) ≠ unknown) goto(pos(c)) take(r,c)

!  mHfindHwhere(r,c) goal: achieve(pos(c) ≠ unknown) pre: body: while there is a location l such that view(l)=F"do goto(l) perceive(l)

17"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Extensions(to(RAE(●  Section 3.3.4 discusses some additional features that extend RAE’s capabilities:

!  Controlling the progress of tasks, e.g., suspend a task for a while !  Refining into concurrent subtasks

•  mHfoo(x,y,z) task: foo(x,y,z) pre: body: .".". {concurrent: ⟨ν1,1,...,ν1,n⟩⟨ν2,1,...,ν2,m⟩...⟨νk,1,...,νk,l⟩}

•  Each ⟨νi,1,...,νi,j⟩ is a sequence of steps, like the body of a method •  Split the current stack into k sub-stacks, one for each ⟨νi,1,...,νi,j⟩

!  Choosing methods, and stack ordering •  If there are multiple stacks, which ones get higher priority?

▸  Application-specific heuristics •  For a task t, which method to try first?

▸  Refinement planning (Section 3.4)

18"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Refinement(Planning(●  When dealing with an event or task, RAE

requires choosing a refinement method to decompose it

●  An important question we need to address: Which method to try first?

●  Important because RAE immediately executes commands that are generated during decomposition !  Costly/irreversible; cannot reverse

effects if bad method is chosen

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

19"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Refinement(Planning(

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

Blue door has obstacle in front of it. With RAE, agent will realize this impacts the plan only when it attempts to open the door

20"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Refinement(Planning(●  When dealing with an event or task, RAE

requires choosing a refinement method to decompose it

●  An important question we need to address: Which method to try first?

●  Important because RAE immediately executes commands that are generated during decomposition !  Costly/irreversible; cannot reverse

effects if bad method is chosen ●  Solution: predict effects of available

methods to determine best course of action !  Instead of executing commands

immediately, simulate effects of commands using descriptive action models (like in Chap. 2)

startmonitor

open door

m-fetch

take o7

move close to handle

goto door

m-opendoor

get out close door

unlatch throw wide end monitor

…

go to loc1

fetch o7

… … methods for differentkinds of doors

•••

21"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Sequen.al(Refinement(Planning(Engine((SeRPE)(●  An algorithm that does refinement planning to determine best sequence of method

applications (and hence, the best course of action) ●  Refines tasks similar to RAE, except:

!  where RAE executes a command that changes the world state, SeRPE instead uses a descriptive action model to predict the next world state

●  Assumptions SeRPE makes:

!  All action models have deterministic outcomes (like in Chapter 2) •  E.g. unlatch"command in reality has several possible outcomes –

successful execution ensures door is unlatched, failure implies door still latched, etc

•  Our action model for unlatch will only have a single outcome !  No methods have concurrent"operators – so tasks cannot execute in parallel

•  We’ll relax this assumption in the Interleaved"Refinement"Planning"Engine algorithm (IRPE) later on

22"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem(Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

●  Same problem from Chapter 2 !  Now let’s solve this using SeRPE

●  We have seen action models for this domain: load,"unload,"move"

●  Next, we need to define tasks and refinement methods for this domain

23"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

uncover(c) – task of ensuring no containers are on c ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

24"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

uncover(c) – task of ensuring no containers are on c ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

If c is not at the top of its pile (and c’ is on top of c), make c’ the top of the pile and then

remove c’

If c has nothing on it, do nothing

25"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

uncover(c) – task of ensuring no containers are on c ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

90 Chapter 3

in these methods have the following ranges: c 2 Containers; r 2 Robots;d, d0 2 Docks; p, p0 2 Piles. There are three kinds of tasks:

• uncover(c) is the task of ensuring that there are no containers on con-tainer c. For this task, there are two methods. The first one, which isapplicable only if nothing needs to be done, just returns success:

method no-remove(c, p)task: uncover(c)pre: pile(c) = nil _ top(p) = c

body: return success

The second method is applicable if there are containers on c and thereis another pile p0 at the same dock. If a robot is present at the dock, ituses the robot to move those containers to the other pile, and otherwiseit returns failure:

method remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p ^ c 6= top(p) ^

loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

method no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the same dock that p is on. It uses the robot to carry cto p0:

Draft, not for distribution. February 19, 2015.

If c is not at the top of its pile (and c’ is on top of c), make c’ the top of the pile and then

remove c’

If c has nothing on it, do nothing

26"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

uncover(c) – task of ensuring no containers are on c ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

If c has nothing on it, do nothing

90 Chapter 3

in these methods have the following ranges: c 2 Containers; r 2 Robots;d, d0 2 Docks; p, p0 2 Piles. There are three kinds of tasks:

• uncover(c) is the task of ensuring that there are no containers on con-tainer c. For this task, there are two methods. The first one, which isapplicable only if nothing needs to be done, just returns success:

method no-remove(c, p)task: uncover(c)pre: pile(c) = nil _ top(p) = c

body: return success

The second method is applicable if there are containers on c and thereis another pile p0 at the same dock. If a robot is present at the dock, ituses the robot to move those containers to the other pile, and otherwiseit returns failure:

method remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p ^ c 6= top(p) ^

loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

method no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the same dock that p is on. It uses the robot to carry cto p0:

Draft, not for distribution. February 19, 2015.

If c is not at the top of its pile (and c’ is on top of c), make c’ the top of the pile and then

remove c’

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

27"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

putHinHpile(c,p’) – task of putting c in pile p’ ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

28"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

putHinHpile(c,p’) – task of putting c in pile p’ ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

If c is already in pile p’, do nothing

If c is in pile p≠p’, uncover c, pickup c and put it onto pile p’

29"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

putHinHpile(c,p’) – task of putting c in pile p’ ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

If c is already in pile p’, do nothing

If c is in pile p≠p’, uncover c, pickup c and put it onto pile p’

90 Chapter 3

in these methods have the following ranges: c 2 Containers; r 2 Robots;d, d0 2 Docks; p, p0 2 Piles. There are three kinds of tasks:

• uncover(c) is the task of ensuring that there are no containers on con-tainer c. For this task, there are two methods. The first one, which isapplicable only if nothing needs to be done, just returns success:

method no-remove(c, p)task: uncover(c)pre: pile(c) = nil _ top(p) = c

body: return success

The second method is applicable if there are containers on c and thereis another pile p0 at the same dock. If a robot is present at the dock, ituses the robot to move those containers to the other pile, and otherwiseit returns failure:

method remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p ^ c 6= top(p) ^

loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

method no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the same dock that p is on. It uses the robot to carry cto p0:

Draft, not for distribution. February 19, 2015.

30"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

putHinHpile(c,p’) – task of putting c in pile p’ ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

If c is already in pile p’, do nothing

If c is in pile p≠p’, uncover c, pickup c and put it onto pile p’

90 Chapter 3

in these methods have the following ranges: c 2 Containers; r 2 Robots;d, d0 2 Docks; p, p0 2 Piles. There are three kinds of tasks:

• uncover(c) is the task of ensuring that there are no containers on con-tainer c. For this task, there are two methods. The first one, which isapplicable only if nothing needs to be done, just returns success:

method no-remove(c, p)task: uncover(c)pre: pile(c) = nil _ top(p) = c

body: return success

The second method is applicable if there are containers on c and thereis another pile p0 at the same dock. If a robot is present at the dock, ituses the robot to move those containers to the other pile, and otherwiseit returns failure:

method remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p ^ c 6= top(p) ^

loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

method no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the same dock that p is on. It uses the robot to carry cto p0:

Draft, not for distribution. February 19, 2015.

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

31"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

goto"(r,d’) – task of moving robot r to dock d’ ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

32"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

goto"(r,d’) – task of moving robot r to dock d’ ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

If r is already at d’, do nothing

If r is not at d’, then go (be) somewhere adjacent to d’ and then move to d’

33"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

goto"(r,d’) – task of moving robot r to dock d’ ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

If r is already at d’, do nothing

If r is not at d’, then go (be) somewhere adjacent to d’ and then move to d’

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

34"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Example(Problem:(Tasks(

goto"(r,d’) – task of moving robot r to dock d’ ●  Need two methods to decompose this

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

If r is already at d’, do nothing

If r is not at d’, then go (be) somewhere adjacent to d’ and then move to d’

92 Chapter 3

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

The second method is applicable if r isn’t at d0. It navigates to a dockd that is adjacent to d0, and then moves r to d0. The dock d may ormay not be r’s current location.

route(r, d, d0)task: navigate(r, d0)pre: loc(r) 6= d0, adjacent(d, d0)

body: navigate(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as inExample 2.9, and s

3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the refinement trees corresponding to two of SeRPE’s non-deterministic execution traces. The terminal nodes of these trees correspondto the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

3.4.2 Interleaved Plans

In Section 3.4.1, one of the restrictions was that none of the methods inM could contain the “concurrent” programming construct described in Sec-

Draft, not for distribution. March 1, 2015.

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

35"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

●  From SeRPE’s viewpoint, a planning problem consists of: !  s0 – the initial state

•  shown below !  A – action models

•  load,"unload,"move !  M – refinement methods

•  noHremove,"removeHabove,"noHcarry,"carryHtoHpile,"noHgo,"route"

!  τ –task/goal to be accomplished •  putHinHpile (c1,p2)

Initial state s0

Plan(Genera.on(Using(SeRPE(

Section 3.4 91

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

method carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0 ^ occupied(d) = r ^ pile(c) = p

body: uncover(c)load(r, c, pos(c), p, d)if loc(r) 6= d0 then

goto(r, d0)unload(r, c, top(p0), p0, d0)

• goto(r, d0) is the task of moving r along some undetermined route thatends at dock d0. Again there are two methods. The first one returnssuccess if r is already at d0:

method no-go(r, d0)task: goto(r, d0)pre: loc(r) = d0

body: return

The second method is applicable if r isn’t at d0. It routes r through adock d that is adjacent to d0, and then moves r to d0. The dock d mayor may not be r’s current location.

method route(r, d, d0)task: goto(r, d0)pre: adjacent(d, d0)

body: goto(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as in

Draft, not for distribution. February 19, 2015.

36"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Plan(Genera.on(Using(SeRPE(

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

37"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

38"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

39"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

40"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

SeRPE called recursively on chosen method

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

41"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

42"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

… SeRPE called recursively on task

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

43"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

44"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

… SeRPE called recursively on method

45"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

90 Chapter 3

in these methods have the following ranges: c 2 Containers; r 2 Robots;d, d0 2 Docks; p, p0 2 Piles. There are three kinds of tasks:

• uncover(c) is the task of ensuring that there are no containers on con-tainer c. For this task, there are two methods. The first one, which isapplicable only if nothing needs to be done, just returns success:

method no-remove(c, p)task: uncover(c)pre: pile(c) = nil _ top(p) = c

body: return success

The second method is applicable if there are containers on c and thereis another pile p0 at the same dock. If a robot is present at the dock, ituses the robot to move those containers to the other pile, and otherwiseit returns failure:

method remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p ^ c 6= top(p) ^

loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

method no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the same dock that p is on. It uses the robot to carry cto p0:

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

46"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

90 Chapter 3

in these methods have the following ranges: c 2 Containers; r 2 Robots;d, d0 2 Docks; p, p0 2 Piles. There are three kinds of tasks:

• uncover(c) is the task of ensuring that there are no containers on con-tainer c. For this task, there are two methods. The first one, which isapplicable only if nothing needs to be done, just returns success:

method no-remove(c, p)task: uncover(c)pre: pile(c) = nil _ top(p) = c

body: return success

The second method is applicable if there are containers on c and thereis another pile p0 at the same dock. If a robot is present at the dock, ituses the robot to move those containers to the other pile, and otherwiseit returns failure:

method remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p ^ c 6= top(p) ^

loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

method no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the same dock that p is on. It uses the robot to carry cto p0:

Draft, not for distribution. February 19, 2015.

47"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

48"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

… called recursively on the action

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

49"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

50"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

51"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

… called recursively on this task

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

52"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

53"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

54"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

called recursively on this method

55"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

r already at d1, solved with no-go method with no actions added

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

92 Chapter 3

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

The second method is applicable if r isn’t at d0. It navigates to a dockd that is adjacent to d0, and then moves r to d0. The dock d may ormay not be r’s current location.

route(r, d, d0)task: navigate(r, d0)pre: loc(r) 6= d0, adjacent(d, d0)

body: navigate(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as inExample 2.9, and s

3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the refinement trees corresponding to two of SeRPE’s non-deterministic execution traces. The terminal nodes of these trees correspondto the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

3.4.2 Interleaved Plans

In Section 3.4.1, one of the restrictions was that none of the methods inM could contain the “concurrent” programming construct described in Sec-

Draft, not for distribution. March 1, 2015.

56"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

92 Chapter 3

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

The second method is applicable if r isn’t at d0. It navigates to a dockd that is adjacent to d0, and then moves r to d0. The dock d may ormay not be r’s current location.

route(r, d, d0)task: navigate(r, d0)pre: loc(r) 6= d0, adjacent(d, d0)

body: navigate(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as inExample 2.9, and s

3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the refinement trees corresponding to two of SeRPE’s non-deterministic execution traces. The terminal nodes of these trees correspondto the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

3.4.2 Interleaved Plans

In Section 3.4.1, one of the restrictions was that none of the methods inM could contain the “concurrent” programming construct described in Sec-

Draft, not for distribution. March 1, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

57"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

92 Chapter 3

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

p1!!!!!c2!c1!

!!!!!!!!!d2!!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1!

Figure 3.8: Initial state for Example 3.8.

The second method is applicable if r isn’t at d0. It navigates to a dockd that is adjacent to d0, and then moves r to d0. The dock d may ormay not be r’s current location.

route(r, d, d0)task: navigate(r, d0)pre: loc(r) 6= d0, adjacent(d, d0)

body: navigate(r, d)move(r, d, d0)

Now consider the planning problem P = (M, A, s3

, put-in-pile(c1

, p2

)),where M contains the above six methods, A is the same set of actions as inExample 2.9, and s

3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the refinement trees corresponding to two of SeRPE’s non-deterministic execution traces. The terminal nodes of these trees correspondto the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

3.4.2 Interleaved Plans

In Section 3.4.1, one of the restrictions was that none of the methods inM could contain the “concurrent” programming construct described in Sec-

Draft, not for distribution. March 1, 2015.

58"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

… recursively invoked on action

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

59"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

…

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

60"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE(Pseudocode(92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

92 Chapter 3

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d1,d2)

actionmove(r1,d2)

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

taskgoto(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)methodroute(r1,d3,d2)

taskgoto(r1,d3)

methodroute(r1,d1,d3)

actionmove(r1,d3)

Figure 3.9: Decomposition trees for two solution plans.

Example 2.9, and s3

is the following state, which is shown in Figure 3.8:

s3

= {loaded(r1

) = nil, loc(p1

) = d1

, loc(p2

) = d2

,loc(p

3

) = d2

, loc(p4

) = d3

, loc(r1

) = d1

,occupied(d

1

) = r1

, occupied(d2

) = nil, occupied(d3

) = nil,pile(c

1

) = p1

, pile(c2

) = p1

, pile(c3

) = p2

,pos(c

1

) = c2

, pos(c2

) = nil, pos(c3

) = nil,top(p

1

) = c1

, top(p2

) = c3

, top(p3

) = nil,top(p

4

) = nil}.

(3.1)

Figure 3.9 shows the decomposition trees corresponding to two of SeRPE’snondeterministic execution traces. The terminal nodes of these trees corre-spond to the following solution plans:

⇡1

= hload(r1

, c1

, p1

),move(r1

, d1

, d2

), unload(r1

, c1

, p2

)i;⇡2

= hload(r1

, c1

, p1

),move(r1

, d1

, d3

),move(r1

, d3

, d2

), unload(r1

, c1

, p2

)i.

Draft, not for distribution. February 19, 2015.

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

Section 3.4 91

remove-above(r, c, p, p0, d)task: uncover(c)pre: loc(r) = d ^ loc(p) = d ^ pile(c) = p

^ c 6= top(p) ^ loc(p0) = d ^ p 6= p0

body: if loaded(r) 6= nil thenunload(r, loaded(r), top(p0), p0, d)

while top(p) 6= cload(r, top(p), pos(top(p)), p, d)unload(r, loaded(r), top(p0), p0, d)

• put-in-pile(c, p0) is the task of putting container c into pile p0 if it is notalready there. As before, there are two methods. The first one returnssuccess if c is already in p0:

no-carry(c, p0)task: put-in-pile(c, p0)pre: pile(c) = p0

body: return success

The second method is applicable when c is in a pile p 6= p0 and thereis a robot at the dock p is on. It uses the robot to carry c to p0:

carry-to-pile(r, c, p, d, c0, p0, d0)task: put-in-pile(c, p0)pre: at(p, d) ^ at(p0, d0) ^ p 6= p0

^ occupied(d) = r ^ pile(c) = pbody: uncover(c)

load(r, c, pos(c), p, d)if loc(r) 6= d0 then

navigate(r, d0)unload(r, c, top(p0), p0, d0)

• navigate(r, d0) is the task of moving r along some undetermined routethat ends at dock d0. Again there are two methods. The first onereturns success if r is already at d0:

no-go(r, d0)task: navigate(r, d0)pre: loc(r) = d0

body: return

Draft, not for distribution. March 1, 2015.

61"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

SeRPE:(Refinement(of(Goals(

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

…

88 Chapter 3

SeRPE(M, A, s, ⌧)case(type(⌧)): // ⌧ is an action, task, goal, or method

action:if s satisfies pre(⌧) then return (h⌧i, �(s, ⌧))else return (h⌧i, failure)

task:Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidatesreturn SeRPE(M, A, s,m)

else return failuregoal:

if s satisfies ⌧ then return (hi, s)Candidates Instances(M(⌧), s)if Candidates 6= ? then

nondeterministically choose m 2 Candidates(⇡, s0) SeRPE(M, A, s,m)if s0 satisfies ⌧ then return (⇡, s0)else return (⇡, failure)

else do one of the following (see the text)⇢return (hi, failure)return Find-plan(M, A, s, ⌧)

�

method:i 0 // i is the program counter for body(⌧)⇡ hi // ⇡ will be the plan produced by body(⌧)loop

i nextstep(⌧, i)if i = success then return (⇡, s)else if i = failure then return (⇡, failure)// if we get here, ⌧ [i] is an action, task, or method(⇡0, s) SeRPE(M, A, s, ⌧ [i])⇡ ⇡.⇡0

if s = failure then return (⇡, failure)

Figure 3.7: SeRPE, the Sequential Refinement Planning Engine.

Draft, not for distribution. February 19, 2015.

62"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Interleaved(Refinement(Tree((IRT)(Procedure(●  Remember: SeRPE does not allow using the ‘concurrent’ programming construct

●  Assume same initial state as before ●  Assume we want to move both c1 and c3, to p2 and p1 respectively

!  Can be represented by two tasks: putHinHpile (c1, p2) and putHinHpile (c3,p1) ●  Problem: without concurrency, SeRPE needs to fully complete one of tasks

before beginning another

94 Chapter 3

!!!!!!!!!d1!

!!!!!!!!!!!d3!!

!!!!!!!!!d2!

p1!!!!!c2!c1!

!!!!!!!!!!!p2!c3!

!!!!!!!!!!!p3!

r1! r2!

Figure 3.10: The same initial state as in Example 2.6.

⇡4

to produce a plan such as this one:

⇡5

= hload(r1

, c1

, p1

), load(r2

, c3

, p2

),move(r2

, d2

, d3

),move(r1

, d1

, d2

),

move(r2

, d3

, d1

), unload(r1

, c1

, p2

), unload(r2

, c3

, p1

)i.

To provide a way of specifying that a plan such as ⇡5

is a permissiblesolution, we will allow the body of a method to include steps of the form

{interleave: p1

, . . . , pk

},

where each pj

is a sequence of steps pj

= h⌫j,1

, . . . , ⌫j,kj i. This operator has

the same semantics as the “concurrent” operator in Section 3.3.4, exceptthat only one command can be performed at a time.

Example 3.10. Continuing with Example 3.9, suppose that M includesone additional method, where c, c0 2 Containers and p, p0 2 Piles:

put-interleaved(c, p, c0, p0)task: put-both(c, p, c0, p0)pre: none

body: {interleave:hput-in-pile(c, p)i,hput-in-pile(c0, p0)i}

Then for the task put-both(c1

, p2

, c3

, p1

), we can generate ⇡5

using the re-finement tree shown in Figure 3.11.

Figure 3.12 shows a planning procedure, IRPE (Interleaved RefinementPlanning Engine), that can generate refinement trees such as the one inFigure 3.11. IRPE is a generalization of SeRPE that includes code to dealwith “interleave” statements. IRPE generates refinement trees that containfive kinds of nodes:

• A task node or action node contains a task or action, respectively.

Draft, not for distribution. March 1, 2015.

63"Dana"Nau"and"Vikas"Shivashankar:"Lecture"slides"for!Automated!Planning!and!Ac0ng" Updated"3/24/15"

Interleaved(Refinement(Tree((IRT)(Procedure(●  IRT extends SeRPE to

remedy this ●  Refer to 3.4.2 for more

details

Section 3.4 95

taskput-in-pile(c1,p2)

methodcarry-to-pile(r1,c1,p1,d1,p2,d2)

taskuncover(c1)

methodno-remove(c1)

tasknavigate(r1,d2)

actionload(r1,c1,p1)

actionunload(r1,c1,p2)

(no children)

methodroute(r1,d1,d2)

actionmove(r1,d1,d2)

taskput-in-pile(c3,p1)

methodcarry-to-pile(r2,c3,p2,d2,p1,d1)

taskuncover(c3)

methodno-remove(c3)

tasknavigate(r2,d1)

actionload(r2,c3,p2)

actionunload(r2,c3,p1)

(no children)

methodroute(r2,d3,d1)

tasknavigate(r2,d3)

methodroute(r2,d2,d3)

actionmove(r2,d2,d3)

methodput-interleaved(c1,p2,c3,p1)

interleave

taskput-both(c1,p2,c3,p1)

actionmove(r2,d3,d1)

Figure 3.11: Interleaved refinement tree for ⇡5

.

• A method node or program node contains a pair (p, i), where p is amethod or a program, and i is a program counter.

• An interleave node represents a statement of the form{interleave: p

1

, . . . , pk

}. It is an empty node whose children in-clude a program nodes ⌫

1

, . . . , ⌫k

.

The SeRPE algorithm was simple because there was always just one choicefor which node to expand next. For IRPE, the situation is considerablymore complicated, because there will be many di↵erent possible orders inwhich to expand the nodes below each interleave node. IRPE handles this by

Draft, not for distribution. March 1, 2015.