[Documentation] [TitleIndex] [WordIndex

Multi-Master [Fuerte]

(!) Continued in Groovy Multimaster Planning

Details

SIG Coordinator: Jeff Rousseau

Mailing list:

Topics: Adding multi-master support for a couple of common use cases

Members:

Use Cases

Security

Ken Conley, Daniel Stonier, Jeff Rousseau

When connecting to a robot remotely (e.g. web, or even public wifi), its useful to only expose public interfaces instead of the entire robot. One mechanism for doing this is to have a 'public Master', which only has the public subset of topics that are exposed. One can then use iptables and other mechanisms to 'lock down' access to non-publicly declared ports.

This is partially implemented in app_manager. Using a 'interface' file, we are able to dynamically bring up the public master and maintain synchronization of the enumerated topics. The app_manager goes a bit further as it does launching and remapping of the topic names into robot-specific namespaces, which is mainly to support multirobot scenarios. The latter needs much more work to be usable.

Yujin is also very interested in this path - particularly because of commercialisation of products, but also because I think multi-robot stuff is at a higher level - such simplification makes sense.

Multi-Robot

Nick Armstrong-Crews

Robots talking to each other directly (I'm thinking over wifi). They may wander in and out of range of each other.

Android to Robot

Ken Conley, Daniel Stonier

Currently, an Android device can either run its own master, or attach to a remote master. Ideally, it should be able to do both, i.e. the Android device is a robot, and it is also capable of controlling one or more other robots, all without having to restart any nodes.

NAC: is this a special case of "teleop over wifi?"

Faster remote debugging

Ken Conley

When interacting on a remote terminal with a robot, commands line rostopic/etc... can get sluggish as they have to poll the master for the latest information; tab-complete in particular slows down. The master information usually does not change that fast, so it would be ideal to 'cache' this information somehow. As the master DB is not very large, one way of implementing caching is simply to replicate the master. In this particular view, every machine that interacts in a ROS graph would have a master; one authoritative, the rest just syncing.

Auto-Discovery

Daniel Stonier

The ability to be able to advertise/discover ros masters or other services so connections do not have to be manually configured by hand.

Network Topology Awareness

Daniel Stonier

Possible courses of action that might be taken to provide a means of determining and distributing information about the network connection state of components in a multi-robot solution (see Network Quality of Service for implementation ideas).

Teleop over Wifi

Human->joystick->laptop /\/\--wifi--/\/\-->laptop-->robot

Motor commands go out, video feed (and maybe telemetry) comes back.

Technologies to support Use Cases

Network Quality-of-Service

Nick Armstrong-Crews

I'm thinking mainly for wifi, but maybe 3G, etc. This is not really multi-master, but the "flaky wifi" topic got lumped into this SIG.

Testimonials


2019-10-19 12:42