Introduce intermediate node programmatically?

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

mathiasi
31 ●2 ●4 ●5

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:

Example

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 ( http://wiki.ros.org/ROS/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?

Thanks,

edit retag flag offensive close merge delete

Comments

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 ( 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 ( 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 ( 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 ( 2016-11-05 12:00:28 -0500 )edit

add a comment

0

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

lucasw

8729 ●137 ●239 ●256 https://github.com/lucasw

The manual method might benefit from http://wiki.ros.org/topic_tools/mux , 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

Comments

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

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 ( 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 ( 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 ( 2016-11-09 17:12:12 -0500 )edit

add a comment

0

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

mathiasi
31 ●2 ●4 ●5

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

rospy.init_node('test_node_intermediate')

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

Comments

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

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 ( 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 ( 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 ( 2016-11-19 08:16:26 -0500 )edit

add a comment

Introduce intermediate node programmatically?

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Introduce intermediate node programmatically? edit

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Introduce intermediate node programmatically?