ARCS/en
Un article de Wiki-evr@.
< ARCS(Différences entre les versions)
| Version du 20 juillet 2006 à 10:35 (modifier) Gi (Discuter | Contributions) (→Components) ← Différence précédente |
Version actuelle (17 novembre 2011 à 22:19) (modifier) (défaire) Gi (Discuter | Contributions) |
||
| (9 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. | ||
| - | == | + | [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. | ||
| - | + | ==== 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 === | === Compositions of components === | ||
| - | ==== The sheet, an | + | 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 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
Pdf