ARCS/en

Un article de Wiki-evr@.

< ARCS(Différences entre les versions)

Version actuelle

Vers la version française

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 »

 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
+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
 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
 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 ],
 libsigc++ [http://libsigc.sourceforge.net] derived from
 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
+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 ====-->
+<!--[[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.
-== The ARCS Core ==
+==== 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.
-=== Components ===
+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 ===
-==== 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 ==
 {{bibtex|Didier06}}

ARCS/en

Un article de Wiki-evr@.

Version actuelle

[modifier] Publications

Affichages

Outils personnels

Navigation

Rechercher

Boîte à outils