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