RFC: Swarm management (without actual multimaster)

[claude....@gmail.com]

Hello.

I'm working on converting a custom closed-source infrastructure, developed internally in my university, to ROS.
This infrastructure currently handles experiments with a swarm of little rovers for which a single room is usually sufficient (robot measures about 40x30 cm even less probably).
This means that we use a single wifi network with a central server (which is in charge of global positioning with a camera).

Going fully multimaster seems to me way beyond the needs: no robot will ever fall outside of comm range, also the single robots have no need to access high-bandwidth nodes like the camera.

What I am trying to setup is something like this (hopes formatting doesn't get lost)

$ roslaunch project.launch
   (search for machines, found 1 through 3)
    |||
    ||\_ machine.launch (on machine 1)
    ||       |||
    ||       ||\_ laser
    ||       |\__ motors/odometry
    ||       \___ amcl/navigation
    ||
    |\__ machine.launch (on machine 2)
    |
    \___ machine.launch (on machine 3)

Now nothing of this is possible with the current architecture.

What would you do in my use case?
Write a customization of roslaunch to handle the above?

What would the multimaster route entail?
I think there are fairly big problems of synchronization and with a single wifi link I don't know what performance can be expected.

Security in my case is not a problem.

Thanks for the comments
Claudio

[Daniel Stonier]

On 30 January 2013 20:39, <claude....@gmail.com> wrote:

Hello.

I'm working on converting a custom closed-source infrastructure, developed internally in my university, to ROS.
This infrastructure currently handles experiments with a swarm of little rovers for which a single room is usually sufficient (robot measures about 40x30 cm even less probably).
This means that we use a single wifi network with a central server (which is in charge of global positioning with a camera).

Going fully multimaster seems to me way beyond the needs: no robot will ever fall outside of comm range, also the single robots have no need to access high-bandwidth nodes like the camera.

What I am trying to setup is something like this (hopes formatting doesn't get lost)

$ roslaunch project.launch
   (search for machines, found 1 through 3)

    |||
    ||\_ machine.launch (on machine 1)
    ||       |||

    ||       ||\_ laser
    ||       |\__ motors/odometry
    ||       \___ amcl/navigation

    ||
    |\__ machine.launch (on machine 2)
    |

    \___ machine.launch (on machine 3)

Now nothing of this is possible with the current architecture.

What would you do in my use case?

You have well defined constraints, so you can probably keep it simple.

 

Write a customization of roslaunch to handle the above?

If you're guaranteeing everything being up already (and continuously) a single roslaunch from the central server can do what you're describing with the machine tag.

The only thing extra that you seem to wish to do is to scanning for machines and bring them up as they are found? If that's the case, then that can be done quite simply. Run avahi on each machine, also start a bash/python script from the project's launch which then forks off and manages it's own calls to roslaunch whenever it finds a machine come up.

I have some similar code in a python script which spawns multiple terminals and fires up a roslaunch in each shell with their own ROS_MASTER_URI's here. It doesn't do the zeroconf, but it shows how you can manage a few roslaunches.

Also, make sure you configure ntp on each robot.

What would the multimaster route entail?

Set the robots up autonomously with their own app manager and ros core. Then the central server as a centralised workspace. The central server automatically invites each robot and gets them to flip across required pub/subs/action servers across to that workspace.

We can do this now - but it's still very beta code and heavy in development. Probably a bit too wild to use right away (give us six months).

 

I think there are fairly big problems of synchronization and with a single wifi link I don't know what performance can be expected.

Do you have high performance needs for the synchronisation? Depending on what you're doing with the wifi - you may need to make sure you compress some high volume traffic (bit like the image transport plugins). 

Daniel.

 

Security in my case is not a problem.

Thanks for the comments
Claudio

--
You received this message because you are subscribed to the Google Groups "ROS Multi-Master Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-mm+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Claudio Carbone]

On Fri, Feb 1, 2013 at 3:39 PM, Daniel Stonier <d.st...@gmail.com> wrote:

You have well defined constraints, so you can probably keep it simple.

 

Write a customization of roslaunch to handle the above?

If you're guaranteeing everything being up already (and continuously) a single roslaunch from the central server can do what you're describing with the machine tag.

I'm already using machine tags, but one of the main constraints is properly that not all machines and in no particular order may be operational.
Think of it this way (and it seems to me it would suit a wide range of experimental setups): you have a number of vehicles in your fleet, but you never (or very seldom) use them all in any given experiment, rather you grab those that you know are working (no broken parts waiting for repair, batteries full, same software versions, proven durability records...) and put those to work.
Now if you structure your fleet so that they share a name definition, for us I think it's gonna be something like labrob-panda-xx, you can just ping the whole subnet and find which ones are active in a programmatic way.
Only then you launch the various nodes on each one.
Even ROS nodes could search the topic list programmatically knowing in advance what prefix to look for and thus connecting dynamically to the available resources.

The only thing extra that you seem to wish to do is to scanning for machines and bring them up as they are found? If that's the case, then that can be done quite simply. Run avahi on each machine,

I already have a network configuration that takes care of this.
 

also start a bash/python script from the project's launch which then forks off and manages it's own calls to roslaunch whenever it finds a machine come up.

Would you care to elaborate on that?
Is roslaunch capable of launching standard processes or do I have to make it a node?
How would I have such a script fork over different machines?

I have some similar code in a python script which spawns multiple terminals and fires up a roslaunch in each shell with their own ROS_MASTER_URI's here. It doesn't do the zeroconf, but it shows how you can manage a few roslaunches.

You seem to imply I can have roslaunch launch this script, but in the xml syntax I can only find nodes.
So I should treat such a script as a node?
Meanwhile I'll try to understand that, python noob here.
 

Also, make sure you configure ntp on each robot.

Already done.

Set the robots up autonomously with their own app manager and ros core. Then the central server as a centralised workspace. The central server automatically invites each robot and gets them to flip across required pub/subs/action servers across to that workspace.

What do you mean by app manager in this context?

Regards
Claudio

[Daniel Stonier]

Sorry for the delay, eventful week last week.

On 2 February 2013 18:50, Claudio Carbone <claude....@gmail.com> wrote:

On Fri, Feb 1, 2013 at 3:39 PM, Daniel Stonier <d.st...@gmail.com> wrote:

You have well defined constraints, so you can probably keep it simple.

 

Write a customization of roslaunch to handle the above?

If you're guaranteeing everything being up already (and continuously) a single roslaunch from the central server can do what you're describing with the machine tag.

I'm already using machine tags, but one of the main constraints is properly that not all machines and in no particular order may be operational.
Think of it this way (and it seems to me it would suit a wide range of experimental setups): you have a number of vehicles in your fleet, but you never (or very seldom) use them all in any given experiment, rather you grab those that you know are working (no broken parts waiting for repair, batteries full, same software versions, proven durability records...) and put those to work.
Now if you structure your fleet so that they share a name definition, for us I think it's gonna be something like labrob-panda-xx, you can just ping the whole subnet and find which ones are active in a programmatic way.
Only then you launch the various nodes on each one.
Even ROS nodes could search the topic list programmatically knowing in advance what prefix to look for and thus connecting dynamically to the available resources.

I'd guessed it was something like this.

 

The only thing extra that you seem to wish to do is to scanning for machines and bring them up as they are found? If that's the case, then that can be done quite simply. Run avahi on each machine,

I already have a network configuration that takes care of this.
 

also start a bash/python script from the project's launch which then forks off and manages it's own calls to roslaunch whenever it finds a machine come up.

Would you care to elaborate on that?
Is roslaunch capable of launching standard processes or do I have to make it a node?
How would I have such a script fork over different machines?

I have some similar code in a python script which spawns multiple terminals and fires up a roslaunch in each shell with their own ROS_MASTER_URI's here. It doesn't do the zeroconf, but it shows how you can manage a few roslaunches.

You seem to imply I can have roslaunch launch this script, but in the xml syntax I can only find nodes.

It's the other way around. It's a python script that starts and manages multiple roslaunch executions in the background. I'm triggering which roslaunch executions I want via an initial yaml script, but you could just as easily programmatically execute a roslaunch based on some network detection (i.e. when you see a robot come up).

So I should treat such a script as a node?
Meanwhile I'll try to understand that, python noob here.
 

Also, make sure you configure ntp on each robot.

Already done.

Set the robots up autonomously with their own app manager and ros core. Then the central server as a centralised workspace. The central server automatically invites each robot and gets them to flip across required pub/subs/action servers across to that workspace.

What do you mean by app manager in this context?

I've got some initial documentation for it here: http://ros.org/wiki/rocon_concert (big picture). There are two simple software demos down the page (chatter_concert and turtle_concert).

Also some more detail about the app manager here: http://ros.org/wiki/rocon_app_platform

It's still early, but if you're interested in using it, we'll be working quite heavily on it over the next few months with Austin/OSRF.

Cheers,

Daniel.

Regards
Claudio

--
You received this message because you are subscribed to the Google Groups "ROS Multi-Master Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-mm+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

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

Yujin R&D: http://rnd.yujinrobot.com/

[Claudio Carbone]

On Wed, Feb 13, 2013 at 3:03 AM, Daniel Stonier <d.st...@gmail.com> wrote:

It's the other way around. It's a python script that starts and manages multiple roslaunch executions in the background. I'm triggering which roslaunch executions I want via an initial yaml script, but you could just as easily programmatically execute a roslaunch based on some network detection (i.e. when you see a robot come up).

I think in your case this works because you can launch multiple masters, what would happen in my case using multiple launch instances?

I suspect I'd get with multiple masters...

Or is there a way to avoid launching a master with roslaunch?

Claudio

[Jack O'Quin]

Roslaunch only creates a master if it does not find one already running at start-up. 

--
 joq

[Claudio Carbone]

Thanks for clarifying that up: so if the script correctly sets the ROS_MASTER_URI envvar then roslaunch will not launch another master.

Why not proposing the inclusion of the relevant code in roslaunch itself?
Seems to me it is an addition on top of roslaunch itself, so it may well benefit from it.

Claudio

--

[Daniel Stonier]

On 15 February 2013 23:00, Claudio Carbone <claude....@gmail.com> wrote:

Thanks for clarifying that up: so if the script correctly sets the ROS_MASTER_URI envvar then roslaunch will not launch another master.

Yes - you can even set the ROS_MASTER_URI as an environment variable in the launch xml itself. 

Why not proposing the inclusion of the relevant code in roslaunch itself?

Seems to me it is an addition on top of roslaunch itself, so it may well benefit from it.

Are you talking about the rocon_launch code I'm using to manage multiple roslaunches? It's experimental and I'm just playing around with the idea so far - may well change alot. And us multirobot/multimaster groups are only a very small user group so far. Probably better building our own tools on top rather than complicating existing tools. The python code is very modular, so that is not too hard.

There are actually alot of features people would like to add to roslaunch - there was a group talking about it a while ago. I'm not sure if they ever got beyond talking though.

 

Claudio

On Thu, Feb 14, 2013 at 8:08 PM, Jack O'Quin <jack....@gmail.com> wrote:

On Thu, Feb 14, 2013 at 9:21 AM, Claudio Carbone <claude....@gmail.com> wrote:

On Wed, Feb 13, 2013 at 3:03 AM, Daniel Stonier <d.st...@gmail.com> wrote:

It's the other way around. It's a python script that starts and manages multiple roslaunch executions in the background. I'm triggering which roslaunch executions I want via an initial yaml script, but you could just as easily programmatically execute a roslaunch based on some network detection (i.e. when you see a robot come up).

I think in your case this works because you can launch multiple masters, what would happen in my case using multiple launch instances?

I suspect I'd get with multiple masters...

Or is there a way to avoid launching a master with roslaunch?

Roslaunch only creates a master if it does not find one already running at start-up. 

--
 joq

--
You received this message because you are subscribed to the Google Groups "ROS Multi-Master Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-mm+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "ROS Multi-Master Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-mm+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.