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

Wireless data transfer to multiple subscribers

asked 2013-05-31 05:59:49 -0600

aharmat gravatar image

In our current setup, we have a laptop connected wirelessly to our robot, everything running ROS. The laptop does most of the processing and sends commands back to the robot, pretty standard stuff.

However, we have noticed that if we are recording all (or even some) of the data being sent by the robot (with rosbag record) while also doing the usual processing, the laptop slows down intermittently, negatively affecting the rate of control commands being sent out.

As a potential solution, we would like to use two laptops, one for data processing and control command generation, and the other one for data recording and maybe data visualization. This would also nicely split tasks between people, with the controller laptop operator focusing on running his algorithm an the data recording laptop operator making sure the experiments are running as designed.

However, I am concerned about the data being sent wirelessly being needlessly duplicated if it has to go to both laptops. The setup I envision has the two laptops connected (wired) to a network switch, along with our wireless radio (a Ubiquity Networks NanoStation) so everything is on the same subnet. On the other side of the wireless connection we have a Ubiquity Networks Rocket connected to a single PC also on their own subnet.

Is my concern warranted, will the data be sent twice if both laptops are subscribing to a topic? Some of the data are images from various cameras so double sending this would be very bad. Is there any way to resolve this problem other than having one of the laptops relay messages to the other (so the second laptop would only subscribe to relayed topics on the first laptop)?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2013-06-01 02:42:36 -0600

Markus Achtelik gravatar image

To make sure your topic goes over the air only once when having multiple subscribers, you can have a look at topic_tools/relay. A relay on (one of) the laptop(s) would subscribe to the image from the robot and republish it to multiple subscribers on a different topic in your local wired network.

edit flag offensive delete link more



Thanks Markus, this looks like what I need. I'll try to write a node relays all topics from a given machine, essentially acting as a proxy for the aircraft.

aharmat gravatar image aharmat  ( 2013-06-03 09:29:28 -0600 )edit

Thank you Markus. topic_tools/relay is working well for this purpose

NickSpeal gravatar image NickSpeal  ( 2013-06-17 16:29:58 -0600 )edit

answered 2013-06-01 02:22:31 -0600

Philip gravatar image

Yes, your concern is warranted: for each publisher-subscriber pair, a new TCP-connection is established. So the amount of bandwidth is proportional to the number of subscribers.

I can't think of any elegant solutions right now, my only ideas:

  • Republish the data as you suggested. In fact, there already is a republish node for image transport. However, you'd probably have to rename the topics in your code.
  • Try compressing your image topics by installing the required codecs on all machines and using the compressed streams (see known transport packages). Mayby this already saves enough bandwidth for doing the connection twice (which I doubt and doesn't scale further)?
  • Use a powerful pc that can both control the robot and record data. Have one or both of the "operators" work remotely on this machine (ssh -X).
edit flag offensive delete link more


Thanks Philip. I'm working with aharmat on this, and we'll be implementing the 3 suggestions you made. I think we'll use topic_tools/relay instead of republish, because it is more general. It seems as though the problem is the Wifi, not the local recording, so we could use 1 machine.

NickSpeal gravatar image NickSpeal  ( 2013-06-17 16:28:32 -0600 )edit

Question Tools


Asked: 2013-05-31 05:59:49 -0600

Seen: 1,340 times

Last updated: Jun 01 '13