©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Planning Chapter 11.1 – 11.4 Introduction, Assumptions, & Approaches to Planning STRIPS Representation Planning as Search STRIPS Planner and Algorithm Sussman Anomaly Interleaving vs. Non-Interleaving Total vs. Partial Order Planners 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Introduction: Goal Goal: Mechanically and efficiently find a sequence of actions that when "executed", achieves a goal. Define a initial state, goal state and actions Find a plan: a sequence of action instances that when applied to the initial state, transforms the world into a goal state 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Introduction: Assumptions with Planning Goal is a conjunction of sub-goals: to achieve a goal, you achieve a set of sub-goals Actions are: atomic (i.e. indivisible) sequenced (i.e. no concurrency) deterministic: no uncertainty in performing an action result is completely determined by the definition of the action Agent is sole cause of change in the world World is fully observable (i.e. agent is omniscient) 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Introduction: Assumptions with Planning Databases (and people) assume that the information provided is complete so that ground atomic sentences not asserted to be true are assumed to be false. This is called the Closed World Assumption: state description lists all that is true anything else is assumed false FOL doesn't make this assumption planning systems we'll cover do 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Approaches to Planning State-space search (Ch. 3, 4): state space representation where each node is a state operators: used to generate next state start state: describes the initial situation goal test: used to determine if a goal is reached Situation calculus (Ch 10.3): augmented FOL representation that enables reasoning about actions in time situation variable: a "timestamp" added to fluents situation: a "snapshot" of world when nothing changes Result(a, s): function that returns next situation after applying action a in situation s 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Approaches to Planning: State-Space Search Can't reason about operator definition or ordering can only generate the next state can't look at operator definition to reason, e.g. how to reduce the number of successor states Can't reason about goal definition can only determine if goal reached can't look at goal definition to reason, e.g. how best to achieve the goal Approach is all algorithm & representation weak heuristics simply measure the distance to goal heuristics can only rank states based on this distance 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Approaches to Planning: Situation Calculus Frame problem: simple effect axioms in situational calculus describe what changes, but don’t specify what stays the same a solution: frame axioms specify what doesn't change many axioms are required approach not modular, each new predicate requires axioms to be added for each operator further solution: successor-state axioms specify how fluents change and now a theorem prover can be used Approach is representation strong but knowledge is too fined-grained resulting in weak reasoning because of the inefficiency of the theorem prover. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Approaches to Planning: Combine Ideas Combine the two approaches: "Open up" the representation of states, operators, and goal test rather than blindly applying operators, reason about which ones are most useful reduces the number of states that are considered Simplify the representation language allow reasoning about how to achieve the goal inference procedure is faster than resolution theorem prover 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Representation Facts: ground literals without variables Situations: conjunction of facts Goal: conjunction of positive literals variables assumed to be existentially quantified Actions: action name preconditions: conjunction of positive literals that defines when action is legal/applicable effects: conjunction of positive literals (called the add list) and negative literals (called the delete list) *when lists are combined it’s called the effects list 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Representation Operator Examples: 1. action name: Buy(x) preconditions: At(s), Sells(s,x) effects: Have(x) 2. action name: Pickup(x) preconditions: OnTable(x), Clear(x), HandEmpty effects: Holding(x), ØOnTable(x), ØClear(x), ØHandEmpty Worksheet Assume everything stays the same unless explicitly on the add or delete lists (this avoids the frame problem). 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Planning as Search Situation-space search: search space: all possible situations (i.e. states) node: situation (i.e. world state) arcs: operators/actions start node: initial situation goal node: situation where all of the sub-goals solved plan: sequence of actions in path from start to goal Plan-space search: search space: all possible plans more later 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Planning as Search A plan is complete iff every precondition is achieved. A precondition is achieved iff it is the effect of an earlier step and no intervening steps undo it. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Planning as Search: Situation-Space Planners Progression: forward chaining like state-space search except for representation inefficient due to large situation space to explore Worksheet, cont. Regression: backward chaining start from the goal state and solve its sub-goals (preconditions) more efficient and goal-directed than progression (fewer applicable operators) 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Planner: A Regression Planner Uses a goal stack that orders what task to do next: achieve(goal): find an operator that achieves sub/goal achieve(goals): check for goal interaction by verifying sub/goals are still achieved, if not try new order apply(operator): update current state using operator effects list Maintains a current situation: facts that are true in the current state updated by operators' effects list, i.e. add positive literals, delete negated literals 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Planner: A Regression Planner IDEA: pick an order for the goals & push them onto the stack when each goal is popped from stack, do achieve(goal) if not already achieved (i.e. true in current situation): find operator that adds the goal push the operator onto stack push its preconditions (i.e. subgoals) in some order onto stack then solve each subgoal in the same fashion when all of the preconditions are solve (i.e. popped from stack), do verification step achieve(goals), which checks that none of the preconditions have been undone when an operator is popped from stack, do apply(operator) to the current situation Worksheet, cont. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Planner: Key Assumptions Strips assumes no interaction of sub/goals, i.e. sub/goals are independent of each other whole plan is sum of all subplans, i.e. solve each subgoal independently and then concatenate these solutions to form the whole plan the problem can be divided and conquered without worrying about other parts of the problem interfering e.g. putting on a sock doesn't interfere with putting on pants 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Algorithm: Method Header Plan strips (List currState, List goals, OpsList ops) currState: the list of facts for the current situation that is originally the initial situation goals: list of goals that are assumed to be conjoined G1Ù..ÙGn ops: list of operators defined in STRIPS language Plan: either "success" or "failure", (use a data structure to record the apply steps for constructing the successful plan) 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Algorithm: Main Cases Plan strips (List currState, List goals, OpsList ops) { stack gs = new Stack(); //the goal stack gs.push(achieve(goals)); //add task to achieve goals //G1Ù..ÙGn while (true) { if (gs.isEmpty()) return "successful" Plan; N = gs.pop(); //Next task if (N of the form achieve(g1,..,gm)) { verify sub/goals g1,..,gm achieved, if not try new order if no ordering of sub/goals works then return failure} else if (N of the form achieve(g)) { find an operator that achieves sub/goal g if no operator can achieve goal then return failure} else if (N of the form apply(o)) { update currState using operator o} } 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Algorithm: Case Details Plan strips (List currState, List goals, OpsList ops) { stack gs = new Stack(); gs.push(achieve(goals)); while (true) { //... if (N of the form achieve(g1,..,gm)) { //check if sub/goals are achieved, if so continue loop if (N is true in currState) continue; //if all orderings tried then fail if (all orderings of gi tried) return "failure"; //add task to re-verify conjoined sub/goals gs.push(N); //add tasks in differnt order to achieve each sub/goal gs.push(gi) in a new order; } ... 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Algorithm: Case Details Plan strips (List currState, List goals, OpsList ops) { stack gs = new Stack(); gs.push(achieve(goals)); while (true) { //... if (N of the form achieve(g)) { //check if sub/goal is achieved, if so continue loop if (N is true in currState) continue; //find an operator that adds sub/goal StripsOp o = ops.findAddEffect(g); if (o == null) return "failure"; //if none fail unify(o,g); //variables bound so g adds o //add tasks to: gs.push(apply(o)); //update currState gs.push(achieve(preconditions of o));//continue plan } ... 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

