[Documentation] [TitleIndex] [WordIndex

Terminology

Assumptions

Design

Overview

The building manager is assumed to be running.

When the robot is brought up, 2 masters are launched. The primary master, MR, and the secondary master, MRs. 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 MRs. The contents of MRs are then weakly sync'd into MB. 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 MRs

  3. launch the application
  4. using the application interface definition, the appropriate APIs for the application should be sync'd strongly from MR into MRs, and in turn sync'd to MB 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 MRs for a given robot, and maybe some extra metainformation -- robot name, type, etc.

Longer term


2019-12-07 12:21