Writing Planning Domains and Problems in PDDL

What is PDDL?

PDDL ("Planning Domain Definition Language") is a recent atempt to standardize planning domain and problem description languages. It was developed mainly to make the 1998/2000 International Planning Competitions possible.

PDDL contains STRIPS, ADL and more. Most planners, however, do not support full PDDL: in fact, the majority support only the STRIPS subset.

Here is the IPC 1998 specification of PDDL: it should be taken with a grain of salt, however. The IPC 2000 specification is significantly reduced, and closer to what most planning systems actually support.

The specification for IPC 2002 (often called PDDL 2.1) adds many new features, including numerical state variables, actions with duration and the possibility to specify a metric to optimize in addition to the logical problem goal. However, there are still not many planners supporting these extensions.


Several examples of PDDL domain and problem definitions may be found in /home/TDDA13/www-pub/labbar/planning/strips/ (using only the STRIPS subset of PDDL) and /home/TDDA13/www-pub/labbar/planning/pddl/ (using types and some ADL features).

In /home/TDDA13/labbar/planning/2003/sat/satellite/ are several variants of the Satellite domain (used in IPC 2002), which illustrate the extended features of PDDL 2.1.

Parts of a PDDL Problem Definition

A PDDL definition consists of two parts: The domain and the problem definition.

Note: Although not required by the PDDL standard, many planners require that the two parts are in separate files.


Comments in a PDDL file start with a semicolon (";") and last to the end of the line.


Because PDDL is a very general language and most planners support only a subset, domains may declare requirements. The most commonly used requirements are:
The most basic subset of PDDL, consisting of STRIPS only.
This requirement means that the domain uses the predicate =, interpreted as equality.
This requirement means that the domain uses types (see Typing below).
Means that the domain uses some or all of ADL (i.e. disjunctions and quantifiers in preconditions and goals, quantified and conditional effects).
Compare with the table in figure 11.1 (page 379) in the course book.

The Domain Definition

The domain definition contains the domain predicates and operators (called actions in PDDL). It may also contain types (see Typing, below), constants, static facts and many other things, but these are not supported by the majority of planners.

The format of a (simple) domain definition is:

(define (domain DOMAIN_NAME)
  (:requirements [:strips] [:equality] [:typing] [:adl])
  (:predicates (PREDICATE_1_NAME [?A1 ?A2 ... ?AN])
               (PREDICATE_2_NAME [?A1 ?A2 ... ?AN])

  (:action ACTION_1_NAME
    [:parameters (?P1 ?P2 ... ?PN)]
    [:precondition PRECOND_FORMULA]
    [:effect EFFECT_FORMULA]

  (:action ACTION_2_NAME


Elements in []'s are optional, for those not familiar with formal grammars.

Names (domain, predicate, action, et c.) usually may contain alphanumeric characters, hyphens ("-") and underscores ("_") (there may be some planners that allow less).

Parameters of predicates and actions are distinguished by their beginning with a question mark ("?").

The parameters used in predicate declarations (the :predicates part) have no other function than to specify the number of arguments that the predicate should have, i.e. the parameter names do not matter (as long as they are distinct). Predicates can have zero parameters (but in this case, the predicate name still has to be written within parenthesises).

Action Definitions

All parts of an action definition except the name are, according to the spec, optional (although, of couse, an action without effects is pretty useless). However, for an action that has no preconditions some planners may require an "empty" precondition, on the form :precondition () (some planners may also require an empty :parameter list for actions without parameters).

Note: Some planners require that the arguments to an action are all different, i.e. the same object may not instantiate two parameters. This may cause some difficulties (e.g. problems becomming unsolvable) if one is not aware of it. See the domain definition slidetile.pddl and the two problem definitions eight01.pddl and eight01x.pddlfor an example of this problem and how to fix it.

Precondition Formulas

In a STRIPS domain, a precondition formula may be: If the domain uses :equality, an atomic formula may also be of the form (= ARG1 ARG2). Many planners that support equality also allow negated equality, which is written (not (= ARG1 ARG2)), even if they do not allow negation in any other part of the definition.

In an ADL domain, a precondition may in addition be:

Effect Formulas

In PDDL, the effects of an action are not explicitly divided into "adds" and "deletes". Instead, negative effects (deletes) are denoted by negation.

In a STRIPS domain, an effect formula may consist of:

The equality predicate (=) can of course not occur in an effect formula; no action can make two identical things be not identical!

In an ADL domain, an effect formula may in addition contain:

The Problem Definition

The problem definition contains the objects present in the problem instance, the initial state description and the goal.

The format of a (simple) problem definition is:

(define (problem PROBLEM_NAME)
  (:domain DOMAIN_NAME)
  (:objects OBJ1 OBJ2 ... OBJ_N)
  (:init ATOM1 ATOM2 ... ATOM_N)

The initial state description (the :init section) is simply a list of all the ground atoms that are true in the initial state. All other atoms are by definition false. The goal description is a formula of the same form as an action precondition. All predicates used in the initial state and goal description should naturally be declared in the corresponding domain.

In difference to action preconditions, however, the initial state and goal descriptions should be ground, meaning that all predicate arguments should be object or constant names rather than parameters. (An exception is quantified goals in ADL domains, where of course the quantified variables may be used within the scope of the quantifier. However, even some planners that claim to support ADL do not allow quantifiers in goals.)


PDDL has a (very) special syntax for declaring parameter and object types. If types are to be used in a domain, the domain should first of all declare the requirement :typing.

Second, the type names have to be declared before they are used (which usually means before the :predicates declaration). This is done with the declaration

  (:types NAME1 ... NAME_N)

Then, to declare the type of a parameter of a predicate or action one writes ?X - TYPE_OF_X. A list of parameters of the same type can be abbreviated to ?X ?Y ?Z - TYPE_OF_XYZ. Note that the hyphen between parameter and type name has to be "free-standing", i.e. surrounded by whitespace.

The syntax is the same for declaring types of objects in the problem definition.