Planning Problem Solving  Planning –Action Centred –More flexible decision strategies A Representation for Planning –Add & Delete Lists Planning Techniques –Forward Search & Regression / Backward Chaining –Interaction Problems and Operator Conflicts –Partial Order Plans  Total Order Plans –Hierarchical Planning Memory-Based Paradigms –Case-Based Reasoning etc...

STRIPS Planning Plans can be represented as sequences of assertion additions and deletions. –On(x,y), On (x,Table) & Clear(z) C A B D Move Block A onto Block C from Block D Add: On(A,C) Delete : On(A,D) The BLOCKS World

C A B D Initial Situation Clear(A) Clear(D) On(A,C) On(C,Table) On(D,B) On(B,Table) CBDA Goal Situation To add the following to the situation description:- On(A,B) On(B,C) Note:- Don’t care where C or D end up!

To plan we need to to capture the preconditions and effects of various actions. We can use if-add-delete rules. For example, in our Blocks World... Operator 1: Move x from y to z If On(x,y)  Clear(x)  Clear(z) then Add: On(x,z)  Clear(y) Del: On(x,y)  Clear(z) Operator 2: Move x from y to Table If On(x,y)  Clear(x) then Add: On(x,Table),Clear(y) Del: On(x,y) Operator 3: Move x from Table to z If On(x,Table)  Clear(x)  Clear(z) then Add: On(x,z) Del: On(x,Table),Clear(z)

Planning By Searching Use a breadth-first search to reach the goal from the initial situation... On(A,Table) On(D,Table) On(B,C) On(A,B) On(A,D) On(D,Table)On(D,A) As usual we must contend with exponential tree growth - what would happen if more irrelevant blocks were added to the scene?

Regression Planning Progression Planning –Our search strategies search forward from the initial states to the goal states. Search back from the goal –Fewer goal states than initial states. Backward Chaining –Look for a match between an operator’s add pattern and the goal. –Then treat the any unsatisfied preconditions of this operator as new goals (actually these can be considered as subgoals) and continue backward chaining. Initial Goal

Initials On(A,C) Clear(A) On(D,B) Clear(D) On(C,Table) On(B,Table) If On(D,B) Clear(D) Add On(D,Table) Clear(B) Delete On(D,B) If On(A,C) Clear(A) Clear(B) Add On(A,B) Clear(C) Delete On(A,C) Clear(B) Goals: On(A,B) Initials On(A,C) Clear(A) On(D,B) Clear(D) On(C,Table) On(B,Table) If On(D,B) Clear(D) Add On(D,Table) Clear(B) Delete On(D,B) If On(A,C) Clear(A) Clear(B) Add On(A,B) Clear(C) Delete On(A,C) Clear(B) Goals: On(A,B) Initials On(A,C) Clear(A) On(D,B) Clear(D) On(C,Table) On(B,Table) If On(A,C) Clear(A) Clear(B) Add On(A,B) Clear(C) Delete On(A,C) Clear(B) Goals: On(A,B) Operator 1Operator 2 Operator 1Operator 2 Operator 1

“Establishes” Links The operator links are called establishes (or enabling) links. –E.g. Operator 1 establishes the assertion On(A,B) An establishes link means that the operator that establishes the assertion must appear in the final plan before the operator that requires the assertion. –E.g., Operator 2 must appear before operator 1. –The establisher does not have to appear immediately before the establishee however. –Other operators may be placed between the establisher and establishee. However care must be taken to ensure that none of these interposed operators deletes the established assertion.

