I have published a GitHub repository with some PDDL experiments I have mentioned in the last posts.
The repository contains domain and problem files that cover different fragments of PDDL (as of now STRIPS, numeric fluents, and durative actions), with some recommendations on the planners to use to solve them.
In my (re)exploration of PDDL I've understood better not only how different language features drive the decision of what planner to use, but also one more dimension that makes planners different: satisfiability versus optimality.
Beyond classical planning based on predicates (using :predicates and :actions in PDDL), it is possible to plan based on numeric quantities (:functions) and actions with a duration (:durative-actions). The two domains can be mixed, for example by expressing durations as functions rather than fixed numbers. Both require the use of a metric (:metric), which can be any numeric function (or just total-time for temporal domains) to be minimized or maximized.
Some planners like LPG-td can cover both domains, but more often than not planners specialize in one of the two (and not many planners cover the temporal domain).
A planner can not only cover just some construct of PDDL (say, numeric fluents but not durative actions), but also be limited to find solutions that satisfy the domain (satisficing planners) without necessarily be optimal (a task for optimal planners). Some planners such as ENHSP can even do both, but it's necessary to always make sure of the capabilities of a planner with respect to the problem to solve.
planutils server
In the previous post I mentioned the planutils project as an easy way to try several PDDL planners. Today I learned about the planutils server, a simple Flask app that exposes an HTTP API to invoke planners remotely, and I thought it's a brilliant idea. As of now, the API can only be used to get information on installed planners and to invoke each of them with its basic parameters, namely the PDDL domain and problem.
The nice thing about it is that there is a setup script to set up a planutils server Docker container with a few representative planners (among which OPTIC for PDDL3 support, ENHSP-2020 for numeric planning, and TFD for temporal planning) and an exposed port (5555 by default).
With the server container running, the API can be used with any usual tool. An example with curl could be like this:
curl -s -H "Content-Type: application/json" -d "{\"domain\": \"$(cat domain.pddl | tr '\n' ' ')\", \"problem\": \"$(cat problem.pddl | tr '\n' ' ')\"}" localhost:5555/package/enhsp-2020/solve
In this example, the two PDDL files are converted to strings and passed to the ENHSP-2020 planner as JSON values.
I will shortly put all this in a GitHub repo along with some example PDDL files for reference.
Prompted by a recent discussion, I went “back to the basics” and took a new look at PDDL.
The language, based on STRIPS (which I know from early courses in robotics), has undergone several improvements to make it more and more expressive. This means that, as it happened with RDFS, OWL, and their reasoners, there are different planners that make use of one version of the language or another, and finding what planner supports what version and what specific features of the language is not always easy.
The Planning.wiki website has a good review of the main versions of the languages as well as a list of (some of) the known planners. Today I also discovered the planutils project that aims to make trying different planners easier by packaging them with Docker. The setup is quite easy and using it is also relatively straightforward.
I began doing some experiments with PDDL myself, which I'll write about in another post.