[ros-users] multi-master support for Fuerte

Fri Sep 9 00:11:09 UTC 2011

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110909/336994c2/attachment-0003.html>