
71
We have seen relaxation before
 How does it apply to planning?
 How can we make the definition more precise?

Fundamental idea:
We have a
planning problem P
[domain + instance]
Solutions(P):
All plans
achieving the goal
We create another
planning problem P'
[change domain/instance]
Then P' is a relaxation of P
Solutions(P')
⊇ (include)
Solutions(P)
jonkv@ida
Relaxation in Planning (1)

72
Only preserving solutions matter
 If a plan [a1, a2, a3] was a solution for P, it must also be a solution for P'
 We have relaxed the constraints that a solution must satisfy
We have a
planning problem P
[domain + instance]
Solutions(P):
All plans
achieving the goal
We create another
planning problem P'
[change domain/instance]
Then P' is a relaxation of P
Solutions(P')
⊇ (include)
Solutions(P)
jonkv@ida
Relaxation in Planning (2)

A simple planning problem (domain + instance)
 Blocks world, 3 blocks
 Initially all blocks on the table
 Goal: (and (on B A) (on A C))
(only satisfied in s19)
 Solutions: All paths from init to goal (infinitely many – can have cycles)
Init
Goal
73
jonkv@ida
Relaxation Example: Basis

74
Relaxation 1: Adding goal states
 New goal formula: (and (on B A) (or (on A C) (on C B)))
▪ Relaxes constraints on which state a solution can "end" in
▪ All old solutions still valid, but new solutions may exist
▪ Retains the same states and transitions
Init
Goal
Goal
jonkv@ida
Relaxed Problem 1

75
Relaxation 2: Adding new actions to the domain
 Modifies the state transition system (states/actions)
▪ This particular example: shorter solution becomes possible
Init
Goal
on(B,A)
on(A,C)
jonkv@ida
Relaxed Problem 2

Essential:
 Must understand the fundamental concept:
relaxed problem = another problem that retains the "old" solutions
 Saying "relaxation = removing constraints" is incomplete
▪ Sounds like "relaxation = weaker action preconditions"
▪ There are many other relaxations, including adding new actions
You’ve seen relaxations adapted to the 8-puzzle
What can you do automatically,
independently of the planning domain used?
76
jonkv@ida
Relaxation: Important!

77
One domain-independent technique: delete relaxation
 Assume a classical problem with:
▪ Positive preconditions (no negations)
▪ Positive goals
▪ Both negative and positive effects
 Relaxation: remove all negative effects (all "delete effects")!
▪ (unstack ?x ?y) before transformation:
:precondition (and (handempty) (clear ?x) (on ?x ?y))
:effect
(and (not (handempty)) (holding ?x) (not (clear ?x)) (clear ?y)
(not (on ?x ?y)
)
▪ (unstack ?x ?y) after transformation:
:precondition (and (handempty) (clear ?x) (on ?x ?y))
:effect
(and (holding ?x) (clear ?y))
jonkv@ida
Delete Relaxation 1
State space: delete-relaxed problem
A
C B
ontable(B)
ontable(C)
clear(B)
A
clear(C)
holding(A) C B
Notice:
Transitions are
not added
but moved
(leading to
other states)!
on(A,C)
ontable(C)
clear(A)
holding(B) A
C
Every action applicable (or goal satisfied)
after unstack(A,C)
in the original problem…
B
A
C B
on(A,C)
ontable(B)
ontable(C)
clear(A)
clear(B)
clear(C)
holding(A)
handempty
on(A,C)
ontable(B)
ontable(C)
clear(A)
clear(B)
handempty
No physical
”meaning”!
State space: Original problem
on(A,C)
ontable(B)
ontable(C)
clear(A)
clear(B)
handempty
78
on(A,C)
ontable(B)
ontable(C)
clear(A)
clear(B)
holding(B)
handempty
…is applicable (satisfied)
after unstack(A,C) here –
we assumed positive preconds/goals!
jonkv@ida
Delete Relaxation 2: Example
79
5 states
8 transitions
25 states
210 transitions
jonkv@ida
Delete Relaxation 3: Blocks World, 2 blocks

Comments:
 Yes, delete relaxation has strange effects on the state space…
▪ Can increase the number of states
▪ Leads to states that cannot occur in reality
▪ Hold multiple blocks
▪ Blocks are on the table and on other blocks simultaneously
▪ …
 This is not a problem
▪ All we need is for solutions to be preserved – and they are!
▪ Delete relaxation can "compensate"
by increasing the number of reachable goal states,
or making it easier to find a way there!
▪ For example: There are no dead ends
(which there could be in the original problem: crack-egg(e2))
80
jonkv@ida
Delete Relaxation 4: Comments

But when is relaxation useful?
 Suppose we want an admissible heuristic h(s)
▪ Never overestimating real costs:
In every world state s,
h(s) ≤ the cost of an optimal plan starting in state s
 We want some estimate that cannot exceed the cost of an optimal plan…
An optimal solution for a relaxed problem
can never be more expensive
than an optimal solution for the original problem…
but it can be easier to solve the relaxed problem!
Suppose the cost of an optimal solution for P is 8.
Suppose the cost of an optimal solution for P' is greater: 9.
This can't happen, because the optimal solution for P also solves P'…
81
jonkv@ida
Delete Relaxation 5: Why?

82
Gives us the optimal delete relaxation heuristic, h+(s)
 We started in some state – say s0
 We expanded new states – say s1, s2
 To find h+(s1):
▪ Apply delete relaxation
▪ Find an optimal path from s1 to a goal state
in the delete-relaxed problem –
faster than solving the real problem
▪ h+(s1) = Calculate the length
of this optimal path
 To find h+(s2):
▪ As above, for s2
Finding an optimal path still requires (a limited form of) planning!
Calculating h+(n) still takes too much time  will relax more (soon)…
jonkv@ida
Delete Relaxation 6: Heuristic

83
Important:
You cannot “use a relaxed problem as a heuristic”.
What would that mean? The problem is not a number or function…
You use the cost of an optimal solution to the relaxed problem as a heuristic.
If you just take the cost of "a solution" to the relaxed problem,
it can be inadmissible!
You have to solve it optimally to get the admissibility guarantee.
You don’t just solve the relaxed problem once.
Every time you reach a new state and want to calculate a heuristic,
you have to solve the relaxed problem
of getting from that state to the goal.
"Delete relaxation" does not mean "remove the relaxation"
jonkv@ida
Important Issues
The h1 Heuristic

85
We need a “faster” heuristic!
 How about relaxing h+ further?
h+(n) (optimal delete relaxation):
Remove delete effects,
find a long plan achieving all goals
h1(n), approximately:
Find a separate plan for each goal fact,
in a way that still ignores delete effects
Take the maximum of their costs
g1
Size: Grows
quickly with
plan length
g2
g3
Much easier/faster,
since search trees tend to branch out!
Example: Branching factor 6, depth 20
∗
(and g1 g2 g3 g4)
g4
jonkv@ida
The h1 Heuristic
Goal:
86
clear(A)
on(A,B)
on(B,C)
ontable(C)
clear(D)
ontable(D)
Done: cost 0
cost 2
cost 2
cost 0
cost 0
cost 0
1 for the action
1 for the most costly precond
Must use stack(A,B)
holding(A)
clear(B)
cost 1
cost 0
Preconditions handled
separately, like goals!
stack(B,C)
holding(B)
clear(C)
cost 1
A
B
C
D
h1(s0) =
max(2,2) =
2
cost 1
Could use unstack(A,C)
handempty
clear(A)
on(A,C)
cost 0
cost 0
Cheaper!
Could use unstack(A,D)
handempty
clear(A)
on(A,D)
We discover this is expensive…
cost 0
pickup(B)
handempty
clear(B)
cost 0
cost 0
unstack(A,C)
handempty
clear(A)
on(A,C)
A
C B D
s0: clear(A), on(A,C), ontable(C), clear(B), ontable(B), clear(D), ontable(D), handempty
jonkv@ida
The h1 Heuristic: Example
on(B,C)
cost 2
This is why it is fast!
No need to consider interactions
 no combinatorial explosion
Can generalize,
consider all pairs of goals/preconds
Yields the h2 heuristic,
more powerful, still reasonably fast
87
Each goal considered
separately!
A
B
C
stack(B,C)
holding(B)
clear(C)
cost 1
cost 1
pickup(B)
handempty
clear(B)
cost 0
cost 0
unstack(A,C)
handempty
clear(A)
D
Each precondition
considered separately!
Each precondition
considered separately!
on(A,C)
jonkv@ida
The h1 Heuristic: Important Property

88
Given an admissible heuristic, we often use A* (not always)
 Guarantees optimal plans, just like Dijkstra

Comparison:
 Let len(p) be the number of actions in plan p
 Let h(p) be an admissible heuristic (applied to the final state of plan p)
 Blocks world, 400 blocks initially on the table, goal is a 400-block tower
▪ 399 blocks to pick up and stack
▪ Dijkstra considers plans where len(p)
<= 798
▪ A*
considers plans where len(p) + h(p) <= 798
Explored by Dijkstra,
not by A*
len(p)=400
h(p)=398
len(p)=401
h(p)=398
len(p)=401
h(p)=397
jonkv@ida
Search Strategies for Admissible Heuristics

89
Admissible heuristics:
 Must never overestimate
 To guarantee this, they often underestimate (by a large margin)!
Example: h1 -- could have hundreds of goals…
Goal:
clear(A)
on(A,B)
on(B,C)
ontable(C)
clear(D)
ontable(D)
cost 3
cost 2
cost 2
cost 1
cost 4
cost 1
…but we can only ”count” the most expensive one!
Achieving clear(D) seems exactly as expensive
as achieving all of the goals above
Stronger:
considers pairs of goal facts
There are many stronger admissible heuristics (TDDD48)!
But sometimes we don't need admissibility…
jonkv@ida
Admissible Heuristics
Non-admissible Heuristics for Non-Optimal
Forward State Space Planning

When do we need admissibility?

If we must guarantee optimal plans:
 Need optimal search strategies such as A*
 Must use admissible heuristics – or we may get suboptimal plans

If we are satisfied with a high-quality plan:
 Satisficing planning
▪ Find a plan that is sufficiently good, sufficiently quickly
 Can use non-admissible heuristics
▪ …which can often be more informative
(give us more help in finding reasonably good alternatives)
 Generally much faster
▪  Handles more complex domains, larger problem instances
91
jonkv@ida
Optimal and Satisficing Planning
Goal:
 §
clear(A)
on(A,B)
on(B,C)
ontable(C)
clear(D)
ontable(D)
Lowest
cost: 0
cost 2
cost 3
cost 0
cost 0
cost 0
1 for the stack action
2 for the sum of preconds
stack(A,B)
holding(A)
clear(B)
cost 1
92
cost 1
D
hadd(s0):
2+3=5
stack(B,C)
holding(B)
clear(C)
cost 0
A
B
C
max  sum
cost 1
pickup(A)
handempty
clear(A)
cost 0
cost 0
Cheaper!
unstack(A,D)
handempty
clear(A)
on(A,D)
Turns out to be expensive…
pickup(B)
handempty
clear(B)
cost 0
cost 0
unstack(A,C)
handempty
clear(A)
jonkv@ida
hadd: Use sum instead of maximum
on(A,C)
A
C B D
s0: clear(A), on(A,C), ontable(C), clear(B), ontable(B), clear(D), ontable(D), handempty

The hadd heuristic:
 Can under- and over-estimate: Not admissible!
▪ The same action can be counted twice
▪ Can miss the opportunity to achieve two goals with one action
Goal:
clear(A)
clear(B)
clear(C)
clear(D)
cost 0
cost 1
cost 1
cost 1
unstack(A,B)
unstack(H,C)
unstack(P,D)
…but we could have used a single
tearDownAllTowers action!
 But: Retains much more information
▪ Example: Every unsatisfied goal contributes to the heuristic value
on(A,B)
cost 2
on(B,C)
+
cost 3
=5
93
jonkv@ida
The hadd Heuristic: Properties

94
Which search algorithm to use?
 A* expands many nodes (expensive),
and for hadd, there is still no optimality guarantee!
 HSP planner, and some others, use Hill Climbing
Successors: States created
by applying an action to
the current state
Value: Calculated as –hadd
(maximize –hadd  minimize +hadd)
Only considers children of the current node
 tries to move quickly towards low heuristic values
 doesn’t examine ”all nodes” with len(p)+f(p) <= some value
jonkv@ida
Search Algorithms for hadd

Problem:
95
Can end up in a local maximum
(where h() is locally minimal)
This is not ”good enough”:
The goal is not satisfied!
Possible solution:
Restart search from another expanded state
jonkv@ida
Local Optima in Planning
96
Init
Local
Optimum
on(B,A)
on(A,C)
Goal
Restart in any of the gray nodes
jonkv@ida
Local Optima: Restarting

97
Forward State Space Search:
 Very common planning method
 Many heuristic functions defined
▪ TDDC17: Focus on understanding the basics,
and general principles for defining general heuristics
without knowing the problem to be solved (blocks, helicopters, …)
▪ TDDD48: Many additional heuristics (and principles for creating them)
 Many search strategies defined
▪ TDDC17: Focus on applying standard strategies from general search
▪ TDDD48: Many additional planning-inspired strategies
and their relations to specific heuristic functions
jonkv@ida
Summary of Forward Search
99
If we are here
initial
We’ve seen
state space search
in this direction:
What can the next
action be?
Forward search,
initial  goal
Where do we end up?
goal
goal
goal
Known initial state
Deterministic actions
 Every node corresponds to one well-defined state
jonkv@ida
Repetition: Forward State Space Search

100
jonkv@ida
Backward Search
Classical Planning: Find a path in a finite graph
initial
Where would we
have to be before?
What about
this direction:
Backward,
goal  initial?
What can the previous
action be?
goal
goal
goal
If we want to be here
Forward search uses applicable / executable actions
Backward search uses relevant actions:
Must achieve some requirement, must not contradict any requirement
What
stack(A,B)
needs
—————
What the goal
needs, but
stack(A,B) did
not achieve
We want to achieve:
holding(A)
clear(B)
—————
ontable(C)
ontable(D)
…
101
We want
to achieve
this…
A
B
C
D
jonkv@ida
Backward Search: Intuitions
We want to achieve:
holding(A)
clear(B)
—————
ontable(C)
ontable(D)
…
We want to achieve:
holding(D)
—————
ontable(C)
ontable(D)
…
102
We want
to achieve
this…
A
B
C
D
jonkv@ida
Backward Search: Intuitions (2)

Classical planning:
 Given a known state, applying an action gives single possible result
at(home)
drive-to(shop)
at(shop)
 Given an action and a desired result, there can be
many possible starting states
at(home)
at(work)
at(restaurant)
drive-to(shop)
at(shop)
103
jonkv@ida
Backward and Forward: Asymmetric!
Intuitive successor node:
Before:
Must be holding A
B must be clear
…
stack(A,B) is relevant:
It could be the last action
in a plan achieving this goal…
Formal successor node:
clear(B), on(B,C), ontable(C)
clear(D), ontable(D)
holding(A)
104
jonkv@ida
Backward Search: More Details
Intuitive goal:
A
B
C
D
Formal goal:
Applying stack(A,B) here
leads to the goal state
Suppose there is a
single goal state:
clear(B), on(B,C), ontable(C)
clear(D), ontable(D)
holding(A), handempty
Applying stack(A,B) here
leads to the goal state
sg = { clear(A), on(A,B),
on(B,C), ontable(C),
clear(D), ontable(D),
handempty }
clear(B), on(B,C), ontable(C)
clear(D), ontable(D)
holding(A), on(A,B)
Applying stack(A,B) here
leads to the goal state
So: Every node must correspond to many possible states!
105
Using arbitrary sets of goal states is too expensive!
Use the classical goal representation!
The (sub)goal of a search node is an arbitrary set of ground goal literals (positive/negative facts):
g = { in(c1,p3), …, in(c5,p3), ¬on(A,B) }
Works for:
Classical goals (already sets of ground literals)
Classical effects (conjunction of literals)
Classical preconditions (conjunction of literals)
Suppose you execute action a to reach goal g.
Then the goal to achieve before a is:
(g – effects(a)) ∪ precond(a).
What the goal needs, but the
action won't achieve
What the action
needs
jonkv@ida
Classical Representation
106
Regression Example: Classical Representation
on(B,C)
clear(B)
clear(A)
ontable(A)
handempty
on(B,C)
holding(A)
clear(B)
on(B,C)
on (A B)
clear(A)
handempty
Initial state:
on(A,C)
clear(A)
ontable(B)
clear(B)
ontable(C)
clear(D)
ontable(D) handempty
Relevant:
Achieves
on(A,B), does
not delete
any goal fact
(g – effects(a))
on(A,B)
precond(a)
holding(B)
clear(C)
The goal is
not
already
achieved…
Goal:
on(A,B)
on(B,C)
Relevant:
Achieves
on(B,C), does
not delete
any goal fact
Represents
many
possible
goal states!
jonkv@ida
Regression
Forward search
…
107
Backward search
…
I can reach this node
from the initial state…
But what comes next?
Can I reach the goal?
Efficiently?
on(B,C)
clear(B)
on(A,B)
clear(A)
handempty
I can reach the goal
from this node…
But what comes before?
Can I reach it from s0?
Efficiently?
on(A,B)
on(B,C)
jonkv@ida
Backward and Forward Search: Unknowns
FORWARD SEARCH

Problematic when:
 There are many applicable actions
 high branching factor
 need guidance
 Blind search knows
if an action is applicable,
but not if it will contribute
to the goal
108
BACKWARD SEARCH

Problematic when:
 There are many relevant actions
 high branching factor
 need guidance
 Blind search knows
if an action contributes to the goal,
but not if you can achieve its
preconditions
Blind backward search
is generally better than blind forward search:
Relevance tends to provide better guidance than applicability
This in itself is not enough to generate plans quickly: We still need heuristics!
jonkv@ida
Backward and Forward Search: Problems

Just because we are looking for a path in this graph…

…doesn’t mean we have to use it as a search space!
What if a search step could insert actions anywhere in a plan?
110
jonkv@ida
Plan-Space Search

111
Idea: Partial Order Causal Link (POCL) planning
 As in backward search:
▪ Add useful actions to achieve necessary conditions
▪ Keep track of what remains to be achieved
 But use a partial order for actions!
▪ Insert actions ”at any point” in a plan
▪ Least/late commitment to ordering – "don't decide until you have to"
We have:
robotat(A)
at(c1,A)
at(c2,A)
pickup(c1,A)
pickup(c2,A)
drive(A,B)
put(c1, B)
put(c2, B)
More sophisticated ”bookkeeping” required!
We want:
at(c1,B)
at(c2,B)
jonkv@ida
POCL 1: Intuitions
How to keep track of initial state and goal?
initaction
A ”fake” initial action,
whose effects are
the facts of the initial
state
A ”fake” goal action,
whose preconditions are
the conjunctive goal facts
clear(A)
clear(A)
ontable(A)
on(A,B)
clear(B)
on(B,C)
ontable(B)
clear(C)
on(C,D)
on(C,D)
ontable(D)
ontable(D)
handempty
handempty
Streamlines the planner: Initial state and action effects are handled equivalently
goal and action preconditions are handled equivalently.
goalaction

112
jonkv@ida
Partial-Order Planning
No sequence  must have explicit precedence constraints
initaction
A ”fake” initial action,
whose effects are
the facts of the initial
state
A ”fake” goal action,
whose preconditions are
the conjunctive goal facts
clear(A)
clear(A)
ontable(A)
on(A,B)
clear(B)
on(B,C)
ontable(B)
clear(C)
on(C,D)
on(C,D)
ontable(D)
ontable(D)
handempty
handempty
initaction happens before goalaction
goalaction

113
jonkv@ida
Partial-Order Planning
No current state – how to keep track of what remains to do?
initaction
A ”fake” initial action,
whose effects are
the facts of the initial
state
A ”fake” goal action,
whose preconditions are
the conjunctive goal facts
clear(A)
clear(A)
ontable(A)
on(A,B)
clear(B)
on(B,C)
ontable(B)
clear(C)
on(C,D)
ontable(D)
handempty
A set of flaws!
First type: Open goals
to be achieved
on(C,D)
ontable(D)
handempty
goalaction

114
jonkv@ida
Partial-Order Planning
115
To resolve an open goal:
initaction
Alternative 1:
Add a causal link
from an action
that already achieves it
Causal link:
1) "initaction causes (achieves) clear(A) for goalaction"
2) "From the start of the link until its end,
the property [clear(A)] will be true!"
clear(A)
clear(A)
ontable(A)
on(A,B)
clear(B)
on(B,C)
ontable(B)
clear(C)
on(C,D)
on(C,D)
ontable(D)
ontable(D)
handempty
handempty
goalaction

jonkv@ida
Resolving Open Goals 1
To resolve an open goal:
ontable(A)
initaction
clear(B)
ontable(B)
¬holding(A)
clear(B)
¬clear(B)
on(A,B)
Alternative 2:
Add a new action
with the open goal
as an effect
clear(A)
on(A,B)
handempty
on(B,C)
clear(A)
clear(C)
on(C,D)
on(C,D)
ontable(D)
ontable(D)
handempty
handempty
goalaction
clear(A)
holding(A)
stack(A,B)

116
jonkv@ida
Resolving Open Goals 2
Some pairs of actions can remain unordered
holding(A)
¬holding(A)
clear(B)
¬clear(B)
ontable(A)
clear(A)
on(A,B)
handempty
on(B,C)
clear(A)
ontable(B)
¬handempty
¬holding(B)
on(C,D)
¬clear(B)
¬clear(C)
on(C,D)
on(B,C)
ontable(D)
ontable(D)
handempty
handempty
clear(B)
¬ontable(B)
holding(B)
holding(B)
clear(C)
stack(B,C)
clear(C)
pickup(B)
initaction
clear(B)
on(A,B)
handempty
handempty
clear(B)
goalaction
clear(A)
stack(A,B)

117
jonkv@ida
Partial Orders

118
Second flaw type: A threat to be resolved
▪ initaction supports clear(B) for stack(A,B) – there’s a causal link
▪ pickup(B) deletes clear(B), and may occur "during" the link
▪ We can’t be certain that clear(B) still holds when stack(A,B) starts!
¬holding(A)
clear(B)
¬clear(B)
ontable(A)
clear(A)
on(A,B)
handempty
on(B,C)
clear(A)
ontable(B)
¬handempty
¬holding(B)
on(C,D)
¬clear(B)
¬clear(C)
on(C,D)
on(B,C)
ontable(D)
ontable(D)
handempty
handempty
clear(B)
¬ontable(B)
holding(B)
holding(B)
clear(C)
stack(B,C)
clear(C)
pickup(B)
initaction
clear(B)
on(A,B)
handempty
handempty
clear(B)
goalaction
clear(A)
stack(A,B)
holding(A)
jonkv@ida
Threats

119
How to make sure that clear(B) holds when stack(A,B) starts?
 Alternative 1: The action that disturbs the precondition
is placed after the action that has the precondition
▪ Only possible if the resulting partial order is consistent (acyclic)!
¬holding(A)
clear(B)
¬clear(B)
ontable(A)
clear(A)
on(A,B)
handempty
on(B,C)
clear(A)
clear(C)
on(C,D)
ontable(D)
handempty
handempty
clear(B)
¬handempt
y
¬clear(B)
¬holding(B)
¬ontable(B)
holding(B)
holding(B)
clear(C)
stack(B,C)
ontable(B)
pickup(B)
initaction
clear(B)
on(A,B)
goalaction
clear(A)
stack(A,B)
holding(A)
¬clear(C)
on(C,D)
on(B,C)
ontable(D)
handempty
handempty
clear(B)
jonkv@ida
Resolving Threats 1
120
 Alternative 2:
▪ The action that disturbs the precondition
is placed before the action that supports the precondition
▪ Only possible if the resulting partial order is consistent – not in this case!
¬holding(A)
clear(B)
¬clear(B)
ontable(A)
clear(A)
on(A,B)
handempty
on(B,C)
clear(A)
clear(C)
on(C,D)
ontable(D)
handempty
handempty
clear(B)
¬handempt
y
¬clear(B)
¬holding(B)
¬ontable(B)
holding(B)
holding(B)
clear(C)
stack(B,C)
ontable(B)
pickup(B)
initaction
clear(B)
on(A,B)
goalaction
clear(A)
stack(A,B)
holding(A)
¬clear(C)
on(C,D)
on(B,C)
ontable(D)
handempty
handempty
clear(B)
jonkv@ida
Resolving Threats 2

Again, this is not sufficient in itself
 Heuristics are required

But it has advantages
 No need to commit to order
Remember what a flaw is!
 Not something "wrong" in a final solution
 Not a mistake
 Simply bookkeeping for "something we haven't taken care of yet"
 Open goal: Must decide how to achieve a precondition
 Threat:
Must decide how to order actions
121
jonkv@ida
Heuristics

122
Original motivation: performance
 Therefore, a partial-order plan is a solution
iff all sequential plans satisfying the ordering are solutions
▪
▪
▪
▪
▪
Similarly, executable iff corresponding sequential plans are executable
<pickup(c1,A), pickup(c2,A), drive(A,B), put(c1,B), put(c2,B)>
<pickup(c2,A), pickup(c1,A), drive(A,B), put(c1,B), put(c2,B)>
<pickup(c1,A), pickup(c2,A), drive(A,B), put(c2,B), put(c1,B)>
<pickup(c2,A), pickup(c1,A), drive(A,B), put(c2,B), put(c1,B)>
We have:
robotat(A)
at(c1,A)
at(c2,A)
pickup(c1,A)
put(c1, B)
drive(A,B)
pickup(c2,A)
put(c2, B)
We want:
at(c1,B)
at(c2,B)
jonkv@ida
Partial-Order Solutions

123
Can be extended to allow concurrent execution
 Requires an extended action model!
▪ Our model does not define what happens
if c1 and c2 are picked up simultaneously
(or even if we are allowed to do this)!
We have:
robotat(A)
at(c1,A)
at(c2,A)
pickup(c1,A)
put(c1, B)
drive(A,B)
pickup(c2,A)
put(c2, B)
We want:
at(c1,B)
at(c2,B)
jonkv@ida
Partial Orders and Concurrency

125
Example questions:
 Describe and explain:
▪ Relaxation, and how it can be applied to create an admissible heuristic
▪ Delete relaxation
▪ The optimal relaxation heuristic
▪ The different kinds of flaws that can occur in a partially ordered plan
▪ What is the main advantage of partial-order planning over forward state space
planning?
▪ In which ways can you resolve an open goal?
 Why:
▪ Why don’t planners use Dijkstra’s algorithm to search the state space?
▪ Why can the
heuristic be calculated more quickly
than the optimal delete relaxation heuristic ?
▪ What
jonkv@ida
Example Questions
126
 Is the number of open goals an admissible heuristic? Why / why not?
 Describe one important difference between backward and forward search.
 Given a domain, problem and initial state:
▪ Expand the forward state space by two levels
▪ Expand the backward search space by two levels
 How can you apply hill climbing to planning?
▪ How do you have to modify standard hill climbing,
and why?
jonkv@ida
Example Questions
 Deeper discussions about all of these topics
 Formal basis for planning
▪ Alternative representations of planning problems
▪ Simple and complex state transition systems
 Completely different principles for heuristics
▪ Landmarks
▪ Pattern databases
 Alternative search spaces
▪ Planning by conversion to boolean satisfiability problems
 Extended expressivity
▪ Planning with time and concurrency
▪ Planning with probabilistic actions (Markov Decision Processes)
▪ Planning with non-classical goals
127
jonkv@ida
TDDD48 Automated Planning (1)

128
jonkv@ida
TDDD48 Automated Planning (2)
Example: concurrent actions with duration
▪ (:durative-action turn
:parameters (?current-target ?new-target - target)
Duration dependent on
:duration (= ?duration (/ (angle ?current-target ?new-target)
parameters, current
(turn-rate)))
state
:condition (and (at start (pointing ?current-target))
(at start (not (controller-in-use))))
Conditions / effects
:effect (and (at start (not (pointing ?current-target)))
at the start or end
(at start (controller-in-use))
of the action
(at start (vibration))
(at end (not (controller-in-use)))
Implemented by quite a few planners –
(at end (not (vibration)))
affects algorithms and heuristics!
(at end (pointing ?new-target))))
[0,10] load(P1,T1)
[10,570] drive(T1,A,B)
[570,580] unload(P1,T1)
[0,10] load(P2,T2)
[10,420] drive(T2,C,D)
[420,430] unload(P2,T2)
[0,10] load(P3,T3)
[10,845] drive(T3,E,F)
[845,855] unload(P3,T3)
129
jonkv@ida
TDDD48 Automated Planning (3)
 Planning with domain knowledge
▪ Using what you know: Temporal control rules
▪ Breaking down a task into smaller parts: Hierarchical Task Networks
The “travel” task has a method called
“air-travel”
buy-ticket (airport(x), airport(y))
travel (x, airport(x))
 Alternative types of planning
▪ Path planning
 And so on…
travel(x,y)
Task
air-travel(x,y)
Method
fly(airport(x), airport(y))
travel (airport(y), y)