|
Size: 5085
Comment:
|
Size: 5086
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 39: | Line 39: |
| Through the !AppManager API, which should now be visible to anyone connected to the building master, one can now launch an appliction on an arbitrary robot. As a result, the Application Manager should: | 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: |
| Line 43: | Line 43: |
| 1. using the application interface definition, the appropriate APIs for the application shoudl 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. | 1. 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. |
Terminology
Operator: An end-user wanting to control, and/or retrieve information about, one or more robots in the building.
Robot Master (MR): The primary master running on a given robot. All nodes on the robot are launched against this master.
Robot Secondary Master (MRs): The secondary master running on a given robot. This master is sync'd to MR, 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 (MB): 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, 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:
- terminate any existing application
clear the application namespace in MRs
- launch the application interface
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
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
