Wv19 9 Planning

Institute for Software Technology
Expert Systems
- Planning -
Gerald Steinbauer
Institut für Softwaretechnologie
Inffeldgasse 16b/2
A-8010 Graz
Austria
Gerald Steinbauer Expert Systems

1
Shakey, the Robot

developed 1966-1972
at Stanford Research
Institute (SRI)
move boxes in an
office environment
Nils Nilsson
used STRIPS
~300k word program

2
Motivation
• planning is …
• a very old problem
• a very important problem
• related to scheduling
• part of research on AI since ever
• part of every intelligent system
• annual conferences on planning; e.g. ICAPS
• annual competitions for planning

3
Applications of Planning
• Classical Action Planning, e.g., Robots
• Renormalization of Diagnosis Problems
• Software Testing
• Repair and Reconfiguration
• Exploration
• Logistics
• … and many more

4
Example: Logistics
s1 = {attached(p1,loc1), in(c1,p1), in(c3,p1), top(c3,p1), on(c3,c1), on(c1,pallet),

attached(p2,loc1), in(c2,p2), top(c2,p2), on(c2,palet), belong(crane1,loc1),
empty(crane1), adjacent(loc1,loc2), adjacent(loc2,loc1), at(r1,loc2), occupied(loc2,
unloaded(r1)}

5
Running Example
• rigid propositions
•
•
•
• dynamic propositions
•
•
•
•
.. location •
.. robot •
.. pile •
.. crane •
.. container •
6
Running Example - Operators

• •
• pre: 𝑎𝑑𝑗𝑎𝑐𝑒𝑛𝑡 𝑙 , 𝑙 , 𝑎𝑡 𝑟, 𝑙 , • pre: 𝑏𝑒𝑙𝑜𝑛𝑔(𝑘, 𝑙), ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐),
¬𝑜𝑐𝑐𝑢𝑝𝑖𝑒𝑑 𝑙 𝑎𝑡(𝑟, 𝑙), 𝑢𝑛𝑙𝑜𝑎𝑑𝑒𝑑(𝑟)
• effect:𝑎𝑡 𝑟, 𝑙 , ¬𝑎𝑡 𝑟, 𝑙 , • effect: ¬ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), 𝑙𝑜𝑎𝑑𝑒𝑑 𝑟, 𝑐 ,
¬𝑜𝑐𝑐𝑢𝑝𝑖𝑒𝑑 𝑙 , 𝑜𝑐𝑐𝑢𝑝𝑖𝑒𝑑 𝑙 𝑒𝑚𝑝𝑡𝑦 𝑘 , ¬𝑢𝑛𝑙𝑜𝑎𝑑𝑒𝑑 𝑟
• •
• pre: 𝑏𝑒𝑙𝑜𝑛𝑔 𝑘, 𝑙 , 𝑎𝑡𝑡𝑎𝑐ℎ𝑒𝑑 𝑝, 𝑙 , • pre: 𝑏𝑒𝑙𝑜𝑛𝑔(𝑘, 𝑙), 𝑒𝑚𝑝𝑡𝑦(𝑘),
𝑒𝑚𝑝𝑡𝑦 𝑘 , 𝑡𝑜𝑝(𝑐, 𝑝), 𝑜𝑛(𝑐, 𝑑) 𝑎𝑡(𝑟, 𝑙), 𝑙𝑜𝑎𝑑𝑒𝑑(𝑟, 𝑐)
• effect: ℎ𝑜𝑙𝑑𝑖𝑛𝑔 𝑘, 𝑐 , ¬𝑒𝑚𝑝𝑡𝑦(𝑘), • effect: ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), ¬𝑙𝑜𝑎𝑑𝑒𝑑 𝑟, 𝑐 ,
¬𝑖𝑛 𝑐, 𝑝 , ¬𝑡𝑜𝑝(𝑐, 𝑝), ¬𝑜𝑛(𝑐, 𝑑), ¬𝑒𝑚𝑝𝑡𝑦 𝑘 , 𝑢𝑛𝑙𝑜𝑎𝑑𝑒𝑑(𝑟)
𝑡𝑜𝑝(𝑑, 𝑝)
•
• pre: 𝑏𝑒𝑙𝑜𝑛𝑔(𝑘, 𝑙),
𝑎𝑡𝑡𝑎𝑐ℎ𝑒𝑑 𝑝, 𝑙 , ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐),
𝑡𝑜𝑝(𝑑, 𝑝)
• effect: ¬ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐),
𝑒𝑚𝑝𝑡𝑦(𝑘), 𝑖𝑛(𝑐, 𝑝), 𝑡𝑜𝑝(𝑐, 𝑝),
𝑜𝑛(𝑐, 𝑑), ¬𝑡𝑜𝑝(𝑑, 𝑝)
7
Example: Dinner-Date
initial situation: one has clean hands and there is
garbage in the kitchen. it is quiet in the house.
desired situation: a dinner is cooked, there is no
garbage in the kitchen and we have a present.
what can we do?
cook a dinner,
wrap a present,
carry the garbage out or
dolly the garbage out

