[ros-users] Transport statistics?

Armstrong-Crews, Nicholas - 0447 - MITLL nickarmstrongcrews at ll.mit.edu
Mon Oct 31 21:00:52 UTC 2011

Hi Cem,

Have you looked at OLSR? It provides that kind of dynamic routing info, and people have already written visualization tools for it.

It might be worthwhile to make an OLSR wrapper for ROS. I know dynamic discovery is also being discussed in the multimaster SIG, but I'm not sure what the consensus is on what (semi-standard) protocols to use.

For network monitoring, we'll take your use case into account (it's a lot like my use case). It'll probably come down to a bunch of OS-specific hacks (parsing output of linux command-line tools, exposing in ROS)... but at least they're not application-specific!


-----Original Message-----
From: ros-users-bounces at code.ros.org [mailto:ros-users-bounces at code.ros.org] On Behalf Of Karan, Cem F USA CIV (US)
Sent: Wednesday, October 26, 2011 4:27 PM
To: ros-users at code.ros.org
Subject: Re: [ros-users] Transport statistics?

Since both Nick and Lorenzo replied, I'm going to reply to both.  Nick,
I have an API suggestion at the end, please have a look at it.

> We're working on network health monitoring for inclusion in the next
> release (Fuerte). ("we" being the ROS SIGs for IPC and multirobot) It
> would be helpful to know more about your use case: what transport
> statistics you think would be useful, and what nodes would modify
> behavior as a result.
> Thanks!
> -Nick

Thanks for working on this Nick!  My use case is that I have a group of
robots that are connected wirelessly, wandering around and exploring an
indoor environment.  Since the environment pretty much guarantees that
they will not be able to communicate with the base station directly,
we've got a multi-hop protocol that we're putting together that relays
the messages from the base station to the lead robot and back again. The
reason I want to know about network health is so that intermediate
robots that are acting autonomously can be tasked with moving to
maintain communications.  To determine if a robot is in danger of losing
communications, we need to know the following:

- Latency between any pair of robots.

- Throughput between any pair of robots.

- Message loss rate; we all know that TCP tries to hide lost packets,
but we really need to know how many messages are lost to get an idea of
which robots are losing communications.

- At a much lower level, any information that the radio can provide; the
power it is transmitting at, the power that it is receiving from each of its
neighbors, etc.  I know that that could be a real headache as not all devices
are going to give you this information, but you asked what I wanted! :)

- If you choose to support multihop routing, then a routing list showing
the nodes that a message passed through, in the order that it passed
through them, and when it passed through them.  

The last point is what I'm working on right now. I'm writing an
application layer hack (NOT good enough for the general case!) that 
wraps the messages we're interested in in our own message that carries
this information along.  All nodes that relay a message along tack their
own names/timestamps onto the message, and all relays snoop on the     
information to update their own tables.  No idea if that will be good 
enough, but it is part of the information that I'd like to get hold of.

> Maybe this is slightly off topic, but it might be very useful to know
> the bandwidth usage of a single node, or even better if this bandwidth
> is split among topics/services (advanced feature?). This could be done
> e.g. by inserting a proxy node between the sender and the receiver,
> but other ways are possible.
> Lorenzo

That information would be useful to us as well, but to a lesser degree.

As for the API, I've always favored callbacks that permit any callable
to get passed in.  As a suggestion, pass in a dictionary to the callback
that contains any information of interest (e.g., if my callback is 'foo',
then the signature is 'foo(someDict)').  That way, if you need to add
more information later on, it is just a key/value pair away from being 

Cem Karan
ros-users mailing list
ros-users at code.ros.org

More information about the ros-users mailing list