ARCS/en
Un article de Wiki-evr@.
| Version du 24 juillet 2006 à 11:41 (modifier) Gi (Discuter | Contributions) (→Component Initializations) ← Différence précédente |
Version du 24 juillet 2006 à 12:03 (modifier) (défaire) Gi (Discuter | Contributions) (→The ARCS Core) Différence suivante → |
||
| Ligne 58 : | Ligne 58 : | ||
| ==== Component representation ==== | ==== Component representation ==== | ||
| - | [[Image:ARCS_component.png|right|thumb|ARCS Component representation]] | + | <!--[[Image:ARCS_component.png|right|thumb|ARCS Component representation]]--> |
| A component in ARCS is an entity | A component in ARCS is an entity | ||
| or object able to export by itself its interface which is | or object able to export by itself its interface which is | ||
| Ligne 79 : | Ligne 79 : | ||
| ==== Component Initializations ==== | ==== Component Initializations ==== | ||
| - | [[Image:ARCS_Preconnexion.png|thumb|250px|Pre-connexion initialization. Since components are not connected, initializations cannot propagate]] | + | <!--[[Image:ARCS_Preconnexion.png|thumb|250px|Pre-connexion initialization. Since components are not connected, initializations cannot propagate]]--> |
| - | [[Image:ARCS_Postconnexion.png|thumb|250px|Post-connexion initialization. When components are connected, if a slot triggers a signal, then the initialization may propagate through components]] | + | <!--[[Image:ARCS_Postconnexion.png|thumb|250px|Post-connexion initialization. When components are connected, if a slot triggers a signal, then the initialization may propagate through components]]--> |
| Components initializations are performed through | Components initializations are performed through | ||
| Ligne 101 : | Ligne 101 : | ||
| Since a component can be connected to other components, | Since a component can be connected to other components, | ||
| - | we will see | + | we will see how they communicate to each other. |
| - | + | ||
| === Compositions of components === | === Compositions of components === | ||
| - | + | An explicit composition let us know exactly how components are connected. | |
| - | + | It is performed by connecting signals to slots. | |
| - | ==== | + | ==== The sheet concept ==== |
| + | <!--[[Image:ARCS_sheet.png|right|350px|thumb]]--> | ||
| + | We introduce here the concept | ||
| + | of sheet. In a component based framework, an application | ||
| + | could be seen as a set of components working (or | ||
| + | more properly communicating) together. We choose | ||
| + | to name this set a “sheet”. | ||
| + | A sheet is storing components initialization and | ||
| + | components signal/slots connections. | ||
| - | ==== | + | ==== Macro-blocks ==== |
| + | A sheet can also be used to represent a subset of components | ||
| + | working together. They will be called macroblocks. | ||
| + | They are defined by global slots and | ||
| + | signals to which classical components of our system | ||
| + | can connect and interact. These global inputs/outputs | ||
| + | are mapped to internal components of the macroblock. | ||
| - | === | + | ==== Extensions of composition mechanism ==== |
| + | We will introduce two more mechanisms, the first is | ||
| + | consisting in using a state machine and the second is | ||
| + | dedicated to components life-cycle management. | ||
| + | |||
| + | ===== Adding a statemachine ===== | ||
| + | Indeed, a sheet reflects a state of an application. | ||
| + | An application could be seen as a stack of sheets. We | ||
| + | then need a mechanism to switch between sheets: its core is a statemachine. | ||
| + | |||
| + | A state machine | ||
| + | is, in our case, composed of states and transitions. | ||
| + | The transitions are described by an initial state, | ||
| + | a token and a final state. | ||
| + | Sheets are modified to send tokens to the statemachine | ||
| + | relying on one specific component for it. | ||
| + | Each token sent to the state machine | ||
| + | can make it switch to another application state | ||
| + | that will be represented by another sheet. | ||
| + | The new | ||
| + | state can be a terminal state that will shutdown components. | ||
| + | If we suppose a sheet (current sheet) is active and | ||
| + | that the state machine has received an identified token | ||
| + | triggering a transition, the sheet switch mechanism | ||
| + | will follow these steps: | ||
| + | # ''Disconnections:'' each signal/slot connection of the current sheet is destroyed. All components specifically instantiated for the current sheet are destroyed. All components communications are stopped, | ||
| + | # ''Change of current sheet:'' the final state of the triggered transition becomes the current sheet. Each object that needs to be specifically set up for the sheet is instantiated, | ||
| + | # ''Pre-connection initializations:'' before connecting signal/slot couples of the current sheet, components can be initialized separately, | ||
| + | # ''Connections:'' each signal/slot connection described in the current sheet is activated. New communication links between components are established, | ||
| + | # ''Post-connection initializations:'' reserved to initializations that propagate through different components when they’re connected to each other. | ||
| + | |||
| + | This described mechanism allows us to change the | ||
| + | data path between components. We then have a reconfigurable | ||
| + | data-flow. At the same time, life-cycle component management during the application run time is introduced | ||
| + | in steps 1 and 2. | ||
| == Publications == | == Publications == | ||
| {{bibtex|Didier06}} | {{bibtex|Didier06}} | ||
Version du 24 juillet 2006 à 12:03
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, reaches other scopes of 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.
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 with only one parameter which to a list of simple types such as strings, numerical values and other components.
We 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 how they communicate to each other.
Compositions of components
An explicit composition let us know exactly how components are connected. It is performed by connecting signals to slots.
The sheet concept
We introduce here the concept of sheet. In a component based framework, an application could be seen as a set of components working (or more properly communicating) together. We choose to name this set a “sheet”. A sheet is storing components initialization and components signal/slots connections.
Macro-blocks
A sheet can also be used to represent a subset of components working together. They will be called macroblocks. They are defined by global slots and signals to which classical components of our system can connect and interact. These global inputs/outputs are mapped to internal components of the macroblock.
Extensions of composition mechanism
We will introduce two more mechanisms, the first is consisting in using a state machine and the second is dedicated to components life-cycle management.
Adding a statemachine
Indeed, a sheet reflects a state of an application. An application could be seen as a stack of sheets. We then need a mechanism to switch between sheets: its core is a statemachine.
A state machine is, in our case, composed of states and transitions. The transitions are described by an initial state, a token and a final state. Sheets are modified to send tokens to the statemachine relying on one specific component for it. Each token sent to the state machine can make it switch to another application state that will be represented by another sheet. The new state can be a terminal state that will shutdown components. If we suppose a sheet (current sheet) is active and that the state machine has received an identified token triggering a transition, the sheet switch mechanism will follow these steps:
- Disconnections: each signal/slot connection of the current sheet is destroyed. All components specifically instantiated for the current sheet are destroyed. All components communications are stopped,
- Change of current sheet: the final state of the triggered transition becomes the current sheet. Each object that needs to be specifically set up for the sheet is instantiated,
- Pre-connection initializations: before connecting signal/slot couples of the current sheet, components can be initialized separately,
- Connections: each signal/slot connection described in the current sheet is activated. New communication links between components are established,
- Post-connection initializations: reserved to initializations that propagate through different components when they’re connected to each other.
This described mechanism allows us to change the data path between components. We then have a reconfigurable data-flow. At the same time, life-cycle component management during the application run time is introduced in steps 1 and 2.
Publications
J.Y. Didier, S. Otmane, M. Mallem - A Component Model for Augmented/Mixed Reality Applications with Reconfigurable Data-flow
Pdf