My testimonial is remarkably similar to Jon’s: team of mobile ground robots talking over wifi (vanilla 802.11n, in our case). We also made a node to mirror pub/sub topics between multiple masters, like Jon’s item (2), using a whitelist. We didn’t do (1), though… nice job.

Our use case was multi-robot mapping, using the standard azimuthal lidar configuration. Our primary challenge was (a) intermittent connectivity; (b) bandwidth did not really cause a problem (laser scans are relatively small [vis-à-vis video]); and as for (c) hard de-centralized algorithmic problems of multi-robot coordination and localizing each other in a common spatial reference frame, I don’t think we can really solve that in this SIG.

To address (a), we made a ROS network monitor that would notify subscribing nodes of which robots were connected (and any changes), with what signal strengths, and with what data rates; we also built in our own scan buffering / bursting based on that knowledge of connectivity.

As mentioned, to address (b), we did exactly what Jon did (albeit independently).

I also recall that ROS pub/sub was not very robust to the connection going up and down; this was back in pre-history before the advent of ROS UDP, so I’m not sure if this is still an issue. In any case, pub/sub parameters being able to change as the network changes (data rates, latencies, topology) would be really cool.