Modeling Classical
Planning Domains
Some common modeling issues
jonas.kvarnstrom@liu.se – 2015

Consider modeling a ”drive” operator for a truck
 ”Natural” parameters: The truck and the destination
▪ (:action drive :parameters (?t – truck ?dest – location)
:precondition …
:effect …
)
 ”Natural” precondition:
▪ There must exist a path between the current location and the destination
▪ Should use the predicate (path-between ?loc1 ?loc2 – location)
▪ State variable representation  can express the location of the truck:
(:precondition (path-between (location-of ?t) ?dest))
▪ But in a first-order predicate representation,
we can only test whether a truck is at some specific location:
(at ?t ?location)
3
jonkv@ida
Property Values 1

Standard solution:
 Add a parameter to the operator
▪ (:action drive :parameters (?t – truck ?from – location ?dest – location)
:precondition …
:effect …
)
 Constrain that variable in the precondition
▪ :precondition (and (at ?t ?from) (path-between ?from ?dest))
▪ Can only apply those instances of the operator
where ?from is the current location of the truck
4
jonkv@ida
Property Values 2

Example:
 Initially:
▪ (at truck5 home)
5
These parameters are "extraneous"
in the sense that they do not add choice:
We can choose truck and dest (given some constraints):
from is uniquely determined by state + other params!
 Action:
▪ (:action drive :parameters (?t – truck ?from – location ?dest – location)
:precondition (and (at ?t ?from) (path-between ?from ?dest))
:effect …
)
 Which actions are executable?
▪ (drive truck5 work home) – no, precond false
▪ (drive truck5 work work) – no, precond false
▪ (drive truck5 work store) – no, precond false
▪ (drive truck5 home store) – precond true, can be applied!
With quantification, we could have changed the precondition:
(exists (?from – location) (and (at ?t ?from) (path-between ?from ?dest))
No need for a new parameter – in this case…
jonkv@ida
Property Values 3

6
What about effects?
 Same ”natural” parameters: The truck and the destination
▪ (:action drive :parameters (?t – truck ?dest – location)
:precondition …
:effect …
)
 ”Natural” effects:
▪ The truck ends up at the destination:
▪ The truck is no longer where it started:
(at ?t ?dest)
(not (at ?t …???... ))
 How do you find out where the truck was before the action?
▪ Using an additional parameter still works:
(not (at ?t?from))
▪ The value of ?from is constrained in the precondition – before
▪ The value is used in the effect state
jonkv@ida
Property Values 4

8
We often need at least some ”primitive” support for counting
 Elevator domain:
▪ Which floor is an elevator at?
▪ Which is the next floor?
▪ Which is the previous floor?
 Few planners support general numeric state variables
jonkv@ida
Counting 1

9
Standard solution:
 Create a type of ”pseudo-numbers”
▪ (:types … num …)
 Define a set of value objects
▪ (:objects … n0 n1 n2 n3 n4 n5 n6 n7 – num)
 Define the operations you need – for example, find the next number
▪ (:predicates … (next ?numA ?numB – num)
▪ (:init … (next n0 n1) (next n1 n2) (next n2 n3) … (next n6 n7))
 Use the value objects as if they were numbers
These are also
▪ (:action move-up
"extraneous" parameters…
:parameters (?e – elevator ?from ?to – num)
:precondition (and (at ?elevator ?from) ;; Where is the elevator?
(next ?from ?to) …) ;; Now ”to” is the next number
:effects
(and (not (at ?elevator ?from)) (at ?elevator ?to)))
There is no ”next” for n7
 Won’t be able to move up from the top floor
(an "implicitly modeled" precondition)
jonkv@ida
Counting 2

11
Some planners lack support for explicit types
 Constants are untyped, operators have untyped parameters, …
 Consider an untyped operator in the Logistics domain:
▪ (:action load-truck :parameters (?obj ?truck ?loc)
:precondition (and (at ?truck ?loc) (at ?obj ?loc))
(and (not (at ?obj ?loc)) (in ?obj ?truck)))
:effect
 This is a valid instance of that action:
▪ (load-truck truck1 truck1 loc2)
;; Truck1 loads truck1 at location loc2
So how do we ensure an untyped planner never uses that action?
jonkv@ida
Untyped Domains

12
Standard solution: Preconditions use type predicates
 Ordinary predicates that happen to represent types:
▪ (:predicates (OBJ ?x)
(TRUCK ?x)
(AIRPLANE ?x)
(CITY ?x)
(at ?x ?y)
(in ?x ?y)
(LOCATION ?x)
(AIRPORT ?x)
(in-city ?x ?y))
 Initialized in the problem instance:
▪ (:init (OBJ package1) (OBJ package2) …
 Used as part of preconditions:
▪ (:action LOAD-TRUCK :parameters (?obj ?truck ?loc)
:precondition (and
(OBJ ?obj) (TRUCK ?truck) (LOCATION ?loc)
(at ?truck ?loc) (at ?obj ?loc))
:effect
(and (not (at ?obj ?loc)) (in ?obj ?truck)))
 Since we don’t have ”real” types:
▪ load-truck(truck1, truck1, loc2) is still a valid action
▪ Doesn’t matter: Its preconditions can never be satisfied in reachable states!
▪ OBJ, TRUCK and LOCATION are static (never modified)
 such actions can be ignored by all planners
jonkv@ida
Untyped Domains (2)

13
What about Dock Worker Robots?
 Shown in an earlier lecture
 Did not have explicit type predicates:
▪ 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)
 This is a valid instance of that action:
▪ take(c3, crane1, r1, crane2, r2)
;; Container c3 at location crane1 takes robot1 off crane2 in pile robot2
Was the DWR specification wrong?
jonkv@ida
Untyped Domains (3)

14
What’s important:
 Given arguments of the wrong type, the precondition is false!
▪ take(k, l, c, d, p): ;; crane k at location l takes container c off container d in pile p
belong(k,l), empty(k), attached(p,l), top(c,p), on(c,d)
precond:
effects:
holding(k,c), ¬empty(k), ¬in(c,p), ¬top(c,p), ¬on(c,d), top(d,p)
▪ The precondition requires belong(k,l):
(belong ?k - crane ?l - location)
; crane ?k belongs to location ?l
▪ In any "reasonable" initial state, this is only true if k really is a crane
▪ Since belong is static, this will remain true in all reachable states
jonkv@ida
Untyped Domains (4)