TDDD48 Automated planning (6 ECTS)

Defining Planning Domains and Problem Instances in PDDL

These instructions were adapted
by Jonas Kvarnström from an earlier
version written by Patrik Haslum.

What is PDDL?

PDDL, the Planning Domain Definition Language, was developed with the aim of
generating a standard to replace or augment a variety of existing planning
domain and problem description languages. It was created mainly to make a
series of International Planning Competitions possible.

PDDL supports the full expressivity of STRIPS and ADL, as well as a
large set of extensions of varying complexity. Providing full
support for all aspects of PDDL is a very complex task. In fact,
many planners support only the STRIPS subset, possibly with a few
extensions. The most important of these extensions are indicated in
the list of available planners.

We will now give a brief introduction to PDDL. If you want more details,
the International Planning Competition web pages contain a list
of papers
related to PDDL, including definitions of PDDL 1.2, 2.1, 2.2, and 3.0.

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

Unfortunately, most planners' parsers are quite simple and often written under
the assumption that you already know which parts of PDDL the planner supports.
They often ignore the :restrictions clause – if you use a
feature of PDDL they don't support, they give you a parse error without
further information. Nevertheless, you should declare the correct
requirements in any domain you write.

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.

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

Names (of domains, predicates, actions, etc.) can usually contain alphanumeric
characters, hyphens ("-") and underscores ("_"). There may
be planners that allow less. Some planners use the same namespace for
different items, so that you cannot (for example) use the same name for a
domain and for a type.

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

For untyped domains, 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 the predicate name still has to be written within parentheses.

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 be used to
instantiate two parameters. This may cause some difficulties
(e.g. problems becoming unsolvable) if one is not aware of
it. See the domain
definition slidetile.pddl
and the two problem
definitions eight01.pddl
and eight01x.pddl
for an example of this problem and how to fix it.

Actions: Precondition Formulas

In a STRIPS domain, a precondition formula may be:

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)

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.

Actions: 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:

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)

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

Note that you can't use "exists" in action effects, since that would correspond to
non-deterministic effects.

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.

Note that nested use of "when" and "and" will confuse some planners. In general,
don't nest conditions more than necessary, and try to keep your expressions
simple and readable. Most operators can be written using a single list of
effects with a single level of nesting: "(and (p1) (p2) (when (p3) (p4))
(p5) (p6))".

The Problem Definition

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

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. Goals are generally specified as a single conjunction: (and
(something) (somethingelse)). Few planners handle complex formulas
as goals, even though this is technically allowed in ADL.

In difference to action preconditions, 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.

Warnings and Hints

Planners often add their own assumptions about the format of a
planning domain. For example, they may require preconditions to be on the
form "(and ...)", even if the precondition only consists of a single
atom. If you have problems getting a planner to parse your domain definition,
please first try some alternatives. If this does not help, ask the lab
assistant.