Contributors: Adam Green, Jan Dolejsi,
As with all previous installations of PDDL, PDDL 3.0 introduces new requirements. It also introducing syntax for defining constraints. Constraints are form of goal which must be satisfied in all states of the plan.
As an additional curiosity note, whilst it may seem that a constraint adds more complexity to a state space, in general it allows us to reduce it significantly, by increasing the number of invalid states.
(define (domain logistics) (:requirements :preferences :constraints) (:types lorry package recipient location - object ) (:predicates (deliver-to ?r - recipient ?p - package) (delivered ?p - package) (in ?p - package ?l - lorry) (at ?l - lorry ?loc - location) ) (:constraints (and (forall (?l - lorry ?loc - location) (at-most-once (at ?l ?loc))) ... additional constraints omitted ) ) ; Actions omitted )
Requirements are similar to import/include statements in programming languages, however as PDDL is a kind of declarative language, it is a
:requirement as a given planner is “required” to facilitate some aspect of the language.
:requirements can be specified through a space separated list e.g.
(:requirements :strips :adl :typing)
This is a list of requirements that were added by PDDL3.0 to the language of PDDL.
(:constraints <logical_expression> )
Constraints are a conjunction of various
exists statements, which can make use of the keywords designed to facilitate preferences. Constraints are essentially facts which must be true in all states within a valid plan.
Essentially a constraint expresses something we want to always be true, or some state-trajectory constraint (A constraint on how the state changes over time) . e.g.
(:constraints (and (forall (?l - lorry ?loc - location) (at-most-once (at ?l ?loc))) ... additional constraints omitted ) )
The single constraint shown above expresses that for each lorry and location, the lorry should visit that location at most once.
These kind of expressions can help planners reduce the number of states they need to explore by enforcing common sense logic.
Now it may seem logical that if packages can be delivered in any particular order and there could potentially be more than one package to be delivered to a single location, that we would want to express that we only visit any given location exactly once with a given lorry (thus preventing us going to the same place twice).
Users of this feature should be cautious of not ruling out non-apparent solutions. If for example we were planning a lorry based on fuel cost, it may be appropriate for a lorry to visit a location (such as a city) twice, once to deliver a package at the start of the journey, and once at the end to refuel for the journey home at a cheap fuel station.
always state-trajectory constraint expresses that every state reached in the execution of the plan, contains the predicate specified.
It essentially creates a constant predicate. In the case below we say that
package1 is in
lorry1 for all states reached by the plan.
always (in package1 lorry1)
sometime state trajectory constraint expresses at some point within the states reached by a plan, that the predicate specified is true.
It essentially says, at some point, this fact is true. In the case below we’re saying that at some point,
lorry1 should be in
sometime (at lorry1 glasgow)
within <number> <predicate>
within state-trajectory constraint express that some predicate must become true within the specified number of plan steps.
This is a rather unusual constraint because it varies between temporal and STRIPS domain. The number in the statement expresses the point in time in temporal plans. The number in the statement expresses the number of plan steps in STRIPS plans.
within 10 (at lorry1 collectionpoint)
at-most-once state-trajectory constraint expresses that a fact be true at most once. It is useful to prevent repeated visits to the same fact. e.g.
at-most-once (at lorry1 theendoftheworld)
sometime-after <before_predicate> <after_predicate>
sometime-after state-trajectory constraint expresses that some predicate becomes true, at some point after a separate predicate becomes true.
sometime-after (at lorry1 london) (at lorry1 pompey)
The above statement expresses that once
lorry1 has been in london some point afterwards in should be in
sometime-before <after_predicate> <before_predicate>
sometime-before state-trajectory constraint expresses that some predicate should become true, before a separate predicate becomes true. e.g.
sometime-before (delivering lorry1) (at lorry1 warehouse)
The above statement expresses that before
lorry1 is marked as delivering it should have been
warehouse (i.e. to pickup goods).
always-within <number> <condition> <predicate>
The always within expresses a composition of
within, essentially it says that whenever some condition/predicate is true, then within the specified number of steps/time, the other predicate should become true.
hold-during <number> <number> <predicate>
holding-during state-trajectory constraint expresses that a predicate should hold true between the two points in time expressed. Essentially, action as an
always with a fixed start and end point.
hold-during 20 30 (at lorry1 lorrycarpark)
The statement above expresses that
lorry1 should be parked between the points in time
30. If we imagine that time in our problem represents hours, then
20 would be 8PM on the first day, and
30 would be 6AM on the next day.
hold-after <number> <predicate>
hold-after state-trajectory constraint expresses that a predicate should hold true after some point in time.
Note that this predicate must remain true, forever after the give point. This makes it assymetric to
within which only expresses a fact must become true before some point at least once.
hold-after 40 (empty lorry1)
The above statement indicates that
lorry1 should be
40 and remain empty.