|
||||
Most of the content on this page was adapted from notes by Patrick Doherty found here. Planning Domain Definition LanguageIntroductionThe Planning Domain Definition Language (PDDL) is a language for defining planning domains and problems. It was initiall developed to support the 1998 and 2000 International Planning Competitions. It was first developed by a group of researchers lead by Drew McDermott and has evolved with each International Planning Competition. read the description of PDDL 1.2 and a subsequent paper by Mcdermott on the 1998 IPC. PDDL incorporates the STRIPS formalism, Pendault's Action Description language (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
ExamplesSeveral 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 DefinitionA PDDL definition consists of two parts: The domain and the problem definition. Although not required by the PDDL standard, many planners require that the two parts are in separate files.CommentsComments in a PDDL file start with a semicolon (";") and last to the end of the line.RequirementsBecause PDDL is a very general language and most planners support only a subset, domains may declare requirements. The most commonly used requirements are:
The Domain DefinitionThe 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 DefinitionsAll 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 FormulasIn a STRIPS domain, a precondition formula may be:
In an ADL domain, a precondition may in addition be:
Effect FormulasIn 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:
In an ADL domain, an effect formula may in addition contain:
The Problem DefinitionThe 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) (: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.) TypingPDDL 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.
|