Hi,
On 08.03.2012 11:28, Stéphane Magnenat wrote:
> Dear community,
>
> At some point, I would like to integrate planner9 [1,2], my HTN planner,
> into ROS. At that occasion, it would be nice if planner9's node could
> conform to a standard HTN-planner interface. I have been looking for one
> but did not found any. Currently planner9 can distribute search on
> multiple nodes using avahi and be called using D-Bus. The interface to
> D-Bus could be a source of inspiration (at least it works for me), here
> is a rosmsged version:

I'm writing from the perspective of classical planning, so obviously
the messages won't be able to match exactly, but the state I am giving
to my planner in ROS looks quite similar. It might be useful to have a
interface for some common parts.

> * HTN/Atom.msg:
> String relation
> uint32[] params
> String value

In particular predicates I give in the initial state have:
string name
string[] parameters
So I would suggest strings as parameters. You could still convert them
to numbers if you need them to be like that internally.

 > * HTN/State.msg:
 > Atom[] atoms

For me, the type of the value for Atoms depends on the kind of fluent
used, it is either bool, double or string, so string could be the most
general value and might then need to be converted depending on the type.
I don't think that many/all planners will be able to support numerical
values for the state, so to be extensible it might be a good idea to
just name your state SymbolicState or LogicalState or something similar.


> * HTN/Task.msg:
> String head
> uint32[] params
>
> * HTN/Plan.msg:
> Task[] actions
>
> * HTN/StartPlanning.msg:
> String[] constants # for debug output
> State initial_state
> Task task # task to do
>
> * HTN/PlanningSucceeded:
> Plan plan
> uint32 total_iteration_count
>
> * HTN/PlanningFailed:
> uint32 total_iteration_count
>
> These messages assume:
> * constants are represented by integers
> * relations are represented by strings
> * values are represented by strings
> * the goal is specified as a task
> * the planner node has a description of the planning domain, and only
> problems are specified dynamically.
>
>
> What do you think? Are there people interested in such interface? Should
> we make a REP?
I'd follow joq's suggestion and start with an API for your implementation.

Best regards,
   Christian Dornhege


-- 
Albert-Ludwigs-University
Institute of Computer Science
Research Group Foundations of Artificial Intelligence
Georges-Köhler-Allee 52
79110 Freiburg
Phone: +49 761 203 8225