> What about partially ordered plans? Also, shouldn't there be a way to
> indicate that action a further expands into actions b and c, say?
Planner9 supports partially-ordered task networks but always produces
fully-ordered plans. The goal can be partially-ordered, although the API
I proposed does not support it, but maybe it should?
The specification of actions (tasks) expansion is done in the planning
domain. The proposed API allows to specify the planning problem, not the
domain. The domain could be loaded by the planner node from a file, for
instance written in YAML. We could imagine to specify the domain
dynamically, but I'm not sure it makes sense; do you see a use case in
which it would be useful?
> Is the constants field necessary?
The idea is to use it to link the meaning of constant identifiers to
their names, for debug. If we switch to strings for constants, it is not
> Second Martin's suggestion that these be turned into a single
> actionlib interface to planners.
> Is there a reason why constant symbols are integers but relation
> symbols are strings? Might be good to just use strings for everything
> so messages are human readable.
Yes there is a reason: The relations are defined in the planning domain,
therefore strings are the only way to refer them from the problem,
excepted if we retrieve from the planner a mapping of these names to
identifiers. The constant symbols originate from the client of the
planner, therefore it can use strings because it knows their meanings.
What I like with the integers constants is that the parsing is kept to
the minimum. But if everyone else in the community prefers strings, I
will not try to impose my view.