# Tool for analyzing ROS network traffic?

We have a robot with 3 onboard computers with an internal LAN. One of the onboard computers creates an adhoc wifi network and forwards packets to the others. We control the robot via a laptop connected over wifi. We are managing to bring down our wifi connection pretty regularly, so I'm trying to figure out which nodes/topics need to be throttled or moved to a different machine.

Is there a nifty ROS tool that shows bandwidth usage without affecting the network traffic, or is my best bet using wireshark?

EDIT:

"rostopic bw" doesn't quite do what I'm looking for, as it creates a new connection to the publisher and then monitors the bandwidth on that connection, which is actually dependent on what else is running. For example, starting up a second "rostopic bw /my_camera/image_raw" significantly slows down the first one.

So, I can use it in isolation to figure out what topics are likely to be an issue, but I'd like to be able to observe the whole system as it runs and dies, w/o affecting it. (Or at least the part that's transferring data to/from a given computer)

I'm not even sure that I'm asking the right question ... perhaps a better one would be "What's the best way to debug/understand network traffic in a system running ROS?" I'm envisioning some tool that's a mashup of rxgraph, rostopic and ???. If I'm approaching this all wrong, please let me know :)

EDIT 2:

I took a look at linux_networking, and it looks like it has tools to determine properties of a network and to emulate various network properties, but I didn't see anything that quite fits what I think I need.

So, I'm trying to use wireshark (running on the laptop) to monitor packets going over the wifi connection to the robot. I can successfully capture the packets and view their contents. However, I'm stuck on how to determine which packets correspond to which nodes and topics.

I've seen documentation about the connection header [1] and TCPROS [2], but I'm not sure how this translates into the raw data that I can view in wireshark.

Can anybody point me to information about how to set up appropriate filters?

[2] http://mirror.umd.edu/roswiki/ROS(2f)TCPROS.html

edit retag close merge delete

Have you looked through the linux_networking stack ( http://ros.org/wiki/linux_networking )? Maybe there is something you can use in there?

( 2012-05-31 10:04:55 -0500 )edit
1

I'd go with wireshark and add filtering as needed...

( 2012-05-31 10:08:05 -0500 )edit

( 2018-01-25 03:50:51 -0500 )edit

Sort by » oldest newest most voted

There are lots of standard linux tools for network diagnostics. Ones I use regularly include ntop, netstat, and wireshark.

Adding more statistics counting into the client APIs would be a great feature, for now no one has wanted it enough to spend the time to write it.

more

Using:

rostopic bw /your_topic


will give you the bandwidth usage of a particular topic.

more

I've approached the very same topic (see here).

I even started a discussion on the NTP ng about how to best verify the synchronization of clocks. Turns out Chrony appears to be better than NTP.

(Shunning all the infeasible proposals like linking every computer to a PPS source -as if I had any- with equal length cables... way above my paygrade ;-P)

Now what I'm fiddling with is a very small program that does just a ping but on the ROS side of the network rather than via the TCPIP stack (which is bound to be much faster and less affected by ROS traffic, and btw is not directly what we want to monitor). Just that this ping is effectively a message that goes via its own topic. The node has an in and an out topic, this way you can build however long chains by daisy-chaining ins and outs of multiple identical nodes. Only the first one is a master thus doing the timing, the others are just relays.

Now I need to figure out a way to easily assemble data from multiple such chains. I could have each master public a results topic: if all masters used the same topic (using a header to distinguish between them) you'd have to tap only one topic (just like tf_monitor does) but then plotting would be nigh impossible.

On the contrary if you used a different topic for each master, plotting would be easy but aggregating data would be a nightmare...

more