8
Planning is Problem Solving

• Classical Planning Problem (I,G,A)
• I … a description of the initial state
• G  S … a description of the goal (S … state space)
• A … a description of actions (domain theory)
• Plan=Solution
• sequence of actions that when executed satisfy in the initial
state and will achieve the goal
• Descriptions
• usually given in a formal language: e.g., first order predicate
calculus, propositional logic, situation calculus, STRIPS, …

9
Restrictive Assumptions
• A0: Finite system:
• finitely many states, actions, events
• A1: Fully observable:
• the controller always knows Σ’s
current state
• A2: Deterministic:
• each action has only one outcome
• A3: Static (no exogenous events):
• no changes but the controller’s actions
• A4: Restricted goals:
• a set of goal states 𝑆
• A5: Sequential plans:
• a plan is a linearly ordered sequence of actions (𝑎 , 𝑎 , … , 𝑎 )
• A6: Implicit time:
• no time durations; linear sequence of instantaneous states
• A7: Off-line planning:
• planner doesn’t know the execution status
10
Transition System
• a transition system is a 5-tupel
T=<S,L,T,s0,S*>
• S a finite set of states
• L is a finite set of (transition) labels
• TSLS is transition relation
• s0S is the initial state
• S*S is the set of goal states
• T has a transition <s,l,s’> if <s,l,s’>  T

11
Transition System
goal states a
C B c
b
d b d
d
D A
a f
b
d E F
e
initial states

12
Set-Theoretic Representation
• it relies on a finite set of proposition symbols
• let L={p1,p2,…,pn} a finite set of proposition symbols
then a set-theoretic planning domain is a restricted
transition system =(S,A,)
• S2L, each state is a subset of L, if p  s then p holds in the
world represented by s
• each action aA is a triple of subsets of L
a=(pre(a),effects+(a),effects-(a)), effects+(a) and effects-(a)
are disjoint, a is applicable if pre(a)S
• if sS the state produced by an action is also in S
• transition function (s,a)=(s-effects-(a))effects+(a)

13
Classical Representation
• let L be a first-order language with finite many
predicate and constant symbols
• a classical planning domain is a restricted transition
system =(S,A,)
• S2{all ground atoms of L}
• A are all ground operators in O, O is the set of all operators
defended as triple (name(o) with n(x1,...,xn), pre(o),
effects(o)), x1,…,xn are variables in pre(o) and effects(o),
pre(o) and effects(o) are set of literals, a is applicable if
pre+(a) s and pre-(a) s =
• (s,a)= (s-effects-(a))effects+(a) if a is applicable in s
• if sS the state produced by an action is also in S

14
Relevant Actions and Regression

