[Documentation] [TitleIndex] [WordIndex

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

Foreign Relay

Details

Command line tool that can flip local topics to a foreign master.

Pros/Cons

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


2019-10-12 13:08