Comments (8)
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!
from pddl.jl.
@ztangent sure, please feel free to contact me on [email protected]
from pddl.jl.
@ztangent Hello, excellent work with the current developments.
I wonder if you are still interested in integrating temporal and numerical planning.
from pddl.jl.
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!
from pddl.jl.
This will be great, let me check the thesis, and we can arrange a call in Feb.
from pddl.jl.
@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
from pddl.jl.
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.ConditionalDiff
s 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!
from pddl.jl.
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.
from pddl.jl.
Related Issues (16)
- Create Problem instance from code HOT 1
- Towers of Hanoi Issue HOT 1
- Trouble running the execute function HOT 1
- Generating all grounded actions for a problem instance HOT 3
- Action precondition `(not (= ?a ?b))` doesn't work HOT 6
- Confusion over the `_extras` field of `Domain` HOT 2
- `Base.propertynames(::Domain)` is ambiguous HOT 1
- Failed at parsing sokoban problems from HOT 2
- A bug in the strips test domain HOT 3
- Constraints unintuitive? HOT 3
- Hierarchical Planning HOT 2
- Error when compiling states HOT 2
- Compiler returns no solution HOT 10
- forall when PDDL failure HOT 3
- How to get grounded predicates and functions HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pddl.jl.