Planning Problem Solving Planning –Action Centred –More flexible decision strategies A Representation for Planning –Add & Delete Lists Planning Techniques

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

AB

D

Move Block A onto Block C from Block D Add : On(A,C) Delete : On(A,D)

The BLOCKS World

C

AB

D

Initial Situation

Clear(A)Clear(D)On(A,C)On(C,Table)On(D,B)On(B,Table)

C

BD

A

Goal Situation

To add the followingto 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

InitialsOn(A,C)Clear(A)On(D,B)Clear(D)On(C,Table)On(B,Table)

IfOn(D,B)Clear(D)

AddOn(D,Table)Clear(B)

DeleteOn(D,B)

IfOn(A,C)Clear(A)Clear(B)

AddOn(A,B)Clear(C)

DeleteOn(A,C)Clear(B)

Goals:On(A,B)


IfOn(D,B)Clear(D)


DeleteOn(D,B)


AddOn(A,B)Clear(C)


Goals:On(A,B)



AddOn(A,B)Clear(C)


Goals:On(A,B)

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.


IfOn(D,B)Clear(D)


DeleteOn(D,B)


AddOn(A,B)Clear(C)


Goals:On(A,B)On(B,C)





AddOn(A,B)Clear(C)


Operator 1

IfOn(D,B)Clear(D)


DeleteOn(D,B)

Operator 2

IfOn(B,Table)Clear(B)Clear(C)

AddOn(B,C)

DeleteOn(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.

IfOn(D,B)Clear(D)


DeleteOn(D,B)

Operator 2


AddOn(A,B)Clear(C)


Operator 1


AddOn(B,C)


Operator 3

Before

Before Before

Before

Scenario 1: Operator 1 appears before Operator 2

IfOn(D,B)Clear(D)


DeleteOn(D,B)

Operator 2


AddOn(A,B)Clear(C)


Operator 1


AddOn(B,C)


Operator 3

Before

Before Before

Before

Scenario 1: Operator 1 appears after Operator 3

Before cycles signal failure.



IfOn(D,B)Clear(D)


DeleteOn(D,B)

Operator 2a


AddOn(B,C)


Operator 3b

IfOn(A,C)Clear(A)

AddOn(A,Table)Clear(C)

DeleteOn(A,C)

Operator 2b

IfOn(A,Table)Clear(A)Clear(B)

AddOn(A,B)

DeleteOn(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 2aOp 2bOp 3bOp 3a

Plan 1

Op 2aOp 2bOp 3bOp 3a

Plan 2

Op 2bOp 2aOp 3bOp 3a

Plan 2

Op 2bOp 2aOp 3bOp 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 AlgorithmPlanner(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.

IfOn(A,D)Clear(A)Clear(B)

AddOn(A,B)Clear(D)

DeleteOn(A,D)Clear(B)

Operator 1 (Full instantiation 1)

IfOn(A,E)Clear(A)Clear(B)

AddOn(A,B)Clear(E)

DeleteOn(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.

IfOn(A,y?)Clear(A)Clear(B)

AddOn(A,B)Clear(y?)

DeleteOn(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

IfOn(A,C)Clear(A)Clear(z?)

AddOn(A,z?)Clear(C)

DeleteOn(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.

}Decompositionof 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.

BuildHouse

ObtainPermit

HireBuilder

Construct BuildInterior

Decomposes to

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

WCS

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

CaseBase Target

Specification

Retrieval Adaptation

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

• 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.

Documents

Planning Problem Solving Planning –Action Centred –More flexible decision strategies A Representation for Planning –Add & Delete Lists Planning Techniques