Initials On(A,C) Clear(A) On(D,B) Clear(D) On(C,Table) On(B,Table) If On(D,B) Clear(D) Add On(D,Table) Clear(B) Delete On(D,B) If On(A,C) Clear(A) Clear(B) Add On(A,B) Clear(C) Delete On(A,C) Clear(B) Goals: On(A,B) On(B,C) Operator 1Operator 2 Initials On(A,C) Clear(A) On(D,B) Clear(D) On(C,Table) On(B,Table) Goals: On(A,B) On(B,C) If On(A,C) Clear(A) Clear(B) Add On(A,B) Clear(C) Delete On(A,C) Clear(B) Operator 1 If On(D,B) Clear(D) Add On(D,Table) Clear(B) Delete On(D,B) Operator 2 If On(B,Table) Clear(B) Clear(C) Add On(B,C) Delete On(B,Table) Clear(C) Operator 3 Threatens Tackle both goal assertions...

Conflict & Interactions Interaction Problems –Operators can conflict or interfere with each other. –In adding an assertion needed by one operator, you may withdraw an assertion that you had added previously to satisfy a goal or establish a precondition of another operator. Monitor the Establishes Links –Check for operators that invalidate these links. –If a conflict is found then an ordering constraint can be added to insure that the operator in question does no damage. For example… –Operator 1 poses a threat to the establishes link between operator 2 and operator 3. –The threatening operator must appear before the establisher or after the establishee but not between them.

If On(D,B) Clear(D) Add On(D,Table) Clear(B) Delete On(D,B) Operator 2 If On(A,C) Clear(A) Clear(B) Add On(A,B) Clear(C) Delete On(A,C) Clear(B) Operator 1 If On(B,Table) Clear(B) Clear(C) Add On(B,C) Delete On(B,Table) Clear(C) Operator 3 Before Scenario 1: Operator 1 appears before Operator 2 If On(D,B) Clear(D) Add On(D,Table) Clear(B) Delete On(D,B) Operator 2 If On(A,C) Clear(A) Clear(B) Add On(A,B) Clear(C) Delete On(A,C) Clear(B) Operator 1 If On(B,Table) Clear(B) Clear(C) Add On(B,C) Delete On(B,Table) Clear(C) Operator 3 Before Scenario 1: Operator 1 appears after Operator 3 Before cycles signal failure.

Initials On(A,C) Clear(A) On(D,B) Clear(D) On(C,Table) On(B,Table) Goals: On(A,B) On(B,C) If On(D,B) Clear(D) Add On(D,Table) Clear(B) Delete On(D,B) Operator 2a If On(B,Table) Clear(B) Clear(C) Add On(B,C) Delete On(B,Table) Clear(C) Operator 3b If On(A,C) Clear(A) Add On(A,Table) Clear(C) Delete On(A,C) Operator 2b If On(A,Table) Clear(A) Clear(B) Add On(A,B) Delete On(A,Table) Clear(B) Operator 3a Threatens Note : Threats do not signal failure. It may still be impossible to satisfy all of the ordering constraints imposed by the establishes and threat links.

Op 2b Op 3a Op 3b Op 2a In this new example Operator 3a threatens the link between Operator 2a and 3b. There are two options. Either 3a goes before 2a or after 3b. The former is impossible because 2a also establishes one of 3a’s preconditions. However the latter is possible and gives the following ordering network. This net represents a complete plan because every goal is satisfied, every precondition of every step has been met, and the implied before links are loop free (no cycles). A partial plan is any other plan in which the before links do not form a loop; for example some of the goals may not be satisfied or some operator preconditions may not be met. A total order plan is one where the ordering of steps has been determined as a linear sequence. A partial order plan specifies only some of these orderings. Plan 1 Op 2a Op 2b Op 3b Op 3a Plan 1 Op 2a Op 2b Op 3b Op 3a Plan 2 Op 2b Op 2a Op 3b Op 3a Plan 2 Op 2b Op 2a Op 3b Op 3a

Linearization A Basic Planning Strategy –Many planners construct plans by extending partial plans to form complete plans. –Ordering constraints are imposed during plan extension to limit conflicts. –Once a complete plan has been produced it is linearized to produce a total order plan. Partial Order Plan  Total Order Plan –Can we always produce a total order plan from a complete, partial order plan? –Yes, we can use a standard topological sorting algorithm.

