<br><br><div class="gmail_quote">On 9 September 2011 03:41, Jeff Rousseau <<a href="mailto:jrousseau@aptima.com">jrousseau@aptima.com</a>> <span dir="ltr"><<a href="mailto:JRousseau@aptima.com">JRousseau@aptima.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> -----Original Message-----<br>
> From: <a href="mailto:ros-users-bounces@code.ros.org">ros-users-bounces@code.ros.org</a> [mailto:<a href="mailto:ros-users-">ros-users-</a><br>
</div>> <a href="mailto:bounces@code.ros.org">bounces@code.ros.org</a>] On Behalf Of I Heart Robotics<br>
> Sent: Thursday, September 08, 2011 1:35 PM<br>
<div class="im">> To: User discussions<br>
> Subject: Re: [ros-users] multi-master support for Fuerte<br>
><br>
</div><div class="im">> On Fri, 2011-09-09 at 02:09 +0900, Daniel Stonier wrote:<br>
> > I got started from that one - thanks for the push in the right<br>
> > direction. I was going to contact you about it, but here is as good a<br>
> > chance as any :)<br>
> ><br>
> ><br>
> > I ended up pushing a little further and in some different directions<br>
> > though:<br>
> ><br>
> ><br>
> > * Permit any ros program to publish services of any type, not<br>
> > just the _ros-master._tcp.<br>
<br>
</div>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.<br>
<br>
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.<br>
<br>
I'm probably misunderstanding what you meant by your above bullet point--I'm just thinking in the context of multi-robot services.<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>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,</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Daniel.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
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.<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br>