[ros-users] HTN planning messages

[Bhaskara Marthi]

2012/3/9 Stéphane Magnenat <stephane.magnenat at mavt.ethz.ch>:
> Hello,
>
>
>> 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?

I guess it depends on why exactly a plan is being sent across ROS.  I
could imagine, e.g., a least committment planner that produces a
partially ordered plan and sends it to an executive which will decide
how to order things.

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

Potentially if different planning problems come up during the lifetime
of the overall system, and the different nodes need to communicate
about which one is currently active.  But that could be a backward
compatible future addition.
- b

>> 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 needed
> anymore.
>
>
>> Second Martin's suggestion that these be turned into a single
>> actionlib interface to planners.
>
>
> Agreed.
>
>
>> 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.
>
>
> Kind regards,
>
> Stéphane
>
> --
> Dr Stéphane Magnenat
> http://stephane.magnenat.net
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users



-- 
Bhaskara Marthi
Research Scientist
Willow Garage Inc.
650-475-2856