Concert Framework/Concert Clients

= Concert Clients =

Participants in a concert can range from robots to embedded devices, humans with tablets (androids), pc applications, web services and apps. Each of these is considered unequivocally as a. Concert clients have the freedom to define their own implementations (support for cross-platform or varied robot operating system types) so long as they conform to a minimum specification that allows them to connect to concerts.

Concert clients implementations are typically thin pieces of software between the concert and the applications that run on the client and are responsible for three areas of activity:


 * Transferring platform information to the concert
 * Handling connectivity of the client with the concert.
 * Optionally, retasking of the client.

= Variants =

A concert client's behaviour differs significantly depending on its means of connectivity, thus two groups are distinctly defined below.


 * : autonomously operating clients that are invited to the concert [robots, embedded devices, pc applications and web services].
 * : a concert client that can change its mode of behaviour by relaunching its internal software under a different configuration upon request.
 * : interactive clients operated by a human that pro-actively join the concert [tablets, web apps].

Embedded devices are an example of a regular concert client. This may be a processing unit attached to a mechanism or sensor that is always available and not retaskable. The client interfaces will either be embedded on the device or proxied somewhere on the network as representative of that device. Device configuration may optionally provide a means of whitelisting/blacklisting concerts to automatically join.

Complex robots and pc applications are examples of retaskable clients. Typically a robot may have multiple launch configurations that modify it's behaviour for different environments or activities (e.g. hall navigation may be significantly different from outdoor navigation on the balcony), or enable/disable internal components at will to direct computational power where it is needed. A pc concert client will likely have multiple applications that could be run on a pc (from off-robot algorithms to human friendly interfaces to the concert) with the major difference being the pc applications will more often be standalone whilst the robot launchers are usually a complex interaction of working components. The concert clients at the moment provide retasking via relaunchable entities referred to as (rocon/robot applications). This concept may change as the Orchestration layer becomes more formally defined.

Humans working on tablets or across the internet (via a web portal) are examples of interactive concert clients. In our design, humans will always be provided the choice to participate in a concert - this choice may be activated via an nfc swipe, qrcode or zeroconf scan, or logging into a web portal and choosing a concert to join. This is different from the former clients who are always automatically invited by the system.

= Specification =

The following is only a rough working draft (and very ros-oriented). More formal versions to follow.

Concert Communications
Communications are currently using the ROS framework, so any incoming/outgoing communications from the client to the concert and vice versa must be done with one of the ros transport implementations - this currently includes roscpp, rospy, roslisp, rosjava or rosc. This doesn't preclude the internals of the concert client being ros agnostic though - in these cases the concert client implementation acts as a bridge between two systems. For ROS concert clients, the implementation requires a multimaster framework such as the gateways.

Client API
Since the higher level communications is currently using ros, these are defined by ros messages and services. If any of the links below become out of date, the latest message types can be found on github.

All api must be appropriately nested underneath a namespace defined by the 'robot name + uuid suffix'.

Services

 * platform_info (rocon_app_manager_msgs/GetPlatformInfo)

Provide a description of the robot via a platform tuple (see below for more information).


 * status (rocon_app_manager_msgs/Status)

Status of the concert client (busy, idle, running an app or not).


 * invite (rocon_app_manager_msgs/Invite)

Request to assume control of the app manager (start_app, stop_app).


 * start_app (rocon_app_manager_msgs/StartApp)

Start an application. Any services or topics that are listed in the rapp's public interface should be flipped and remapped rules as requested. For clients that are not retaskable, this may be a stub (application is always assumed to be running) that always returns true.


 * stop_app (rocon_app_manager_msgs/StopApp)

Start an application. For clients that are not retaskable, this may be a stub (application is always assumed to be running) that always returns true.

Publishers

 * list_apps (rocon_app_manager_msgs/AppList)

List apps that are available/installable on the robot.

Invitation Handling

 * (Retaskable) Concert Clients

Non-interactive clients must run in conjunction with a gateway system for which the platform_info, status and invite services are advertised. Upon being invited, start_app and stop_app api must be flipped to the centralised concert workspace.


 * Interactive Concert Clients

Interactive concert clients may directly connect to the centralised concert workspace where they are required to establish platform_info, status and invite handles. Upon invitation, they then directly establish start_app and stop_app handles.

Platform Info
Each client is expected to advertise a tuple representing it’s platform. This tuple is of the form:

os.version.framework.robot.name


 * Operating Systems: linux, windows, android
 * Versions : precise, 7.3, jellybean
 * Frameworks: ros, opros, custom
 * Robots: pc, jellybean (android tablets), pr2, turtlebot
 * Name: provided by the robot, or by the concert, e.g. 'Cybernetic Pirate'.

= Implementations =


 * ROS Python Concert Client

= Status =

State:

History:


 * Dec '13 - Incorporate capabilities introduced by OSRF.
 * June '13 - Linux python based concert client, first version.