Modeling Classical
Planning Domains
jonas.kvarnstrom@liu.se – 2015

2
Exactly what is classical planning?
 Some disagreements…
▪ Inevitable: Just a group of similar techniques, formalisms
 Where to draw the line?
We'll use the book's definitions
Be aware: You can go outside those boundaries and still be "kind of classical"!
jonkv@ida
Classical Planning: Disagreements
3
A0: Finite number of states
Can't model continuous positions of containers
OK – we're only interested in some discrete alternatives:
in pile x, on truck y, carried by crane z, …
We want to affect a world
which is always in a given state
Another possible state
A6: Every action results in a discrete state transition
No concept of time
No concept of continuous change (crane swinging from A to B), only:
Before pickup, the container is on truck y;
after, the container is carried by crane z
Many planners do model some forms of time  "semi-classical"
jonkv@ida
Assumptions 1
4
A1: We can always detect the current state
Given A2, this only means that we know the initial state
Without A2, we can execute an action and then know where
we ended up
The world is always in
a given state
Another possible state
A2: Deterministic actions
If we know the current state and the action that is executed,
we can predict with 100% certainty which state we will end up in
Some planners support non-determinism
Complicated due to explosion of possibilities!
jonkv@ida
Assumptions 2
A3: If we don't execute an action, we remain in the state
No random changes in the world
No other agents acting in the world
At least not in the part of the world we model!
The world is always in
a given state
5
jonkv@ida
Assumptions 3
other possible state
6
Another possible state
Another possible state
Goal states
Another possible state
Another possible state
The world is always in
a given state
Another possible state
A4: Restricted objectives
The objective is always to end up in a goal state,
a state having certain properties:
No constraint on cost, time requirements, states to avoid, …
Many planners support more complex objectives
jonkv@ida
Assumptions 4
 A5: Sequential plans
▪ A solution never executes two actions concurrently
▪ Many planners do allow concurrency  "semi-classical"
 A7: Offline planning
▪ No need to consider changes that may happen while generating plans.
We can define many other classes of planning problem
For now, we'll stay with classical problems
7
jonkv@ida
Assumptions 5

The language of Artificial Intelligence was/is logic
 First-order, second-order, modal, …

1959: General Problem Solver (Newell, Shaw, Simon)
9
jonkv@ida
History: 1959

1969: Planner explicitly built on Theorem Proving (Green)
10
jonkv@ida
History: 1969

11
Full theorem proving generally proved impractical for planning
 But even when different techniques were found,
the foundations in logical specifications remained
We can identify three wide classes of logical specification
Propositional
(boolean propositions)
First-order
(boolean predicates)
State-variable-based
(non-boolean functions)
atHome, atWork
at(person, location)
loc(person) = location
General classes containing many languages!
Need to pin down something concrete…
Can be done at several levels!
jonkv@ida
Basis in Logic
Practical representation language
Many convenient high-level constructs for practical modeling
Possibly a large, complex language
Formal representation language
"The simplest representation that is (more or less) reasonable to use for modeling“
Not too far from how we think about planning,
still reasonable to use for simple domains and examples,
but fewer concepts to keep track of
Underlying formal model
Concepts should be as few, as simple and as clearly defined as possible
Good for analysis, correctness proofs, understanding what planning is
Could be cumbersome for modeling
…and we also focus on this
Practical
language
Formal
representation

three variations
pinned down
in the book
PDDL:
Planning Domain Definition Language
Propositional
First-order
Set-theoretic
Classical
State variable
representation
representation
representation
of classical problems of classical problems of classical problems
Today’s focus
Formal model
–
later…
State-variable
When we say
"classical representation",
we mean
the definition in the book
Planning Domain Definition Language

15
Running example (from the book): Dock Worker Robots
Containers shipped
in and out of a harbor
Cranes move containers
between ”piles” and robotic trucks
jonkv@ida
Running Example

16
PDDL: Planning Domain Definition Language
 Origins: First International Planning Competition, 1998
 Most used language today
 General; many expressivity levels

Lowest level of expressivity: Called STRIPS
 One specific predicate-based syntax/semantics for classical planning domains/instances
 Not exactly what the STRIPS planner supported
This will illustrate what we are truly interested in:
The underlying concepts!
jonkv@ida
PDDL

17
PDDL separates domains and problem instances
Domain file
Named
(define (domain dock-worker-robots)
…
)
Problem instance file
Named
(define (problem dwr-problem-1)
(:domain dock-worker-robots)
Associated with
…
a domain
)
Colon before many keywords,
to avoid collisions
when new keywords are added
jonkv@ida
PDDL: Domain and Problem Definition

