Track 3

In any case, the use of PDDL to state problems simply means that we will express problems in this format:

(define (situation transplan-world)
(:domain transplan)
(:init (package p1)
(stuff p1 fuel)
...)

(define (problem prob-39)
(:domain transplan)
(:situation transplan-world)
(:init (not (available ramp72))
...)
(:expansion (parallel (transport p1 depot1 house22)
(transport p2 depot1 airport23)
...)))

The solver must then be callable with the problem name (prob-39) as argument.

Because this is a hierarchical planning domain, a solution is not just a sequence of actions. Instead, it is a sequence of actions plus a schema instantiation hierarchy, which specifies how the actions in the sequence satisfy the legal expansions of the transport actions. The details are found in the file transplan/doc.ps at the website. In the near future, we will supply a solution checker that can verify that a proposed solution works.

For Phase 1 of the competition, we will ignore fuel, time, and water constraints, and will not count plan execution time in computing a planner's score.

In Phase 2 of the competition, these constraints will become nontrivial. Then it will be possible for vehicles to fail to move for lack of fuel. Vehicles can refuel at depots, but they have to have enough fuel to reach the depots.

In Phase 3 of the competition, new plans will be added to the the standard plan library, and planners will have to cope with them.

Ideally, planners should take the PDDL domain definition as input, suitably augmented with explicit advice, as explained in the PDDL Manual. Points will be taken off for the use of advice, although the exact formula has not been arrived at yet.

Some contestants may find it burdensome to have to retarget their planners to handle PDDL input. In that case, they are allowed to rewrite the entire domain spec in their own language, subject to the following provisos: