planningpddl

Unexpected PDDL behavior with fluents and durative actions


I posed this as an issue with a specific planner, but it's a more general PDDL question so posing here.

I'm trying to create a plan that has durations and a limited number of things it can do in parallel. No matter what I try, SMTPlan either says it should all go in parallel, or it hangs and runs forever, or reports the plan is unsolveable. It's quite possible this is an error on my part in the PDDL, or maybe I'm tweaking some issue in the planner. To its credit, SMTPlan is the one thing I find that even comes close --- most in planutils simply dump core or complain! If anyone has pointers to other planners that should work, please post pointers....

The idea is to have a count of things that are OK to operate on, aggregated into pools (in this case I have a single "object-group" but there would be more). There's a check per object group that at all times, including after the start of the action with the start effect decrementing this count, the count should be > 0. So if I have 3 things, I expect it to operate on 2, wait 5 seconds, and operate on the 3rd. Instead the plan does all 3 at once.

Here is the simplified domain.

        (domain showbug)
        (:requirements :durative-actions :fluents :action-costs :negative-preconditions)
        (:functions
         (num-objects-unselected ?og)
         )
        (:predicates
                (object-group ?og)
                (object ?o)
                (object-in-group ?o ?og)
                (object-selected ?o)
        )
        (:durative-action select-object
                :parameters (?o ?og)
                :duration (= ?duration 5)
                :condition  (and
                             (at start (object ?o))
                             (at start (object-group ?og))
                             (at start (object-in-group ?o ?og))
                             (at start (not (object-selected ?o)))
                             (at start (> (num-objects-unselected ?og ) 0))
                             (over all (forall (?og2) (> (num-objects-unselected ?og2 ) 0)))
                           )
                :effect (and (at start (decrease  (num-objects-unselected ?og) 1))
                             (at end (object-selected ?o))
                             (at end (increase  (num-objects-unselected ?og) 1))
                             )
        )
)

And the problem instance:

        (problem showbug)
        (:domain showbug)
        (:objects
                o1 o2 o3 og1
        )
        (:init (object o1) (object o2) (object o3) (object-group og1)
               (object-in-group o1 og1) (object-in-group o2 og1) (object-in-group o3 og1)
               (= (num-objects-unselected og1) 3)
        )
        (:goal (and (object-selected o1) (object-selected o2) (object-selected o3)
               ))
)

Note that num-objects-unselected og1 goes from 3 to 2 at the start, and 5s later goes from 2 to 3. I expect that if it is selecting o1 o2 o3 at once, then it should decrement from 3 to 0. Since there is a requirement that it be above 0, it wouldn't allow all three to be selected simultaneously, exactly as I want.

If I run with debugging, I get this:

smtplan domain-bug.pddl problem-bug.pddl -d -v 
Grounded:   0.001963 seconds
Algebra:    0.003671 seconds
Encoded 1:  0.042437 seconds
Solved 1:   0.003274 seconds
Encoded 2:  0.000248 seconds
0.0:    (select-object o1 og1) [5.0]
0.0:    (select-object o2 og1) [5.0]
0.0:    (select-object o3 og1) [5.0]
0.0:    |(select-object o1 og1)0_run|   (running)
0.0:    |(select-object o2 og1)0_run|   (running)
0.0:    |(select-object o3 og1)0_run|   (running)
0.0:    |(num-objects-unselected og1)0_0| == 3.0
0.0:    |(num-objects-unselected og1)0_1| == 2.0
5.0:    |(select-object o1 og1)1_end|   (end)
5.0:    |(select-object o2 og1)1_end|   (end)
5.0:    |(select-object o3 og1)1_end|   (end)
5.0:    |(object-selected o1)1_1|
5.0:    |(object-selected o2)1_1|
5.0:    |(object-selected o3)1_1|
5.0:    |(num-objects-unselected og1)1_0| == 2.0
5.0:    |(num-objects-unselected og1)1_1| == 3.0
Goal at [5.0]
Solved 2:   0.007638 seconds
Total time: 0.117884 seconds

I expect that it would select two objects at time 0, decrementing num-objects-unselected og1 from 3 to 1, then at time 5 it would select the third object and change it from 1 to 2 (or 1 to 3 and then back down to 2), ending at time 10.


Solution

  • So if the entire exploration was on SMTPlan, you may be facing bugs that are known and ignored at this point. I'm not sure the planner is being actively maintained, and not entirely sure how to dive into diagnosing it.

    As for a rewrite to something POPF / Optic can handle, [this] is what I had in mind. Not that some spots may look a bit odd, but this is to remove the ADL aspects (no negative preconditions and existential). The plan it finds:

    ; Plan found with metric 10.002
    ; States evaluated so far: 10
    ; States pruned based on pre-heuristic cost lower bound: 0
    ; Time 0.09
    0.000: (select-object o3 og1)  [5.000]
    5.001: (select-object o2 og1)  [5.000]
    5.002: (select-object o1 og1)  [5.000]
    

    That look reasonable?