-
Notifications
You must be signed in to change notification settings - Fork 0
PDDL Classical Planning Syntax
Here are some remarks about the plain PDDL syntax. As usual, copy and paste these patterns to make the overall code.
classical PDDL can deal with domain-specific deterministic discrete problems. It is not able to deal with time, neither with numerical values.
-
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.
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.
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 uses a LISP-like syntax.
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 (...))
βοΈ 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...
; ...
)
π 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!
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
(: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 ...)
)
)
βοΈ 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
)
)
)
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.
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.
- pddl editor online just to try a bit what the language can offer and how it works
- Planning.wiki, a very good resource where to find infos about PDDL