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 shoe Put on right sock Put on left shoe Put on left sock Take off right shoe Take off right sock Take off left shoe Take 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 1 Left sock Left shoe Right sock Right shoe Plan 2 Left sock Right sock Left shoe Right shoe Plan 3 Left sock Right sock Right shoe Left 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 doesnt 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 planners 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)