'[ros-users] multi-master support for Fuerte'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ros-users
Subject:    [ros-users] multi-master support for Fuerte
From:       goncabrita () gmail ! com (=?iso-8859-1?Q?Gon=E7alo_Cabrita?=)
Date:       2011-09-25 14:57:48
Message-ID: 953DAE27-A508-4E58-AB9F-1542051FEFB3 () gmail ! com
[Download RAW message or body]

Hi Nick,

OLSR should allow us to use the robots as an ad hoc network so the robots can work as \
repeaters, so robots can be placed in order to maintain connectivity. I never tried \
this myself though, I always used a WiFi router to create a WiFi network. All data is \
shared using ROS msgs, using foreign_relay. You just pick the msg you want to send \
and wether you want to send it to one robot in specific or to all robots and it is \
published.

Back when we developed this we started a discussion on the mailing list. We ended up \
doing it this way using the suggestions and feedback provided. It's not perfect and \
it has some problems but it does the job. Back then there was already some talk about \
a future version of roscore that supported multiple robots.

Gon?alo Cabrita
ISR University of Coimbra
Portugal

On Sep 23, 2011, at 6:14 PM, Armstrong-Crews, Nicholas - 0447 - MITLL wrote:

> Awesome!
> 
> 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 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)? \
>  Thanks,
> -Nick
> 
> 
> 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: 
> http://www.ros.org/wiki/wifi_comm
> 
> 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? 
> http://www.ros.org/wiki/fuerte/Planning/Multimaster
> 
> Best regards,
> 
> Gon?alo Cabrita
> ISR University of Coimbra
> Portugal
> 
> On Sep 9, 2011, at 1:11 AM, Daniel Stonier wrote:
> 
> 
> 
> 
> On 9 September 2011 03:41, Jeff Rousseau <jrousseau at aptima.com> <JRousseau at \
> aptima.com> wrote:
> > -----Original Message-----
> > From: ros-users-bounces at code.ros.org [mailto:ros-users-
> > 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. 
> Cheers,
> Daniel.
> 
> 
> 
> 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
> https://code.ros.org/mailman/listinfo/ros-users
> 
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
> 
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </lurker/list/ros-users.html/attachments/20110925/925a115b/attachment.html>

[prev in list] [next in list] [prev in thread] [next in thread] 