Graphplan
Adapted from slides by
José Luis Ambite*
[* based in part on slides by Jim Blythe and Dan Weld]
1
GraphPlan
 Many Planning Systems now use these Ideas:






GraphPlan
IPP
STAN
SGP
Blackbox
Medic
 Runs orders of magnitude faster than partial
order planners (as POP, SNLP, UFPOP, etc.)
2
Basic idea
 Construct a graph that encodes constraints on
possible plans
 Use this “planning graph” to constrain search
for a valid plan:
 If valid plan exists, it’s a subgraph of the planning
graph
 Planning graph can be built for each problem in
polynomial time
3
Problem handled by GraphPlan*
 Pure STRIPS operators:




conjunctive preconditions
no negated preconditions
no conditional effects
no universal effects
 Finds “shortest parallel plan”
 Sound, complete and will terminate with failure
if there is no plan.
*Version in [Blum& Furst IJCAI 95, AIJ 97],
later extended to handle all these restrictions [Koehler et al 97]
4
Planning graph
 Directed, leveled graph
 2 types of nodes:
 Proposition: P
 Action: A
 3 types of edges (between levels)
 Precondition: P -> A
 Add: A -> P
 Delete: A -> P
 Proposition and action levels alternate
 Action level includes actions whose preconditions
are satisfied in previous level plus no-op actions
(to solve frame problem).
5
The Planning Graph
Alternating layers of ground literals and actions (ground instances
of operators) representing the literals and actions that might occur
at each time step 0 < i < N
literals that might be true at time t = (i-1)/2
literals
that are
true at
the initial
state
0
i-1
...
i
i+1
...
preconditions
literals that
might be true
at time
t = (i+1)/2
effects
...
operators
...
Maintenance:
NoOps
6
Rocket domain
7
Constructing the planning graph
 Level P1: all literals from the initial state
 Add an action in level Ai if all its preconditions are
present in level Pi
 Add a precondition in level Pi if it is the effect of some
action in level Ai-1 (including no-ops)
 Maintain a set of exclusion relations to eliminate
incompatible propositions and actions (thus reducing
the graph size)
P1 A1 P2 A2 … Pn-1 An-1 Pn
9
Mutual Exclusion relations
 Two actions (or literals) are mutually exclusive (mutex)
at some stage if no valid plan could contain both.
 Two actions are mutex if:
 Inconsistent effects: an effect of one negates an effect of the
other
 Interference: one clobbers others’ effect or precondition
(deletes other’s precondition)
 Competing needs: mutex preconditions
 Two propositions are mutex if:
 Inconsistent support: One is the negation of the other, or all
