Planning. Outline. Planning. Planning

Transcription

1 Planning Outline Jacky Baltes University of Manitoba urses/comp_4190-artificial-intelligence Reasoning about actions STRIPS representation Planning vs search Means-ends analysis Partial order planning Case-based planning Planning and execution Planning Planning Definition (Webster s) Method or procedure, esp. conceived beforehand, by which something is to be done goal oriented Most of human behavior is goal oriented General vs. special purpose planners Early research area in AI (GPS, 1969) You've seen planning problems many times e.g. the water-jugs problem way back in 319 A plan is a sequence of operators that, when applied or carried out, transforms a known world/state into some desired world/state In the real worlds, plans may be more or less detailed (e.g. a computer program vs. a blueprint vs. a recipe)

2 The Planning Problem Planning Representation Formally a planning algorithm has three inputs: A description of the world in some formal language, A description of the agent s goal in some formal language, and A description of the possible actions that can be performed. The planner s output is a sequence of actions which when executed in any world satisfying the initial state description will achieve the goal Synthesis problem: classification, synthesis, learning Consider the problem of being at home and deciding you needed a jug of milk, a bunch of bananas, and a drill What for? We can easily specify an initial state: at home with none of these objects Goal: at home with all of these objects Operations: everything the agent could do A Planner would take a formal description of these (e.g. in FOL) to allow the planner to make direct connections between states and actions Problems? Planning as Search Planning Representation Huge branching factor too many actions, too many states to consider more on this in a minute! Before we can even talk about using search, however How do we describe the world? e.g., this classroom,... How do we describe the goals? I want to be rich? How do we describe operators? Pick up the chair Changes in the world

3 Representing Change Approaches to Managing Change Our planning agent must have an internal model of how the world works, and how it's changes will affect it All the operations an agent can follow involve change across time e.g. buying bananas means having them, and having less money How can we represent this formally? Have a Non-Monotonic Knowledge base - that is, be able to delete facts as well as add them so as a result of a buying action, for example, we add having bananas, and retract having money The problem with this is that we need to reason about what was, and what will be too A strict non-monotonic knowledge base can't do this: we have just one single snapshot Representing States Explicitly Situation Calculus An alternative is to have many snapshots, not just one i.e. add info to each primitive: Have(Bananas,S5) I have bananas in state S5 One of the most common, and simplest, ways of managing change is the Situation Calculus Section 10.3 in text World is a sequence of situations Each is a snapshot frozen in time Each step we take causes a new snapshot We can have logical predicates that reason across situations (diachronic rules) e.g. forall X,S present(x,s) ^ portable(x) implies holding(x,result(grab,s)) Result is a function that generates a state (the result of the Grab action)

