[ros-users] Nodelets and figuring out a publisher's source name

[François Ferland]

Hi everyone,

Thanks for your answers. Here's our use-case: I'm building a simple toolkit
for behavioral architectures. We had three design ideas for our
priority-based arbitration:

1. Create special topic types that contain both a command and a priority
value. This works, but we need to define new topic types for each type of
command we use, and using a common node like a path planner requires a
wrapper node that add the priority value to incoming commands. It became
cumbersome rather quickly.
2. Create a generic arbitration module based on topic_tools::ShapeShifter
and ros::MessageEvent. On incoming commands, look in the publisher's
namespace for a priority parameter and cache the value. It works pretty
well, except for the problem described earlier.
3. The solution you described, where each behavior module publish on its own
topic. Register these topic names through a service on the arbitration node
and create a subscription for each behavior module. It's probably more
flexible, but we didn't try it yet.

After being dissatisfied with the first design we went ahead and tried the
second one. We liked the idea that we could pretty much turn any
command-producing node in a behavior by adding a single parameter to its
namespace and nothing else. The second design didn't rely on hard-coded
names or anything, but I didn't really expected the nodelet issue since I
thought we could still differentiate the source of each message.

The third design is still elegant and we can reuse much of the code from the
second design. The priority parameter's name could be based on the
registered topic (e.g. /behavior_1/cmd_vel/priority), and we can always
create a service interface and scripts inspired by the nodelet manager or
the pr2_controller_manager to ease the process of registering our behavior
node(let)s on the arbitration module.

We're developing this toolkit for our robots and I'm planning on using it in
a course on behavior-based robotics I'm tutoring this winter. We'll post it
on a public repository when it will be stable/documented enough.

Thanks again,

François Ferland

On Mon, Dec 27, 2010 at 4:13 PM, Tully Foote <tfoote at willowgarage.com>wrote:

>  Hi François,
>
> If the identity of the sender must be known I believe your use case would
> be better handled by using separate topics.  If the callback is going to be
> switching on the callerid, it would be just as easy to create different
> callbacks(aka different topics) for each case.   You can do this by
> parameterizing both the publisher and subscriber on namespaces rather than
> callerids. This is significantly cleaner than breaking the anonymous publish
> subscribe model of topics.
>
> Here are a few advantages of this approach:
> * being able to introspect each different channel w/ standard tools (aka no
> network within a network requiring another set of routings and debugging
> tools)
> * being able to put throttle or relay nodes in between in case of a
> changing system architecture (if you end up changing your layout of your
> network or something it may be desirable to have relays or throttling of
> messages)
> * no hard coded node names in executables which would break operation of
> different node if a node's name is remapped, which break w/o visibility
> (whereas if a topic doesn't match up you will see it in rostopic and it can
> be remapped with standard tools.)
> * you can use multiple senders and receivers in the same process (aka this
> can be used by both libraries and dynamically loaded libraries such as
> nodelets)
>
> Tully
>
>
> On 12/27/2010 12:02 PM, Josh Faust wrote:
>
> Relying on the callerid to do anything programmatic is usually a bad idea.
>  It's not just nodelets you'll have a problem with, it's any node with
> multiple publishers to the same topic.  It's possible some identifying
> information will be added for each publisher at some point in the future,
> but not near-term.
>
>  What exactly are you trying to do that requires a unique identifier per
> publisher?
>
>  Josh
>
> On Mon, Dec 27, 2010 at 11:51 AM, François Ferland <
> francoisferland at francoisferland.com> wrote:
>
>> Hi,
>>
>>  I'm currently porting some code over to a new Nodelet setup and I'm
>> running into a small issue. We're using MessageEvent subscribers to find out
>> from where some messages come from on topics with multiple publishers. The
>> thing is, when these publishers are from nodelets, they all appear to come
>> from the nodelet manager's node. From what I can figure out, this comes from
>> the fact that ros::this_node::getName() is used to fill out message headers.
>> Since this seems to be attached to the process itself, it
>> won't contain the name of the ros::NodeHandle from which the publication
>> was created.
>>
>>  We do have have a workaround: running these specific nodelets as
>> standalone, but it somewhat beats the whole point of writing them as
>> nodelets. I do realize that changing the "callerid" header field behavior
>> might have some important repercussions over the whole API, but would it be
>> possible in a future revision ? Does anyone have a better workaround idea ?
>>
>>  Thanks,
>>
>>  François Ferland
>> IntRoLab - Université de Sherbrooke, Canada
>> http://introlab.gel.usherbrooke.ca
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing listros-users at code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101227/f5ed6c48/attachment-0003.html>