Post on 19-Dec-2015
AI – Week 18 + 19AI Planning – Plan Generation Algorithms: GraphPlan
Lee McCluskey, room 2/09Email lee@hud.ac.uk
http://scom.hud.ac.uk/scomtlm/cha2555/
This lecture I have broken the habit of a lifetime and inserted some slides from someone else!! They are from Dana S. Nau’s collection from his and Ghallab and Traverso’s book on AI Planning (see ‘resources’ in the website to find them)
Artform Research Group
Relaxing …..
One way to reduce branching factor in a problem is by relaxing!! :
First create a relaxed problem -- remove some restrictions of the original problem
The solutions to the relaxed problem will include all solutions to the original problem
Then do a modified version of the original search. Restrict its search space to include only those actions that occur in solutions to the relaxed problem
Artform Research Group
The Graphplan algorithm
1. Designed in the mid-1990’s
2. Generally faster than any other known algorithm at that time
3. Produces optimal (parallel) plans
4. Introduced the MOST INFLUENTIAL TECHNIQUE IN PLANNING –
The Planning Graph
Artform Research Group
Parallel Operators
Two operators can be applied „in parallel“ if their outcome does not depend on the order of execution
Drive T1 A B, Drive T2 C D Operators a and a' interfere if:
del(a) ^ (add(a') U pre(a')) is not empty, or del(a') ^ (add(a) U pre(a)) is not empty
Allowing sets of non-interfering operators at each step in the plan can make plans shorter => potentially fewer search iterations
Artform Research Group
The Graphplan algorithm : Outline
1. Incrementally construct a planning graphAssume all applicable ground operators are applied in
parallel to the initial state predicates; Produce new state and repeat.Stop when goal predicates are all present in state.2. Construct mutual exclusion constraintsConstrain ground operators that cannot be executed
together3. Do solution extractionSearch backwards considering only actions in the planning
graph
Artform Research Group
state-level i
effectsMaintenance actions: propagate literals to the next level. These represent what happens if no action in the final plan affects the literal.
state-level i-1
state-level 0 (the literals true in s0)
The Planning GraphAlternating layers of ground literals and actions
All actions that might possibly occur at each time step
All of the literals asserted by those actions
action-level i
preconditions
Artform Research Group
Example
due to Dan Weld (University of Washington) Suppose you want to prepare dinner as a surprise for your sweetheart
(who is asleep)
Initial State s0 = {garbage, cleanHands, quiet}
Goal g = {dinner, present, garbage}
Action Preconditions Effects
cook() cleanHands dinner
wrap() quiet present
carry() none garbage, cleanHands
dolly() none garbage, quiet
Also have the maintenance actions: one for each literal
Artform Research Group
Example (continued)state-level 0:
{all atoms in s0} U {negations of all atoms not in s0}
action-level 1:{all actions whose prconditions are satisfied in s0}
state-level 1:{all effects of all of the actions in action-level 1}
Action Preconditions Effects
cook() cleanHands dinner
wrap() quiet present
carry() none garbage, cleanHands
dolly() none garbage, quiet
Also have the maintenance actionsdinner
present
dinner
present
state-level 0 state-level 1action-level 1
Artform Research Group
Mutual Exclusion
Two actions at the same action-level are mutex if Inconsistent effects: an effect of one negates an effect of the other Interference: one deletes a precondition of the other Competing needs: they have mutually exclusive preconditions
Otherwise they don’t interfere with each other Both may appear in a solution plan
Two literals at the same state-level are mutex if Inconsistent support: one is the negation of the other, or all ways of achieving
them are pairwise mutex
Artform Research Group
Example (continued) Augment the graph to indicate mutexes carry is mutex with the maintenance
action for garbage (inconsistent effects) dolly is mutex with wrap
interference ~quiet is mutex with present
inconsistent support each of cook and wrap is mutex with
a maintenance operation
Action Preconditions Effectscook() cleanHands dinnerwrap() quiet presentcarry() none garbage, cleanHandsdolly() none garbage, quiet
Also have the maintenance actions dinner
present
dinner
present
state-level 0 state-level 1action-level 1
Artform Research Group
dinner
present
dinner
present
Example (continued)
Check to see whether there’s a possible plan
Recall that the goal is{garbage, dinner, present}
Note that
All are prossible in s1
None are mutex with each otherThus, there’s a chance that a plan existsTry to find it
Solution extraction
state-level 0 state-level 1action-level 1
Artform Research Group
Solution Extraction
procedure Solution-extraction(g,j)
if j=0 then return the solution
for each literal l in g
nondeterministically choose an actionto use in state s j–1 to achieve l
if any pair of chosen actions are mutex
then backtrack
g’ := {the preconditions of the chosen actions}
Solution-extraction(g’, j–1)
end Solution-extraction
The level of the state sj
The set of goals we are trying to achieve
state-leveli-1
action-level
i
state-level
i
A real action or a maintenance action
Artform Research Group
Example (continued)
Two sets of actions for the goals at state-level 1
Neither works: both sets contain actions that are mutex
dinner
present
dinner
present
state-level 0 state-level 1action-level 1
Artform Research Group
Example (continued)
dinner
present
dinner
present
dinner
present
state-level 0 state-level 1action-level 1 state-level 2action-level 2
Artform Research Group
Example (continued)
Solutionextraction
Twelve combinationsat level 4 Three ways to
achieve garb Two ways to
achieve dinner Two ways to
achieve present
dinner
present
dinner
present
dinner
present
state-level 0 state-level 1action-level 1 state-level 2action-level 2
Artform Research Group
Example (continued)
Several of the combinations look OK at level 2
Here’s one of them
dinner
present
dinner
present
dinner
present
state-level 0 state-level 1action-level 1 state-level 2action-level 2
Artform Research Group
Example (continued)
Call Solution-Extraction recursively at level 2
It succeeds Solution
whose parallel length is 2
dinner
present
dinner
present
dinner
present
state-level 0 state-level 1action-level 1 state-level 2action-level 2
Artform Research Group
RECAP: The Graphplan algorithm
1. Incrementally construct a planning graphAssume all applicable ground operators are applied in
parallel to the initial state predicates; Produce new state and repeat.Stop when goal predicates are all present in state.2. Construct mutual exclusion constraintsConstrain ground operators that cannot be executed
together3. Do solution extractionSearch backwards considering only actions in the planning
graph
Artform Research Group
Graphplan’s limiting assumptions / drawbacks:
Need to create ground instances of everything – all actions and all literals - many of the groundings may be irrelevant. The groundings may lead to an enormous/infinite database!
the goal is a set of literals If the goal literals are found in the graph very
early on, then solution extraction at each subsequent level may be very inefficient..
Artform Research Group
Conclusions Before Graphplan came out, most planning
researchers were working on plan or state space planners
Graphplan caused a sensation because it was so much faster
Many subsequent planning systems have used ideas from it IPP, STAN, GraphHTN, Blackbox, TGP, LPG
Several of them are much faster than the original Graphplan
(see PLANET website for how to download them)
Artform Research Group
Rocket Exercise: First Layer..
at-rocket(London)
at(c1,London)
at(c2,London)
¬at-rocket(Paris),
¬at(c1,Paris)
¬at(c2,Paris)
¬in-rocket(c1)
¬in-rocket(c2)
¬ at-rocket(London),
at-rocket(Paris)
¬ at(c1,London),
in-rocket(c1)
¬ at(c1,London),
in-rocket(c2)
at-rocket(London)
at(c1,London)
at(c2,London)
¬at-rocket(Paris),
¬at(c1,Paris)
¬at(c2,Paris)
¬in-rocket(c1)
¬in-rocket(c2)
move(London,Paris)
load(c1,London)
load(c2,London)
Artform Research Group
¬ at-rocket(London),
at-rocket(Paris)
¬ at(c1,London),
in-rocket(c1)
¬ at(c1,London),
in-rocket(c2)
at-rocket(London)
at(c1,London)
at(c2,London)
¬at-rocket(Paris),
¬at(c1,Paris)
¬at(c2,Paris)
¬in-rocket(c1)
¬in-rocket(c2)
Unload(c1,Paris)
Unload(c2,Paris)
move(London,Paris)
load(c1,London)
load(c2,London)
at(c1,Paris)
at(c2,Paris)
¬ at-rocket(London),
at-rocket(Paris)
¬ at(c1,London),
in-rocket(c1)
¬ at(c1,London),
in-rocket(c1)
at-rocket(London)
at(c1,London)
at(c2,London)
¬at-rocket(Paris),
¬at(c1,Paris)
¬at(c2,Paris)
¬in-rocket(c1)
¬in-rocket(c2)
Second Layer… GoalsPresent –But no consistentAction sequence
Need a Third Layer…