Requirements in PDDL are very important. Generally, we can obtain the syntax supported by the current version of PDDL from all requirements of different versions of PDDL. At the same time, adding parameters to the requirements can judge whether the planner used supports a certain syntax (you can also directly start with the requirements mentioned in the paper corresponding to the planner), It can be said that requirements is an indispensable step in learning each version of PDDL.

It is also inevitable that we may encounter a vulnerability that the planner claims to support but in fact only supports syntax parsing...

Here are all the requirements from PDDL to PDDL 3.0 and a brief introduction

:STRIPS

(:requirements :strips)

Allows you to use the basic add and remove effects specified in strings.

; Add:
:effect (walls-built ?s)

; Delete:
:effect (not (walls-built ?s))

:TYPING

(:requirements :typing)

Allow object typing. Typing is similar to classes and subclasses in object-oriented programming

(:types
    site material - object
    bricks cables windows - material
)

:Preferences

(:requirements :preferences)

Allow preferences to be used in problem definitions (soft goals).

:Constraints

(:requirements :constraints)

Allow constraints in domain definitions (goals that must be met in each state)

(:constraints
    (and
    (forall (?l - lorry ?loc - location) (at-most-once (at ?l ?      loc)))
))

:Numeric Fluents

(:requirements :numeric-fluents)

Allow blocks containing: function representing numeric variables in the field.

(:functions
    (battery-amount ?r - rover)
)

:Durative Actions

(:requirements :durative-actions)

Allow durative action to be used in domain definitions. Continuous action refers to an action with completion duration.

(:durative-action move
    :parameters (<arguments>)
    :duration (= ?duration 5)
    :condition (logical_expression)
    :effect (logical_expression)
)

:Durative Inequalities

(:requirements :durative-inequalities)

Inequalities are allowed to represent duration. We can express that an action has a duration range using inequality, rather than expressing that the action has a fixed length of time.

:continuous Effects

(:requirements :continuous-effects)

Allows continuous effects on numbers in continuous action. Since the persistence operation takes some time, we can model changes in values as a function of time. In fact, it supports this instability. Linear function is relatively easy for planners, but nonlinear effect is still a research field.

:Negative Preconditions

(:requirements :negative-preconditions)

Not is allowed under preconditions. The way some planners imitate actions means that they cannot deal with negative preconditions. This is a serious design flaw for each predicate, which is even more inconvenient because they are an opposite predicate and are true when it is false. That is, Rover charged and Rover not charged are mutually exclusive. When negative preconditions are not supported, we can introduce a second predicate, which represents the negation of the predicate we want to express negative preconditions.

:derived Predicates

(:requirements :derived-predicates)

Allow derived predicates in the realm

(:derived (train-usable ?t
    (and
    (train-has-guard ?t
    (train-has-driver ?t
    )
)

:Timed Initial Literals

(:requirements :timed-initial-literals)

Allow Timed Initial Literals when defining issues

(at 10 (train-not-in-use t1))

:Disjunctive Preconditions

(:requirements :disjunctive-preconditions)

Allow or objectives and prerequisites

(or
    (walls-built ?s)
    (windows-fitted ?s)
)

:Equality

(:requirements :equality)

(not (= ?s1 ?s2))

:Existential Preconditions

(:requirements :existential-preconditions)
(exists (?c - crane)
    (crane-is-free ?c)
)

:Universal Preconditions

(:requirements :universal-preconditions)

(forall (?c - crane)
    (crane-is-free ?c)
)

:Quantified Preconditions

(:requirements :quantified-preconditions)

amount to

(:requirements :existential-preconditions :universal-preconditions)

:Conditional Effects

(:requirements :conditional-effects)

when is allowed to express action effects. Basically, if something is true, this effect should also be applied.

(when
    ;Antecedent
    (and (has-hot-chocolate ?p ?c) (has-marshmallows ?c))
    ;Consequence
    (and (person-is-happy ?p))
)

:Action Expansions

(:requirements :action-expansions)

Allow action extensions. This allows you to define the effects of variant conditions and actions. In essence, we can define a MOVE action to describe a person's movement, but include different extensions to describe the movement of aircraft, train, car or walking. This has become redundant because we only express multiple actions, such as MOVE-BY-PLANE and MOVE-BY-TRAIN.

:Foreach Expansions

(:requirements :foreach-expansions)

Allows the use of foreach action extensions, basically allowing effects to be applied to one or all objects. This requirement implies the existence of requirements, so: action expansions is equivalent to (: Requirements: action expansions: foreach expansions)

:DAG Expansions

(:requirements :dag-expansions)

Allows you to mark the extensions described in Action Expansions so that you can distinguish the sub actions selected by the scheduler. For example, if we define what an move uses to move simultaneous interpreting modes, we may want to know exactly what patterns the tags use. This requirement implies the existence of requirements, so: Action Expansions is equivalent to (: Requirements: Action Expansions: DAG expansions)

:Domain Axioms

(:requirements :domain-axioms)

Axioms are allowed. Axioms are essentially predicates implied by other predicates.

See the axiom section in the PDDL 1.2 domain reference

:subgoals through Axioms

(:requirements :subgoals-through-axioms)

:Safety Constraints

(:requirements :safety-constraints)

:expression Evaluation

(:requirements :expression-evaluation)

:Fluents

(:requirements :fluents)

:Open World

(:requirements :open-world)

In the plan, it is assumed that all unknown values are false. That is, if we don't know the value of the predicate, we think it is false. This is called the "closed world" hypothesis. This requirement changes the planner's assumption of "open world". That is, unknown values are not necessarily wrong. This is rarely supported by modern planners and is usually a sign of plan execution rather than a requirement in the domain.

:True Negation

(:requirements :true-negation)

:ADL

(:requirements :adl)

:UCPOP

(:requirements :ucpop)

Please note that not every requirements planner needs to be supported. Different planners have different "strengths" and their supported syntax.

More detailed or specific requirements can be planning.wiki View in.