• set-theoretic representation
• an action a is relevant for a goal g if geffects+(a) and
geffects-(a)=
• -1(g,a)=(g-effects+(a))pre(a)
• classical representation
• an action a is relevant for a goal g if geffects(a) and
g+effects-(a)= and g-effects+(a)=
• -1(g,a)=(g-effects(a))pre(a)
• goal g can be a set of literals

15
Types of Planning
• State-Space Planning
• search in the space of states
• states are connected by state transitions (i.e., actions )
• find a state which satisfied the goal
• solution: a path from the initial state to the goal state

16
Forward Search
the most simple algorithm
Forward-Search(D,I,g)
sI
  the empty plan
loop
if s satisfies g return 
applicable  {a|a is a ground action of D and
precond(a) is true in s}
if applicable=Ø then return failure
non-deterministically choose an action a  applicable
s  (s,a)
  .a
there exist also deterministic implementation
17
Backward Search
Backward-Search(D,I,g)
  the empty plan
loop
if I satisfies g return 
relevant  {a|a is a ground action of D and
a is relevant for g}
if relevant=Ø then return failure
non-deterministically choose an action a  relevant
  a.
g   -1(g,a)
backward search is in general more focused as

it includes the goal into the search

18
Types of Planning
• Plan-Space Planning
• search in the space of partially defined plans
• plans are connected by refinement actions, i.e., achieve a
new sub-goal or remove inconsistencies
• search starts with an empty plan node
• search for a final node containing a solution plan
• uses the “least commitment” philosophy
• a partial plan comprises a set of actions plus some ordering
and grounding constraints

19
Plan-Space Planning
• each node of the search space is a partial plan
• a set of partially-instantiated actions
• a set of constraints
• make more and more refinements, until we have a solution
• types of constraints
• precedence constraint: a must precede b
• binding constraints: inequality constraints, e.g., v1 ≠ v2 or v ≠ c;
equality constraints (e.g., v1 = v2 or v = c) and/or substitutions
• causal link: use action a to establish the precondition p needed by
action b

20
Solution to Plan-Space Planning

• a partial plan is a solution for plan
problem if
• its ordering constraints and binding constraints are consistent
• every sequence totally ordered and totally instantiated actions of
satisfying and defines a path of from to with with
initial state as effects and with goal state as precondition
• this is not a practical condition

21
Threat
• an action in a plan is a threat on a causal link
iff
• has an effect that is possibly inconsistent with , i.e and
are unifiable
• the ordering constraints and are consistent with
• the binding constraints for the unification of and consistent with

22
Flaw
• a flaw in a plan is either:
• a subgoal, i.e. a precondition of an action in without a causal link
or
• a threat, i.e. an action that may interfere with a causal link
• a partial plan is a solution to the
planning problem if has no flaws and
if the set of ordering constraints and binding
constraints are consistent

23
The PSP Procedure
• PSP is both sound and complete

• it returns a partially ordered solution plan
• any total ordering of this plan will achieve the goals
• or could execute actions in parallel if the environment permits it

24
The PSP Procedure continued

•
• finds all open goals in
• preconditions not supported by a causal link
• efficiently implemented using an agenda, a list of open
preconditions
•
• finds every action that is a threat to a causal link ( )
• naively test all triples of actions in ,
• better us an incremental processing:
• new action 𝑎: test all causal links not involving 𝑎, 𝑂(𝑛 )
• new causal link: test all actions not involved, 𝑂(𝑛)

25

•
• finds all ways to resolve a flaw
• if is a subgoal for precondition of action
• a causal link (𝑎 → 𝑎 ) if there is already an action 𝑎 in 𝜋 whose effect
can provide 𝑝; add causal link, ordering constraint (𝑎 ≺ 𝑎 ) if consistent
with ≺ and binding constraints to unify 𝑝 with the effect of 𝑎
• a new action 𝑎 that can provide 𝑝, add action 𝑎, causal link including
ordering and binding constraints including (𝑎 ≺ 𝑎 ≺ 𝑎 )
• if is a threat on a causal link ( ) by an action that has an

