Multi-robot collaboration in ROS

[Ammar Husain]

Hello Community,

We have been working at a multi robot coordination project here at Carnegie Mellon. The framework is completely ROS based right from the robot controller to communication, front end and task allocation. While starting this project I was unable to find ROS packages catering to coordination among multiple robots. An important note here is that each robot runs its own master since we assume a failure prone network. Anyways we thought we would release some of the software we wrote that could help someone else wanting to run multi-robot systems as well. Since we are in the process of packaging and cleaning (its a university project so we really need to clean it!) our code I would like to get some suggestions on what you would desire in a Multi-Robot package. Anything from vague ideas to specific implementations is welcome.

Just a brief and high level description: There are 4 packages: 

1) Communication package - currently using UDP however we may switch to ZeroMQ. Any input on protocol is appreciated. This package will handle transmitting topics of interest to other robots on a strictly request-respond basis. This scheme worked well for us in the work we did. Currently the comms can transmit Map, Pose, tf, Task (which is a goto Pose), Laser Scans, Camera Image. These topics were relevant to our work so we would appreciate inputs on other topics that might be useful communicating to other robots. One can either query another robot for any of these or request to transmit its own information. Additionally it can serve as a proxy for another robot.

2) Robot Specific Pkg - This provides high level implementation of basic Robot capabilities. Planning, Occupancy Mapping, Task Execution (move base Action client), & Costing.

3) Front End: Visualizes the map, pose etc from multiple robots. Additionally it can manually control, assign tasks to individual robots or to the swarm.

4) Task Allocation: We used a proprietary market based allocation system to handle task management. Unfortunately we cannot publish that. However if you have suggestions on task management systems we might be able to port some of it in this package.

Sorry for the long post. We would really appreciate suggestions, concerns and comments in this multi-robot framework. I have read some discussion in the multimaster package. The work we have is more narrow and focussed on inter-robot coordination as compared to the overarching multimaster package. However we would love to contribute in whichever small way we can by putting out some work we did if it can help. 

Thanks,

Ammar

[Armstrong-Crews, Nicholas - 1002 - MITLL]

Hi Ammar,

 

I’m curious – are you working with Manuela Veloso? She was my PhD advisor when I was at the CMU/RI :-)

 

At a high level, I would strongly encourage integrating your stuff into http://ros.org/wiki/multi_master_fkie , which looks like the most fully-featured multi-master stuff I’ve seen so far. Hopefully this will lead to a de-facto standard, which is what the community really needs to move forward in this regard (in contrast, right now there are probably 10+ ad-hoc partial implementations for multirobot stuff running around in the wild, none of which work together).

 

I’d say the same thing for the market-based planner… if you can expose all the ROS msgs/srvs and design pattern, then anyone can instantiate the logic for the coordination routine. I don’t know who all has multirobot planners as ROS pkgs currently (there’s http://sourceforge.net/p/fmrp/code , maybe more), but I’d do a quick google search to see if there’s someone with similar enough stuff that it would make sense for you to re-use/reinforce their existing structure.

 

Cheers! Looking forward to a great CMU multi-robot package!

 

-Nick

[Daniel Stonier]

Hi Ammar,

On 24 August 2012 01:47, Ammar Husain <mrah...@gmail.com> wrote:

Hello Community,

We have been working at a multi robot coordination project here at Carnegie Mellon. The framework is completely ROS based right from the robot controller to communication, front end and task allocation. While starting this project I was unable to find ROS packages catering to coordination among multiple robots. An important note here is that each robot runs its own master since we assume a failure prone network. Anyways we thought we would release some of the software we wrote that could help someone else wanting to run multi-robot systems as well. Since we are in the process of packaging and cleaning (its a university project so we really need to clean it!) our code I would like to get some suggestions on what you would desire in a Multi-Robot package. Anything from vague ideas to specific implementations is welcome.

Fantastic!

Just a brief and high level description: There are 4 packages: 

1) Communication package - currently using UDP however we may switch to ZeroMQ. Any input on protocol is appreciated. This package will handle transmitting topics of interest to other robots on a strictly request-respond basis. This scheme worked well for us in the work we did. Currently the comms can transmit Map, Pose, tf, Task (which is a goto Pose), Laser Scans, Camera Image. These topics were relevant to our work so we would appreciate inputs on other topics that might be useful communicating to other robots. One can either query another robot for any of these or request to transmit its own information. Additionally it can serve as a proxy for another robot.

