ARCS/en
Un article de Wiki-evr@.
ARCS (for Augmented Reality Component System) is a framework dedicated to the design of augmented reality applications. The core of the framework is a general purpose component system cutomized to meet the requirements of augmented reality applications (mostly real-time constraints). A set of components is developped on top of this system for augmented reality applications.
Sommaire |
Motivations
During the last years, AR (Augmented Reality) community has proven the need of an infrastructure. Almost 30 different projects of framework have been developed for AR [Endres05].
Amongst these projects, the most remarkable ones are :
- Studierstube, one of the oldest project relying on a ditributed scenegraph,
- Tinmith, which is oriented for developpers,
- Dwarf, developped for distributed augmented reality services,
- AMIRE, which is the closest architecture to ARCS.
Our choice is to develop or rely on a component system that meets several requirements such as portability, a variable granularity, some scalability, and a high level of abstraction for end-users. As we will see, we will introduce component life-cycle management mechanisms in ours application developed with our framework. We will also combined it with with a system allowing on-line reconfiguration of data-flow.
The ARCS Core
Components
According to Szyperski’s definition [Szyperski02], “A component is a coherent package of software that can be independently developed and delivered as a unit, and that offers interfaces by which it can be connected, unchanged, with other components to compose a larger system”.
It means that, the way components will communicate with each other should be described, how they’re implemented, how they’re initialized and how we can use them to build applications.
Signal/slots
Our solution is based on the signal/slot communication model between components. This paradigm, mainly used in user interfaces API, tends to reach other scopes of specific programming. Some libraries are implementing it, for example: QT [1], libsigc++ [2] derived from GTK+, sigslot [3] and boost [4]. Signals represent callbacks with multiple targets. Signals are connected to some set of slots, which are callback receivers. They are triggered when the signal is ”emitted”. Signals and slots can be connected and disconnected dynamically at runtime and are managed. That is to say, connections are tracked by objects owning signals and slots. They’re able to automatically disconnect signal/slot connections when one of the object involved in communication is destroyed. This allows the user to make signal/slot connections without expending a great effort to manage the lifetimes of those connections with regard to the lifetimes of all objects involved.
Component representation
A component in ARCS is an entity or object able to export by itself its interface which is made of signals and slots. As we will see, we will often use both the terms of components and objects to refer to the same thing, since the components we will develop are objects.
Component libraries
Components are compiled pieces of code stored in dynamic libraries with three specific entry points:
- one for describing objects stored in the library,
- one for instantiating an object contained in the library,
- one for destroying an object instantiated from this library.
Once components are stored in dynamic libraries, we can load and use them on demand. Therefore, a component may require some configuration so we need a system to set component properties.
Component Initializations
Components initializations are performed through slots. However, these slots must meet a few requirements. They must have only one parameter and this parameter belongs to a list of simple types such as strings, numerical values and other components.
Further, we will establish a distinction between two kinds of initializations depending on when they’re triggered. Indeed, a slot call can also trigger a signal that belongs to the same component; this last one may call another slot if a signal/slot connection is established between them. So, we have Pre-connection initializations that are performed before the component is connected with others and we have a second category we call post-connection initialization that are triggered after the component is connected to other ones. This second one allows propagating initializations through connections.
Since a component can be connected to other components, we will see the different solutions we have to connect components.
Compositions of components
The sheet, an explicit composition
Initialisations of components
Other composition mechanism
Extending the sheet capabilities
Publications
J.Y. Didier, S. Otmane, M. Mallem - A Component Model for Augmented/Mixed Reality Applications with Reconfigurable Data-flow
Pdf