ROSS API Concept

The core of the ROSS API rests on the notion that the different objects, surfaces and spaces in a responsive environment can exist in nested relationships with respect to one another.

ROSS Approach

  • The ROSS API is designed to communicate through several software levels across multiple platforms that are very different but have common interactions.
  • The ROSS API establishes communication between the hardware driver level and the application software level by making the interface between these levels abstract.
  • The ROSS API uses a nested structure to make interactions visible from one software level to others.

Core Class Structure of the ROSS API

RSpaces can have nested RSurfaces and RObjects. RSurfaces can only have nested RObjects and vice versa. RControls correspond to physical interface controls (e.g. buttons, dials) that can be attached to an RObject. The core classes all derive from the RTangible class, which provides common attributes across all classes.

Example nested structure of the ROSS API

In the left figure are the ROSS API components in a room. There is an interactive tabletop with a puck and a mobile phone on its tabletop surface. Users interact with the tabletop and the objects on top of it. The right figure shows the hierarchical nested structure.

Nested Structure of the ROSS API

RSurfaces, RObjects and RControls for a given platform configured can be configured in XML by the application developer. This xample shows a portion of the XML file used to configure the TViews Table platform for an application that uses a range of button-enabled tagged objects.

ROSS API Communication Architecture

The RManager and RProxy serve as an interface between the device drivers and applications. Devices report events to the RManager in real-time via OSC. The current platform configuration in XML is reported to and stored in the RProxy at start-up and shut-down. Routing and device information exchange is done via XML between the RProxy and RManager.

Supported Platforms

Some platforms configurations currently supported by the ROSS API with a representation of their nested structures of RSurfaces, RObjects and RControls. Currently, the two full-body environments are represented as RSurfaces since they track 2D blobs via computer vision.

For Further Technical Details

For further technical details about the ROSS API, please see the ROSS Publications.

Other Synlab Projects:


emBodied Digital Creativity

Tangible Anchoring



Project Supporter: