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@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@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users