1. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

2. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

3. 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
© James D. Skrentny from notes by C. Dyer, et. al.

4. 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
© James D. Skrentny from notes by C. Dyer, et. al.

5. 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
© James D. Skrentny from notes by C. Dyer, et. al.

6. 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
© James D. Skrentny from notes by C. Dyer, et. al.

7. 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
© James D. Skrentny from notes by C. Dyer, et. al.

8. 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
© James D. Skrentny from notes by C. Dyer, et. al.

9. 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
© James D. Skrentny from notes by C. Dyer, et. al.

10. 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
© James D. Skrentny from notes by C. Dyer, et. al.

11. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

12. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

13. 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
© James D. Skrentny from notes by C. Dyer, et. al.

14. 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
© James D. Skrentny from notes by C. Dyer, et. al.

15. 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
© James D. Skrentny from notes by C. Dyer, et. al.

16. 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
© James D. Skrentny from notes by C. Dyer, et. al.

17. 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
© James D. Skrentny from notes by C. Dyer, et. al.

18. 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
© James D. Skrentny from notes by C. Dyer, et. al.

19. 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
© James D. Skrentny from notes by C. Dyer, et. al.

20. 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
© James D. Skrentny from notes by C. Dyer, et. al.

21. 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
© James D. Skrentny from notes by C. Dyer, et. al.

22. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

23. 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
© James D. Skrentny from notes by C. Dyer, et. al.

24. 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
© James D. Skrentny from notes by C. Dyer, et. al.

25. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

26. 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
© James D. Skrentny from notes by C. Dyer, et. al.

27. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

28. 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
© James D. Skrentny from notes by C. Dyer, et. al.

29. 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
© James D. Skrentny from notes by C. Dyer, et. al.

30. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

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

32. 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
© James D. Skrentny from notes by C. Dyer, et. al.

33. 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
© James D. Skrentny from notes by C. Dyer, et. al.

34. 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
© James D. Skrentny from notes by C. Dyer, et. al.

35. 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
© James D. Skrentny from notes by C. Dyer, et. al.

36. 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
© James D. Skrentny from notes by C. Dyer, et. al.

37. 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
© James D. Skrentny from notes by C. Dyer, et. al.

38. 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
© James D. Skrentny from notes by C. Dyer, et. al.

39. 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
© James D. Skrentny from notes by C. Dyer, et. al.

40. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

41. 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
© James D. Skrentny from notes by C. Dyer, et. al.

42. 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
© James D. Skrentny from notes by C. Dyer, et. al.

43. 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
© James D. Skrentny from notes by C. Dyer, et. al.

44. 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
© James D. Skrentny from notes by C. Dyer, et. al.

45. 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
© James D. Skrentny from notes by C. Dyer, et. al.

46. 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
© James D. Skrentny from notes by C. Dyer, et. al.

47. 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
© James D. Skrentny from notes by C. Dyer, et. al.

48. 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
© James D. Skrentny from notes by C. Dyer, et. al.

49. 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
© James D. Skrentny from notes by C. Dyer, et. al.

50. 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
© James D. Skrentny from notes by C. Dyer, et. al.

51. 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
© James D. Skrentny from notes by C. Dyer, et. al.

52. 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
© James D. Skrentny from notes by C. Dyer, et. al.

53. 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
© James D. Skrentny from notes by C. Dyer, et. al.

54. 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
© James D. Skrentny from notes by C. Dyer, et. al.

55. ©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
© James D. Skrentny from notes by C. Dyer, et. al.

56. ©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
© James D. Skrentny from notes by C. Dyer, et. al.