next up previous
Next: Problems Up: BNF Specification of PDDL2.1 Previous: Actions

Durative Actions

Durative action syntax is built on a relatively conservative extension of the existing action syntax.

 <durative-action-def> ::= (:durative-action <da-symbol>

:parameters ( <typed list (variable)> )
<da-def body>)
<da-symbol> ::= <name>
<da-def body> ::= :duration <duration-constraint>
:condition <da-GD>
:effect <da-effect>

The conditions under which a durative action can be executed are more complex than for standard actions, in that they specify more than the conditions that must hold at the point of execution. They also specify the conditions that must hold throughout the duration of the durative action and also at its termination. To distinguish these components we introduce a simple temporal qualifier for the preconditions. The use of the name ``precondition'' would be somewhat misleading given that the conditions described can include constraints on what must hold after the action has begun. This has motivated the adoption of :condition to describe the collection of constraints that must hold in order to successfully apply a durative action. The logical form of conditions for durative actions has been restricted to conjunctions of temporally annotated expressions, but there is clearly scope for future extension to allow more complex formulae.

 <da-GD>   ::= () 

<da-GD> ::= <timed-GD>
<da-GD> ::= (and <timed-GD>$^{\tt +}$)
<timed-GD> ::= (at <time-specifier> <GD>)
<timed-GD> ::= (over <interval> <GD>)
<time-specifier> ::= start
<time-specifier> ::= end
<interval> ::= all

The duration (?duration) of a durative action can be specified to be equal to a given expression (which can be a function of numeric expressions), or else it can be constrained with inequalities. This latter allows for actions where the conclusion of the action can be freely determined by the executive without necessarily having further side-effects. For example, a walk between two locations could be made to take as long as the executive considered convenient, provided it was at least as long as the time taken to walk between the locations at the fastest walking speed possible. Constraints that do not specify the exact duration of a durative action might prove harder to handle, so we have introduced a label (:duration-inequalities) to signal that a domain makes use of them. A duration constraint is supplied to dictate or limit the temporal extent of the durative action. The duration is an implicit parameter of the durative action and must be supplied in a plan that uses durative actions. To denote this, a durative action is denoted in a plan by t:(name arg1...argn)[d] where d is the (non-negative, rational valued) duration in floating point format ($n.n$). Duration constraints can be explicitly temporally annotated to indicate that they should be evaluated in the context of the start or end point of the action, or else they can be left unannotated, in which case the default is that they are evaluated in the context at the start of the action (as indicated in Definition 16).

 <duration-constraint>  ::= $^{\tt :duration-inequalities}$

(and <simple-duration-constraint>$^{\tt +}$)
<duration-constraint> ::= ()
<duration-constraint> ::= <simple-duration-constraint>
<simple-duration-constraint> ::= (<d-op> ?duration <d-value>)
<simple-duration-constraint> ::= (at <time-specifier>
<d-op> ::=$^{\tt :duration-inequalities}$ <=
<d-op> ::=$^{\tt :duration-inequalities}$ >=
<d-op> ::= =
<d-value> ::= <number>
<d-value> ::=$^{\tt :fluents}$ <f-exp>

In addition to logical effects, which can occur at the start or end of a durative action, durative actions can have numeric effects that refer to the literal ?duration. More sophisticated durative actions can also make use of functional expressions describing effects that occur over the duration of the action. This allows functional expressions to be updated by a continuous function of time, rather than only step functions.

 <da-effect> ::= ()

<da-effect> ::= (and <da-effect>$^*$)
<da-effect> ::= <timed-effect>
<da-effect> ::=$^{\tt :conditional-effects}$ (forall (<variable>$^*$) <da-effect>)
<da-effect> ::=$^{\tt :conditional-effects}$ (when <da-GD> <timed-effect>)
<da-effect> ::=$^{\tt :fluents}$ (<assign-op> <f-head> <f-exp-da>)
<timed-effect> ::= (at <time-specifier> <a-effect>)
<timed-effect> ::= (at <time-specifier> <f-assign-da>)
<timed-effect> ::=$^{\tt :continuous-effects}$ (<assign-op-t> <f-head> <f-exp-t>)
<f-assign-da> ::= (<assign-op> <f-head> <f-exp-da>)
<f-exp-da> ::= (<binary-op> <f-exp-da> <f-exp-da>)
<f-exp-da> ::= (- <f-exp-da>)
<f-exp-da> ::=$^{\tt :duration-inequalities}$ ?duration
<f-exp-da> ::= <f-exp>

Note that the ?duration term can only be used to define functional expression updating effects if the duration constraints requirement is set. This is because in other cases the duration value is available as an expression, whereas when duration constraints are provided the duration can, sometimes, be freely selected within constrained boundaries.

 <assign-op-t>  ::= increase 

<assign-op-t> ::= decrease
<f-exp-t> ::= (* <f-exp> $\char93 $t)
<f-exp-t> ::= (* $\char93 $t <f-exp>)
<f-exp-t> ::= $\char93 $t

The symbol $\char93 t$ is used to represent the period of time that a given durative action has been active. It is therefore a local clock value for each duration, independent of similar clocks for each other duration. There has been discussion with members of the committee about the use of the expression using $\char93 t$: it was proposed that an expression declaring the rate of change alone could be used. We decided against this on the grounds that the assertion of a rate of change suggests that the rate of change is determined by one process effect alone. In fact, it is intended that if multiple active processes affect the same fluent then these effects are accumulated. Using the expression that directly defines the amount by which each process contributes to the change in a fluent value over time we do not appear to assert (inconsistently) that a fluent has multiple simultaneous rates of change.

next up previous
Next: Problems Up: BNF Specification of PDDL2.1 Previous: Actions
Derek Long 2003-11-06