540 likes | 642 Vues
Explore the concept of partial order planners which avoid unnecessary ordering constraints, causal links, and threats in planning scenarios. Learn the components of plans and how to construct and execute them effectively. Dive into using the POP algorithm for plan construction and handling threats efficiently.
E N D
For Wednesday • Read chapter 12, sections 3-5 • Program 2 progress due
Program 2 • Any questions?
Plan-Space Planners • Planspace planners search through the space of partial plans, which are sets of actions that may not be totally ordered. • Partialorder planners are planbased and only introduce ordering constraints as necessary (least commitment) in order to avoid unnecessarily searching through the space of possible orderings
Partial Order Plan • Plan which does not specify unnecessary ordering. • Consider the problem of putting on your socks and shoes.
Plans • A plan is a three tuple <A, O, L> • A: A set of actions in the plan, {A1 ,A2 ,...An} • O: A set of ordering constraints on actions {Ai <Aj , Ak <Al ,...Am <An}. These must be consistent, i.e. there must be at least one total ordering of actions in A that satisfy all the constraints. • L: a set of causal links showing how actions support each other
Causal Links and Threats • A causal link, Ap®QAc, indicates that action Ap has an effect Q that achieves precondition Q for action Ac. • A threat, is an action A t that can render a causal link Ap®QAc ineffective because: • O È {AP < At < Ac} is consistent • At has ¬Q as an effect
Threat Removal • Threats must be removed to prevent a plan from failing • Demotion adds the constraint At < Ap to prevent clobbering, i.e. push the clobberer before the producer • Promotion adds the constraint Ac < At to prevent clobbering, i.e. push the clobberer after the consumer
Initial (Null) Plan • Initial plan has • A={ A0, A¥} • O={A0 < A¥} • L ={} • A0 (Start) has no preconditions but all facts in the initial state as effects. • A¥ (Finish) has the goal conditions as preconditions and no effects.
Example Op( Action: Go(there); Precond: At(here); Effects: At(there), ¬At(here) ) Op( Action: Buy(x), Precond: At(store), Sells(store,x); Effects: Have(x) ) • A0: • At(Home) Sells(SM,Banana) Sells(SM,Milk) Sells(HWS,Drill) • A¥ • Have(Drill) Have(Milk) Have(Banana) At(Home)
POP Algorithm • Stated as a nondeterministic algorithm where choices must be made. Various search methods can be used to explore the space of possible choices. • Maintains an agenda of goals that need to be supported by links, where an agenda element is a pair <Q,Ai> where Q is a precondition of Ai that needs supporting. • Initialize plan to null plan and agenda to conjunction of goals (preconditions of Finish). • Done when all preconditions of every action in plan are supported by causal links which are not threatened.
POP(<A,O,L>, agenda) 1) Termination: If agenda is empty, return <A,O,L>. Use topological sort to determine a totally ordered plan. 2) Goal Selection: Let <Q,Aneed> be a pair on the agenda 3) Action Selection: Let A add be a nondeterministically chosen action that adds Q. It can be an existing action in A or a new action. If there is no such action return failure. L’ = L È {Aadd®QAneed} O’ = O È {Aadd < Aneed} if Aadd is new then A’ = A È {Aadd} and O’=O’ È {A0 < Aadd <A¥} else A’ = A
4) Update goal set: Let agenda’= agenda - {<Q,Aneed>} If Aadd is new then for each conjunct Qi of its precondition, add <Qi , Aadd> to agenda’ 5) Causal link protection: For every action At that threatens a causal link Ap®QAc add an ordering constraint by choosing nondeterministically either (a) Demotion: Add At < Ap to O’ (b) Promotion: Add Ac < At to O’ If neither constraint is consistent then return failure. 6) Recurse: POP(<A’,O’,L’>, agenda’)
Example Op( Action: Go(there); Precond: At(here); Effects: At(there), ¬At(here) ) Op( Action: Buy(x), Precond: At(store), Sells(store,x); Effects: Have(x) ) • A0: • At(Home) Sells(SM,Banana) Sells(SM,Milk) Sells(HWS,Drill) • A¥ • Have(Drill) Have(Milk) Have(Banana) At(Home)
Example Steps • Add three buy actions to achieve the goals • Use initial state to achieve the Sells preconditions • Then add Go actions to achieve new pre-conditions
Handling Threat • Cannot resolve threat to At(Home) preconditions of both Go(HWS) and Go(SM). • Must backtrack to supporting At(x) precondition of Go(SM) from initial state At(Home) and support it instead from the At(HWS) effect of Go(HWS). • Since Go(SM) still threatens At(HWS) of Buy(Drill) must promote Go(SM) to come after Buy(Drill). Demotion is not possible due to causal link supporting At(HWS) precondition of Go(SM)
Example Continued • Add Go(Home) action to achieve At(Home) • Use At(SM) to achieve its precondition • Order it after Buy(Milk) and Buy(Banana) to resolve threats to At(SM)
GraphPlan • Alternative approach to plan construction • Uses STRIPS operators with some limitations • Conjunctive preconditions • No negated preconditions • No conditional effects • No universal effects
Planning Graph • Creates a graph of constraints on the plan • Then searches for the subgraph that constitutes the plan itself
Graph Form • Directed, leveled graph • 2 types of nodes: • Proposition: P • Action: A • 3 types of edges (between levels) • Precondition: P -> A • Add: A -> P • Delete: A -> P • Proposition and action levels alternate • Action level includes actions whose preconditions are satisfied in previous level plus no-op actions (to solve frame problem).
… … … Planning graph
Constructing the planning graph • Level P1: all literals from the initial state • Add an action in level Ai if all its preconditions are present in level Pi • Add a precondition in level Pi if it is the effect of some action in level Ai-1 (including no-ops) • Maintain a set of exclusion relations to eliminate incompatible propositions and actions (thus reducing the graph size)
Mutual Exclusion relations • Two actions (or literals) are mutually exclusive (mutex) at some stage if no valid plan could contain both. • Two actions are mutex if: • Interference: one clobbers others’ effect or precondition • Competing needs: mutex preconditions • Two propositions are mutex if: • All ways of achieving them are mutex
Mutual Exclusion relations Inconsistent Effects Interference (prec-effect) Competing Needs Inconsistent Support
Dinner Date example • Initial Conditions: (and (garbage) (cleanHands) (quiet)) • Goal: (and (dinner) (present) (not (garbage)) • Actions: • Cook :precondition (cleanHands) :effect (dinner) • Wrap :precondition (quiet) :effect (present) • Carry :precondition :effect (and (not (garbage)) (not (cleanHands)) • Dolly :precondition :effect (and (not (garbage)) (not (quiet)))
Observation 1 p ¬q ¬r p q ¬q ¬r p q ¬q r ¬r p q ¬q r ¬r A A A B B Propositions monotonically increase (always carried forward by no-ops)
Observation 2 p ¬q ¬r p q ¬q ¬r p q ¬q r ¬r p q ¬q r ¬r A A A B B Actions monotonically increase
Observation 3 p q r … p q r … p q r … A Proposition mutex relationships monotonically decrease
Observation 4 A A A p q r s … p q r s … p q r s … p q … B B B C C C Action mutex relationships monotonically decrease
Observation 5 Planning Graph ‘levels off’. • After some time k all levels are identical • Because it’s a finite space, the set of literals never decreases and mutexes don’t reappear.
Valid plan A valid plan is a planning graph where: • Actions at the same level don’t interfere • Each action’s preconditions are made true by the plan • Goals are satisfied
GraphPlan algorithm • Grow the planning graph (PG) until all goals are reachable and not mutex. (If PG levels off first, fail) • Search the PG for a valid plan • If none is found, add a level to the PG and try again
Searching for a solution plan • Backward chain on the planning graph • Achieve goals level by level • At level k, pick a subset of non-mutex actions to achieve current goals. Their preconditions become the goals for k-1 level. • Build goal subset by picking each goal and choosing an action to add. Use one already selected if possible. Do forward checking on remaining goals (backtrack if can’t pick non-mutex action)
Plan Graph Search • If goals are present & non-mutex: • Choose action to achieve each goal • Add preconditions to next goal set
Termination for unsolvable problems • Graphplan records (memoizes) sets of unsolvable goals: • U(i,t) = unsolvable goals at level i after stage t. • More efficient: early backtracking • Also provides necessary and sufficient conditions for termination: • Assume plan graph levels off at level n, stage t > n • If U(n, t-1) = U(n, t) then we know we’re in a loop and can terminate safely.
Dinner Date example • Initial Conditions: (and (garbage) (cleanHands) (quiet)) • Goal: (and (dinner) (present) (not (garbage)) • Actions: • Cook :precondition (cleanHands) :effect (dinner) • Wrap :precondition (quiet) :effect (present) • Carry :precondition :effect (and (not (garbage)) (not (cleanHands)) • Dolly :precondition :effect (and (not (garbage)) (not (quiet)))
Knowledge Representation • Issue of what to put in to the knowledge base. • What does an agent need to know? • How should that content be stored?
Knowledge Representation • NOT a solved problem • We have partial answers
Question 1 • How do I organize the knowledge I have?
Ontology • Basically a hierarchical organization of concepts. • Can be general or domain-specific.
Question 2 • How do I handle categories?
Do I need to? • What makes categories important?
Defining a category • Necessary and sufficient conditions
Think-Pair-Share • What is a chair?
In Logic • Are categories predicates or objects?