Classical Planning
Chapter 10
Outline
 The challenges in planning with standard
search algorithm
 Representing Plans – the PDDL language
 Planning as state-space search
 Planning Graphs and the GRAPHPLAN
Algorithm
 Other Approaches
Classical Planning
 What is planning:
 The task of coming up with a sequence of
actions to achieve a given goal is called
planning
 Classical planning: When the environment is




Fully observable
Deterministic
Static
Discrete
Challenges in Planning with
Standard Search Method (A*, etc)
 Why real-world planning problem with state-
space search is hard:


Too many irrelevant actions – goal oriented
search would help
Difficult to find a good heuristic function
 So the language for planning should make it
easy for algorithms to exploit the logical
structure of the problem
Challenges in Planning – too many
choices!
PDDL Language
 Planning Domain Definition Language
 State: represented by a conjunction of ground
atoms without function symbols
At(Truck1, LSU ) At(Truck2, Downtown)

 Action: represented by a set of action
schemas
 Action( Fly( p, from,to)
PRECOND: At( p, from)  Airplane( p)  Airport( from)  Airport(to)
EFFECT :  At( p, from) At( p,to) )
A specific planning problem
 Initial state – a conjunction of ground atoms
 Goal state – a conjunction of literals (positive
+ negative) that may contain (existentially
quantified) variables
 A set of action schemas
 Clearly a planning problem can be seen as a
search problem

Example – the blocks-world
Complexity of classical planning
 PlanSAT: Is there a plan for a planning problem
 Bounded PlanSAT: is there a plan of length <= k?
 Both are decidable if the planning language is
function-free – finitely many states
 Both in the class of PSPACE – more difficult than NP!
 But for many domains:


Bounded PlanSAT: NP-complete
PlanSAT: P – thus finding A (possibly suboptimal) plan
may be not so hard!
Algorithms for planning as statespace search
 Forward (progression) state-space search
 Backward (regression) relevant-states search


Heuristics for planning
 Look at relaxed problem
 Adding edges in the state-space graph
 Ignoring pre-conditions
 Ignoring delete list
 Use state-abstraction – reduce the number of states
 Key idea: decomposition – dividing the problem into
parts (which may be independent) and solve each
part independently, then combine the subplans
 Subgoal independence assumption

Planning Graphs - motivation
 A big source of inefficiency in search algorithms is
the branching factor
 One way to reduce branching factor:
 First create a relaxed problem


Remove some restrictions of the original problem
Want the relaxed problem easy (polynomial time)
 The solutions to the relaxed problem will include all
solutions to the original problem
 Then do a modified version of the original search
(backward search)
 Restrict the search space to include only those
actions that occur in solutions to the relaxed problem
Planning Graphs
 Search space for a relaxed version of the planning





problem
Alternating layers of states (ground literals) and
actions
Nodes at action-level i: actions that might be possible
to execute at time i
Nodes at state-level i: literals that might possibly be
true at time i
Edges: preconditions and effects
Mutual exclusion links
Sample Planning Graph
Init( Have(Cake))
Goal( Have(Cake)  Eaten(Cake))
Action( Eat(Cake)
PRECOND: Have(Cake)  Eaten(Cake)
EFFECT : Have(Cake)  Eaten(Cake))
Action( Bake(Cake)
PRECOND: Have(Cake)
EFFECT : Have(Cake))
Mutual Exclusions
 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
 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
The GRAPHPLAN Algorithm
 graph  Initial-planning-graph(problem)
 goals  Conjuncts(Problem, GOAL)
 nogoods  an empty hash table
 For t = 0 to infinity do

if goals all non-mutex in St of graph then

solution  Extract-solution(graph, goals, numlev(graph), nogoods)

if solution != failure, then return solution

if graph and nogoods have both leveled off then

return failure

graph  Expand-graph(graph, problem)
The spare tire problem
Init(Tire( Flat) Tire( Spare)  At( Flat, Axle)  At( Spare,Trunk))
Goal( At( Spare, Axle))
Action(Re m ove(obj, loc),
PRECOND: At(obj, loc)
EFFECT : At(obj, loc)  At(obj, Ground))
Action( PutOn(t , Axle),
PRECOND: Tire(t )  At(t , Ground)  At( Flat, Axle)
EFFECT : At(t , Ground)  At(t , Axle))
Action( LeaveOvernight,
PRECOND:
EFFECT : At( Spare, Ground)  At( Spare, Axle)  At( Spare, Trunk)
 At( Flat, Ground)  At( Flat, Axle)  At( Flat, Trunk))
The spare-tire problem
Extract-solution as a search
problem
 Initial state: the last level of the planning graph Sn
 Actions at state level Si: select any conflict-free
subset of actions in Ai-1 that covers the goals of the
state. The result state: level Si-1, the goals at the new
state = the pre-conditions of the selected actions
 Goal of the backward search: reach a state at S0
such that all goals are satisfied.
 The cost of each action is 1
 When extract-solution fails to find a solution for a set
of goals at a level, a pair (level, goals) is added as a
no-good.
Other Classical Planning
Approaches
 Classical Planning as Boolean satisfiability
 Planning as a first-order logical deduction: Situation
calculus
 Planning as constraint satisfaction