ARCS/en

Un article de Wiki-evr@.

< ARCS(Différences entre les versions)
Version du 20 juillet 2006 à 10:53 (modifier)
Gi (Discuter | Contributions)
(→Why programming with components ?)
← Différence précédente		 Version actuelle (17 novembre 2011 à 22:19) (modifier) (défaire)
Gi (Discuter | Contributions)

 
(7 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.
-== Basics ==+[http://arcs.ibisc.univ-evry.fr ARCS has now its own website.]
 + 
 + 
 +<!--== 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 {{refa|Endres05}}.
 + 
 +Amongst these projects, the most remarkable ones are :
 +* [http://studierstube.icg.tu-graz.ac.at Studierstube], one of the oldest project relying on a ditributed scenegraph,
 +* [http://www.tinmith.net Tinmith], which is oriented for developpers,
 +* [http://ar.in.tum.de/Chair/ProjectDwarf Dwarf], developped for distributed augmented reality services,
 +* [http://www.amire.net 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 === === Components ===
According to Szyperski’s definition {{refa|Szyperski02}}, “A component According to Szyperski’s definition {{refa|Szyperski02}}, “A component
Ligne 18 : Ligne 46 :
applications. applications.
-Before detailing our components, we should introduce the main communication mechanism +==== Signal/slots ====
-we use, which is based on the signal/slot paradigm.+
- +
-=== Signal/slots ===+
Our solution is based on the signal/slot communication Our solution is based on the signal/slot communication
model between components. This paradigm, mainly model between components. This paradigm, mainly
-used in user interfaces API, tends to reach other scopes+used in user interfaces API, reaches other scopes
-of specific programming. Some libraries are implementing+of programming. Some libraries are implementing
it, for example: QT [http://www.trolltech.com ], it, for example: QT [http://www.trolltech.com ],
libsigc++ [http://libsigc.sourceforge.net] derived from libsigc++ [http://libsigc.sourceforge.net] derived from
Ligne 33 : Ligne 58 :
triggered when the signal is ”emitted”. Signals and triggered when the signal is ”emitted”. Signals and
slots can be connected and disconnected dynamically slots can be connected and disconnected dynamically
-at runtime and are managed. That is to say, connections+at runtime and are managed.
-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.+
-=== Why programming with components ? ===+==== Component representation ====-->
-During the last years, AR (Augmented Reality) community+<!--[[Image:ARCS_component.png|right|thumb|ARCS Component representation]]--><!--
-has proven the need of an infrastructure. Almost+A component in ARCS is an entity
-30 different projects of framework have been developed+or object able to export by itself its interface which is
-for AR {{refa|Endres05}}. +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.
-Amongst these projects, the most remarkable ones are :+==== Component libraries ====
-* [http://studierstube.icg.tu-graz.ac.at Studierstube], one of the oldest project relying on a ditributed scenegraph,+Components are compiled pieces of code stored in dynamic
-* [http://www.tinmith.net Tinmith], which is oriented for developpers,+libraries with three specific entry points:
-* [http://ar.in.tum.de/Chair/ProjectDwarf Dwarf], developped for distributed augmented reality services,+* one for describing objects stored in the library,
-* [http://www.amire.net AMIRE], which is the closest architecture to ARCS.+* one for instantiating an object contained in the library,
 +* one for destroying an object instantiated from this library.
-Our choice+Once components are stored in dynamic libraries, we
-is to develop or rely on a component system+can load and use them on demand. Therefore, a component
-that meets several requirements such as portability, a+may require some configuration so we need a
-variable granularity, some scalability, and a high level+system to set component properties.
-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 ==+==== Component Initializations ====
 +--><!--[[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]]-->
 +<!--
 +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.
-=== 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 === === Compositions of components ===
-==== The sheet, an explicit composition ====+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.
-==== Initialisations of components ====+==== 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.
-==== Other composition mechanism ====+===== 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.
-=== Extending the sheet capabilities ===+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

Vers la version française
A view of the graphical editor.
A view of the graphical editor.

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.

ARCS has now its own website.


[modifier] Publications

J.Y. Didier, S. Otmane, M. Mallem - A Component Model for Augmented/Mixed Reality Applications with Reconfigurable Data-flow

8th International Conference on Virtual Reality (VRIC 2006) pp. 243-252, Laval (France), April 26-28, 2006
Pdf Bibtex

Récupérée de « http://evra.ibisc.univ-evry.fr/index.php/ARCS/en »