REVIEW : Planning

• To make your thinking more concrete, use a “real” problem to ground your discussion. – Develop a plan for a person who is getting out

of bed in the morning that results in the person being dressed for class.

REVIEW : Planning As Search

• What is the initial state?Have right shoe + Have left shoe + Have right sock +

Have left sock + bare right foot + bare left foot

• What is the goal state?Wearing right shoe + wearing left shoe + wearing right

sock + wearing left sock.

• How can you recognize goal states (what is the goal test)?Is the current state equal to the goal state?Is the goal state a subset of the current state?

REVIEW : Planning As Search

• What operators can the agent use to change state (what successor function can be used to generate the set of states reachable from the current state)?Put on right shoePut on right sockPut on left shoePut on left sockTake off right shoeTake off right sockTake off left shoeTake off left sock

REVIEW : Planning As Search

• What deadend states can the agent reach, and how can it recognize deadends?Without the “take off” operators, then any state in

which I am wearing my right shoe but not my right sock is a deadend. Likewise for the left foot.

REVIEW : Planning as Search

• Advantages– The formalism is simple.– We know a rich set of algorithms for doing

search.– The result of a search is a path from the start

state to a goal state. Just return that path as the answer, the plan.

Search vs. planning

• Standard search algorithms seem to fail miserably:

• Problems with search approach– too many irrelevant actions

Consider the task get milk, bananas, and a cordless drill

Search vs. planning

• Standard search algorithms seem to fail miserably:

• Problems with search approach– too many irrelevant actions– finding good heuristics is difficult

Search vs. planning

• Standard search algorithms seem to fail miserably:

• Problems with search approach– too many irrelevant actions– finding good heuristics is difficult– cannot take advantage of problem

decomposition

REVIEW : Planning as Search

• A major disadvantage:– Search overcommits.

• Do I really want my plan to commit me to putting my left shoe before I put on my right shoe???

Plan 1Left sockLeft shoeRight sockRight shoe

Plan 2Left sockRight sockLeft shoeRight shoe

Plan 3Left sockRight sockRight shoeLeft shoe

REVIEW : Planning Viewed as Logical Inference

• Write a set of sentences that describe the world:bare( leftFoot )

bare( rightFoot )

...

if bare(X,t) and

have(Y,t) and

wearOn( Y, X )

then not bare(X,t+1 )

REVIEW : Planning Viewed as Logical Inference

• Use an inference engine to derive the goal state:wearing( leftShoe )

wearing( rightShoe )

...

• And return the set of support for each sentence in the goal state.

REVIEW : Planning Viewed as Logical Inference

• Advantages– States are explicit.

• I and G are sets of sentences.

– Operators are explicit.• Each operator in O is a set of sentences.

– Predicate logic with only a few extensions gives a rich language for describing states and operators.

REVIEW : Planning Viewed as Logical Inference

• Disdvantages– Inference in predicate logic is very expensive,

both in time and space.– Even restricting the language severely doesn’t

sufficiently offset the costs in time and space.

Planning as its Own Problem

• Search and logical inference seem to complement each other, with the strengths of one offsetting the weaknesses of the other.

• Can we combine the two to create a planning method that is better?– Use logic to write state descriptions and operators and

to reason about them.

– Use search-style algorithms to build the plans.

The Key Ideas of Planning

1. Planning problems are decomposable and (mostly) independent, so our planner should be able to recognize this and use it to the planner’s advantage.Example: dressing my feet.

2. If plans are decomposable, then operators and states should be, too.

3. A planner should be able to choose any action that makes sense and add it to the “right place” in the plan at any time.

So we need a system that

1. open up action and goal representation to allow selection

2. divide-and-conquer by subgoaling

3. relax requirement for sequential construction of solutions

• Classical Planning systems devising a sequence of actions achieving a goal in a domain that is fully observable, deterministic, static, and discrete

Language for planning problems• STRIPS: STanford Research Institute Problem Solver• world described by logical conditions• state as conjunction of positive literals

– propositional; e.g., Happy ^ Hungry to represent the state of the agent

– first-order ground and function-free terms; • e.g., At(Plane1, Verona) ^ At(Plane2,Malpensa)

• closed-world assumption; i.e., any not mentioned condition is false

• goal is a partially specified state– a state satisfies a goal if contains all the literals of the goal– e.g. state At(Plane1, Verona) ^ At(Plane2,Malpensa) satisfies goal

At(Plane2,Malpensa)

STRIPS actions

• actions are described by– preconditions: when the action can be applied– effects: state changes by the action

• add-list: propositions that become true• delete-list: propositions that become false

• actions contain variables• a single action schema represents different

actions (instantiation of variables)

STRIPS actions (contd.)• Tidily arranged actions descriptions, restricted

language• Action schema:

– ACTION: specifies name and parameter list• Buy(x)

– PRECONDITION: conjunction of positive literals• At(p) ^ Sells(p, x)

– EFFECT: conjunction of literals (positive or negative)• Have(x)

– [Note: no information on how to execute the action!]• A complete set of STRIPS operators can be

translated into a set of successor-state axioms

Have(X) ^ GoesOn(X,Y) ^ Bare(Y)

PutOn(X)

HaveOn(X)

In order to PutOn(LeftSock) we have to Have(LeftSock) ^ GoesOn(LeftSock,LeftFoot) ^ Bare(LeftFoot)

This leaves us with HaveOn(LeftSock)

STRIPS actions

Semantics• Given a state (conjunction of literals)

– precondition is satisfied if there is a variable assignment s.t. the literals are included in the state; e.g.,

• state At(HW) ^ Sell(HW,Drill) • satisfies precondition At(p) ^ Sells(p, x)• with assignment p/HW and x/Drill

– actions with preconditions satisfied can be applied• delete items from the delete-list• add items from the add-list• order does matter!• new state: At(HW) ^ Sell(HW,Drill) ^ Have(Drill)

Example: Shopping• Actions

– Buy(x)• PRE: At(store), Sells(store, x)• EFF: Have(x)

– Go(x, y)• PRE: At(x)• EFF: At(y),¬At(x)

• Start– At(Home) ^ Sells(SM,Milk) ^ Sells(SM,Banana) ^

Sells(HWS,Drill)• Goal

– Have(Milk) ^ Have(Banana) ^ Have(Drill)