Groovy planning meeting?

[Jack O'Quin]

I sense that this group is mainly engaged in productive design
discussions and prototyping efforts.

Do we need a Groovy planning meeting discussion here?

Are there items that are already well-enough understood to go in that release?
--
 joq

[Daniel Stonier]

I certainly would like to start the ball rolling on a few of the items we have been discussing, particularly since we seem to be coming to some consensus on a few areas (that took some time!).

I think before we have a meeting though, it would be useful to have a reference document laying out our objectives and skeletal design plan. We can then draw attention to detail in the meeting.  I can start putting a summary of points from our email discussions into a google doc.

Regards,

Daniel.

[Jack O'Quin]

Yes. A summary would help.

There is a groovy planning wiki page, but not much on it yet...

http://ros.org/wiki/groovy/Planning/Multimaster
--
 joq

[Daniel Stonier]

I started a quick multimaster reference document for us, beginning initially with a focus on gateways (aka master_sync) because I believe that is one of the first areas we need to work on (especially given so many variations are popping up). I'll also be able to invest time on it over the next two months and it would be good to find a common solution for most of us.

https://docs.google.com/document/d/1gw-tQfif_onFNu5Yx0WC7c2wQF1XD4najl7n0AWVSoQ/edit

Bear in mind that it is probably biased towards our earlier discussions and some of the experiments we ran here at Yujin Robot last year. Please add comments, raise questions or add items you think you need for your use cases - either here or in the document.

Regards,

Daniel.

PS - if you want to edit the document, please reply to this. 

[Piyush]

Hi Daniel,

Thanks a lot for preparing this document. I have a few
comments/questions based on earlier discussions on this mailing list.

1) At this time, I don't understand auto-discovery well. Is it
necessary to have a central super master? Can gateways directly
discover each other without What are the advantages/disadvantages of
such a central server. I don't think it makes a difference to me if we
have a central super master, but I would like to understand why we
need it.
2) One of the points Jeff made earlier was that to use PGM, there
would be no direct node-to-foreign-node communication. Transmissions
through PGM would have to be routed through the gateway. To prevent
this relay, PGM needs to be added as a native transport method
directly into rospy/roscpp. What are you thoughts on such a strategy?

I would also like to add that I will continue developing our
mulit-robot framework here at utexas, and will be more than happy to
contribute towards the multimaster setup. If needed, I can spend a
decent amount of time over the next 3 months to help with development.

Thanks!
Piyush

[Daniel Stonier]

On 26 May 2012 02:49, Piyush <piy...@gmail.com> wrote:

Hi Daniel,

Thanks a lot for preparing this document. I have a few
comments/questions based on earlier discussions on this mailing list.

1) At this time, I don't understand auto-discovery well. Is it
necessary to have a central super master? Can gateways directly
discover each other without What are the advantages/disadvantages of
such a central server. I don't think it makes a difference to me if we
have a central super master, but I would like to understand why we
need it.

Two separate issues there - autodiscovery and super master. 

Auto-discovery should be built in as optional I believe - as a fallback without auto-discovery, you should be able to configure by hand the ip's and hostnames. Auto-discovery just automates discovery of the ip's, making it easier to scale. 

A super master too, can/should be optional. Like Jeff's examples with foreign relays, if you know the connection details, flipping relays off to other gateways doesn't need the idea of a central super master. Nor does using a master sync to sync across a subset of ros api's to another gateway need a super master. So long as you know the connection details, are happy to manually specify the api you are syncing and also handle unique string for each robot's namespace, that is ok.

The central super master allows you to go beyond that and scale up. The first and obvious job is to be a central unique namespacing server, though that is somewhat trivial. I think the really important effect of having a central super master is to be the brain of the entire system. Instead of manually configuring each client to do a particular fixed thing, just attached 'standard' clients to the system, have the central super master auto-discover if they are useful or not, send unique namespaces and invitations to the clients, decide which apps (if present) to download and start on each robot, orchestrate linking for the multi-robot system...that's just getting started. The important point being, it is hard to manually configure each individual robot to do the right thing, it is much easier having just one entry point for everything - the central super master.

Having said that, the idea of a super master is getting ahead of ourselves a bit - what is immediately useful is a gateway which can let people satisfy as many of their use cases as possible (merge all that wild code out there). i.e. Do relays from the command line, master syncs from configuration file or ros api and also optionally auto-discover other gateways.

 

2) One of the points Jeff made earlier was that to use PGM, there
would be no direct node-to-foreign-node communication. Transmissions
through PGM would have to be routed through the gateway. To prevent
this relay, PGM needs to be added as a native transport method
directly into rospy/roscpp. What are you thoughts on such a strategy?

Yes, the transports definitely need some attention. There's alot of focus around developing the ros 2.0 middleware right now though. Jeff mentioned that it might be worth watching what happens with that. I noticed Cedric just posted to ros-users about creating a framework for transport plugin libraries in roscpp. That would be really nice. Rospy needs some work though - I'm finding alot of my multi-robot communication is done via python apps these days as they typically don't need the speed of a c++ app.

 

I would also like to add that I will continue developing our
mulit-robot framework here at utexas, and will be more than happy to
contribute towards the multimaster setup. If needed, I can spend a
decent amount of time over the next 3 months to help with development.

Awesome.

 

Thanks!
Piyush

Daniel.