Topological Sort TopologicalSort(G) While there exists a node, n, in G with no successors Remove n from G and add it to the end of a list L. End While If G is empty then Return the reverse of L Otherwise, report failure (graph had a cycle) A simple topological sorting procedure...

Planning Algorithm Planner(Initial, Goal, Operators) The initial plan contains no operators. Until a complete plan has been constructed If the plan has a before loop then announce failure. If there is an operator that threatens an Establishes link between operators o1 and o2, call the threat ot, and do one of the following:- Place a Before link between ot and o1. Place a Before link between o2 and ot. Otherwise, pick an unsatisfied precondition (subgoal) and do one of the following:- Find an existing operator (part of the current plan) that adds the unsatisfied precondition. Install an Establishes link. Instantiate and add a new operator that meets the precondition. Install the Establishes link. End Until

Partial Instantiation Even with backward chaining, large branching factors can occur unnecessarily. –Think about our options for placing block A while we put B onto C. –Block A can go on to the table or any other clear blocks that happen to be lying around. That is, there are potentially as many options as there are clear blocks, even though the placement chosen is not crtical to the plan (more or less). Partially Instantiate Operators –Only instantiate operators insofar as is necessary. Least Commitment Strategy –If there is uncertainty about what move is correct then commit to as little as possible. Search is not eliminated! –The branching factor is reduced however.

Suppose our example had a fifth clear block, E, and that we chose to move block A from a parking block to block B rather than from the table to B. This decision can lead to a decision about where to park A. If On(A,D) Clear(A) Clear(B) Add On(A,B) Clear(D) Delete On(A,D) Clear(B) Operator 1 (Full instantiation 1) If On(A,E) Clear(A) Clear(B) Add On(A,B) Clear(E) Delete On(A,E) Clear(B) Operator 1 (Full instantiation 2) Should A come from D or E? Instead partially instantiate Op 1 to cover both options. If On(A,y?) Clear(A) Clear(B) Add On(A,B) Clear(y?) Delete On(A,y?) Clear(B) Operator 1 (Partial Instantiation 1) We can regress directly from here to get A from block C again using a partial instantiation of Operator 1 If On(A,C) Clear(A) Clear(z?) Add On(A,z?) Clear(C) Delete On(A,C) Clear(z?) Operator 1 (Partial Instantiation 2) The thing is that we do not have to look for bindings for y? and z?. In this situation we need only insist that they are bound to the same thing.

Hierarchical Planning Hierarchical Decomposition –Many planners use hierarchical decomposition. –They use abstract planning operators which can be decomposed in to more detailed operators. –E.g. Build(House):- Obtain(Permit), Hire(Builder), Construct(House), : –Final solution plans contain only primitive operators. Necessary Extensions –Need to represent abstract planning operators. –Need to represent decomposition methods. –Need to extend out planning algorithms to facilitate the replacement of an abstract operator with its decomposition. } Decomposition of Build(House)

A Hierarchical Planner Primitive & Abstract Operators –Hammer(Nail) = Primitive –Build(House) = Abstract Decomposition Methods –Decomposition methods specify how an abstract operator decomposes into a plan of less abstract operators. Build House Obtain Permit Hire Builder ConstructBuild Interior Decomposes to

Conflict & Consistency Considerations –Decompose(o,p): Every effect of o must be asserted by at least one step of p (and must not be retracted by a later step). Every precondition of the steps in p must be achieved by a step in p or be one of the preconditions of o. –While these checks ensure that p is conflict free they do not remove the possibility of conflicts from newly added steps or interactions with later plan sections. Many different algorithms have been suggested. –The planner must not only find ways of achieving unsatisfied preconditions, it must also find ways of decomposing abstract operators. –Our planning algorithm can be modified so that during each iteration a decomposition is chosen as well as a precondition satisfied.

