ARCS/en

Un article de Wiki-evr@.

< ARCS(Différences entre les versions)
Version du 19 juillet 2006 à 14:57 (modifier)
Gi (Discuter | Contributions)

← Différence précédente		 Version actuelle (17 novembre 2011 à 22:19) (modifier) (défaire)
Gi (Discuter | Contributions)

 
(14 révisions intermédiaires masquées)
Ligne 1 : Ligne 1 :
{{fr}} {{fr}}
-ARCS (for Augmented Reality Component System) is a framework dedicated to the design of augmented reality applications.+[[Image:Metaruntime_sheet.png|right|300px|thumb|A view of the graphical editor.]]
 +'''ARCS''' (for '''A'''ugmented '''R'''eality '''C'''omponent '''S'''ystem) 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. 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.
 +
 +[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 ===
 +According to Szyperski’s definition {{refa|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 [http://www.trolltech.com ],
 +libsigc++ [http://libsigc.sourceforge.net] derived from
 +GTK+, sigslot [http://sigslot.sourceforge.net] and boost [http://www.boost.org]. 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 ====-->
 +<!--[[Image:ARCS_component.png|right|thumb|ARCS 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 ====
 +--><!--[[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.
 +
 +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 ====-->
 +<!--[[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 ==
 +{{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 »