Autodiscovery

[Daniel Stonier]

Jeff had an open question on his slides:

• Should discovery be part of a new master api?

I'd like to understand the arguments others may have for this. 

As far as I can see the MM use case is a special case of ros, so discovery in the master would be redundant in most systems.The building manager, master sync, app manager was nice, because it didn't try and embed all of that extra functionality in the ros master. It moved it all to the side. Discovery to me, seems to be just another component that could be done the same way.

So, what are the advantages to having it actually in the master api?

Regards,

Daniel.

[Piyush]

I agree with this viewpoint. If we go with a public master (which I will call a gateway to avoid confusion) approach, at least right now I envision it being its own separate entity from the regular master. I'll try to summarize my thoughts on implementing this gateway. This is somewhat influenced by my usage of master_sync:

1) Each machine will have a regular ROS master.

2) To use the multimaster framework, alongside each master a gateway can also be launched (similar to master_sync). 

3) This gateway launches it's own XMLRPC server, on which it can be contacted by other foreign gateways.

4) A gateway keeps a track of some subset topics on the regular master. These topics can be specified via a whitelist (instantiated via a configuration file and updated programmatically via service calls from the local machine?).

5) The gateway registers itself against a foreign gateway (insert Auto Discovery here?) by making an XMLRPC call. A number of things happen here:

 - Both gateways pass information about the publicly visible topics on their local machines to each other. Each gateway registers these topics (after dealing with namespace concerns) against the regular master.

 - Both gateways make a service call to local nodes informing that a new machine has become available (Required for some applications)

 - The 2 gateways establish some keep-alive traffic. If this traffic goes out, the gateways unregister all the appropriate topics with the respective masters and make appropriate service calls to inform local nodes that a foreign machine went unavailable.

My reasoning for this is as follows:

1) As Daniel suggested, this does not affect the regular master at all. A large majority of the ROS community don't need this functionality

2) The master does not have to worry about other masters being out there

I suspect there are a number of problems with this solution that I have not thought of. 

 

Regards,

Daniel.

Piyush

[Alexander Tiderko]

I agree with that. Not each system need a discovering. As a separate feature the discovering can be enabled on demand or allow the usage of different discovering strategies. For me is the timeout of zeroconf/avahi to long if a machine go unavailable. Depending on the used hardware/software the usage of subjacent layer discovering can be interesting (e.g. wifi_comm or other proprietary solutions).

Regards,

Alexander

[Jeff Rousseau <jrousseau@aptima.com>]

Again, sounds like some general consensus around discovery and “gateways” (public masters with subgraph “sync”): they’re inherently different enough to warrant keeping them split into different libraries/nodes (zeroconf, olsrd and friends should handle the discovery aspect just fine).

 

The only argument I’ve thought of for including discovery would be a way to auto-connect gateways based on an access policy defined in the gateway config file (that’s what I was alluding to in my bringing up “acl” before).  Think of larger networks of robots where you may not want to reconfigure every one whenever you add a new robot or ros system to the network (assumedly there would be a “watch list” inside the gateway config).  However, if we supply a library for gateway instantiation and configuration then folks could spin their own custom gateways with auto-conf/acl, etc.

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.

[Daniel Stonier]

On 14 May 2012 18:19, Alexander Tiderko <alexande...@googlemail.com> wrote:

I agree with that. Not each system need a discovering. As a separate feature the discovering can be enabled on demand or allow the usage of different discovering strategies. For me is the timeout of zeroconf/avahi to long if a machine go unavailable. Depending on the used hardware/software the usage of subjacent layer discovering can be interesting (e.g. wifi_comm or other proprietary solutions).

Did you check avahi for a way to configure these timeouts? They probably have a configurable setting or api for handling that. I expect it's important not to have it too short, because a system will spam you with an up/down status, especially as they get close to being out of range. Again, that may cause issues like the DNS solution if users can't configure that for their advertised zeroconf services.

Different platforms, different zeroconf implementations. It seems we have some strong requirements of what we want in terms of monitoring the  up/down status of ros services (i.e. those that are advertised on zeroconf) that aren't likely to be met in every implementation. Should we endeavour to try/check first? Depending on how much work it is, I'm also leaning towards developing a simple solution for this in ros. 

 