ways of achieving them are mutex
10
Mutual Exclusion relations
Inconsistent
Effects
Interference
(prec-effect)
Competing
Needs
Inconsistent
Support
11
Dinner Date example
 Initial Conditions: (and (garbage) (cleanHands) (quiet))
 Goal: (and (dinner) (present) (not (garbage))
 Actions:
 Cook :precondition (cleanHands)
:effect (dinner)
 Wrap :precondition (quiet)
:effect (present)
 Carry :precondition
:effect (and (not (garbage)) (not (cleanHands))
 Dolly :precondition
:effect (and (not (garbage)) (not (quiet)))
12
Dinner Date example
13
Dinner Date example
14
Observation 1
p
¬q
¬r
p
A
q
p
A
¬q
q
A
¬q
B
¬r
p
r
q
¬q
B
¬r
r
¬r
Propositions monotonically increase
(always carried forward by no-ops)
15
Observation 2
p
¬q
¬r
p
A
q
p
A
¬q
q
A
¬q
B
¬r
p
r
q
¬q
B
¬r
r
¬r
Actions monotonically increase
16
Observation 3
p
p
p
q
q
q
r
r
r
…
…
…
A
Proposition mutex relationships monotonically decrease
17
Observation 4
A
A
A
p
p
p
p
q
q
q
q
…
B
C
r
s
…
B
C
r
s
…
B
C
r
s
…
Action mutex relationships monotonically decrease
18
Observation 5
Planning Graph ‘levels off’.
 After some time k all levels are identical
 Because it’s a finite space, the set of literals
never decreases and mutexes don’t reappear.
19
Valid plan
A valid plan is a planning graph where:
 Actions at the same level don’t interfere
 Each action’s preconditions are made true by
the plan
 Goals are satisfied
20
GraphPlan algorithm
 Grow the planning graph (PG) until all goals are
reachable and not mutex. (If PG levels off first,
fail)
 Search the PG for a valid plan
 If non found, add a level to the PG and try
again
21
The Algorithm
function GRAPHPLAN(problem) returns solution or failure
graph  INITIAL-PLANNING-GRAPH(problem)
goals  GOALS[problem]
loop
do
solution
 EXTRACT-SOLUTION (graph, goals, LENGTH(graph))
if goals all non-mutex in last level of graph then do
if solution  failure then return solution
else if NO-SOLUTION-POSSIBLE(graph) then return failure
graph  EXPAND-GRAPH(graph, problem)
22
Searching for a solution plan
 Backward chain on the planning graph
 Achieve goals level by level
 At level k, pick a subset of non-mutex actions to
achieve current goals. Their preconditions become the
goals for k-1 level.
 Build goal subset by picking each goal and choosing an
action to add. Use one already selected if possible. Do
forward checking on remaining goals (backtrack if can’t
pick non-mutex action)
23
Solution Extraction: The Algorithm
procedure SOLUTION-EXTRACTION(goal_set, graphlevel)
if graphlevel = 0 we have found a solution
for each goal in goal_set
choose (nondeterministically) an action
at level graphlevel–1 that achieves it
Level of
the graph
we are at
if any pair of chosen actions are mutex, then backtrack
precondition_set:= {the precondition of the chosen actions}
SOLUTION-EXTRACTION(precondition_set, graphlevel-2)
24
Plan Graph Search
If goals are present & non-mutex:
Choose action to achieve each goal
Add preconditions to next goal set
25
Termination for unsolvable problems
 Graphplan records (memoizes) sets of
unsolvable goals:
 U(i,t) = unsolvable goals at level i after stage t.
 More efficient: early backtracking
 Also provides necessary and sufficient
conditions for termination:
 Assume plan graph levels off at level n, stage t > n
 If U(n, t-1) = U(n, t) then we know we’re in a loop
and can terminate safely.
26
Dinner Date example
 Initial Conditions: (and (garbage) (cleanHands) (quiet))
 Goal: (and (dinner) (present) (not (garbage))
 Actions:
 Cook :precondition (cleanHands)
:effect (dinner)
 Wrap :precondition (quiet)
:effect (present)
 Carry :precondition
:effect (and (not (garbage)) (not (cleanHands))
 Dolly :precondition
:effect (and (not (garbage)) (not (quiet)))
27
Solution Extraction for the Example (2):
 Two sets of actions for the goals at level 2
 Neither works: both sets contain actions that are mutex
0
garb
1
carry
2
garb
0
garb
carry
garb
dolly
cleanH
1
cleanH
cleanH
cleanH
cleanH
cook
cook
quiet
wrap
garb
dolly
cleanH
quiet
2
garb
quiet
quiet
quiet
wrap
quiet
dinner
dinner
present
present
28
Solution Extraction Example (3)
 Go back and do more graph extension: generate two
more levels
0
garb
1
carry
2
garb
garb
garb
dolly
cleanH
cleanH
cleanH
cleanH
cook
quiet
cook
quiet
wrap
4
garb
carry
dolly
cleanH
3
quiet
quiet
wrap
quiet
dinner
dinner
present
present
29
Example: Solution extraction (4)
0
garb
1
carry
2
garb
garb
garb
dolly
cleanH
cleanH
cleanH
cleanH
cook
quiet
cook
quiet
wrap
4
garb
carry
dolly
cleanH
3
quiet
quiet
wrap
quiet
dinner
dinner
present
present
Twelve combinations at level 4
• Tree ways to archive “garb”
• Two ways to archive “dinner”
• Two ways to archive “present”
30
Example: Solution extraction (5)
Several of the combinations look OK at level 2. Here is one of them:
0
garb
1
carry
2
garb
garb
garb
dolly
cleanH
cleanH
cleanH
cleanH
cook
quiet
cook
quiet
wrap
4
garb
carry
dolly
cleanH
3
quiet
quiet
wrap
quiet
dinner
dinner
present
present
31
Example: Solution extraction (6)
Call Solution-Extraction recursively at level 2; one combination works, so we
have got a plan
0
garb
1
carry
2
garb
garb
garb
dolly
cleanH
cleanH
cleanH
cleanH
cook
quiet
cook
quiet
wrap
4
garb
carry
dolly
cleanH
3
quiet
quiet
wrap
quiet
dinner
dinner
present
present
32
Planning Graph Example
Rocket problem
37
Plan Graph creation is Polynomial
Theorem 1:
 The size of the t-level PG and the time to create it are
polynomial in




t = number of levels
n = number of objects
m = number of operators
p = propositions in the initial state
 Max nodes proposition level: O(p+mlnk)
 Max nodes action level: O(mnk)
k = largest number of action parameters, constant!
38
Compare with POP
 Graphplan will examine fewer actions than POP,
because it will only look at actions in the
planning graph
 However (like POP), Graphplan may examine the
same actions more than once if it finds multiple
plans to achieve them
 Look at ways to make Graphplan more efficient
39
Ways to improve GraphPlan
 Techniques from Constraint satisfaction
Problems (CSP)




Forward checking
Memorization
Variable ordering
Handling the closed-world assumption
 Action schemata, type analysis, and
simplification
 Not reachable states (because of domain
theory)
 e.g. impossible: at(car1 Washington, t)  at(car1
Philadelphia, t)
40
In-place plan graph expansion
q2
A1

B3
r4
7
C3
s4
D5
…
…
p
0
6
 start time
end level  end time
Props & actions: start level
Mutex relations:
41
Perverting Graphplan
Graphplan
ADL
Graphplan
Uncertainty
Rao
Gazen & Knoblock
Koehler
Anderson, Smith & Weld
Boutilier
Conformant
PGP
Smith & Weld
Blum & Langford
Time
Smith & Weld
Koehler ?
?
Sensory/Contingent
Weld, Anderson & Smith
42
Expressive Languages




Negated preconditions
Disjunctive preconditions
Universally quantified preconditions, effects
Conditional effects
43
Negated Preconditions
 Graph expansion
 P, P mutex
 Action deleting P must add P at next level
 Solution extraction
44
Disjunctive Preconditions
 Convert precondition to DNF
 Disjunction of conjunctions
 Graph expansion
 Add action if any disjunct is present, nonmutex
 Solution extraction
 Consider all disjuncts
45
Universal Quantification
 Graph Expansion
 Solution Extraction
46
Universal Quantification
 Graph Expansion
 Expand action with Herbrand universe
replace block x P(x)
with P(o17)  P(o74)  …  P(o126)
 Solution Extraction
 No changes necessary
47
Conditional Effects
48
Full Expansion
in-keys in-pay
in-keys in-pay
in-keys in-pay
in-keys in-pay
49
Factored Expansion
 Treat conditional effects as primitive
 “component” = <antecendant, consequent> pair
 STRIPS action has one component
 Consider action A
 Precond: p
 Effect:
e
(when q (f  g))
(when (r  s) q)
 A has three components: antecedent
p
pq
prs
consequent
e
f  g
q
50
Changes to Expansion
 Components C1 and C2 are mutex at level I if
 The antecedants of C1 and C2 are mutex at I-1
 C1, C2 come from different action instances, and the consequent of
C1 deletes the antecedant of C2, or vice versa
  C, C1 induces C and C is mutex with C2
 Intuitively, C1 induces C if it is impossible to execute C1 without
executing C.
 C1 and C are parts of same action instance
 C1 and C aren’t mutex (antecedants not inconsistent)
 The negation of C’s antecedant can’t be satisfied at level I-1
51
Induced Mutex
52
Revised Backchaining
 Confrontation
 Subgoaling on negation of something
53