[ros-users] multi-master support for Fuerte

Armstrong-Crews, Nicholas - 0447 - MITLL nickarmstrongcrews at ll.mit.edu
Fri Sep 23 17:14:42 UTC 2011


Yes, feel free to add to the wiki at http://www.ros.org/wiki/fuerte/Planning/Multimaster , although it seems most discussions are happening on the ros-sig-mm at code.ros.org<mailto:ros-sig-mm at code.ros.org> mailing list. You can sign up for it at https://code.ros.org/mailman/listinfo/ros-sig-mm

I'm sure you saw Brian's email about IPC/Wifi... maybe that's a better SIG for this contribution? Unclear.

Curious: OLSR does routing, right? Can this make robots participating into repeaters? Is data forwarded via wifi_comm (ROS messages, just ROS advertisements)?


From: ros-users-bounces at code.ros.org [mailto:ros-users-bounces at code.ros.org] On Behalf Of Gonçalo Cabrita
Sent: Thursday, September 22, 2011 4:47 PM
To: User discussions
Subject: Re: [ros-users] multi-master support for Fuerte

Hi everyone!

I've been following the multi-master topic with great interest and I'd like to share some thoughts.

In the past we have developed some work with multiple robots. To tackle the problem of communication we developed the wifi_comm pkg:


It is basically a wrapper for foreign_relay using olsrd to take care of stuff like auto-discovery and ip table. Using this lib we have a node that provides a list of the robots currently online and in range (olsrd also provides signal strength). Furthermore it is possible to open foreign_relays to other robots to exchange data. These foreign_relays are destroyed if a robot leaves the network.

The main problem that I found was tf. Sharing tf over wifi is not advisable, however many msgs have a frame_id which will not exist outside of their own robot. One solution that we tried was to only share msgs that were already on the global frame (in our case "/map") however this means that one cannot simply open a foreign_relay and start sending msgs, sometimes they need to be transformed before being sent.

With this in mind I guess a multi-master version of ROS would imply some changes to tf.

I hope this can help somehow, also would any of this be of any interest to the multi-master discussion page?


Best regards,

Gonçalo Cabrita
ISR University of Coimbra

On Sep 9, 2011, at 1:11 AM, Daniel Stonier wrote:

On 9 September 2011 03:41, Jeff Rousseau <jrousseau at aptima.com<mailto:jrousseau at aptima.com>> <JRousseau at aptima.com<mailto:JRousseau at aptima.com>> wrote:
> -----Original Message-----
> From: ros-users-bounces at code.ros.org<mailto:ros-users-bounces at code.ros.org> [mailto:ros-users-<mailto:ros-users->
> bounces at code.ros.org<mailto:bounces at code.ros.org>] On Behalf Of I Heart Robotics
> Sent: Thursday, September 08, 2011 1:35 PM
> To: User discussions
> Subject: Re: [ros-users] multi-master support for Fuerte
> On Fri, 2011-09-09 at 02:09 +0900, Daniel Stonier wrote:
> > I got started from that one - thanks for the push in the right
> > direction. I was going to contact you about it, but here is as good a
> > chance as any :)
> >
> >
> > I ended up pushing a little further and in some different directions
> > though:
> >
> >
> >       * Permit any ros program to publish services of any type, not
> >         just the _ros-master._tcp.
We should think carefully about what level in the system, either node or master, where "service discovery" takes place.  To me the logical place is at the master since everything in ROS is neatly namespaced and nodes generally do not operate in a vacuum, but rather work together to provide a set of common interfaces through named topics & services.

Putting discovery in the node places the burden on that node to export all the data from the necessary topics/services to accomplish a useful task.  It seems more natural to extend the ability of the master to configure what set of topics/services it wants to expose to other masters and they in turn have the ability to choose what topics/services to connect to.

I'm probably misunderstanding what you meant by your above bullet point--I'm just thinking in the context of multi-robot services.

I think there's an ambiguity in terminology that I used that probably made the above statement confusing so I'll talk about adding/discovering zeroconf services and handling ros communications (topics/services/actions).

The above idea was strictly talking about adding/discovering zeroconf services with no relation to ros communications. I wanted a set of c++ libraries and ros nodes (one for each platform), with similar api that could be used to administer zeroconf services in a general way. It might be simpler just to think of it as a building block that could easily be incorporated wherever you wish. Fusing it with the notion of multimaster somewhat complicates the issue needlessly. But to expound a little,

1) Disregarding multimaster, it is feasible that some ros programs may want to discover or add non-ros zeroconf services on the domain. They may need access to an apple air tv, or a robot may have some bizarre wish to advertise itself as a member of a chat group on a lan (these often have zeroconf capabilities). You might want to just open a socket port for a custom (non-ros) job that another program can utilise and advertising that as a zeroconf service makes sense too. I haven't actually done anything along these lines yet - but I don't want others to have to rework through the complicated platform specific zeroconf libraries when a standardised ros library/node can get them up and running very quickly.

2) Ken's style app manager-multimaster - it is a gateway that exposes ros communications via non zeroconf mechanisms. However, the app manager and ros masters still needs to be auto-discovered to be conveniently useful. It also adds only a single zeroconf service to the domain for a robot and lets that service handle the detail. I don't know whether polluting the zeroconf namespace with *alot* of services is an issue, but if it is, providing a gateway like this can be of assistance. It is also an approach we can really start utilising short term.

3) A multimaster approach using zeroconf to expose the ros communications themselves. More swam style and actually 'masterless' describes it better. Troy Straszheim was talking to me about this a couple of weeks ago and is interested in playing around with a new roscpp that could do this. I like this approach for certain solutions as well - though I think there are alot of design implications to worry about along the way. It's also a fair way off yet. It'll still need a basic api for zeroconf though, whether an existing avahi embedded, jmdns or custom lightweight mdns implementation, a simple library implementation can go into a zeroconf stack quite nicely.


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

ros-users mailing list
ros-users at code.ros.org<mailto:ros-users at code.ros.org>

ros-users mailing list
ros-users at code.ros.org<mailto:ros-users at code.ros.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110923/ea4ac3a0/attachment.html>

More information about the ros-users mailing list