ARCS/en
Un article de Wiki-evr@.
< ARCS(Différences entre les versions)
Version du 24 juillet 2006 à 11:27 (modifier) Gi (Discuter | Contributions) (→Signal/slots) ← Différence précédente |
Version actuelle (17 novembre 2011 à 22:19) (modifier) (défaire) Gi (Discuter | Contributions) |
||
(3 révisions intermédiaires masquées) | |||
Ligne 4 : | Ligne 4 : | ||
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. | 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. | ||
- | == Motivations == | + | [http://arcs.ibisc.univ-evry.fr ARCS has now its own website.] |
+ | |||
+ | |||
+ | <!--== Motivations == | ||
During the last years, AR (Augmented Reality) community | During the last years, AR (Augmented Reality) community | ||
has proven the need of an infrastructure. Almost | has proven the need of an infrastructure. Almost | ||
Ligne 57 : | Ligne 60 : | ||
at runtime and are managed. | at runtime and are managed. | ||
- | ==== 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 82 : | ||
==== 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 | ||
- | slots | + | slots with only one parameter which to a list of simple types such as |
- | + | ||
- | + | ||
strings, numerical values and other components. | strings, numerical values and other components. | ||
- | + | We establish a distinction between two | |
kinds of initializations depending on when they’re triggered. | kinds of initializations depending on when they’re triggered. | ||
Indeed, a slot call can also trigger a signal that | Indeed, a slot call can also trigger a signal that | ||
Ligne 103 : | Ligne 104 : | ||
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 === | ||
- | ==== The sheet | + | An explicit composition let us know exactly how components are connected. |
- | [[Image:ARCS_sheet.png|right|350px|thumb]] | + | 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 actuelle
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.
[modifier] Publications
J.Y. Didier, S. Otmane, M. Mallem - A Component Model for Augmented/Mixed Reality Applications with Reconfigurable Data-flow