ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Introduce intermediate node programmatically?

asked 2016-11-05 09:56:32 -0500

mathiasi gravatar image

Hi there,

I'm fairly new to ROS and I'm exploring the possibilities and I have come up with a scenario that I have not quite figured out if it is possible.

Consider a situation where you have two nodes: a publisher (my_publisher) and a subscriber (my_subscriber). I want to be able to control the communication between those two nodes (use-cases could be for logging but also for cutting the communication all together). My solution proposal is to introduce an "intermediate" node that could relay the communication and using the remapping functionality in launch files to redirect the subscriber to the new topic.

The transformation is displayed as followed:


This is not a problem if you manually create a node but lets say you have many nodes and don't want to manually add the topic to the intermediate node, then you would do this programmatically. I have looked at the getPublishedTopics method from the Master API ( ) - it does return the name of the topic but the topic message type is also returned as a string however I need a reference to the class in order to publish a new topic. Is there a way to get that or can the goal be achieved in an entirely other way?


edit retag flag offensive close merge delete


Just a comment: you mention 'logging' as being one use-case for why runtime rewiring could be used. That is true, but in a pub/sub system really not required. Pub/sub relations between nodes are not p2p channels, where only one publisher and one subscriber can see the data, all subscribers ..

gvdhoorn gravatar image gvdhoorn  ( 2016-11-05 10:05:53 -0500 )edit

.. can see the same data. Logging should then be as simple as creating a subscriber that writes out incoming msgs to disk. In fact, this is how rosbag works.

gvdhoorn gravatar image gvdhoorn  ( 2016-11-05 10:07:13 -0500 )edit

@gvdhoorn - That's right, logging might not be the best example as a use-case. I'm more generally interested in controlling the communication between the two nodes. Lets say I want to filter out some messages based on the values in them ; the ability to entire block communication is what going for.

mathiasi gravatar image mathiasi  ( 2016-11-05 10:29:27 -0500 )edit

Afaik, such node graph orchestration is not possible right now. Nodes control their subscriptions, not an outside system. Remapping is also an 'off-line' affair (ie: not something that can be changed after the configuration phase). But let's see what others can come up with.

gvdhoorn gravatar image gvdhoorn  ( 2016-11-05 12:00:28 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2016-11-07 09:36:34 -0500

lucasw gravatar image

The manual method might benefit from , the mux connection would have to exist from the start (and would default to passing through the message unfiltered), but other filter nodes subscribing to the publisher could be launched at a later time and the mux could switch to their modified output. That doesn't scale well to an existing system with lots of nodes though.

Also if the nodes can be arranged to be on different sides of a network link there must be options for putting another computer with two network ports between and it could sniff traffic (and completely parse ros messages?) and make changes (and probably add a bunch of latency). For the DRC they wanted to selectively degrade network traffic between control computers and robots, and I think they got special network hardware to do that but it wasn't that interested in the content of the traffic.

edit flag offensive delete link more


Thank you for your input - very much appreciated. I'll have a closer look at it.

mathiasi gravatar image mathiasi  ( 2016-11-08 12:15:41 -0500 )edit

@lucasw - Do you happen to know if there is a similar tool available for services and actions?

mathiasi gravatar image mathiasi  ( 2016-11-09 04:10:55 -0500 )edit

That's a really interesting question- you should make into a proper answers.ros question (or even two questions?). actionlibs are carried out over multiple topics, so a topic mux could be attached to each one... but maybe wouldn't function properly after switching? Could be worth experimenting.

lucasw gravatar image lucasw  ( 2016-11-09 17:11:03 -0500 )edit

I suspect a service mux doesn't exist, but wouldn't be hard to write. (or just a custom node service intermediary node that does all that you require directly, without the mux)

lucasw gravatar image lucasw  ( 2016-11-09 17:12:12 -0500 )edit

answered 2016-11-19 07:05:35 -0500

mathiasi gravatar image

It seems that I have managed to find a solution myself. I stumbled upon the get_message_class method in roslib.message that seems to do the job. Here is a code snippet if anyone is interested:

import rospy
from roslib.message import get_message_class


topics = rospy.get_master().getPublishedTopics("/")[2]
for topic in topics:
    msg_class = get_message_class(topic[1])
    pub = rospy.Publisher("/inter"+topic[0],msg_class,queue_size=1)
edit flag offensive delete link more


But this only creates a republisher node. The subscribers will still listen to the old topics...

NEngelhard gravatar image NEngelhard  ( 2016-11-19 07:31:10 -0500 )edit

You are totally right about that but my plan was to use remapping to get them to listen to the new topics.

mathiasi gravatar image mathiasi  ( 2016-11-19 08:03:24 -0500 )edit

Remapping is a configuration phase activity, it will not influence existing pub-sub associations between nodes.

gvdhoorn gravatar image gvdhoorn  ( 2016-11-19 08:11:24 -0500 )edit

That is not a problem for my use-case. I'm sorry if it was not clear in my original post and has caused confusion.

mathiasi gravatar image mathiasi  ( 2016-11-19 08:16:26 -0500 )edit

Question Tools



Asked: 2016-11-05 09:56:32 -0500

Seen: 933 times

Last updated: Nov 19 '16