4 Situation Calculus State during execution of an action is unknown No multiple agents No duration of actions Another way: Fluents Reify predicates: loc, clear (holds clear(b) S) & (holds clear(l1) S) -> (holds loc(b L1) result(move(b L1) S) loc and clear are called fluents (functions that depend on state) Change in Situation Calculus More Representation Problems These are Effect Axioms: show what happens when we do something There is a representation problem associated with these: in any very complex world, we don't have the ability to detail every ramification of an action e.g. put an apple on the table e.g. put 5 tons of apples on the table ramification problem As often as not we care what is preserved as much as what is changed e.g. grab(bananas) means they're still edible, or that if we are holding something and we don't drop it, we're still holding it In fact, what doesn't change as the result of an action most stuff! A Frame Axiom is an axiom that we add to ensure that our representation states that something remains true after we perform some action

5 Frame Axioms Blocksworld These can get arbitrarily "silly" forall a,s currency(canada,$,s) ^ (A=grab) implies (currency(canada,$,(result(a,s))) We technically have an infinite number of such axioms in any real logical system The Frame Problem Several blocks on a table All blocks have the same size Robot arm can lift one block Table is infinitely large as opposed to qualification problem: Infinite exceptions to any clause e.g when grabbing bananas they stay edible unless we grab too hard, have poison on our hands, wear spiked gloves, Blocksworld Blocksworld General method for describing domains Effects of actions are dependent on the situation Predicate logic Add situation S (is-on B C) (move B L1 S1) -> (is-at B L1 next(s1)) (is-at B L1) How to describe actions? Use results of actions (loc B L1 result(move(b L1),S)) Predicates: move(b L1) -> (is-at B L1) move and result are functions But: move(b L1) & move(b L2) -> (is-at B L1) & (is-at B L2)

6 Frame/Ramification/Quantification Problem Frame problem: what does not change pickup dog How do we know that... did not change Ramification problem: what changes Put apple on table Put ton apple on table Qualification problem: list all preconditions have key ^ has_gas car --> car running unless... Better Planning Representations Recall looking at logic in 319 It's nice in that it's general, but it isn't always easy to say the things you want in a way that's simple to represent and easy to work with for a specific task So, for example, we move to rule-based systems for particular kinds of reasoning Planning is similar, we can develop more streamlined representations STRIPS Representation Representation for states and goals Reduced language Actions are represented as Preconditions: Effects conjunction of positive/negative literals conjunction of positive/negative literals Implemented as add and del lists In the STRIPS language, states are represented by conjunctions of function-free ground literals, that is, predicates applied to constant symbols, possibly negated. For example, At(Home)^ Have(Milk)^ Have(Bananas)^ Have(Drill)^. Goals are also described by conjunctions of literals. For example, At(Home)^Have(Milk)^ Have(Bananas)^ Have(Drill) Goals can also contain variables. For example, the goal of being at a store that sells milk would be represented as At($X) ^ Sells($X,Milk) No states associated with actions. Actions create new states from initial state

7 STRIPS representation Blocksworld Operators STRIPS assumption: Assume only predicates mentioned in the effects of operators are changed Closed world assumption: State contains all true predicates only Example: (is-on B table) (holding C) ~ (arm-empty) How many operators in the blocksworld domain? How do we represent them? Operators in the blocksworld Operators in the blocksworld Predicates: is-on, clear, arm-empty, holding Pickup Precondition: (clear $X) & (arm-empty) Effects: add (holding $X) Pickup ($X) Prec.: (is-on $X table) (arm-empty) (clear $X) Eff.: add (holding$x) UnStack($X $Y) Prec: (is-on $X $Y) (clear $X) (arm-empty) Eff: add (holding $X) del (arm-empty) Note that we have to add that whatever X was on is now clear but did we pick X up from the table, or from another block? Operator variables must be bound in order to use the operator or know if it is applicable in a specific case del (arm-empty) Putdown ($X) Prec.: (holding $X) Eff.: add (is-on $X table) add (arm-empty) del (holding $X) add (clear $Y) del (is-on $X $Y) del(arm-empty) Stack ($X $Y) Prec: (holding $X) (clear $Y) Eff:...

8 Blocksworld Operators Situation Space Planning Need four instead of two operators. Why? -(clear table) Why not add a rule (conditional effect) Stack($X, $Y) :- Effects: if ( $Y!= table ) del (clear $Y) No way to reason backwards from the action We could use this planning representation to deal with the blocks world problem Take the initial state and apply operators one at a time until we hit the goal state, using any standard search method This would be a situation space planner: it searches through the space of possible situations (graph node:state; arcs:operators) It would also be a Progression Planner because it reasons purely in a forward direction Search through World Space Search vs Planning The simplest way to build a planner is to cast the planning problem as search through the space of world states. Each node in the graph denotes a state of the world, and arcs connect worlds that can be reached by executing a single action. We would call it a situation space planner because it searches through the space of possible situations. There are two types of planners: Progression Planner: it searches forward from the initial situation to the goal situation. Forward chaining. Regression Planner: it searches backward from the goal situation to the initial situation. Backward chaining. Goal: get milk, bananas, and cordless drill Standard search techniques: DFS, BFS,...

9 Forward chaining From the initial state Apply operators whose preconditions are satisfied Generate new state Example: Buying coffee, cake, and ice-cream Start at home Actions with no bearing on the solution Forward Chaining Apply all possible operators to the current state Adventure game mentality Computational explosion 1st Insight: Goal: pass COMP_4190 State:... Operator: drink beer How does this accomplish the goal? Progression/Regression Planning Progression/Regression Planning The problem with progression planning is the high branching factor We can reduce it by starting at the goal: Regression planning In general there will be fewer ways to arrive at a goal immediately than places to go from an initial state Like other forms of backward reasoning, regression planning is naturally recursive: we have an action that will lead to a goal, and then plan to get to a state where that action can be achieved We have a stack of goals to achieve at any time (since solving one may only partially achieve the goal that it was ultimately adopted for, and so on up the stack) Whether we are progression or regression planning, one important technique used in planning is to reason about difference between the initial and goal states and reduce them: Means-Ends Analysis

10 Summary: Search in planners Planning can be represented as a search problem Simplest Nodes (World-states) Links: Application of an operator Planning can also be interpreted as a classification problem (reactive planning, situated activity) Summary: Representations for actions Our STRIPS operators consist of three components: the action description is what an agent actually returns to the environment in order to do something. the precondition is a conjunction of atoms (positive literals) that says what must be true before the operator can be applied. the effect of an operator is a conjunction of literals (positive or negative) that describes how the situation changes when the operator is applied. Here s an example for the operator for going from one place to another: Op(Action:Go(there), Precond:At(here)^Path(here, there), Effect:At(there)^ At(here)) Means ends analysis GPS (69) Ernst and Newell Based on analysis of human problem solving: Logic puzzles The idea is to compare the current state to the goal description and to compute the differences Pick a difference and an operator that reduces this difference Means ends analysis This operator may not be applicable (yet!) Example: B C Goal: (holding C) & (is-on B A) & (is-on A table)

11 Initial state: (is-on B C) (is-on A table) (arm-empty) Goal: (holding C) Differences(2) (holding C) (is-on B A) (holding C) Operators Pickup(C) UnStack(A C) UnStack(B C) UnStack(C C) Which one to choose? Pickup(C) Prec: clear(c) After 1 st Iteration We ve got something that will reduce one of our difference, but the goal still has other things that have to be achieved I now need to reason about how to reduce the differences between our initial state and that necessary to precede the pickup [clear(c)] subgoaling After nth iteration Eventually we have a sequence of actions that goes back to the initial state each of these may have other preconditions that have yet to be satisfied, but we have regressed back to the beginning based on minimizing differences we'd now need to minimize the other differences between the state preceding action 2 After nth iteration That is, our current state for reducing differences becomes the state preceding operator 2, and we examine the other differences between that and what 2 needs to achieve its effects i.e. our current state moves forward through the states created by the actions we've adopted

12 Problems We may get repeated states/goals as we proceed this way For example, we may need to provide condition A, adopt an action to do that, and then as planning ensues adopt an earlier action that undoes A as one of its consequences Essentially an infinite loop problem Means ends analysis Problem: State loops -> check for repeated state Goal loops: check for repeated goals Plan: Apply or Add operator Linear planning Sussman Anomaly (clear C) as new goal specification Assumption: Subgoals are independent Linear planner can not solve: Linear planning uses a stack of goals: only the unsatisfied preconditions of the recently added operator are used Call the planner recursively (is-on A B) & (is-on B C)

13 Non-linear planning Add unsatisfied preconditions and all open goals to the new goal descriptions Increases search space Can solve the Sussman anomaly Algorithm: Extended MEA (Prodigy) Terminate if the goal is satisfied in the current state Compute set of pending goals G and set of applicable operators A A goal is pending if it is an unsatisfied precondition in the current state of an operator in the tail An operator is applicable when all its preconditions are satisfied Choose a goal g from G or an operator a from A If g has been chosen: add an Operator o that can achieve g If a has been chosen: apply a, calculate new current state In contrast to standard MEA, pending operators are not ordered Apply or subgoal SAVTA Heuristic State determines if the goal has been reached which goals still need to be achieved which operators are applicable which operators to try first Two possibilities: SAVTA: Eager application SABA: Eager subgoaling Subgoal after every try to apply Eager state changes Assumption: Eager state changes may lead to more informed planning decisions State changes achieve goals for which they were selected State changes do not interfere with other goals

14 SABA Heuristic Select an operator to apply based on two constraints 1. Operator must not negate preconditions of other pending operators 2. No other operator should delete any effects of this operator Preference to condition 1 Comparison of planners 150 problems with different number of goals (1..15/10 each) Run problem on each planner and average results If there is no subgoal interaction all planners perform equally well Eager subgoaling can be better Paint domain: colors white, yellow,... black. One roller. Operator Ai Prec.: {I i } Eff: add {G i } del {I j for all i<j} Allow determination of subgoal interactions Eager applying can be better Paint domain: Use different brushes 1 to 8 Subgoaling attempts to reuse the same brush Fortuitous achieves parts of the goal One operator achieves the whole goal Operator selection Many possible operators achieve goal FLECS: Veloso (94) Intermediate heuristic

15 Moral of the story Partial order planning There is no single planning strategy that performs more efficiently than others for all problems or in all domains No general problem solver (GPS) Analyze conditions for planning strategies Learning conditions for planning strategies Planners that can use different strategies DoLittle (Baltes 1996): Combine different problem solving strategies on single problem Different sequences of the same operators Least commitment principle Sacerdoti (72) Noah, Chapman (87) Tweak Ordering of the operators Binding of variables No backtracking in Noah State space vs. Plan space Search through the Space of Plans Standard search: Each node represents a state Applying operators to move from one state to the next Plan space approach: Each node represents a possibly incomplete/faulty plan Apply changes to the plans to move from one state to the next (e.g., add operator, instantiate variable, reorder operators) Search through space of plans rather than space of situations i.e planspace node denote plans Start with a simple partial plan Expand the plan until the complete plan is developed Operators in this step: The solution: final plan Path to goal is irrelevant

16 Representation of Plans Partial Order Plans: Start Totally Order Plans: Start Start Start Start Start Start Consider a simple problem: Goal RightShoeOn ^ LeftShoeOn Four operators: Left Sock Left Shoe Left Shoe on Left Sock on Right Sock on Finish Right Sock Right Shoe Right Shoe on Right Sock Left Sock Right Shoe Left Shoe Right Sock Left Sock Left Sock Right Shoe Left Sock Right Sock Right Shoe Left Shoe Left Sock Right Sock Left Shoe Right Shoe Right Sock Right Shoe Left Sock Left Shoe Left Sock Left Shoe Right Sock Right Shoe Finish Finish Finish Finish Finish Finish Least Commitment Least Commitment One should make choices only about things that you currently care about,leaving the others to be worked out later. Partial Order Planner A planner that can represent plans in which some steps are ordered (before or after) w.r.t each other and other steps are unordered. Total Order Planner Planner in which plans consist of a simple lists of steps Linearization of P A totally ordered plan that is derived from a plan P by adding constraints Example Planning Domain

17 Towers of Hanoi Means-ends Analysis Objects: (Peg1,Peg2,Peg3, Small_D, Medium_D, Large_D) Predicates: (is-on $Disk_X $Peg_Y) order of disks is determined Operator Example: Move-Medium ($Peg_X $Peg_Y) Prec: ~ (is-on Small_D $Peg_X) ~ (is-on Small_D $Peg_Y) Eff: add (is-on Medium_D $Peg_Y) del (is-on Medium_D $Peg_X) Means-ends analysis sample problem Initial State: (is-on S P2)^(is-on M P1)^(is-on L P3) Goal: (is-on S P3)^(is-on M P1)^(is-on L P2) Trace the execution of linear MEA. Find optimal solution Show the current plan and the goal stack Identify all choice steps and list all alternatives Partial Solution Partial order planning Differences: (io S P3)^(io L P2). Choose goal Relevant operators: move-large(p1 P2), ml (P2 P2), ml (P3 P2) Add operator ml (P3 P2) to plan tail Precond of move-large(p3 P2) ~(io S P3)^ ~(io S P3)^ ~(io S P2)^ ~(io S P2) ~(io M P3)^~(io M P3)^~(io M P2)^~(io M P2) Differences: ~(io S P2) Relevant Operators: ms (P2 P1), ms (P2 P3) Precond: nil Apply or subgoal Apply or subgoal... Add operator ms(p1 P3) Apply or subgoal Plan I ml (P3 P2)->G I ms(p2 P1)-> ml(p3 P2)-> G I -> ms(p2 P1) -> ml (P3 P2) -> G I -> ms(p2 P1) -> ml (P3 P2) -> ms (P1 P3) -> G Problem

18 Partial order planning Planner chooses ordering of steps for no good reason Goals: Representation (P,A), where P is a precondition of A Plan to put on a pair of shoes (right one first?) Plans: Least commitment planning: Only make choices that are necessary. Delay other choices until later. Avoid backtracking! Same principle: fully instantiated vs. partially instantiated plans. Choice of variables Operators (Actions) Ordering constraints (A i < A j ) Causal links to record reasons for operators in the plan (A i, A j,p): A i achieves P for A j Causal links need to be protected from threats Partial order planning algorithm To start: create an empty plan to start Plans,Causal Links and Threats Loop: Pick an open goal (P,A y ) Try to find an existing action AX that achieves P Else create a new action AX that can precede A y Add ordering (A X < A Y ) Check for threats Promotion Demotion If A X is a new action, generate new goals for its preconditions Representing a Plan as a three tuple :-- <A,O,L> If A ={A1,A2,A3} then O might be set{a1<a3,a2<a3} These constraints specify a plan in which A3 is necessarily the last action but does not commit to a choice of which of the three actions comes first. As least commitment planners refine their plans, they must do constraint satisfaction to ensure consistency of O

19 Causal Links A Causal Links is written as S i -> S j and read as S i achieves c for S j Causal Links serve to record the purpose of steps in the plan:here a purpose of S i is to achieve the precondition c Example Problem of S j Threat Causal Links are used to detect when a newly introduced action interferes with past decision. Such an action is called a Threat. Let At be a different action in A : we say that A t threatens A p <- A c when the two criteria are met: Initial State and Goals of Operators Partial Order Plan Actions, Ordering, Links

20 Partial Order Planning Actions, Ordering, Links Partial Order Planning Actions, Ordering, Links Partial Order Planning Actions, Ordering, Links What constitutes a correct plan?

21 Why do we need an ordering? do we need an ordering? Must buy milk before going home Why Allow the other ordering Why do we need an ordering? do we need an ordering? Allow the other ordering Why Ordering resolves the threat

22 Plan Correctness Complete and Consistent Partial Order Planning Algorithm The algorithm can be derived from consistency and completeness Completeness achieve all preconditions Backward chaining from goal to initial state by inserting actions and causal links Must avoid intervening actions that threaten After adding an action, search for possible threats and introduce an ordering to resolve the threat Partial Order Planning Algorithm Backward Chaining Consistent Ordering must be consistent After each causal link and ordering is inserted, check for loops

23 Backward Chaining Backward Chaining Backward Chaining Threat Resolution

24 Promotion Demotion Example Problem Example Problem

25 Example Problem POP Planning Algorithm POP(<A,O,L>, agenda, actions) <A,O,L> a partial plan to expand Agenda: a queue of open conditions still to be satisfied: <p, a_need> Actions: a set of actions that may be introduced to meet needs a_add: an action that produces the needed condition for p for a_need a_threat: an action that may threaten a causal link from a_producer to a_consumer POP Planning Algorithm Initial: Sussman anomaly (again) (is-on C A),(is-on A table),(is-on B table) (clear B),(clear C) Goal: (is-on A B) (is-on B C)

26 Case-based planning Hammond s CHEF system (Szechuan cooking domain) Theory tells us that no matter what planning is a difficult problem. Instead of generating new plans from scratch, we should reuse as much as possible from previous plans. Instead, retrieve a previous plan and adapt it to the new situation Hash tables or discrimination nets CHEF algorithm Retrieve similar plan Domain dependent similarity measure (Goal and initial state Hash tables, discrimination net Superficially adapt the plan (replace objects) Simulate the plan and detect failures: why did an operator fail what goal was it trying to achieve Each failure is associated with a TOP CHEF TOP (Them. Organ. Packet) associate domain independent repair method anticipate failure learning from failure Repair strategies selected by TOPS CHEF Order of repairs depends on domain-dependent and independent control rules Adding a preparation step is easier than adding a cooking step Better to add single operator as opposed to a sequence of operators More expressive plan representation time, concurrent actions Objects have features (which can be changed) Ingredients and tools

27 Abstraction-based planning Tyranny of detail Example: Auckland - New York Create an abstract plan first, then refine later ABSTRIPS (Sacerdoti 1974) create abstract operators by dropping preconditions Each literal in the preconditions is assigned a criticality value TofH: Ignore position of smaller disks ABSTRIPS Hierarchy of problem spaces. Problem space at level i, ignore all predicates with criticality < i. Removal of preconditions leads to additional links between nodes in the world state Creation of abstraction levels User defined, system refined A literal that can not be affected by any operator (static literal)is at the highest criticality level If ABSTRIPS can find a short plan to achieve a precondition, given that the others are true, its criticality is given by the user If ABSTRIPS can not find a short plan, it gets a higher criticality value than any user defined one Reduced abstraction hierarchies Alpine (Knoblock 1991) Abstract problem spaces (goals, states, precond, effects) Dropping literals from the problem space Ordered monotonicity: A literal introduced at level i will not be changed by any lower level. TofH: (is-on Large Peg3), then during refinement, the Large disk can not be moved

28 Execution of Partial Order Plan Execution of Partial Order Plan Execution of Partial Order Plan Execution of Partial Order Plan

29 Execution of Partial Order Plan Execution of Partial Order Plan Execution of Partial Order Plan Execution of Partial Order Plan

30 Plan Execution Problem with Simple Planning Agent Classical Planning Real World World is totally accessible, deterministic, and completely closed - agent is omniscient all actions are complete and correct and all consequences of these actions are known World is inaccessible, nondeterministic, and open - impossible to know everything (Incomplete information) World does not necessarily match agent s model of it (Incorrect information) Anything can happen! How do we deal with this? What s the difference? Two ways of dealing with information that is incomplete or incorrect: Conditional (Contingency) Planning alternate plan for each contingency that could arise agent used sensing actions to test for appropriate conditions Execution Monitoring agent monitors what s happening while it s executing the plan agent sees what goes wrong and can then replan There is one main difference between conditional planning and execution monitoring: agent considers what might go wrong and plans for each contingency before hand. agent puts off dealing with problems until they actually arise

31 Conditional Planning Flat Tire Example A conditional planner: Goal: On(x) Inflated(x) Actions: deals with incorrect and incomplete information by making plans for each situation that might arise uses sensing actions to check the resulting situation and performs the corresponding plan Examples of sensing actions: Initial Conditions: Inflated(Spare) Intact(Spare) Off(Spare) On(Tire1) Flat(Tire1) Op(ACTION: PRECOND: EFFECT: Op(ACTION: PRECOND: EFFECT: Remove(x), On(x), Off(x) ClearHub(x) On(x)) PutOn(x), Off(x) ClearHub(x), On(x) ClearHub(x) Off(x)) CheckOn(Light) Op(ACTION: Inflate(x), CheckPrice(Milk) PRECOND: EFFECT: Intact(x) Flat(x), Inflated(x) Flat(x)) Plan: [Remove(Tire1), PutOn(Spare)] Flat Tire Example continued Is there an easier way? - inflate Tire1 instead of replacing it - Tire1 must be intact Need to add a conditional step: If(<Condition>, <ThenPart>, <ElsePart>) If(Intact(Tire1), [Inflate(Tire1)], [Remove(Tire1), PutOn(Spare)]) Sensing Actions The agent MUST be able to decide the truth or falsehood of a condition Sensing actions make facts known through percepts (eg. CheckTire(x)) Situation Calculus: x,s Tire(x) KnowsWhether( Intact(x), Result(CheckTire(x),s)) Action Schema: Op(ACTION: CheckTire(x), PRECOND:Tire(x), EFFECT: KnowsWhether( Intact(x) ))

32 Context CPOP Example the union of the conditions that must hold in order for the step to be executed describes the branch on which the step lies Example: Start On(Tire1) Flat(Tire1) Inflated(Spare) Check(Tire1) Intact(Tire1) Flat(Tire1) Intact(Tire1) Inflate(Tire1) (Intact(Tire1)) {x/tire1} On(x) Inflated(x) On(Tire1) Inflated(Tire1) Finish (True) The context of the action Inflate(Tire1) is Intact(Tire1). Inflate(Tire1) (Intact(Tire1)) CPOP Example CPOP Example Start On(Tire1) Flat(Tire1) Inflated(Spare) Check(Tire1) Intact(Tire1) Flat(Tire1) Intact(Tire1) Inflate(Tire1) (Intact(Tire1)) On(Tire1) Inflated(Tire1) Finish (Intact(Tire1)) Start On(Tire1) Flat(Tire1) Inflated(Spare) Check(Tire1) Intact(Tire1) Flat(Tire1) Intact(Tire1) Inflate(Tire1) (Intact(Tire1)) On(Tire1) Inflated(Tire1) Finish (Intact(Tire1)) {x/spare} Intact(Tire1) Remove(Tire1) (True) PutOn(Spare) (True) On(x) Inflated(x) On(Spare) Inflated(Spare) Finish ( Intact(Tire1)) Remove(Tire1) ( Intact(Tire1)) PutOn(Spare) ( Intact(Tire1)) On(Spare) Inflated(Spare) Finish ( Intact(Tire1))

33 Parameterized Plans Conditional steps can have more than two possible outcomes. eg. SenseTemperature(t) In this case, t is called a runtime variable because the value will not be known until the step is executed. A Simple Replanning Agent If an agent is in a closed world, it can deal with incomplete information. This is not the case in real domain. Execution Monitoring checks the remaining part of the plan to make sure no errors have occurred so far Action Monitoring check precondition of each action, rather than the entire remaining part of the plan Does not look ahead Detect changes in the world Action Monitoring Execution Monitoring Agent only checks the preconditions of the current step checks the preconditions protected by causal links that begin before or at the current state AND end at or after the current state Agent Checks: Example: s2 is the current state preconditions of s2 p2, p3 Example: s2 is the current state Agent Checks begin before or at cs (p1, p2, p3, p4, p5, p7) AND Links that: end at or after cs p2, p3, p4, p5, p7 Start p4 p5 s3 p6 p7 Finish Start p4 p5 s3 p6 p7 Finish p1 s1 p2 p3 s2 p1 s1 p2 p3 s2

34 Action Monitoring Action Monitoring Plan Execution with Action Monitoring Execution Monitoring

35 Execution Monitoring Plan Execution with Execution Monitoring Plan Execution with Execution Monitoring A Simple Replanning Agent Bounded indeterminacy: Action can have unexpected effects but can be enumerated eg. Open a can of paint having paint available having an empty can spilling the paint

36 A Simple Replanning Agent Simple Replanning with Execution Monitoring Unbounded indeterminacy: Set of possible unexpected outcome is too large Modified version of simple planning agent Complex and/or dynamic domain eg. Driving, economic planning, and military strategy Keep track of p, remaining plan, and q the complete plan Limit the plan and replan when encounter unexpected condition Fully Integrated Planning and Execution Situated Planning Agent Planner and Execution Monitor are a single process Agent can begin executing the plan before it is complete if independent subgoals are present Agent continuously monitors the world Execution monitoring & Replanning

37 Blocks World Example (1) Blocks World Example (2) Start Ontable(A) On(B,E) On(C,F) On(D,G) Clear(A) Clear(C) Clear(D) Clear(B) On(D,G) Clear(D) Clear(B) Move(D,B) On(C,F) Clear(C) Clear(D) Move(C,D) On(C,D) On(D,B) Finish Start Ontable(A) On(B,E) On(C,F) On(D,B) Clear(A) Clear(C) Clear(D) Clear(G) On(D,y) Clear(D) Clear(B) Move(D,B) On(C,F) Clear(C) Clear(D) Move(C,D) On(C,D) On(D,B) Finish B C D External agent moves D onto B D B C A E F G A E F G Blocks World Example (3) Blocks World Example (4) Open Condition! Start Ontable(A) On(B,E) On(C,F) On(D,B) Clear(A) Clear(C) Clear(D) Clear(G) On(C,F) Clear(C) Clear(D) Move(C,D) On(C,D) On(D,B) Finish Start Ontable(A) On(B,E) On(C,A) On(D,B) Clear(F) Clear(C) Clear(D) Clear(G) On(C,D) On(D,B) Finish Causal link is extended and redundant step is eliminated A D B E C F G Move(C,D) action fails because C accidentally drops onto A OOPS! C A D B E F G

38 Blocks World Example (5) Blocks World Example (6) Start Ontable(A) On(B,E) On(C,A) On(D,B) Clear(aF) Clear(C) Clear(D) Clear(G) On(C,A) Clear(C) Clear(D) Move(C,D) On(C,D) On(D,B) Finish Start Ontable(A) On(B,E) On(C,D) On(D,B) Clear(F) Clear(C) Clear(A) Clear(G) On(C,D) On(D,B) Finish Move(C,D) action is put back in to resolve open condition C A D B E F G We re done! A C D B E F G Comparing Conditional Planning & Replanning Summary Conditional Planning: Can have exponential conditions to plan for Impractical Replanning: Assume no action failure and fix it when problems occur Plans are fragile ; hard to fix if things go wrong eg. Spare tire (Conditional Planning) Ways that we can deal with incorrect or incomplete information: Conditional planning uses conditional steps and sensing actions to plan for each contingency Replanning can recover from execution error by checking preconditions and re-executing steps Fully integrated planning and execution allows the agent to remodel the plan during execution Coercion removes uncertainty by forcing the desired state Abstraction removes trivial details from the plan and looks at the bigger picture

39 References Russel and Norvig, AI, a modern approach, Chapter 11 (Planning) and 12 (Planning and acting) Craig Knoblock's PhD thesis (Alpine) Manuela Veloso (CMU) Marie desjardins (Lecture slides) Brian C. Williams (Lecture slides) MakingFall2003/0D0E3B6A-B A BD93A3D11/0/11partordplan.pdf