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
> <mailto: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 <mailto: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
(text/plain)