Skip to content

PDDL Classical Planning Syntax

Francesco Ganci edited this page Jun 25, 2022 · 2 revisions

PDDL -- Classical Planning

Here are some remarks about the plain PDDL syntax. As usual, copy and paste these patterns to make the overall code.

πŸ“š Structure of a PDDL code

classical PDDL can deal with domain-specific deterministic discrete problems. It is not able to deal with time, neither with numerical values.

πŸ“ PDDL entities -- a glossary

  • Objects : the elements part of the world.

    Some versions of PDDL allows also to give a type to the objects, but classical planning doesn't allow it.

    the objects are specified in the problem file.

  • predicates : statements which can be true or false, corresponding to the aspects relevant for our problem. They can change during the execution of the plan, so they are state variables.

    in particular, the problem file specifies a init state as well as a goal state.

    remember that all unknown values are assumed to be false.

  • actions : an action makes the state variables to change from one status to another one. The solution plan is a set of actions, if it exists. Each action has a precondition (prerequisite), i.e. a particular status which makes applicable the action, and a effect which specifies how the status changes after the action has been applied.

πŸ“ PDDL Files

each file has extension .pddl.

  • domain file : overall informations about the problem. The domain file aims at giving the "mechanism" beneath the problem.
  • problem file : the problem statement, given a specific context. This file makes a question, to be solved with a sequence of actions, the plan.

πŸ“ the main purpose

Given a bunch of informations:

  • the "mechanics" of the problem (as a set of state variables and actions to be performed given certain conditions)
  • the entities of the problem
  • starting status and the goal to achieve

find a plan capable which makes the problem to go from the starting state to the goal state, if it exists.

βš™οΈ PDDL Syntax

⚠️ Notice that the general syntax has not a standard, hence it could change depending on the planner you're using for your project.

PDDL uses a LISP-like syntax.

🧰 Tools

Comments:

; this is a inline comment
;; PDDL doesn't allow multiple lines comments

Predicates Syntax: each predicate affirms something depending on a bunch of objects. all unknown values are assumed to be false by the planner. Each argument is an object; you don't need to specify the type of the argument: it could be everything.

;; predicate with no arguments
(zero-predicate )

;; predicate with one argument
(your-predicate-name ?your-argument)

;; with as many arguments as you want
(pred ?a1 ?a2 ?a3 ?a4 ?a5 ?a6)

logical expressions : (...) represents a predicate.

;; and
(and (...) (...) (...))

;; or
(and (...) (...) (...))

;; not (your planner could not support it)
(not (...))

πŸ’» Domain File

☝️ as usual, remember to replace ??? with what you need.

☝️ (domain ???) : the problem statement refers to this domain through the domain name given here

Here's the overall structure:

(define (domain ???)

;; it depends on your planner! usually this is enough:
(:requirements :strips)

(:predicates 
    ;; your predicates here ...
    ;  ...
)

;; and here your actions...
;  ...

)

Requirements

πŸ”— for further information about the requirements, see Planning.wiki

The section (:requirements ...) specifies the kind of "functionalities" you're going to use to define actions. The form of the statements depends on

  • the planner
  • and the kind of PDDL

for classical planning it is typically applied (:requirements :strips). Here are some other common options:

  • :strips -- basic requirement for all the PDDL projects
  • :typing -- the domain uses types
  • :adl -- it corresponds to (:requirements :strops :typing :disjunctive-preconditions :equality :quantified-preconditions :condition-effects)

See the link above if you need other requirements. Each requirement adds new syntaxes and features to your PDDL code!

Action Syntax

An action has three element:

  • :parameters : a set of objects on which to base the evaluation
  • :precondition : a status which must be verified in order to be able to apply the action
  • :effect : how the status changes, as logical expression

⚠️ Notice that the simplest planner (in the worst case) can decide to use a brute force approach to each action, trying with every possible combination of parameters for each action. That's why writing a good prrecondition is so important.

(:action ???action_name???
	:parameters ( ???list_of_the_params??? )
	:precondition (and 
		;; trivial checkings
		;; just list them
		
		;; other checkings
		;; just list them
	)
	:effect (and 
		;; NEGATIVE EFFECTS
		;; just list them
		;; (not (predicate ...))

		;; AFFERMATIVE
		;; just list them
		;; (predicate ...)
	)
)

πŸ’» Problem File

☝️ see (domain ???) before : the problem statement refers to this domain through the domain name given here

πŸ”— see PDDL problem file

A problem file is made up of 4 parts:

  • reference to the domain and name of the problem
  • a list of objects
  • init status
  • and the goal status

The problema states: given these objects in the environment whose mechanics have been defined in the domain file, and given that initial condition, can you find a plan capable to make the goal statement true?

(define (problem ???problem_name???)
    (:domain ???domain_name???)

    (:objects
        ;; just a listing of object names
        obj1 obj2
        obj3
        obj4

        obj5
    )

    (:init
        ;; list true predicate INSTANCES (replace params with objects)
        (on-site b s1)
        (predicate ...)
    )

    (:goal (and
            ;; list of AFFIRMATIVE predicate instances true
        )
    )
)

☝️ Good Practises and tricks

Object Types

How to deal with types in a language that doesn't provide type checking? Just create a predicate giving the type of the object.

For instance, if ?robot is a robot, then a predicate like this (robot ?robot) should be true.

Data associated with a type

if ?a has a object ?b, then a predicate such as this (has ?a ?b) should be true. In this way, we can associate objects to other objects.

πŸ“Ž Useful Links