0% found this document useful (0 votes)
71 views

An Introduction To PDDL: Malte Helmert October 16th, AI Planning 1/15

PDDL (Planning Domain Definition Language) is a standard language for encoding planning problems. A PDDL problem specification separates a domain file defining predicates and actions from a problem file defining objects, initial state, and goals. The domain file specifies the components of a planning task like objects, predicates, and actions/operators to change state. The problem file specifies a particular problem instance by defining objects and the initial state and goals. An example gripper domain moves balls between rooms using a robot that can pick up and drop balls in either of its two arms.

Uploaded by

doiinha
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
71 views

An Introduction To PDDL: Malte Helmert October 16th, AI Planning 1/15

PDDL (Planning Domain Definition Language) is a standard language for encoding planning problems. A PDDL problem specification separates a domain file defining predicates and actions from a problem file defining objects, initial state, and goals. The domain file specifies the components of a planning task like objects, predicates, and actions/operators to change state. The problem file specifies a particular problem instance by defining objects and the initial state and goals. An example gripper domain moves balls between rooms using a robot that can pick up and drop balls in either of its two arms.

Uploaded by

doiinha
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

An Introduction to PDDL

Malte Helmert

October 16th, AI Planning

1/15

What is PDDL?

PDDL = Planning Domain Definition Language

; standard encoding language for classical planning tasks

Components of a PDDL planning task:

Objects: Things in the world that interest us.


Predicates: Properties of objects that we are interested in; can be true or false.
Initial state: The state of the world that we start in.
Goal specification: Things that we want to be true.
Actions/Operators: Ways of changing the state of the world.

Malte Helmert

October 16th, AI Planning

2/15

How to Put the Pieces Together

Planning tasks specified in PDDL are separated into two files:


1. A domain file for predicates and actions.
2. A problem file for objects, initial state and goal specification.

Malte Helmert

October 16th, AI Planning

3/15

Domain Files

Domain files look like this:


(define (domain <domain name>)
<PDDL code for predicates>
<PDDL code for first action>
[...]
<PDDL code for last action>
)
<domain name> is a string that identifies the planning domain, e.g. gripper.
Example on the web: gripper.pddl.

Malte Helmert

October 16th, AI Planning

4/15

Problem Files

Problem files look like this:


(define (problem <problem name>)
(:domain <domain name>)
<PDDL code for objects>
<PDDL code for initial state>
<PDDL code for goal specification>
)
<problem name> is a string that identifies the planning task, e.g. gripper-four-balls.
<domain name> must match the domain name in the corresponding domain file.
Example on the web: gripper-four.pddl.
Malte Helmert

October 16th, AI Planning

5/15

Running Example

Gripper task with four balls:


There is a robot that can move between two rooms and pick up or drop balls with either of
his two arms. Initially, all balls and the robot are in the first room. We want the balls to be in
the second room.

Objects: The two rooms, four balls and two robot arms.
Predicates: Is x a room? Is x a ball? Is ball x inside room y ? Is robot arm x empty? [...]
Initial state: All balls and the robot are in the first room. All robot arms are empty. [...]
Goal specification: All balls must be in the second room.
Actions/Operators: The robot can move between rooms, pick up a ball or drop a ball.

Malte Helmert

October 16th, AI Planning

6/15

Gripper task: Objects

Objects:
Rooms: rooma, roomb
Balls: ball1, ball2, ball3, ball4
Robot arms: left, right
In PDDL:
(:objects rooma roomb
ball1 ball2 ball3 ball4
left right)

Malte Helmert

October 16th, AI Planning

7/15

Gripper task: Predicates

Predicates:
ROOM(x)
BALL(x)
GRIPPER(x)
at-robby(x)
at-ball(x, y )
free(x)
carry(x, y )

true iff x is a room


true iff x is a ball
true iff x is a gripper (robot arm)
true iff x is a room and the robot is in x
true iff x is a ball, y is a room, and x is in y
true iff x is a gripper and x does not hold a ball
true iff x is a gripper, y is a ball, and x holds y

In PDDL:
(:predicates (ROOM ?x) (BALL ?x) (GRIPPER ?x)
(at-robby ?x) (at-ball ?x ?y)
(free ?x) (carry ?x ?y))

Malte Helmert

October 16th, AI Planning

8/15

Gripper task: Initial state

Initial state:
ROOM(rooma) and ROOM(roomb) are true.
BALL(ball1), ..., BALL(ball4) are true.
GRIPPER(left), GRIPPER(right), free(left) and free(right) are true.
at-robby(rooma), at-ball(ball1, rooma), ..., at-ball(ball4, rooma) are true.
Everything else is false.
In PDDL:
(:init (ROOM rooma) (ROOM roomb)
(BALL ball1) (BALL ball2) (BALL ball3) (BALL ball4)
(GRIPPER left) (GRIPPER right) (free left) (free right)
(at-robby rooma)
(at-ball ball1 rooma) (at-ball ball2 rooma)
(at-ball ball3 rooma) (at-ball ball4 rooma))
Malte Helmert

October 16th, AI Planning

9/15

Gripper task: Goal specification

Goal specification:
at-ball(ball1, roomb), ..., at-ball(ball4, roomb) must be true.
Everything else we dont care about.
In PDDL:
(:goal (and (at-ball
(at-ball
(at-ball
(at-ball

Malte Helmert

ball1
ball2
ball3
ball4

roomb)
roomb)
roomb)
roomb)))

October 16th, AI Planning

10/15

Gripper task: Movement operator

Action/Operator:
Description:
Precondition:
Effect:

The robot can move from x to y .


ROOM(x), ROOM(y ) and at-robby(x) are true.
at-robby(y ) becomes true. at-robby(x) becomes false.
Everything else doesnt change.

In PDDL:
(:action move :parameters (?x ?y)
:precondition (and (ROOM ?x) (ROOM ?y)
(at-robby ?x))
:effect
(and (at-robby ?y)
(not (at-robby ?x))))

Malte Helmert

October 16th, AI Planning

11/15

Gripper task: Pick-up operator

Action/Operator:
Description:
Precondition:
Effect:

The robot can pick up x in y with z .


BALL(x), ROOM(y ), GRIPPER(z ), at-ball(x, y ),
at-robby(y ) and free(z ) are true.
carry(z , x) becomes true. at-ball(x, y ) and free(z )
become false. Everything else doesnt change.

In PDDL:
(:action pick-up :parameters (?x ?y ?z)
:precondition (and (BALL ?x) (ROOM ?y) (GRIPPER ?z)
(at-ball ?x ?y) (at-robby ?y) (free ?z))
:effect
(and (carry ?z ?x)
(not (at-ball ?x ?y)) (not (free ?z))))
Malte Helmert

October 16th, AI Planning

12/15

Gripper task: Drop operator

Action/Operator:
Description:

The robot can drop x in y from z .

(Preconditions and effects similar to the pick-up operator.)


In PDDL:
(:action drop :parameters (?x ?y ?z)
:precondition (and (BALL ?x) (ROOM ?y) (GRIPPER ?z)
(carry ?z ?x) (at-robby ?y))
:effect
(and (at-ball ?x ?y) (free ?z)
(not (carry ?z ?x))))

Malte Helmert

October 16th, AI Planning

13/15

A Note on Action Effects

Action effects can be more complicated than seen so far.


They can be universally quantified:
(forall (?v1 ... ?vn)
<effect>)
They can be conditional:
(when <condition>
<effect>)
Example on the web: crazy-switches.pddl

Malte Helmert

October 16th, AI Planning

14/15

Questions?

Malte Helmert

October 16th, AI Planning

15/15

You might also like