Date post: | 25-Dec-2015 |
Category: |
Documents |
Upload: | rudolf-goodman |
View: | 216 times |
Download: | 2 times |
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
Action: represented by a set of action schemas
State: represented by a conjunction of ground atoms without function symbols
),2(),1( DowntownTruckAtLSUTruckAt
)),(),(:
)()()(),(:
),,((
topAtfrompAtEFFECT
toAirportfromAirportpAirplanefrompAtPRECOND
tofrompFlyAction
A specific planning problem
Initial state – a conjunction of ground atoms A set of action schemas Clearly a planning problem can be seen as a
search problem
Goal state – a conjunction of literals (positive + negative) that may contain (existentially quantified) variables
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 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!
Both are decidable if the planning language is function-free – finitely many states
Algorithms for planning as state-space search Forward (progression) state-space searchBackward (regression) relevant-states search
Heuristics for planning
Look at relaxed problem Ignoring pre-conditions Ignoring delete list
Use state-abstraction – reduce the number of states Subgoal independence assumption
Key idea: decomposition – dividing the problem into
parts (which may be independent) and solve each part independently, then combine the subplans
Adding edges in the state-space graph
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
))(:
)(:
)((
))()(:
)()(:
)((
))()((
))((
CakeHaveEFFECT
CakeHavePRECOND
CakeBakeAction
CakeEatenCakeHaveEFFECT
CakeEatenCakeHavePRECOND
CakeEatAction
CakeEatenCakeHaveGoal
CakeHaveInit
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, num-
lev(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
)),(),(),(
),(),(),(:
:
,(
)),(),(:
),(),()(:
),,((
)),(),(:
),(:
),,((Re
)),((
)),(),()()((
TrunkFlatAtAxleFlatAtGroundFlatAt
TrunkSpareAtAxleSpareAtGroundSpareAtEFFECT
PRECOND
ightLeaveOvernAction
AxletAtGroundtAtEFFECT
AxleFlatAtGroundtAttTirePRECOND
AxletPutOnAction
GroundobjAtlocobjAtEFFECT
locobjAtPRECOND
locobjmoveAction
AxleSpareAtGoal
TrunkSpareAtAxleFlatAtSpareTireFlatTireInit
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