slides on chap. 10
Download
Report
Transcript slides on chap. 10
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