Terminology

• Operator: An end-user wanting to control, and/or retrieve information about, one or more robots in the building.

• Robot Master (M_R): The primary master running on a given robot. All nodes on the robot are launched against this master.

• Robot Secondary Master (M_Rs): The secondary master running on a given robot. This master is sync'd to M_R, it serves to present only a reduced interface to clients.

• Platform: the base set of nodes running on a robot against the robot master. These nodes are brought up by robot.launch or equivalent.

• Building Master (M_B): A single master running in the building at a known location.

• Building Manager: The set of nodes running against the building master which provide:

  • A discovery mechanism for building-manager-capable robots
  • A consistent ROS interface, giving operator clients (such as the RIDE UI) access to robots
  • A consistent ROS interface, giving building-manager-capable robots access to information about the building and/or other robots

• Warehouse: The subset of the Building Manager which provides interfaces for data storage and retrieval.

• Building-Manager-Capable Robot: A robot running the required set of nodes for interaction with the Building Manager as part of its platform. These nodes must produce topics that adhere to the Managed Robot API.

• Managed Robot API: The list of topics and services that all building-manager-capable robots must make available. This will include some relevant state information (battery level, location, etc.), and include the AppManager API. Every robot needs to have a unique name. The entirety of the Managed Robot API is should be pushed into a namespace with the name of the robot.

• Application: an additional set of ros nodes designed to run on top of the platform, and which provide a well-defined ROS interface that can be used for

• Application Interface: The list of topics and parameters which are required for an operator to interact with a robot. This is what will be exported to the building master.

• Application Manager: A set of nodes running as part of the robot platform which allow for bringup / teardown of applications. The application manager provides a well-defined interface which is exported to the building master via the Managed Robot API.

• Strong Synchronization: An approach to master synchronization which assumes a constant and reliable connection. Syncing happens rapidly and is likely event driven.

• Weak Synchronization: An approach to master synchronization which assumes a lossy and sometimes missing connection. Syncing happens whenever possible, but is robust to connection failures. Syncing may instead occur via polling or querying the other master for state. If connectivity is lost, resources may time out.

Assumptions

• The building master location is known (http://buildingmaster:11311)

• Warehouse is running against the building master
• RIDE UI runs against the building master
• The building manager does not have a priori knowledge of robots or their IP addresses
• Each robot is running its own master
• Building Manager and all robots are running on the same network. All ros resources are reachable assuming they can be resolved by an appropriate master.
• The building master and robot network segments are separated by a wireless link -- we cannot count on reliable network connectivity between these 2 segments

Design

Overview

The building manager is assumed to be running.

When the robot is brought up, 2 masters are launched. The primary master, M_R, and the secondary master, M_Rs. The entirety of the Managed Robot API is strongly sync'd between these two masters.

A discovery mechanism running on the building manager, and as part of the managed robot platform, allows the building manager to discover M_Rs. The contents of M_Rs are then weakly sync'd into M_B. By construction this should all be within a namespace unique to the robot to prevent name collisions.

Through the AppManager API, which should now be visible to anyone connected to the building master, one can now launch an application on an arbitrary robot. As a result, the Application Manager should:

1. terminate any existing application

2. clear the application namespace in M_Rs

3. launch the application

4. using the application interface definition, the appropriate APIs for the application should be sync'd strongly from M_R into M_Rs, and in turn sync'd to M_B Note: an application API must be remapped/namespaced to place it inside of the managed robot API.

Components

Strong MasterSync

Status: Proof of concept exists

This node needs to be configurable with a set of topics and services and should keep them completely sync'd between two masters. We can likely base this off of the existing master_sync.py. This probably just needs some work on configurabiilty and robustness.

Weak MasterSync

Status: Needs to be designed

The approach used in the strong master sync is unlikely to work. A sensible approach may be to add a new API to the master to allow querying and/or setting all state below some namespace. A node will need to repeatedly try connecting to the robot master with a short connection timeout.

Application Interface Specification

Status: Preliminary working specification exists

../ApplicationInterface

We need to write a formal specification for application interfaces. It makes sense for these to be initially inspired by the node clearsilver specifications in the ROS wiki if we want to use this as a proof of concept of formalized node interfaces. First cut is probably yaml lists of produced and consumed topics and services and their respective types.

Interface resource names should probably be assumed to be relative to a standard name, such as "application," for remapping purposes. Suppose my application Foo.app, wants to subscribe to a std_msgs/String on the topic bar, it might be specified as:

subscribed_topics:
  bar: std_msgs/String

However, in the application launchfile, a node would actually subscribe to application/bar, using a nodehandle to get proper remapping behavior:

ros::NodeHandle app_nh("application");
ros::Subscriber sub = app_nh.subscribe("bar", ...);

and finally, when actually being launched, the launcher would use a remapping such as: application:=turtlebot42/app

Application Manager

Status: Under Development (JL)

The application manager needs to provide a servicecall or action interface for finding out about available/running applications, and launching new applications. This should be fairly straightforward. Open the app file. Roslaunch the referenced launch file with appropriate remapping for the application namespace, and then use the interface specification to setup an instance of strong master sync.

Discovery

Status: Needs to be designed

We need to implement some kind of discovery mechanism so that the building manager can locate the masters of managed robots. It would be cool to do this with something along the lines of zeroconf/bonjour. Some node in the building manager just needs to receive updates that contain the address of M_Rs for a given robot, and maybe some extra metainformation -- robot name, type, etc.

Longer term

• Redis: key/value store backend with replication that may replace prototype components. Has built in TTL support as well.
• Installing apps under new user accounts (restricted permissions): start addressing threat models for apps themselves