list revival, updates, next steps

62 views
Skip to first unread message

Jeff Rousseau <jrousseau@aptima.com>

unread,
Apr 23, 2012, 2:02:09 PM4/23/12
to ros-s...@googlegroups.com
Hey Folks,

I'd like to revive this discussion, starting with what I believe are some next steps. Since it's late in the game, we're taking aim at Groovy now. I believe there is clear interest in this topic and that the ROS community would benefit from a common multi-robot comms solution (please chime in if you disagree).

I'm currently working on a PGM ROS transport solution for ROS (C++) based off of OpenPGM which may help with some of the network issues outlined in the prior transport discussion thread--however, I'm currently leaving QoS and message priority off the table for the sake of keeping it simple (at least on a first-pass). I'm also experimenting with the existing ROSUDP transport in a single-message-in-datagram as an alternative. Assuming a "good enough" transport solution is reached; the next step is finding a way to share topic information across machines.

A quick survey of currently-available multi-master topic-sharing solutions run the gamut from custom ad-hoc & mesh network solutions (using OLSR, BATMAN or RT-WMP for example) to standard infrastructure-mode wifi with mDNS discovery. Here's a shortlist of some solutions:

ros-rt-wmp
wifi_comm
foreign_relay
multimaster_experimental/rosproxy
rosmaster_sd (not touched since 2010?)
batman_mesh_info (deprecated)

I believe our solution should support commodity 802.11 hardware with stock NIC drivers running an IP network (at least as a starting point). Any one of the above solutions can be used as a starting point to get something going--I particularly like the idea of a having a "public" master (I think the idea came from ROS Building manager) that only exposes a particular set of topics from the internal master.

An alternative (and rospy/rocpp-api-breaking) idea is to adopt a rosjava-like interface where each "ros-based executable" (for lack of a better term) can contain any number of masters or nodes--leaving the onus on developers to choose how to segment a ROS graph over different transports. I've experimented with rosjava heavily over the past few months and I find the flexibility to be pretty powerful. This would mean fundamental changes in the c++ & python APIs however.

As for master discovery, multicast DNS seems like the general solution that folks are adopting. Anyone think adopting something like Bonjour for discovery is a bad idea? Are there viable alternatives? I've been using a custom mDNS/Bonjour solution successfully in my lab for several years now.

Jeff

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.

Reply all
Reply to author
Forward
0 new messages