effect und is unifiable with
• the constraint (𝑎 ≺ 𝑎 ), if consistent with ≺, i.e. ordering a before the
causal link
• the constraint (𝑎 ≺ 𝑎 ), if consistent with ≺, i.e. ordering a after the
causal link
• a binding constraint with 𝐵 that makes 𝑝 and 𝑞 nonunifiable
26

•
• refines the partial plan with the elements in the resolver
• adding to
• an ordering constraint,
• one or several binding constraints,
• a causal link, and/or
• a new action
• it has to maintain the set of subgoals and threats
• it performs query and update operations on the sets and
• ordering constraints, 𝑂(𝑛 )
• binding constraints, related to CSP, 𝑁𝑃 − 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒

27
Extension to Classical Planning

• some problems are hard to model with “simple”
descriptions
• therefore some extensions have been introduced
• quantifiers in formulas
• types
• conditional effects
• disjunctive preconditions
• axiomatic inference
• functions

28
Planning Domain Definition Language

• PDDL is a planning language
• standard encoding language for “classical” planning
tasks
• planning tasks specified in PDDL are separated into
two files
• domain file for predicates and actions
• problem file for objects, initial state and goal specification
• several ready-to-go standalone planners available
(e.g., SGPLAN6, fast downward)
• comment: PDDL is not a “hard” standard

29
PDDL Basics
• The Planning Domain Definition Language (PDDL)
• variants used by most implemented planning systems
• supports a formalism comparable to what we have outlined above
(including schematic operators and quantification)
• syntax inspired by the Lisp programming language: e.g., prefix
notation for formulas
(and (or (on A B) (on A C))
(or (on B A) (on B C))
(or (on C A) (on A B)))
• the planner input is separated into a domain file (predicates, types,
action schemas) and a problem file (objects, initial state, goal).

30
PDDL Domain File

