On 9 September 2011 03:41, Jeff Rousseau < JRousseau@aptima.com> wrote: > > -----Original Message----- > > From: ros-users-bounces@code.ros.org [mailto:ros-users- > > bounces@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@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >