This lecture was based on Elaine Rich and Kevin Knight, Artificial Intelligence
textbook. Exercise: compare goal-stack planning and regression planning from ...
Planning and Search
Classical Planning 2
Classical Planning 2
1
Outline ♦ Forward and backward search ♦ Search and planning again ♦ The role of deduction ♦ STRIPS planning algorithm: goal stack planning ♦ Example: Sussman anomaly
Classical Planning 2
2
Backward and forward search So far in the search lectures we only looked at forward search from the initial state to a goal state Nothing prevented us from searching from a goal state to the initial state Sometimes given the branching factor it is more efficient to search backward Motivating example: imagine trying to figure out how to get to some small place with few traffic connections from somewhere with a lot of traffic connections
Classical Planning 2
3
Example
Classical Planning 2
4
Example: backward search tree
Classical Planning 2
5
Backward search Can use any search method, breadth-first or depth-first or iterative deepening or A∗... If there are several goal states, search backwards from each in turn So, regression planning (working back from the goal) which I described in the previous lecture is not something specific to planning
Classical Planning 2
6
Search and planning again Planning is the process of computing several steps of a problem-solving procedure before executing any of them This problem can be solved by search The main difference between search and planning is the representation of states In search, states are represented as a single entity (which may be quite a complex object, but its internal structure is not used by the search algorithm) In planning, states have structured representations (collections of properties) which are used by the planning algorithm
Classical Planning 2
7
Use of logic and deduction In situation calculus (lecture 8), planning is deduction In ‘normal’ planning, we only need to check whether a state description entails some property: s |= P (A, B) ∧ ¬Q(A) for example In simple cases, like in the previous lecture, this just involves checking that P (A, B) is in the list of properties s has, and Q(A) is not (closed world assumption: if Q(A) is not listed, then ¬Q(A) must be true) However, often planning domains are described using additional axioms, and then checking s |= P (A, B) may involve more complex reasoning (whether P (A, B) follows from the description of s and the axioms).
Classical Planning 2
8
An example domain: the blocks world The domain consists of: 1. a table, a set of cubic blocks and a robot arm; 2. each block is either on the table or stacked on top of another block 3. the arm can pick up a block and move it to another position either on the table or on top of another block; 4. the arm can only pick up one block at time, so it cannot pick up a block which has another block on top. A goal is a request to build one or more stacks of blocks specified in terms of what blocks are on top of what other blocks.
Classical Planning 2
9
State descriptions Blocks are represented by constants A, B, C . . . etc. and an additional constant T able representing the table. The following predicates are used to describe states: On(b, x) block b is on x, where x is either another block or the table Clear(x) there is a clear space on x to hold a block
Classical Planning 2
10
Actions schemas Actions schemas: MOVE(b, x, y): Precond: Effect:
On(b, x) ∧ Clear(b) ∧ Clear(y) On(b, y) ∧ Clear(x)∧ ¬On(b, x) ∧ ¬Clear(y)
MOVE-TO-TABLE(b, x): Precond: On(b, x) ∧ Clear(b) Effect: On(b, Table) ∧ Clear(x) ∧ ¬On(b, x)
Classical Planning 2
11
Some problems with this formalisation There is nothing to stop the planner using the ‘wrong’ operator to put a block on the table, i.e. MOVE(b, x, Table) rather than MOVE-TO-TABLE(b, x) which results in a larger-than-necessary search space; and Some of the operator applications, such as MOVE(B, C, C), which should do nothing, have inconsistent effects To solve the first one, we could introduce predicate Block and make Block(x) and Block(y) preconditions of MOVE(x, y, z) To solve the second we could add ¬(y = z) as a precondition for MOVE(x, y, z)
Classical Planning 2
12
An example problem: Sussman anomaly A
B
C
B
A
C
Start
Goal
Initial state On(C, A) ∧ OnTable(A) ∧ OnTable(B) ∧ Clear(B) ∧ Clear(C) Goal On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
13
Goal stack planning One of the earlier planning algorithms called goal stack planning. It was used by STRIPS. We work backwards from the goal, looking for an operator which has one or more of the goal literals as one of its effects and then trying to satisfy the preconditions of the operator. The preconditions of the operator become subgoals that must be satisfied. We keep doing this until we reach the initial state. Goal stack planning uses a stack to hold goals and actions to satisfy the goals, and a knowledge base to hold the current state, action schemas and domain axioms Goal stack is like a node in a search tree; if there is a choice of action, we create branches
Classical Planning 2
14
Goal stack planning pseudocode Push the original goal on the stack. Repeat until the stack is empty: If stack top is a compound goal, push its unsatisfied subgoals on the stack. If stack top is a single unsatisfied goal, replace it by an action that makes it satisfied and push the action’s precondition on the stack. If stack top is an action, pop it from the stack, execute it and change the knowledge base by the action’s effects. If stack top is a satisfied goal, pop it from the stack.
Classical Planning 2
15
Goal stack planning 1 The order of subgoals is up to us; we could have put On(B, C) on top On(A, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
16
Goal stack planning 2 The action which would achieve On(A, B) goes on top: MOVE(A, x, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
17
Goal stack planning 3 On(A, T able) Clear(B) Clear(A) On(A, T able) ∧ Clear(A) ∧ Clear(B) MOVE(A, x, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
18
Goal stack planning 4 On(A, T able) and Clear(B) are true in the current state, so we pop them: Clear(A) On(A, T able) ∧ Clear(A) ∧ Clear(B) MOVE(A, T able, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
19
Goal stack planning 5 To achieve Clear(A), need to move C from A: MOVE-TO-TABLE(C, A) On(A, T able) ∧ Clear(A) ∧ Clear(B) MOVE(A, T able, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
20
Goal stack planning 6 Need to take care of preconditions of MOVE-TO-TABLE(C, A): On(C, A) Clear(C) On(C, A) ∧ Clear(C) MOVE-TO-TABLE(C, A) On(A, T able) ∧ Clear(A) ∧ Clear(B) MOVE(A, T able, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
21
Goal stack planning 7 They are true in the current state, so we pop them: MOVE-TO-TABLE(C, A) On(A, T able) ∧ Clear(A) ∧ Clear(B) MOVE(A, T able, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
22
Goal stack planning 8 Execute MOVE(A, T able, B): On(A, T able) ∧ Clear(A) ∧ Clear(B) MOVE(A, T able, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
23
Goal stack planning 9 pop On(A, T able) ∧ Clear(A) ∧ Clear(B) which became true: MOVE(A, T able, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C)
Classical Planning 2
24
Goal stack planning 10 execute MOVE(A, T able, B) On(B, C) OnTable(C) On(A, B) ∧ On(B, C) ∧ OnTable(C) the current state is
A B
C
Classical Planning 2
25
Goal stack planning 11 The plan so far is: MOVE-TO-TABLE(C, A) MOVE(A, T able, B)
Classical Planning 2
26
Goal stack planning 12 If we follow the same process for the On(B, C) goal, we end up in the state B C
A
On(B, C) ∧ OnTable(A) ∧ OnTable(C) The remaining goal on the stack, On(A, B) ∧ On(B, C) ∧ OnTable(C) is not satisfied. So On(A, B) will be pushed on the stack again.
Classical Planning 2
27
Goal stack planning 13 Now we finally can move A on top of B, but the resulting plan is redundant: MOVE-TO-TABLE(C, A) MOVE(A, T able, B) MOVE-TO-TABLE(A, B) MOVE(B, T able, C) MOVE(A, T able, B) There are techniques for ‘fixing’ inefficient plans (where something is done and then undone) but it is difficult in general (when it is not straight one after another)
Classical Planning 2
28
Why this is an instructive example Sussman anomaly (called ‘anomaly’ because it seemed to make sense for a conjunctive goals to first achieve one goal and then achieve another goal, and then the complete goal would be achieved) is instructive, because achieving one goal (On(A, B)) destroys preconditions of an action which is necessary to achieve the other goal (On(B, C)), namely Clear(B). Such interaction between actions is called clobbering More in the next lecture
Classical Planning 2
29
Next lecture Partial order planning This lecture was based on Elaine Rich and Kevin Knight, Artificial Intelligence textbook. Exercise: compare goal-stack planning and regression planning from lecture 9. What (if any) is the difference? Trace regression planning on the Sussman anomaly example. [This is equivalent to an exam question (25 marks). The exam will be 4 questions out of 6, and I will publish a mock exam by the weekend.]
Classical Planning 2
30
