On 9 September 2011 01:47, I Heart Robotics <iheartrobotics@gmail.com> wrote:

On Fri, 2011-09-09 at 01:37 +0900, Daniel Stonier wrote:
>
>
> On 9 September 2011 01:04, Brian Gerkey <gerkey@willowgarage.com>
> wrote:
> On Thu, Sep 8, 2011 at 7:07 AM, Ken Conley
> <kwc@willowgarage.com> wrote:
> > On Thu, Sep 8, 2011 at 4:30 AM, Jeff Rousseau
> <jrousseau@aptima.com>
>
> >> I’ve been using
> >> foreign_relay for a number of months and it mostly works,
> but I’d like to
> >> see first-class multi-master support in ROS and am willing
> to commit
> >> development time towards it.
> >
> > Glad to hear it, what do you have in mind?
>
>
> Sounds like multi-master is a potential SIG for Fuerte
> planning
> (http://www.ros.org/wiki/fuerte/Planning). As Ken alluded,
> it'll
> likely be hard to find the one-size-fits-all solution, but
> there would
> be a lot of value in polishing up multi-master support for a
> couple of
> common use cases.
>
> brian.
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
> That's an excellent idea - do we just append to that wiki page?
>
>
> Regards,
> Daniel.

We would like to see improved support for multiple TurtleBots using
ZeroConf. This is probably the same SIG.
http://www.ros.org/wiki/zeroconf

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.
In the same vein, listening for any service type.
Multiple publisher/listener support
Runtime addition of publishers/listeners (sometimes needed to find free ports, then configure - there are other use cases too).

I dropped the python implementation as it couldn't do runtime. The c++ library had just implemented some threaded poll locking, and that ended up working well for runtime additions after the polling loop was spun up. In the end, what it resulted in was a package that had:

A pure c++ lib that could be used by any program directly (much simpler c++ api than the avahi api).
A ros node with pub/sub req/resp api for adding services/listeners, listing published and discovered services and publishers for new/lost services.
The node can also do static configuration from the param server.

In most cases I'll just run the node alongside the rest of the ros system. If I want the ros master published, I can configure that in the yaml, or spin off a small python script to do the job. It can then also be used by any other package for any other service.

The android jmdns implementation is a bit different, we just kept that to a library api as I can't envisage (for the near future) a complex system of nodes running on 'droids.

I don't think we'll have any issue moving our zeroconf code out to a public server - shall we get together and polish off a zeroconf stack?

Cheers,

Daniel