Adding PDDL+ for temporal planning

[MFaisalZaki]

Do you have any future plan that PDDL.jl includes PDDL+ or not. In case of no, how can I help with it?

[ztangent]

Hey @MFaisalZaki, great question! I would love to support it in the future, but temporal planning in general is also not a priority for me right now (compared to other extensions of PDDL). That said, I've been redesigning PDDL.jl to be as extensible as possible, and once those interfaces stabilize (they're still under development / refinement), my intention is for there to be extension packages like TemporalPDDL.jl or ProbabilisticPDDL.jl to support various additional functionality without building it into the core package. I'd say it'll take at least a month or two for me to get PDDL.jl into shape for making those extensions, but I'd be happy to chat about it again then!

[MFaisalZaki]

@ztangent sure, please feel free to contact me on [email protected]

[MFaisalZaki]

@ztangent Hello, excellent work with the current developments.
I wonder if you are still interested in integrating temporal and numerical planning.

[ztangent]

Numeric planning is already supported right now!

Temporal planning is still not a priority unfortunately, but if you're keen on making that extension happen, I'd recommend taking a look at this thesis and some of the discussion around how temporal extensions could be supported: https://dspace.mit.edu/handle/1721.1/143179

Probably the easiest thing to do is extend the parser to support durative actions and processes. After that, it'll take some work to figure out the best state representation for temporal problems - I think it would probably be a good idea to create a new TemporalState subtype of State that not only stores what facts are true, but also the history of actions and when they were taken. But exactly what to store would require some thought - I think the POPF temporal planner would be a good source of inspiration here: https://nms.kcl.ac.uk/planning/software/popf.html

If you'd like to get started on this, I'd suggest making it as an extension package called TemporalPDDL. I'll be pretty busy this coming month, but if you are interested in making this happen, I could probably get on a call and chat in early February!

[MFaisalZaki]

This will be great, let me check the thesis, and we can arrange a call in Feb.

[MFaisalZaki]

@ztangent for reference and for documenting my thoughts. We can extend the current state definition to have something like clocks::Dict{Symbol,Int}. This dictionary keeps track of the duration spent per action rather than keeping a history of past actions. then we can update those values in the execute! function. Another thing I do suggest is rather than having a separate state, TemporalState to model the temporal information, why we don't extend the current definition for non-temporal planning, we can make the duration zero by default. What do you think?

Let's talk in Feb, meanwhile I'll try to experiment with different ideas; you can find my modifications here

[ztangent]

Thanks for taking a stab at this!

Regarding extending GenericState to store temporal information, I'm reluctant to do this because storing more information will increase the memory overhead of planning algorithms. It's also unclear to me right now what is the minimal amount of temporal information we would need to store that would be useful for most downstream applications. Rather than baking that information into GenericState, I think it's best to define a new TemporalState type to store the additional information, which will allow for more evolvability in the future.

To reduce code duplication, the TemporalState can wrap a GenericState (or some other non-temporal state representation) within it, e.g., by defining a struct like:

struct TemporalState{S <: State}
    state::S
    temporal_info
end

where temporal_info is a stand-in for whatever temporal information we decide to store. You can then define various methods by just forwarding the method calls to the inner state variable, e.g.:

function PDDL.get_objects(state::TemporalState)
    return get_objects(state.state)
end

As for whether to store clocks as the temporal information, rather than the action history, I'm open to the idea, but I think the main criterion for deciding what to store is to figure out what,s the minimal information needed to perform forward simulation of a temporal plan. Ideally, this information would also be useful for a forward-chaining planner like Temporal FastDownward (TFD) or POPF.

I've taken a closer look at both the TFD paper and the POPF paper, and it seems like both of them include the idea of storing "scheduled events" (in TFD) or an "event queue" (in POPF) as part of the state representation. I think we should do something similar, so that it's possible to simulate what would happen to a (time-stamped) state if we wait for X more time.

Between TFD and POPF, it also seems to me that the TFD state representation is more minimal, in that it contains only the information you need to simulate the time evolution of a plan. In contrast, the POPF state representation also includes the action history, which is useful for coming up with a plan, but I think it should be the job of planning algorithm to store any additional information they need for planning, rather than storing that information in TemporalState.

So all-in-all, I think we should probably try to define TemporalState in a way that's similar to how TFD defines its "time-stamped states". To represent scheduled effects, I think it should be possible to associate a list of either PDDL.GenericDiff or PDDL.ConditionalDiffs with timestamps, such that each diff gets applied after the associated time has passed.

Hopefully this helps in the meantime, and we can talk more in February!

[MFaisalZaki]

Hi @ztangent, I hope you are going great. I was hoping we could chat quickly since I have time now to work on the Temporal extension for PDDL.