Hello,

> 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.

Indeed!

>> * 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.

As far as I've seen, ROS does not have a variant type, does it? So 
strings are ok for me, with the string-to-int conversion on the planner 
side. I somehow liked the idea of int because if the symbolic world 
state is generated by a program, it will mostly be int, and it is a bit 
inefficient to convert on both sides, but I agree that it's not a 
practical problem, just an aesthetic detail.

>
>  > * 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.

Planner9 supports numerical values in the states, that's the reason 
atoms have a string value. Again a variant type with fallback 
string-based conversions would probably be better, but I did not find 
any in ROS.

> I'd follow joq's suggestion and start with an API for your implementation.

Yes, I'll do this in the next weeks.

Cheers,

Stéphane

-- 
Dr Stéphane Magnenat
http://stephane.magnenat.net