I'm in the middle of putting together alot of ideas from current systems in a gateway model we'd briefly discussed here. What you are attempting has alot of overlap with what our company is pushing towards as well. Did you serve topics via a relay mechanism on udp?

There was a rather large impromptu discussion at RosCon about upgrading the ros transport layer. ZeroMQ seems a likely direction. Upgrading from ros messages to a standard protocol (like protobuffs) may also happen. Keeping in mind that this discussion at roscon was at a very early stage, they did mention they were hoping to make this happen for 2.0. I doubt this is likely with the amount of work involved and the concentrated effort going into the build environment right now but I don't think it's too far on the horizon. I think before moving onto the rather large job of overhauling the higher level communications (multimaster comms) it would be worthwhile to contact them to find out more details re their plans for the ros transport layer and if you have resources and aligned interests, work out where you can help.

One thing I would like to see is the functionalities in this area split. The multimaster comms (gateway) and autodiscovery (zeroconf) are pretty standard pieces of gear, but the interfaces people have been building on top are quite varied. You have a request-respond capability interface. Fkie is distributing everything and choosing. We're interested in an application interface. I suspect having the ability to support varied interfaces is necessary since use cases are quite often different.

What strategy did you use to handle the high bandwidth of tf?

2) Robot Specific Pkg - This provides high level implementation of basic Robot capabilities. Planning, Occupancy Mapping, Task Execution (move base Action client), & Costing.

3) Front End: Visualizes the map, pose etc from multiple robots. Additionally it can manually control, assign tasks to individual robots or to the swarm.

4) Task Allocation: We used a proprietary market based allocation system to handle task management. Unfortunately we cannot publish that. However if you have suggestions on task management systems we might be able to port some of it in this package.

May I ask what solution for task allocation you are using? If you have time, your opinions of the software would also be valuable.

Sorry for the long post. We would really appreciate suggestions, concerns and comments in this multi-robot framework. I have read some discussion in the multimaster package. The work we have is more narrow and focussed on inter-robot coordination as compared to the overarching multimaster package. However we would love to contribute in whichever small way we can by putting out some work we did if it can help. 

That's really awesome. The more implementations that are out there give us more to reference. It also helps build up a knowledge base of what works and what doesn't as people try various multimaster experiments.

Cheers,

Daniel Stonier 

(Yujin Robot)

[Daniel Stonier]

Nick, would you like to get together sometime?

I've been parsing your code, alot of it is good, but some of it doesn't work with our use cases. As you say, it makes sense to pool our efforts in a good direction. Perhaps we should sit down and do a review and identify goals so we can maybe push forward together.

Daniel.

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

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

[Daniel Stonier]

On 24 August 2012 23:18, Armstrong-Crews, Nicholas - 1002 - MITLL <nickarmst...@ll.mit.edu> wrote:

Hi Daniel,

 

> Nick, would you like to get together sometime?

 

I’d be happy to get together! If you recall, we spoke a bit at ROSCon, but didn’t get much 1-on-1 time. But aren’t you in Australia or Korea or something? I’m in Boston.

 

Yes, both! I'm in Australia and will be on planes for the next three days on my way back to Korea.  Later this week would be good. I'm usually working late nights, so I find it's usually possible to find a time.

 

> I've been parsing your code

 

Are you sure that was my code? The fkie stuff is from someone else… We have written multi-master solutions and tf compression and multi-channel comms and quality-of-service, but it is nigh impossible for us to release any of it.

  

Anyway, let me know if it is still desirable/feasible to chat.

 

Ah - I had assumed yours was the fkie. Yes, I'd still love to chat, if only to understand what your use case needs were and what areas you had problems with. I don't know how much you are permitted to talk about it - but if we can incorporate some of the basic building blocks into what we'll build, then that perhaps will let your group get on with the more difficult problems. We have no problems releasing it as open source - it is intended to be assistance to help accelerate development on top of such structures.

Would Thur 9:30AM Boston Time - Thur 10:30PM Seoul Time work for you? My skype alias is djstonier, alternatively we could do a google hangout.

Daniel.

Cheers,

-Nick