Planning & Acting Copyright, 1996 © Dale Carnegie & Associates, Inc. Chapter 13

CS 471/598 by H. Liu2 Some assumptions zThe world is accessible, static, deterministic. zAction description are correct & complete with exact stated consequences. zThe real world is not that perfect. So, how can we handle partially accessible, dynamic, non- deterministic world with incomplete information?

CS 471/598 by H. Liu3 zContingency yConditional planning ySensing actions zExecution monitoring ymonitoring what is happening while it executes the plan ytelling when things go wrong zReplanning yfinding a way to achieve its goals from the new situation

CS 471/598 by H. Liu4 Conditional planning zFixing a flat tire yActions: Remove(x), PutOn(x), Inflate(x) yGoal: On(x)^Inflated(x) yInitial conditions: Inflated(Sp)^Intact(Sp)^Off(Sp)^On(T1)^Flat^(T1) yPlan? zCan we have another (better) plan? yWhat if T1 is intact? yWhat if Sp is flat? y...

CS 471/598 by H. Liu5 zA conditional planning agent (Fig 13.1) yTo decide T/F of the condition - a sensing action CheckTire(x) yA conditional planner will sometimes create plans that involve carrying out ordinary actions for the purpose of obtaining some needed information. zGenerating conditional plans yThe flat-tire plan example yFrom a usual plan to a conditional plan

CS 471/598 by H. Liu6 yContexts - track which steps can establish or violate the precond’s of which other steps yConditional links yConditional steps yResolve threats by conditioning yCPOP - Fig 13.8

CS 471/598 by H. Liu7 Extending the plan language zA sensing action may have many outcomes. Goal: Color(Chair, c)^Color(Table,c) Plan: SenseC(T),KnowsC(“Color(T,c)”),GetPaint(c),Paint(C,c) yIt’s a parameterized plan as GetPaint & Paint are parameterized. yRuntime variables such as c whose value will not be known until execution yMaintenance goal: Maintain(Color(T,x)) - some control over which facts are changed and which are preserved. yLoop: While(Knows(‘UnevenC(Ch)’),[Paint(Ch,c),CheckC(Ch)])

CS 471/598 by H. Liu8 Replanning - sensing zIn reality, something can go wrong yannotate a plan at each step with preconditions required for successful completion of the remaining steps ydetect a potential failure by comparing the current preconditions with the state description from percepts yExecution monitoring - see what happens when executing a plan

CS 471/598 by H. Liu9 Sensing (2) zAction monitoring ycheck the preconditions of each action as it is executed rather than checking the preconditions of the entire remaining plan yno need for annotation ywork well with realistic systems (action failures) zAM is less effective than EM as it does not look ahead zAM is useful when a goal is serendipitously achieved.

CS 471/598 by H. Liu10 Anticipating the possible contingencies zBounded indeterminacy yunexpected effects can be enumerated yCPOP can handle it zUnbounded indeterminacy yIn complicated cases, no complete enumeration is possible yPlan for some contingencies yReplan for the rest

CS 471/598 by H. Liu11 Conditional planning with execution monitoring zKeep track of both the remaining plan segment (p) and the complete plan (q) zA replanning agent (Fig 13.9, p 402) yChoose-Best-Continuation(current,q) zExamples yunpainted small areas in chair painting yrun-out-of paint

CS 471/598 by H. Liu12 Difference between CP & RP zUnpainted area will make the agent to repaint until the chair is fully painted. zIs it different from the loop of repainting in conditional planning? zThe difference lies in the time at which the computation is done and the information is available to the computation process yCP - anticipates uneven paint yRP - monitors during execution

CS 471/598 by H. Liu13 Combining planning & execution zSituated planning agent yexecute some steps ready to be executed yrefine the plan to resolve standard deficiencies yrefine the plan with additional information yfix the plan according to unexpected changes xrecover from execution errors xremove steps that have been made redundant zGoal ->Partial Plan->Some actions-> Monitoring the world

CS 471/598 by H. Liu14 Revisit the blocks world zGoal: On(C,D)^On(D,B) zAction: Move(x,y) zOp(Act:Move(x,y), Pre:Clear(x)^Clear(y)^On(x,z), Eff:On(x,y)^Clear(x)^!Clear(y)^!On(x,z)^!Clear(y)) Fig 13.10

CS 471/598 by H. Liu15 Plan and execution zSteps in execution: yOrdering - Move(D,B), then Move(C,D) yAnother agent did Move(D,B) - change the plan yRemove the redundant step yMake a mistake, so On(C,A) xStill one open condition yPlanning one more time - Move(C,D) yFinal state: start -> finish

CS 471/598 by H. Liu16 Extensions zRecap some issues of situated planning yexplicit domain descriptions and goals ypartial-order planning yconditional planning, plan to ask for more info yplan fixing when errors occur

CS 471/598 by H. Liu17 CP and RP zConditional planning yThe number of possible conditions vs. the number of steps in the plan yOnly one set of conditions will occur zReplanning yFix problems as they arise during execution yFragile plans due to replanning zIntermediate planning between CP & RP yThe most likely ones done by CP yThe rest done by RP

CS 471/598 by H. Liu18 Coercion and abstraction zCoercion - forcing the state with unknown into a known state to reduce uncertainty yPaint Table and Chair together zAbstraction - ignore details until it’s necessary, another tool for least commitment yA travel case - Fly(Phoenix, NY) zAggregation - a form of abstraction, or summary yDealing with a large number of objects

CS 471/598 by H. Liu19 Summary zThe unexpected or unknown occurs zIn order to overcome that, we need CP or RP zThere exists incorrectness or incompleteness, we need to monitor the result of planning: execution or action monitoring zCP and RP are different and have different strengthnesses zReducing uncertainty via coercion, abstraction and aggregation