[Documentation] [TitleIndex] [WordIndex


Vapor_master is a drop in replacement for rosmaster enabling high availability ROS service discovery. Vapor removes the single point of failure fundamental to ROS1 enabling new options for achieving greater scale, up-time and resiliency in ROS 1.x solutions.

Vapor applies to three use cases:

If you find yourself dissatisfied with the rosmaster's limitations:

Then vapor_master is for you!


Vapor implements the ROS Master API as well as the Parameter Server API utilizing a modern micro services approach. Unlike rosmaster, which does only supports an in-memory datastore, vapor persists data to a mongodb database. This enables instances of vapor to come and go without the need to stop all other ROS nodes left running on other computers.

vapor uses mongodb replication to work through failure

In assembly lines and mobile robots utilizing 3 or more computers, vapor_master can be deployed to all compute nodes. While mongodb can be deployed to a minimum of 3 nodes. In this scenario the ROS_MASTER_URI can be set to http://localhost:11311 as if each node were its own rosmaster. In this way an given compute node can come and go as needed without preventing ros parameter access or service discovery.

scale up and fan out

In cloud environments vapor_master can be deployed to all cloud instances while a dedicated mongodb cluster is deployed along side. Thus enabling coherent datacenter scale deployments of ROS 1.x work flows.


Vapor does not:

Vapor's focus is on scaling ROS 1.x for applications which require high availability but are unable to be ported to ROS 2.0. It does not address the security short comings of ROS 1.

2024-07-13 14:39