Desirable Properties Abstract Solution –A plan that contains abstract operators but which is consistent and complete. Downward Solution Property –If p is an abstract solution, then there is a primitive solution of which p is an abstraction. –If this holds then once an abstract solution is found we can prune away all other competing abstract plans for the search tree. Upward Solution Property –If an abstract plan is inconsistent, then there is no primitive solution of which it is an abstraction. –If this holds then we can prune away all the descendants of an inconsistent abstract plan. So hierarchical methods allow us to prune the search trees according to these ideas.

Reuse & Experience Search Intensive –Traditional planning & problem solving –Problems solve from scratch Remember the route planning problems... FA SR CG SC S LAR E W CS SG When trying to get from SG to CG would the fact that just yesterday you travelled from SG to SC affect your planning at all? It should!!!

Issues Reuse-Based Reasoning Techniques –Case-Based Reasoning & Derivational Analogy –Remember problem solving experience –Problems solved by reusing the solutions to previous (similar) problems –Knowledge Intensive Issues –Representing experience (as cases) –Retrieving similar problem solving episodes (cases) –Adapting similar solution of a retrieved case. Advantages –Efficiency –Knowledge engineering effort (cases are supposed easy to come by) –Cognitive Plausibility

Case-Based Reasoning Case Base Target Specification RetrievalAdaptation Solution ? …..... ….... …….. …..... ….... …….. Similar Case Modified Case Solution Learning

Basic Issues How to represent cases? –Case Solution: The actual problem solution which, if suitable,will be used to solve the new target problem. –Case Indices: (Descriptive Features) Used during retrieval to detect similarities between case solution and the target specification. Retrieval - When is a case similar/suitable? –Retrieval must be fast and accurate –Base Filtering: removes irrelevant cases quickly –Matching/Mapping & Ranking: locates a best case Heuristic Similarity, Preferences,... Adaptation –Types of Adaptation: Substitution, Structural –Diagnosis: What needs to be changed? –Modification: How can these changes be carried out?

PathFinder Route Planning –Each case corresponds to a previous route. –Cases (Generated by A* for example) Indexing –Index a case on its initial and final location or –Index a case on all locations in its solution route Retrieval –Cases that start (or end) at the initial target location. –Cases whose routes also lead in the direction of the final location. –Retrieve and reuse multiple cases. Adaptation –Remove parts of retrieved routes that wander away from, or overshoot, the final location. –Add new path segments to reach the final location by using traditional methods (e.g. A*)

Performance Issues –Search Time vs. Execution Time –Efficiency vs. Quality Increasing Case-Base Size –Increase likelihood of finding a good case. –Therefore, reduce amount of adaptation needed –Therefore, improve efficiency –Also reduce quality degradation so improve solution optimality –However, retrieval time is increased. The Utility Problem –Increasing case-base size can eventually lead to a decrease in problem solving efficiency!

Derivational Analogy CBR remembers the results of problem solving DA remembers the methods used during problem solving –Cases store derivational traces: step by step accounts of how a solution was produced in terms of decisions made, alternatives considered, justifications etc. Derivational Replay –Instead of adapting solutions according to the differences between the target and retrieved case scenarios, the derivational traces are replayed in the context of the target problem. –New decisions may be made if justifications no longer hold. –More sophisticated reuse possible. –Greater knowledge engineering effort.

Advanced Issues Partial Reuse of Multiple Cases –Representing, accessing, and reusing parts of cases. –Combining cases or parts of cases. –Hierarchical Case-Based Reasoning Improving Retrieval –Typically retrieval is based on some heuristic notion of similarity. –What about using adaptability? Retrieve case which can be adapted to the target. Retrieve a case that is the easiest to adapt –Adaptation-Guided Retrieval Uses adaptation knowledge during retrieval Case Learning –Learning the right cases. –Forgetting the right cases.