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