Writing Planning Domains and Problems in PDDL

What is PDDL?

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 supported at the time.

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.

Examples

In /home/TDDC17/info/labs/planning/2004/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

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

Comments

Requirements

:strips

The most basic subset of PDDL, consisting of STRIPS only.

:equality

This requirement means that the domain uses the predicate =, interpreted as equality.

:typing

This requirement means that the domain uses types (see Typing below).

:adl

Means that the domain uses some or all of ADL (i.e. disjunctions and quantifiers in preconditions and goals, quantified and conditional effects).

The Domain Definition

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

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

• An atomic formula:
  (PREDICATE_NAME ARG1 ... ARG_N)
  The predicate arguments must be parameters of the action (or constants declared in the domain, if the domain has constants).
• A conjunction of atomic formulas:
  (and ATOM1 ... ATOM_N)

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

• A general negation, conjunction or disjunction:
  (not CONDITION_FORMULA)
  (and CONDITION_FORMULA1 ... CONDITION_FORMULA_N)
  (or CONDITION_FORMULA1 ... CONDITION_FORMULA_N)
• A quantified formula:
  (forall (?V1 ?V2 ...) CONDITION_FORMULA)
  (exists (?V1 ?V2 ...) CONDITION_FORMULA)

Effect Formulas

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

• An added atom:
  (PREDICATE_NAME ARG1 ... ARG_N)
  The predicate arguments must be parameters of the action (or constants declared in the domain, if the domain has constants).
• A deleted atom:
  (not (PREDICATE_NAME ARG1 ... ARG_N))
• A conjunction of atomic effects:
  (and ATOM1 ... ATOM_N)

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

• A conditional effect:
  (when CONDITION_FORMULA EFFECT_FORMULA)
  The interpretation is that the specified effect takes place only if the specified condition formula is true in the state where the action is executed. Conditional effects are usually placed within quantifiers.
• A universally quantified formula:
  (forall (?V1 ?V2 ...) EFFECT_FORMULA)

The Problem Definition

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)
  (:goal CONDITION_FORMULA)
  )

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.)

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.