18
Domains declare their expressivity requirements
▪ (define (domain dock-worker-robots)
(:requirements
:strips ;; Standard level of expressivity
…)
;; Remaining domain information goes here!
)
We will see some
other levels as well…
Warning:
Many planners’ parsers ignore expressivity specifications
jonkv@ida
PDDL: Domain and Problem Definition

20
In first-order representations of classical planning problems:
 The world contains a finite number of objects
 Buildings, cards, aircraft, people, trucks, pieces of sheet metal, …
Modeling: Which objects exist and are relevant for the problem?
jonkv@ida
Objects 1

Dock Worker Robots
21
A crane moves containers
between piles and robots
A robot is an automated
truck moving containers
between locations
A container can be
stacked, picked up,
loaded onto robots
loc2
c2
c3
c1
p1
A pile is a stack of containers –
at the bottom, there is a pallet
p2
loc1
r1
A location is an area that can
be reached by a single crane.
Can contain several piles,
at most one robot.
We can skip:
Hooks
Wheels
Rotation angles
Drivers
Essential: Determine what is relevant for the problem and objective!
jonkv@ida
Objects 2: Dock Worker Robots

22
Dock Worker Robots in the book's Classical Representation
 There is an untyped first-order language L
with the constant symbols {c1,c2,c3,p1,p2,loc1,loc2,r1,…}
loc2
c2
c3
c1
p1
p2
loc1
r1
jonkv@ida
Objects 3: Classical Representation

23
In PDDL and most planners:
 Begin by defining object types
▪ (define (domain dock-worker-robots)
(:requirements
:strips
Tell the planner
:typing ) which features you need…
)
(:types
location ; there are several connected locations in the harbor
pile
; attached to a location, holds a pallet + a stack of containers
robot
; holds at most 1 container, only 1 robot per location
crane
; belongs to a location to pickup containers
container)
Earlier, planners used predicates instead:
islocation(obj), ispile(obj), …
Still present in some benchmark domains
Discussed later in this course
c3
c1
p1
loc2
c2
p2
loc1
r1
jonkv@ida
Objects 4: PDDL Object Types

24
Many planners support type hierarchies
 Convenient, but often not used in domain examples
▪ (:types
; containers and robots are movable objects
container robot – movable
…)
 Predefined ”topmost supertype”: object
c3
c1
p1
loc2
c2
p2
loc1
r1
jonkv@ida
Objects 5: PDDL Type Hierarchies

