Contributors: adamgreen, Adam Green, Jan Dolejsi,
New syntax is added to PDDL problems in PDDL3. This syntax allows us to express preferences as part of the
:goal section of a problem file.
(define (problem logistics1) (:domain logistics) (:objects lorry1 lorry2 lorry3 - lorry p1 p2 p3 p4 - package r1 r2 r3 - recipient london portsmouth glasgow - location ) (:init ... omitted ) (:goal (preference visitLDNthenGLS (sometime-after (at lorry1 london) (at lorry1 glasgow)) ) ) (:metric (minimize (is-violated visitLDNthenGLS))) )
preference <name> <goal>
A preference is a soft goal, which often uses a state-trajectory constraint to express its goal. A preference/soft goal is a goal which does not need to be met in order for a plan to be valid but may incur a cost if the preference is not met.
The syntax of a preference is defined such that it can be used as part of a conjunctive goal definition, meaning we can define preferences and goals together. An example preference below shows that
lorry1 would ideally visit
london before it visits
(preference visitLDNthenGLS (sometime-after (at lorry1 london) (at lorry1 glasgow)) )
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.
For a full definition of the metric block in PDDl, please see PDDL 2.1
The metric is a numeric function which must either be minimized or maximised. PDDL3 extends on the definition in PDDL2.1 to include a helper function
is-violated <name> which when given the name of a preference, gives a count of the number of times that constraint has been violated.
In some cases, users may wish to weight certain preferences as being more costly than others, using a
* operator, we can multiply the number of violations by a violation cost, to give us a total cost for violating that preference.
e.g. Imagine we have two preferences,
lorryEndsAtDepot we can define a metric something like this
(:metric (+ (* (is-violated visitLDNthenGLS) 10) (* (is-violated lorryEndsAtDepot) 5) ) )
The metric above essentially costs more not to visit
glasgow than for the
lorry to end at the depot.
Usage notes: a preference can be violated once, or multiple times depending on how it’s defined. This is not covered in this reference, for more details see section 3.1 of Plan Constraints and Preferences in PDDL 3 [Gerevini, A. Long, D.]
- PDDL - The Planning Domain Definition Language, [Ghallab, M. Howe, A. Knoblock, C. McDermott, D. Ram, A. Veloso, M. Weld, D. Wilkins, D.]
- PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains, [Fox, M. Long, D.]
- PDDL2.2: The Language for the Classical Part of the 4th International Planning Competition [Edelkamp, S. Hoffmann, J.]
- Plan Constraints and Preferences in PDDL 3 [Gerevini, A. Long, D.]
- BNF Description of PDDL 3.0 [Gerevini, A. Long, D.]
- PDDL Examples
- OPTIC - Optimising Preferences and Time Dependent Costs