The following is a brief summary of some existing techniques.
Master Sync
History
The first master sync came out with the building manager project in an effort to connect independant robots to a centralised super master (aka the building manager). This you can find in the existing app manager code, which was then spun out into its own package upon request. The building manager project got put on hold though and development stopped there.
Rocon took the master sync code and modified it minimally to handle dhcp connections and the dynamic updates necessary for an updated app manager environment.
Details
It communicates between two ros masters, flipping topics and services across to a remote master.
The multimaster implementation runs a static node which pulls its configuration from the parameter server. The others run as a module inside a higher level interface (app_manager or rocon_app_manager) which can dynamically flip topics and services across to a remote master.
Under the hood, it does everything via the xmlrpc master api.
Pros/Cons
- + can be configurable and runtime usable
- + starts integrating with zeroconf discovery (rocon_master_sync only)
- - it is twomaster, not multimaster
- - direct access to remote masters
Foreign Relay
Details
Command line tool that can flip local topics to a foreign master.
Pros/Cons
- + being a relay, it can convert reliable to unreliable
- - creates an additional pub/sub
- - command line tool only
Fkie Multimaster
Details
It expose the entire ros system from one ros master to another (expect parameter).
Unlike the master_syncs which use the master xmlrpc api directly, fkie's multimaster uses the rosgraph python abstraction interface to the master api.
Pros/Cons
- + starts to add some wireless monitoring
- + starts to do true multimaster, not twomaster
- + starts integrating with multicast/zeroconf discovery
- + NO direct access to remote masters. The discovery node runs localy and collects all registration data of the local ROS master through xmlrpc interface. Remote sync nodes connect to the discovery node to get the registration data.
- + master_sync makes no changes/registrations on remote ROS master
- + transparent extension from one ROS master to a multimaster system (in case of the configuration)
- - completely exposes local master (there are ROS launch parameters to filter discovered hosts or all topics of a specified node. Changes at runtime are not possible.)
- - the detection of registration changes in ROS master is done by polling. (The ROS master does not offer other possibilities to detect new topics or services.)