• A PDDL domain file consists of:
• (define (domain <name>)
• a requirements definition
• definitions of types (each object variable has a type)
• definitions of predicates
• definitions of action schemas

31
Domain File Types and Predicates:

Example Blocksworld
(define (domain Blocksworld)
(:requirements :strips :typing)
(:types block - object
blueblock smallblock - block)
(:predicates (on ?x - smallblock ?y - block)
(ontable ?x - block)
(clear ?x - block))

32
Action Schema: Example Blocksworld

(:action fromtable
:parameters (?x - smallblock ?y - block)
:precondition (and (not (= ?x ?y))
(clear ?x)
(ontable ?x)
(clear ?y))
:effect
(and (not (ontable ?x))
(not (clear ?y))
(on ?x ?y)))

33
PDDL Grammar: Action Schema I

(:action <name>
List of parameters:
(?x - type1 ?y - type2 ?z - type3)
the precondition is a formula:
<predicate>
(and <formula> ... <formula>)
(or <formula> ... <formula>)
(not <formula>)
(forall (?x1 - type1 ... ?xn - typen)
<formula>)
(exists (?x1 - type1 ... ?xn - typen)
<formula>)

34
PDDL Grammar: Action Schema II

the effect is a combination of literals,
conjunction, conditional effects, and
quantification over effects:
<predicate>
(not <predicate>)
(and <effect> ... <effect>)
(when <formula> <effect>)
(forall (?x1 - type1 ... ?xn - typen) <effect>)

35
PDDL Problem Files

• a PDDL problem file consists of:
• (define (problem <name>)
• (:domain <name>)– to which domain does this problem belong?
• definitions of objects belonging to each type
• definition of the initial state (list of ground predicates initially true)
• definition of the goal (a formula like action preconditions).

36
Problem File: Example Blocksworld

(define (problem example)
(:domain Blocksworld)
(:objects a b c - smallblock
d e – block
f - blueblock)
(:init (clear a) (clear b) (clear c)
(clear d) (clear e) (clear f)
(ontable a) (ontable b) (ontable c)
(ontable d) (ontable e) (ontable f))
(:goal (and (on a d) (on b e) (on c f)))
)

37
Dinner-Date: Domain
(define (domain dinner-date)
(:requires :strips)
(:predicates (garbage) (cleanHands) (quiet) (dinner)
(present))
(:action cook
:precondition (cleanHands)
:effect (dinner)
)
(:action wrap
:precondition (quiet)
:effect (present)
)
(:action carry
:effect (and (not (garbage)) (not(cleanHands)))
)
(:action dolly
:effect (and (not (garbage)) (not(quiet)))
)
)
38
Dinner-Date: Problem
(define (problem dinner-date)
(:domain dinner-date)
(:requires :strips :negative-preconditions)
(:init (garbage) (cleanHands) (quiet))
(:goal (and (dinner) (present) (not (garbage))))
)

39
Example
http://editor.planning.domains

40
Graphplan
• basic idea, alternate between two phases
• graph expansion: extends Graphplan forward in time
• solution extraction: performs backward-chaining to look for a
plan that solved the planning problem
• fast algorithm - outperforms (most) others
• basic for encoding planning problems as SAT
problems
• Graphplan uses a planning graph

41
Planning Graph
• two types of nodes
• proposition nodes
• action nodes
• nodes are arranged in levels
• even-numbered levels contain proposition nodes
• odd-numbered levels contain action nodes
• the zero level stores nodes of propositions true in the initial
state
• edges connect proposition nodes of the level i with
action nodes of level i+1 and actions from level i+1 to
propositions of level i+2

42
Planning Graph
• an action is element of a level i iff all propositions
occurring in the precondition are in level i-1.
• an edge between a proposition p at level i and action a
at level i+1 exists iff p is a precondition of a.
• a proposition p is in level i>1 iff there exists an action a
in level i-1 where p is in the effect set. in this case there
exists an edge between a and p.
• we assume the existence of identity actions for each
proposition (aka maintenance actions).
• an action level represents (possible) parallel actions

43
Planning Graph
0 i-1 i i+1
actions
propositions

44
Mutex Relations
• actions at the same level may not be executed at
once, e.g., carry and cook
• binary mutual exclusion (mutex) between nodes
• two actions at level i are mutex if either
• the effect of one action is the negation of the other’s effect
[inconsistent effect]
• one action deletes the precondition of the other [interference]
• the actions have preconditions, that are mutex at level i-1
[competing needs]

45
Mutex Relations
• two propositions at level i are mutex if
• all ways of achieving the proposition (actions at level i-1) are
pairwise mutex [inconsistent support]
--
46
Inconsistent Effect
not A

47
Inference
not A

48
Competing Needs
not A

49
Inconsistent Support
--
50
Graph Expansion
• assume we built up the graph to the proposition level
i.
• create a new action level i+1. for every action a,
where all preconditions are satisfied, create a new
node for a.
• create a new proposition level i+2. for every effect in
action a occurring in level i+1 create a proposition
node in i+1.
• compute the mutex relations.

51
Dinner Example Level 2

garbage garbage
carry
not garbage
dolly
cleanHands cleanHands
not cleanHands
cook
quiet quiet
wrap
not quiet
dinner
present
0 1 2
52
Solution Extraction
1. assume Graphplan has extended the graph up to a
level i, in which all goal propositions are present
[necessary condition].
2. for each of the sub-goals at level i do:
a) choose an action a from level i-1 that achieves the sub-goal.
b) if this action is consistent, i.e., not mutex, with the previously
chosen actions, then take the next sub-goal.
c) otherwise, backtrack to a previous choice.

53
Solution Extraction
3. after Graphplan has found a consistent set of
actions for level i-1, it recursively tries to find a plan
for the action’s precondition on level i-2.
4. if the zero level is reached a plan has been
extracted.
5. if backtracking fails on all combinations (of actions
for each goal) then Graphplan extends the graph (as
described previously) and tries solution extraction
again.

54

All goal propositions are included → solution extraction
1.select not garbage
2. select carry
3. select dinner
4. select cook
5. cook mutex carry backtracking to 4
6. no action backtracking to 2
7. select dolly
8. select dinner
9. select cook
10. select present
11. select wrap
12. wrap mutex dolly backtracking to
10
15. no action finish with no plan
55
garbage
Dinner Example Level 2 garbage
carry carry
not garbage
dolly dolly
cleanHands
cleanHands
not cleanH.
cook cook
quiet quiet
wrap wrap
not quiet
dinner
present
0 1 2 3 4
56

garbage garbage
carry carry
not garbage
dolly dolly
cleanHands
cleanHands
not cleanH.
cook quiet cook

quiet quiet
wrap wrap
not quiet
dinner
possible plan: dinner
cook, wrap, carry
present
0 1 2 3 4
57
Some Observations
• from one level to another …
• propositions monotonically increase
• actions have new effects
• always carried forward by no-ops
• actions monotonically increase
• more preconditions are satisfied
• propositional mutex relations monotonically decrease
• new paths for propositions emerge
• action mutex relations monotonically decrease
• new ways to achieve the precondition emerge

58
Level Off
• plan graph levels off
• after some some levels k all levels are identical
• because of it’s finite state
• and the set of propositions never decrease
• and mutex do not reappear

59
Bibliography
• Daniel S. Weld. Recent advances in AI Planning. AI Magazine, pp
93-123, Summer 1999.
• Richard Fikes and Nils Nilsson. STRIPS: A New Approach to the
Application of Theorem Proving to Problem Solving. Artificial
Intelligence, 2(3-4): 189-208, 1971.
• Avrim L. Blum and Merrick L. Furst. Fast Planning Through
Planning Graph Analysis. Artificial Intelligence 90(1-2). 1995.
• Malik Ghallab, Dana Nau and Paolo Traverso. Automated
Planning – Theory and Practice. Morgan Kaufman. 2005.
• @article{fox2003pddl2,
• Fox, Maria and Long, Derek. PDDL2. 1: An Extension to PDDL for
Expressing Temporal Planning Domains. J. Artif. Intell. Res. (JAIR),
2003(20).

60
Thank You!
--
61

Wv19 9 Planning

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wv19 9 Planning

Uploaded by

Copyright:

Available Formats

Institute for Software Technology

Gerald Steinbauer Expert Systems

Shakey, the Robot

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

s1 = {attached(p1,loc1), in(c1,p1), in(c3,p1), top(c3,p1), on(c3,c1), on(c1,pallet),

Gerald Steinbauer Expert Systems

Running Example - Operators

Gerald Steinbauer Expert Systems

Planning is Problem Solving

Gerald Steinbauer Expert Systems

• T has a transition <s,l,s’> if <s,l,s’>  T

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Relevant Actions and Regression

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

backward search is in general more focused as

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Solution to Plan-Space Planning

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

The PSP Procedure

• PSP is both sound and complete

Gerald Steinbauer Expert Systems

The PSP Procedure continued

Gerald Steinbauer Expert Systems

The PSP Procedure continued

• if is a threat on a causal link ( ) by an action that has an

The PSP Procedure continued

Gerald Steinbauer Expert Systems

Extension to Classical Planning

Gerald Steinbauer Expert Systems

Planning Domain Definition Language

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

PDDL Domain File

Gerald Steinbauer Expert Systems

Domain File Types and Predicates:

Gerald Steinbauer Expert Systems

Action Schema: Example Blocksworld

Gerald Steinbauer Expert Systems

PDDL Grammar: Action Schema I

Gerald Steinbauer Expert Systems

PDDL Grammar: Action Schema II

Gerald Steinbauer Expert Systems

PDDL Problem Files

Gerald Steinbauer Expert Systems

Problem File: Example Blocksworld

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems

Gerald Steinbauer Expert Systems