STRIPS Algorithm: Case Details Plan strips (List currState, List goals, OpsList ops) { stack gs = new Stack(); gs.push(achieve(goals)); while (true) { //... if (N of the form apply(o)) { //next state is result of operator updating currState currState = ops.update(currState, o); } ... 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Sussman Anomaly What happens when subgoals interfere with each other? e.g. socks and pants must be put on before shoes STRIPS algo can solve since it tries all orderings of subgoals: ShoeOn(L), SockOn(R), ShoeOn(R), PantsOn, SockOn(L), SockOn(L), PantsOn, SockOn(R), ShoeOn(R), ShoeOn(L), e.g. How about this classic example of goal interaction: A B C a plan goal: on(A,B) on(B,C) 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Sussman Anomaly What happens when subgoals interfere with each other? achieve(on(A,B)), achieve(on(B,C)) (skipping pickup steps) unstack(C,A) to clear(A) stack(A,B) for on(A,B) unstack(A,B) to clear(B) stack(B,C) for on(B,C) A B C A B C A B C A B C A B C on(A,B) is undone to clear(B) when solving on(B,C)! Try reordering? achieve(on(B,C)), achieve(on(A,B)) 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Sussman Anomaly What happens when subgoals interfere with each other? achieve(on(B,C)), achieve(on(A,B)) (skipping pickup steps) stack(B,C) for on(B,C) unstack(B,C) to clear(C) unstack(C,A) to clear(A) stack(A,B) for on(A,B) A B C A B C A B C A B C A B C on(B,C) is undone to clear(A) when solving on(A,B)! STRIPS can't fix the Sussman Anomaly by reordering goals! 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Sussman Anomaly Thus, STRIPS algorithm given is incomplete, i.e. can't always find a plan even if one exists! STRIPS works if goal is redefined: onTable(C), on(B,C), on(A,B)] requiring "right" list of goals for a plan to be found is undesirable STRIPS may be modified so that if verification check fails it tries to resolve goals that were undone STRIPS algo. shown with modification is still incomplete 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Interleaving vs. Non-interleaving Planner G1 Ù G2: either all the steps for achieving G1 occur before G2, or all of the steps for achieving G1 occur after G2 all of the steps for a sub/goal must occur “atomically” e.g. STRIPS can't solve the Sussman Anomaly Interleaving planner can intermix order of sub/goal steps can solve the Sussman Anomaly by interleaving steps: unstack(C,A), Pickup(B), Stack(B,C), Stack(A,B) 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Planning Chapter 11.1 – 11.4 Partial-Order Planners Principle of Least Commitment Plan-Space Search Links (Constraints) and Arcs (Plan Modification) Finishing the Plan Threat Removal The POP Algorithm 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Partial Order Planning (POP) Total-order planner (linear): maintains a partial solution as a totally ordered list of steps found so far e.g. STRIPS e.g. situation-space progression and regression planners Partial-order planner (non-linear): only maintains ordering constraints on the partially ordered steps in the plan AIMA figure 11.6, putting on shoes and socks 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Principle of Least Commitment Principle of Least Commitment: don’t make an ordering choice, unless required to do so. property of partial-order planners keeps the ordering choice as general as possible reduces the amount of time wasted backtracking to undo steps Situation-space planners, conversely, make commitments about the order of steps as they try to find a solution. may make poor guesses about the ordering of steps may need to undo steps and try a different order 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Planning as Seach Situation-space search: search space: all possible situations (i.e. states) etc., as previously covered Plan-space search: search space: all possible partial-order plans node: a partial-order plan arcs: add/delete/modify steps of previous node’s plan or add temporal and causal constraint between existing steps start node: initial partial-order plan, start  finish start: pre. none, eff. positive literals defining start state finish: pre. goal of conjunctive literals, eff. none goal node: a complete plan that solves all sub/goals 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: Shopping Problem Start Initial State Action Effects Preconditions Start and Finish are psuedo-steps Goal State Finish 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: Shopping Problem Problem: buy cookies, milk, and a drill Start At(Home), Sells(GS, Cookies), Sells(GS, Milk), Sells(HWS, Drill) This is the first node in the plan-space search Have(Cookies), Have(Milk), Have(Drill), At(Home) Finish GS: Grocery Store HWS: Hardware Store 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Links and Arcs: Types of Links Ordering constraints (temporal links): S1 < S2: S1 before S2 S1 must occur before S2 but not necessarily immediately before it thin links S1 S2 Causal constraints (causal links): S1 c S2: S1 achieves c for S2 S1 has a literal c in its effect list that is needed to satisfy part of the precondition for S2 records the purpose of a step in the plan thick links S1 S2 c 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Links and Arcs: Types of Arcs Open precondition: doesn't have a causal link to it, so it's unsatisfied How is an open precondition p for step S solved? step addition: add new plan step R that contains p in its effects list simple establishment: find an existing plan step R prior to S that has p in its effects list then add a causal and ordering links from R to S To keep the search focused, the planner only adds steps that achieve an open precondition. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Links and Arcs: Plan-Space Search Links: within POP node Arcs: from POP node to POP node Start Finish Nodes are partial-order plans (POP) Add Buy(Cookies) Add Buy(Drill) Add Buy(Milk) Start Finish Buy(C) Start Finish Buy(M) Start Finish Buy(D) Arcs are plan modification operators -step addition Establish Add Buy(Cookies) Establish -simple establishment Start Finish Buy(C) Start Finish Buy(D) POP algorithm focuses on solving open preconditions Start Finish Buy(M) Buy(C) 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: Shopping Problem Start At(Home), Sells(GS, Cookies), Sells(GS, Milk), Sells(HWS, Drill) Plan Step Addition Buy(x): Pre: At(store) Ù Sells(store,x) Eff: Have(x) Buy(Cookies) Have(x) At(store), Sells(store, x) At(store), Sells(store, Cookies) Have(Cookies) Have(Cookies), Have(Milk), Have(Drill), At(Home) Finish 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: Shopping Problem Start At(Home), Sells(GS, Cookies), Sells(GS, Milk), Sells(HWS, Drill) Simple Establishment At(GS), Sells(GS, Cookies) At(store), Sells(store, Cookies) Buy(Cookies) Have(Cookies) Have(Cookies), Have(Milk), Have(Drill), At(Home) Finish 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: Shopping Problem Start At(Home), Sells(GS, Cookies), Sells(GS, Milk), Sells(HWS, Drill) Simple Establishment At(GS), Sells(GS, Cookies) At(store), Sells(store, Cookies) Buy(Cookies) Have(Cookies), Have(Milk), Have(Drill), At(Home) Finish Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: Shopping Problem Start At(Home), Sells(GS, Cookies), Sells(GS, Milk), Sells(HWS, Drill) At(GS), Sells(GS, Milk) Buy(Milk) At(HWS), Sells(HWS, Drill) Buy(Drill) Establish At(GS), Sells(GS, Cookies) Buy(Cookies) Add Step Have(Cookies), Have(Milk), Have(Drill), At(Home) Finish Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Finishing the Plan The algorithm is finished when every precondition in every step has a causal link to it. The algorithm fails if a precondition or an ordering constraint can’t be satisfied. e.g. due to inconsistency where S1 < S2 and S2 < S1 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: A Flawed Shopping Plan Start Plan Step Addition Go(there): Pre: At(here) Eff: At(there), ØAt(here) At(here) Go(GS) At(Home) Simple Establishment At(GS), Sells(GS, Cookies) Buy(Cookies) At(GS), Sells(GS, Milk) At(GS), Sells(GS, Milk) Buy(Milk) At(HWS), Sells(HWS, Drill) Buy(Drill) Finish Have(Cookies), Have(Milk), Have(Drill), At(Home) Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: A Flawed Shopping Plan Start Establish At(Home) At(here) Add Step Go(HWS) At(Home) Go(GS) At(GS), Sells(GS, Cookies) Buy(Cookies) At(GS), Sells(GS, Milk) Buy(Milk) At(HWS), Sells(HWS, Drill) Buy(Drill) Finish Have(Cookies), Have(Milk), Have(Drill), At(Home) Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: A Flawed Shopping Plan If Go(HWS) step goes first it deletes At(Home) clobbering the precondition required by Go(GS) and vice versa. Start Establish At(Home) At(here) Add Step Go(HWS) At(Home) Go(GS) At(GS), Sells(GS, Cookies) Buy(Cookies) At(GS), Sells(GS, Milk) Buy(Milk) At(HWS), Sells(HWS, Drill) Buy(Drill) How does algo handle this inconsistency? Requires modification. Finish Have(Cookies), Have(Milk), Have(Drill), At(Home) Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Threat Removal (Declobbering) Threat: a step that deletes (clobbers) a needed effect S2 requires an effect of S1 (i.e. there is a causal link between S1 and S2), but the effect of S3 is to undo the effect S2 requires Thus, S3 can’t occur between S1 and S2 it must occur either before S1 (promotion) add link S3 < S1 or after S2 (demotion) add link S2 < S3 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: A New Plan, A New Threat Could remove threat by going home after GS and then going to HWS, but we’ll do something different. Start At(GS) At(Home) Go(GS) At(Home) Go(HWS) At(GS), Sells(GS, Cookies) Buy(Cookies) At(GS), Sells(GS, Milk) Buy(Milk) At(HWS), Sells(HWS, Drill) Buy(Drill) Finish Have(Cookies), Have(Milk), Have(Drill), At(Home) Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: A New Plan, A New Threat This causes a threat that can be fixed by demotion . add ordering S2 < S3 This causes a threat Start At(Home) S1:Go(GS) At(GS) S3:Go(HWS) At(GS), Sells(GS, Cookies) At(GS), Sells(GS, Milk) Buy(Milk) At(HWS), Sells(HWS, Drill) Buy(Drill) S2:Buy(Cookies) Finish Have(Cookies), Have(Milk), Have(Drill), At(Home) Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: A New Plan, A New Threat Start Another demotion is needed: At(Home) S1:Go(GS) At(GS) S3:Go(HWS) At(GS), Sells(GS, Cookies) At(GS), Sells(GS, Milk) At(HWS), Sells(HWS, Drill) Buy(Drill) Buy(Cookies) S2: Buy(Milk) Finish Have(Cookies), Have(Milk), Have(Drill), At(Home) Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: Completing the Plan Solve the open precondition Start At(HWS), Sells(HWS, Drill) At(HWS) Have(Cookies), Have(Milk), Have(Drill), At(Home) which causes a threat fix by demotion At(Home) Go(GS) At(GS) Go(HWS) At(here) Go(Home) At(GS), Sells(GS, Cookies) Buy(Cookies) At(GS), Sells(GS, Milk) Buy(Milk) At(HWS), Sells(HWS, Drill) Buy(Drill) Have(Cookies), Have(Milk), Have(Drill), At(Home) Finish Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

Example: Final POP Plan go to GS, buy cookies and milk Start then go to HWS, buy drill then go home At(Home) Go(GS) At(GS) Go(HWS) At(here) Go(Home) At(HWS) At(GS), Sells(GS, Cookies) Buy(Cookies) At(GS), Sells(GS, Milk) Buy(Milk) At(HWS), Sells(HWS, Drill) Buy(Drill) Finish Have(Cookies), Have(Milk), Have(Drill), At(Home) Note: For readability, most temporal links and effects lists are NOT shown. 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

POP Algorithm: Method Header Plan pop (List initState, List goals, List ops) initState: list of facts composing the initial situation goals: list of goals that are assumed to be conjoined G1Ù..ÙGn ops: operator definitions (e.g. in STRIPS language) Plan: object containing the final partial-order plan steps: the plan's steps form arcs in plan-space search graph links: the plan's ordering and causal links 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

POP Algorithm: Main Steps Plan pop (List initState, List goals, List ops) { //construct the initial plan Start  Finish Plan plan = new Plan(initState, goals); while (true) { if (is_solution(plan)) return plan; //choose an open precondition, i.e. an unsolved subgoal OpenPC open = select_subgoal(plan); //find operator that solves subgoal and revise plan if (!choose_operator(plan, ops, open))return null; //fix any threats created by solving that subgoal if (!resolve_threats(plan))return null; } 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

POP Algorithm: Details //determines if the plan is a solution boolean is_solution (Plan plan) { if (all-preconditions-in-plan-established-by-causal-links && all-threats-resolved-in-plan && all-temporal-ordering-constraints-consistent-in-plan && all-variable-bindings-consistent-in-plan) return true; else return false; } //selects an open precondtion for some step OpenPC select_subgoal (Plan plan) { pick a plan step S-need from plan.steps with a precondition pc that has not been satisfied return new OpenPC(S-need, pc); 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

POP Algorithm: Details //solves open precondition for some step boolean choose_operator (Plan plan, List ops, OpenPC open) { choose a step S-add by either step_addition: add new step from ops having open.pc in its add-list simple_establishment: pick an existing step in plan.steps having open.pc in its add-list if (S-add can't be found) return false; //fail on open.pc plan.links.addCausalLink(S-add c open.S-need); plan.links.addOrderingLink(S-add < open.S-need); if (S-add new step) { plan.steps.addStep(S-add); plan.links.addOrderingLink(start < S-add); plan.links.addOrderingLink(S-add < finish); } return true; //plan successfully modified 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

POP Algorithm: Details //resolves threats by adding ordering constraints boolean resolve_threats (Plan plan) { foreach S-threat threatening causal link Sic Sj in plan.links { choose either: promotion: plan.links.addOrderingLink(S-threat < Si) demotion: plan.links.addOrderingLink(Sj < S-threat) if (!consistent(plan)) return false; //fail else return true; //threats cleared } 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Summary Planning agents search to find a sequence of actions to achieve a goal using a flexible representation of states, operators, goals, plans STRIPS language describes actions in terms of their preconditions and effects other more expressive languages exist, e.g. ADL It isn’t feasible to search through the entire space as was done with problem-solving search agents regression planning focuses the search STRIPS assumes sub-goals are independent POP uses Principle of Least Commitment, declobbering 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.

©2001-2004 James D. Skrentny from notes by C. Dyer, et. al. Summary POP algorithm is: sound: any total-order plan derived from the POP solves the planning problem complete: finds a solution to the planning problem when one exists See syllabus page for link to Solving Sussman Anomaly using POP 1/2/2019 ©2001-2004 James D. Skrentny from notes by C. Dyer, et. al.