I'm working with PDDL2.1 durative-actions and I'm having difficulty understanding the purpose of over all.
I have a function charge_level which is updated with a value every 10Hz. In a durative-action move, I say condition: (over all (>= (charge_level) 12)).
I interpreted this as "while performing the action, verify that charge_level is greater than or equal to 12, otherwise, move fails and the planner should find a new action with the condition at start (< (charge_level) 12)". However, the planner does not seem to plan that way. I appreciate any clarity on this.
Thanks!
The semantics of the over all condition is indeed as @haz says in his answer (it prevents the planner from scheduling another action in parallel with your move action that would violate the over all condition), but what I think is confusing you is the difference between planning and plan execution. During plan execution, the (charge_level) may drop below 12 at any point unexpectedly due to malfunctioning battery, or faulty sensor, etc.. At such occasion, your plan execution should stop the move action (and therefore the whole plan) and re-plan. At that point, the planner could choose any action, which has a satisfied pre-condition in that new state. So not necessarily at start (< (charge_level) 12).
The PDDL durative action cannot be stopped or paused by the planner, while computing the plan. However, if you tell the planner, how is the (charge_level) changing over time, it could compute the longest possible duration of the move action, and then do something else e.g. recharge battery, before scheduling another instance of the move action into the same plan. In that approach, there are no failures involved, just reasoning about how long a given action could last in order to achieve the goal without violating any constraints, including the over all conditions.
If that is the behavior you want, you will need to model the (charge_level) as a continuously changing function. If you want to see an example, here is the power generator or the coffee machine. Here is a peek from the Generator domain:
The generator must not run out of fuel:
(over all (>= (fuel-level ?g) 0))
The fuel decreases by 1 unit every unit of time #t.
(decrease (fuel-level ?g) (* #t 1))
Given the initial (fuel-level), it is a simple calculation to figure out the maximum duration of the action. For that flexibility, you will need to specify the action duration unconstrained :duration (>= ?duration 0), as in the coffee machine domain.
Now, to be able to process such model including continuous numeric effects, you will need a planner that supports the :continuous-effects requirement, so for example OPTIC, or POPF.