25
Objects are generally specified in the problem instance
▪ (define
(problem dwr-problem-1)
(:domain dock-worker-robot)
(:objects
r1
– robot
loc1 loc2
– location
k1
– crane
p1 p2
– pile
c1 c2 c3 pallet
– container)
c3
c1
p1
loc2
c2
p2
loc1
r1
jonkv@ida
Objects 6: PDDL Object Definitions

26
jonkv@ida
Objects 7: PDDL "Constants"
Some objects should exist in all instances
(define (domain woodworking) (:requirements :typing)
(:types
acolour awood woodobj machine surface treatmentstatus aboardsize apartsize – object
highspeed-saw glazer grinder immersion-varnisher planer saw spray-varnisher – machine
board part - woodobj)
(:constants
Called constants:
verysmooth smooth rough
– surface
Define once –
varnished glazed untreated colourfragments – treatmentstatus
use in all
natural
– acolour
problem instances
small medium large
- apartsize)
(:action do-immersion-varnish
:parameters (?x - part ?m - immersion-varnisher ?newcolour - acolour ?surface - surface)
:precondition (and
…
 Can use in the
(treatment ?x untreated))
domain definition
:effect (and
as well!
(not (treatment ?x untreated)) (treatment ?x varnished)
(not (colour ?x natural))
(colour ?x ?newcolour))) …)

28
jonkv@ida
Facts
In the book's Classical Representation:
 Every fact is represented as an atom: Predicate + arguments
 Properties of the world
▪ raining
– it is raining [not a DWR predicate!]
All values are
called objects
 Properties of single objects…
▪ empty(crane)
– the crane is not holding anything
 Relations between objects
▪ attached(pile, location)
– the pile is in the given location

All parameters
are objects
 Relations between >2 objects
▪ can-move(robot, location, location)
– the robot can move between
the two locations [Not a DWR predicate]
c2
loc2
c3
p2
c1
r1
loc1
Essential:
Determine what is relevant for the problem and objective!
p1

29
In PDDL: Lisp-like syntax for predicates, atoms, …
▪ (define (domain dock-worker-robots)
(:requirements …)
(:predicates
(adjacent ?l1 ?l2 - location)
"Fixed"
(attached ?p - pile ?l - location)
(can't
(belong ?k - crane ?l - location)
change)
(at
?r - robot ?l - location)
(occupied ?l - location)
(loaded ?r - robot ?c - container )
(unloaded ?r - robot)
"Dynamic" (holding ?k - crane ?c - container)
(empty ?k - crane)
(modified by
actions)
(in
?c - container ?p - pile)
(top
?c - container ?p - pile)
(on
?k1 ?k2 - container )
)
Variables are
prefixed with “?”
; can move from ?l1 directly to ?l2
; pile ?p attached to location ?l
; crane ?k belongs to location ?l
; robot ?r is at location ?l
; there is a robot at location ?l
; robot ?r is loaded with container ?c
; robot ?r is empty
; crane ?k is holding container ?c
; crane ?k is not holding anything
; container ?c is somewhere in pile ?p
; container ?c is on top of pile ?p
; container ?k1 is on container ?k2
jonkv@ida
Predicates in PDDL

Modeling Issues: Single or multiple predicates?
▪ (define (domain dock-worker-robots)
(:requirements …)
(:predicates
3 predicates (attached ?p - pile ?l - location)
with similar (belong ?k - crane ?l - location)
?r - robot ?l - location)
meaning (at
; pile ?p attached to location ?l
; crane ?k belongs to location ?l
; robot ?r is at location ?l
 Could use type hierarchies instead – in most planners
▪ (define (domain dock-worker-robots)
(:requirements …)
(:types
robot crane container pile – thing
location
(:predicates
(at
?t – thing ?l - location)
; thing ?t is at location ?l
)
)
30
jonkv@ida
Modeling: Different predicates per type?

Models often provide duplicate information
 A location is occupied  there is some robot at the location
▪ (define (domain dock-worker-robots)
(:requirements …)
(:predicates
(at
?r - robot ?l - location)
; robot ?r is at location ?l
(occupied ?l - location)
; there is a robot at location ?l
 Strictly speaking, occupied is redundant
▪
▪
▪
▪
Still necessary in many planners
No support for quantification: (exists ?r (at ?r ?l))
Have to write (occupied ?l) instead
Have to provide this information + update it in actions!
31
jonkv@ida
Modeling: Duplicate information

32
We have abstracted the real world!
 Motion is really continuous in 3D space
▪ Uncountably infinite number of positions for a container
 But for the purpose of planning:
▪ We model a finite number of interesting positions
▪ On a specific robot
▪ In a specific pile
▪ Held by a specific crane
Real World
Abstraction
Approximation
Simplification
Formal Model
Gives sufficient information
allowing us to solve
interesting problems
jonkv@ida
Modeling: Abstraction

33
Use correct terminology – including on the exam!
A proposition
is used in propositional logic; no parameters (atHome)
A predicate
is like a boolean function – the actual function
A predicate symbol is the name of the predicate
An atom
A literal
consists of a predicate and its arguments – adjacent(a,b),
is a positive or negative atom: ¬adjacent(a,b), adjacent(a,b)
Don’t say ”predicate” when you mean ”atom”.
Then you’re talking about "adjacent", rather than "adjacent(a,b)"
Any formula/term can be ground (variable-free),
nonground (containing variables)
jonkv@ida
Terminology

35
A state defines which facts are true/false in the world at a given time
 In the book's Classical Representation
(and every first-order representation):
▪ A fact is a ground atom
▪ A state assigns a definite value (true/false) to all ground atoms
▪ Number of possible states: 2number of atoms
jonkv@ida
States 0: Intentional Definition
We know all predicates that exist,
and their argument types:
adjacent(location, location), …
We know a set of objects
for each type,
specified in the domain + problem
We assume the objects are unique:
robot1 != robot3,
because their names are different
We assume domain closure:
No other objects exist
than the ones specified
in the domain + problem instance
36
jonkv@ida
States 1: First-order Representation
We can calculate all ground atoms
adjacent(loc1,loc1)
adjacent(loc1,loc2)
…
adjacent(loc7,loc7)
attached(pile1,loc1)
…
To know the current state,
we must somehow specify the value
of all of these ground atoms

37
Important: Here, states have internal structure!
We can see
the difference
between two states
s0
1
2
3
s0 top(1) is true
top(2) is false
top(3) is false
on(1,1) is false
on(1,2) is true
on(1,3) is false
on(2,1) is false
…
take(1,B) s1
put(1,C) s2
put(1,B)
take(1,C)
s1 top(1) is false
top(2) is true
top(3) is false
on(1,1) is false
on(1,2) is false
on(1,3) is false
on(2,1) is false
…
Structure is essential!
We will see later how
planners make use of
structured states…
jonkv@ida
States 2: Internal Structure

38
Efficient specification / storage of a single state:
 Specify which facts are true
▪ All other facts have to be false – what else would they be?
  A state can be specified as a set of all variable-free atoms that are true
▪ s0 = { on(1,2), on(2,3), in(1,B), in(2,B), in(3,B), top(1), bot(3) }
s0
1
2
3
s0 top(1)
on(1,2)
on(2,3)
bot(3)
in(1,B)
in(2,B)
in(3,B)
take(1,B) s1
put(1,C) s2
put(1,B)
take(1,C)
s1 hold(1)
top(2)
on(2,3)
bot(3)
top(1) ∈ s0  top(1) is true in s0
top(2) ∉ s0  top(2) is false in s0
in(2,B)
in(3,B)
s2 top(1)
top(2)
on(2,3)
bot(3)
bot(1)
in(1,C)
in(2,B)
in(3,B)
Why not store all ground atoms
that are false instead?
jonkv@ida
States 3: First-order Representation

39
Initial states in classical representation and PDDL:
 We assume complete information about the
initial state (before any action)
 Classical representation:
▪ Set of true atoms
Complete within the model:
We must know everything
about those predicates and objects
we have specified...
 In PDDL: Similar
Lisp-like notation again:
▪ (define (problem dwr-problem-1)
(attached p1 loc), not
(:domain dock-worker-robot)
attached(p1,loc)
(:objects …)
(:init
(attached p1 loc1) (in c1 p1) (on c1 pallet) (in c3 p1) (on c3 c1) (top c3 p1)
(attached p2 loc1) (in c2 p2) (on c2 pallet) (top c2 p2)
(belong crane1 loc1) (empty crane1)
(at r1 loc2) (unloaded r1) (occupied loc2)
(adjacent loc1 loc2) (adjacent loc2 loc1)
loc2
c2
)
c3
p2
)
c1
p1
loc1
r1
jonkv@ida
States 4: Initial State in PDDL

40
The objective is to reach a goal state satisfying a goal criterion
 In the book's classical representation:
▪ A goal is a set of goal literals: {in(c1,p2), in(c3,p2)} – can contain negations
 In PDDL:
▪ A goal is a goal formula (could possibly have disjunction, quantification, …)
▪ Basic STRIPS expressivity: Formula = conjunction of positive literals
(even more restrictive than above!)
 Example: Containers 1 and 3 should be in pile 2
▪ We don't care about their order, or any other fact
▪ (define (problem dwr-problem-1)
(:domain dock-worker-robot)
(:objects …)
c2
(:goal (and (in c1 p2) (in c3 p2))))
c3
p2
c1
p1
loc1
loc2
r1
jonkv@ida
States 5: Goal States

41
Some planners: Conjunctions of positive / negative literals
 Example:
▪ Containers 1 and 3 should be in pile 2
▪ Container 2 should not be in pile 4
▪ (:requirements :negative-preconditions …)
▪ (define (problem dwr-problem-2)
(:domain dock-worker-robot)
(:objects …)
(:goal (and (in c1 p2) (in c3 p2) (not (in c2 p4)) )
 Buggy support in some planners
▪ Can be worked around
▪ Define outside predicate = inverse of in
▪ Make sure actions update this
▪ (:goal (and (in c1 p2) (in c3 p2)
(outside c2 p4) )
c3
c1
p1
loc2
c2
p2
loc1
r1
jonkv@ida
States 6: Goal States

Terminology:
 An operator is normally parameterized
▪ take(crane, location, container1, container2, pile)
 An action is normally ground
▪ take(crane1, loc2, c3, c1, p1)
 An operator can be instantiated to a set of actions
▪ Given any combination of parameters
of the correct type
43
jonkv@ida
Terminology

44
In the book's classical representation:
▪ take(k, l, c, d, p):
;; crane k at location l takes container c off container d in pile p
precond: belong(k,l), empty(k), attached(p,l), top(c,p), on(c,d)
effects: holding(k,c), ¬empty(k), ¬in(c,p), ¬top(c,p), ¬on(c,d), top(d,p)
precond(o): set of literals (negated or positive atoms)
that must hold in the state where the action is started
effects(o): set of literals (negated or positive atoms)
that will be made to hold by the action
c3
c1
p1
loc2
c2
p2
loc1
r1
jonkv@ida
Operators

45
Notation for the classical representation:
 If
▪
▪
▪
▪
a is an operator or action…
precond+(a)
precond–(a)
effects+(a)
effects–(a)
= { atoms that appear positively in a’s preconditions }
= { atoms that appear negatively in a’s preconditions }
= { atoms that appear positively in a’s effects }
= { atoms that appear negatively in a’s effects }
 Example:
▪ take(k, l, c, d, p):
;; crane k at location l takes container c off container d in pile p
precond: belong(k,l), empty(k), attached(p,l), top(c,p), on(c,d)
effects: holding(k,c), ¬empty(k), ¬in(c,p), ¬top(c,p), ¬on(c,d), top(d,p)
▪ effects+(take(k,l,c,d,p)) = { holding(k,c), top(d,p) }
▪ effects–(take(k,l,c,d,p)) = { empty(k), in(c,p), top(c,p), on(c,d) }
Negation
disappears!
jonkv@ida
Notation

46
Action  ground
 preconds are
ground atoms
An action a is applicable in a state s…
 … if precond+(a) ⊆ s and precond–(a) ∩ s = ∅

Example:
Simple representation (sets)
 simple definitions!

take(crane1, loc1, c3, c1, p1):
;; crane1 at loc1 takes c3 off c1 in pile p1
precond: belong(crane1,loc1), empty(crane1),
attached(p1,loc1), top(c3,p1), on(c3,c1)
effects: holding(crane1,c3), ¬empty(crane1),
¬in(c3,p1), ¬top(c3,p1), ¬on(c3,c1), top(c1,p1)

s1 = {
attached(p1,loc1), in(c1,p1), on(c1,pallet),
attached(p2,loc1), in(c2,p2), on(c2,pallet),
belong(crane1,loc1), empty(crane1),
at(r1,loc2), unloaded(r1), occupied(loc2),
adjacent(loc1,loc2), adjacent(loc2,loc1)
}
in(c3,p1), on(c3,c1), top(c3,p1),
top(c2,p2),
c3
c1
p1
loc2
c2
p2
loc1
r1
jonkv@ida
Applicable Actions

47
Applying will add positive effects, delete negative effects
 If a is applicable in s, then
the new state is (s – effects–(a)) ∪ effects+(a)
 Indirectly specifies the transition relation!
 take(crane1, loc1, c3, c1, p1):
;; crane1 at loc1 takes c3 off c1 in pile p1
precond: belong(crane1,loc1), empty(crane1),
attached(p1,loc1), top(c3,p1), on(c3,c1)
effects: holding(crane1,c3), top(c1,p1),
¬empty(crane1), ¬in(c3,p1), ¬top(c3,p1), ¬on(c3,c1)
c3
c1
p1
loc2
c2
p2
loc1
r1
c3
loc2
c2
c1
p1
p2
loc1
r1
jonkv@ida
Result of Performing an Action

48
PDDL: Operators are called actions, for some reason…
▪ (define (domain dock-worker-robots) …
(:action move
:parameters (?r – robot
?from ?to - location)
Typed params
 can only instantiate
with the intended objects
:precondition (and (adjacent ?from ?to)
(at ?r ?from)
(not (occupied ?to)))
:effect (and (at ?r ?to) (not (occupied ?from))
(occupied ?to) (not (at ?r ?from))
)
Written
as logical conjunctions,
)
instead of sets!
PDDL supports
more expressive preconds and effects
than the pure classical representation
(but not all planners do).
c3
c1
p1
c2
p2
loc1
loc2
r1
jonkv@ida
Operators in PDDL

49
Usual assumption in domain-independent planning:
 Preconditions should have to do with executability, not suitability
▪ Weakest constraints under which the action can be executed
take(crane1, loc1, c3, c1, p1):
;; crane1 at loc1 takes c3 off c1 in pile p1
These are physical
precond:belong(crane1,loc1), empty(crane1),
requirements for taking a
attached(p1,loc1), top(c3,p1), on(c3,c1)
container!
effects: holding(crane1,c3), top(c1,p1),
¬empty(crane1), ¬in(c3,p1), ¬top(c3,p1), ¬on(c3,c1),
 The planner chooses which actions are suitable, using heuristics (etc.)
 Add explicit “suitability preconditions”  domain-configurable planning
▪ ”Only pick up a container if there is a truck on which the crane can put it”
▪ ”Only pick up a container if it needs to be moved according to the goal”
jonkv@ida
Modeling: What Is a Precondition?