Regards,

Alexander

Am Samstag, 12. Mai 2012 09:14:38 UTC+2 schrieb Snorri:

Jeff had an open question on his slides:

• Should discovery be part of a new master api?

I'd like to understand the arguments others may have for this. 

As far as I can see the MM use case is a special case of ros, so discovery in the master would be redundant in most systems.The building manager, master sync, app manager was nice, because it didn't try and embed all of that extra functionality in the ros master. It moved it all to the side. Discovery to me, seems to be just another component that could be done the same way.

So, what are the advantages to having it actually in the master api?

Regards,

Daniel.

--
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/

Yujin Robot: http://www.yujinrobot.com/

Embedded Ros : http://www.ros.org/wiki/eros

Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl

[Daniel Stonier]

On 14 May 2012 21:24, Jeff Rousseau <jrou...@aptima.com> <jrou...@aptima.com> wrote:

Again, sounds like some general consensus around discovery and “gateways” (public masters with subgraph “sync”): they’re inherently different enough to warrant keeping them split into different libraries/nodes (zeroconf, olsrd and friends should handle the discovery aspect just fine).

 

The only argument I’ve thought of for including discovery would be a way to auto-connect gateways based on an access policy defined in the gateway config file (that’s what I was alluding to in my bringing up “acl” before).  Think of larger networks of robots where you may not want to reconfigure every one whenever you add a new robot or ros system to the network (assumedly there would be a “watch list” inside the gateway config).  However, if we supply a library for gateway instantiation and configuration then folks could spin their own custom gateways with auto-conf/acl, etc.

Yes, sounds good. 

 

From: ros-s...@googlegroups.com [mailto:ros-s...@googlegroups.com] On Behalf Of Alexander Tiderko
Sent: Monday, May 14, 2012 5:19 AM
To: ros-s...@googlegroups.com
Subject: [ros-sig-mm] Re: Autodiscovery

 

I agree with that. Not each system need a discovering. As a separate feature the discovering can be enabled on demand or allow the usage of different discovering strategies. For me is the timeout of zeroconf/avahi to long if a machine go unavailable. Depending on the used hardware/software the usage of subjacent layer discovering can be interesting (e.g. wifi_comm or other proprietary solutions).

 

Regards,

Alexander

Am Samstag, 12. Mai 2012 09:14:38 UTC+2 schrieb Snorri:

 

Jeff had an open question on his slides:

 

• Should discovery be part of a new master api?

 

I'd like to understand the arguments others may have for this. 

 

As far as I can see the MM use case is a special case of ros, so discovery in the master would be redundant in most systems.The building manager, master sync, app manager was nice, because it didn't try and embed all of that extra functionality in the ros master. It moved it all to the side. Discovery to me, seems to be just another component that could be done the same way.

 

So, what are the advantages to having it actually in the master api?

 

Regards,

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.

[Jeff Rousseau <jrousseau@aptima.com>]

The simplest solution is probably a configurable-rate ICMP or UDP “ping” between gateways

[Alexander Tiderko]

Am Montag, 14. Mai 2012 14:52:00 UTC+2 schrieb Snorri:

On 14 May 2012 18:19, Alexander Tiderko wrote:

I agree with that. Not each system need a discovering. As a separate feature the discovering can be enabled on demand or allow the usage of different discovering strategies. For me is the timeout of zeroconf/avahi to long if a machine go unavailable. Depending on the used hardware/software the usage of subjacent layer discovering can be interesting (e.g. wifi_comm or other proprietary solutions).

Did you check avahi for a way to configure these timeouts? They probably have a configurable setting or api for handling that. I expect it's important not to have it too short, because a system will spam you with an up/down status, especially as they get close to being out of range. Again, that may cause issues like the DNS solution if users can't configure that for their advertised zeroconf services.

I found no solution to reduce the timeouts of avahi. Perhaps they depends on the cache strategies of zeroconf to reduce the traffic. Besides I don't know the resulted effects caused by reducing of timeouts.

Perhaps a simple solution using UDP (Multicast) is in the case of rapidly dynamic wireless scenario a better option. 

Regards,

Alexander