Lien entre les procédures de maintenance et le moteur multimédia 137

Comme nous l’avons vu précédemment, chaque procédure de maintenance contient une liste de documents multimédia qui l’accompagne. Chaque média est répertorié avec son type MIME (voir section 4.2.2 page 126). A chaque type va correspondre un gestionnaire de média associé qui doit être enregistré avant l’utilisation des procédures de maintenance. Ces composants doivent hériter de la classe MediaManager que nous avons présentée dans notre diagramme de classes. Ainsi, si un média d’un certain type doit être “joué”, le gestionnaire de média correspondant est appelé. La classe

MediaManager est une classe abstraite qui doit être réimplémentée pour chaque type de médias

appelé à être géré par l’interface d’AMRA.

Cette classe met également en place des mécanismes pour faciliter l’accès aux médias qui doivent être lus. L’un des principes important est le préchargement ou ’prefetch’ des médias. Chaque média doit être enregistré par un identifiant lors de cette phase. Il sera alors possible de mettre le média en question en mémoire ou de mettre en place les composants ou objets qui faciliteront sa lecture ultérieurement. L’activation du média s’effectue plus tard lorsqu’une étape de la procédure de main-tenance à laquelle il est lié est activée, le média étant nommé par un identifiant.

Toute liberté est donnée au développeur pour effectivement précharger le média ou non. Toutefois, il devra nécessairement passer par la phase d’enregistrement du média auprès du gestionnaire.

Deux exemples de gestionnaires de médias sont apportés dans l’architecture du système AMRA. Il s’agit des composants :

– ImageMediaManager : un gestionnaire d’images qui affiche des images simples,

Classe Description sommaire

RAxml gère les procédures de maintenance XML

MediaManager interface générique de gestion d’un type de média

VRMLMediaManager gestionnaire de médias au format VRML/X3D

ImageMediaManager gestionnaire de médias de type image

RAQtWidget widget de mixage réel/virtuel prenant également en entrée le flux vidéo

capturé par la caméra du monde réel

RAQtDataRegistration classe d’encapsulation des données de recalage

RAQtVRMLSceneGraph classe gérant les graphes de scènes VRML

RAQtCamera classe gérant les caméras réelles pour les faire coïncider avec les

camé-ras de la scène virtuelle

RAQtECMAScript moteur d’interprétation des scripts Javascript inclus dans les fichiers

VRML

RAQtAnnotation classe gérant le graphe de scène associé à une annotation du graphe

VRML

TAB. 4.3 – Description sommaire des classes développées VRML spécialement conçus pour notre application.

Ces derniers sont une sur-couche du composant RAQtWidget qui effectue le mixage entre les images réelles prise par la caméra et les données multimédia graphiques, notamment les modèles 3D, qui nécessitent des moyens d’interaction particuliers. Nous allons à présent voir comment l’utilisateur peut interagir avec ses derniers grâce au composant développé.

4.4.4 Manipulation des modèles 3D

Plusieurs modes d’interaction sont possibles en utilisant les modèles 3D fournis à l’opérateur. Nous les avons représentés à la figure 4.12 page 140. Ce dernier peut interagir de manière passive avec le modèle virtuel en laissant la procédure de maintenance lancer les animations dès qu’il passe d’une étape de la procédure de maintenance à une autre. L’opérateur peut également interagir directement avec le modèle, soit en mode non recalé pour voir le détail du modèle 3D, soit en cliquant dessus pour lancer les animations correspondant aux différentes étapes de la procédure, ou enfin en l’utilisant pour demander des informations au système sur la pièce qu’il aura désigné.

Dans ce cas, le modèle 3D doit être recalé sur le monde réel. Nous pouvons alors, à l’aide d’un rayon virtuel projeté dans l’espace virtuel entre le point de vue de la caméra et un point désigné par l’utilisateur sur le plan image, désigner une partie du modèle virtuel en détectant l’intersection de ce rayon avec les pièces rencontrées. Ceci nous permet de retrouver l’identifiant de la pièce correspon-dante sur le modèle virtuel et de l’afficher, voir de faire une requête à la base de données concernant cette pièce pour obtenir des renseignements complémentaires. Le système permet également d’affi-cher le nom des pièces ainsi désignées sous forme d’annotations. Cette fonction peut-être employée tant sur le modèle virtuel que sur la vue réelle de l’image comme nous pouvons le voir sur la fi-gure 4.12(a) page 140, si tant est qu’un modèle virtuel (visible ou non) soit recalé.

Afin de pouvoir employer les modèles 3D avec la librairie OpenInventor, nous avons créé un graphe de scène compatible avec les augmentations VRML et les augmentations supplémentaires telles que les annotations. La structure de graphe de scène employée est représentée à la figure 4.13 page 141 Cette figure donne la structure des graphes de scène OpenInventor tel que le widget de mixage les exploite. Pour chaque noeud, son nom est spécifié ainsi que son type qui correspond à un type de noeud OpenInventor. Outre la structure du graphe de scène principal qui est employée dans le composant RAQtWidget, nous retrouvons ici la structure qui est lié au graphe de scène VRML lorsqu’il

4.5. CONCLUSION 139 est chargé à partir d’un fichier et dont la structure est contenue dans la classe RAQtVRMLSceneGraph. L’image de ce graphe de scène principal est une des images du flux vidéo acquis par la caméra. Nous retrouvons également le graphe de scène qui est créé à chaque fois qu’une annotation apparaît à l’écran suite à la demande de l’opérateur , tel qu’il est défini dans la classe RAQtAnnotation.

4.5 Conclusion

Nous avons présenté l’ensemble des fonctionnalités développées par le LSC au cours du projet de recherche AMRA. Ces fonctionnalités, qui font que le système AMRA intègre en réalité un moteur multimédia pour la réalité augmentée, couvrent divers domaines : tant celui de l’exploitation d’un scénario de maintenance décrit dans un format XML, que d’une interface générique de gestion des médias attachés à cette dernière, ainsi la représentation visuelle des informations contenues dans ces médias tout en les rendant cohérentes par recalage avec l’environnement réel de l’opérateur en train d’effectuer des opérations de maintenance. Ceci nous a également permis de développer les composants nécessaires à notre système de réalité augmentée pour permettre la visualisation et le mixage d’un flux vidéo capturant le monde réel avec les entités virtuelles.

Nous allons à présent voir comment nous pouvons partiellement modifier ce système général pour pouvoir le transposer dans le cadre de la problématique en réalité augmentée en vision directe, ce qui nécessite la résolution de problèmes spécifiques. L’idée est en effet de fournir à terme pour le mainteneur une assistance main-libre, ce qui, dans notre cas, implique d’utiliser un casque de réalité virtuelle semi-trasnparent à la place du tablette-PC.

(a) Retrouver les noms d’une partie du modèle

(b) Animer une étape de la procédure de maintenance

(c) Autres modes d’exploration du modèle virtuel

4.5. CONCLUSION 141 image SoImage root SoGroup camera SoPerspecti veCamera callbackPicking SoEventCallback sep SoSeparator pickStyle SoPi ckStyle imageBasePoint SoTranslati on

SceneGraph Annotati on 0 Annotati on X

VR MLroot SoTransf ormSeparator transform SoTransf orm grp SoV RMLGroup Scène V RML Importée AnnotationR oot SoAnnotati on pickStyle SoPi ckStyle material SoMateri al vertexLine SoCoord i nate3 line SoLi neSet s1 SoTransf ormSeparator s2 SoTransf ormSeparator basePointer SoTranslati on baseText SoTranslati on sphere SoSphere font SoFont text SoText2 numVertices SoMFInt32 Sous-graphe VR ML Sous-graphe Annotation

Chapitre 5

Techniques particulières à la réalité

augmentée en vision directe

Dans le cadre de la réalité augmentée en vision directe, la vue de l’opérateur est directement aug-mentée par un dispositif semi-transparent qui affiche les entités virtuelles et qui est placé entre lui et les objets observés. Ce peut-être une plaque de verre fixe qui reprojette les informations par holo-graphie (une tel système est utilisé par [Olwal et al., 2005]) ou un casque de réalité virtuelle pourvu d’un système optique semi-transparent (“optical see-through head mounted display”). Par rapport au travaux que nous avons effectué, nous nous intéressons surtout à la deuxième catégorie de dispositifs. À la différence de la vision indirecte où la représentation du monde réel est acquise par une caméra, la vision directe nécessite de synchroniser les entités virtuelles générées par rapport à la vision de l’utilisateur. Dans le cadre de cette synchronisation, un facteur important entre en jeu : la latence. Il s’agit du temps compris entre l’acquisition des données nécessaires à localiser l’opérateur (pour savoir où ce dernier regarde) et l’affichage effectif des entités virtuelles sur l’écran. Si cette latence n’est pas compensée, il se produit un décalage visuel entre les entités virtuelles et les objets réels, les premières semblant poursuivre les seconds sans jamais toutefois les rattraper lorsque la tête de l’opérateur est en mouvement.

Pour bien comprendre le problème de la latence, nous allons commencer par l’étudier et analyser les sources de latence, puis nous verrons comment cette latence est habituellement compensée dans la communauté de réalité augmentée en employant des méthodes de prédiction de point de vue si-milaires au problème du filtrage des données. Nous verrons également que la communauté de réalité virtuelle emploie d’autres méthodes de compensation de la latence basée sur les méthodes dites de “post-rendering”. Après cette phase préliminaire, nous expliciterons plus précisément le problème du filtrage prédictif par le biais de deux filtres : le filtre de Kalman et sa version étendue qui sont large-ment utilisés, puis nous présenterons le filtre particulaire que nous comparerons en simulation avec les approches classiques. Enfin, nous montrerons comment nous pouvons combiner les approches différentes de la réalité augmentée et de la réalité virtuelle pour compenser efficacement la latence.

5.1 Le problème de la latence

Ce cas est le plus simple pour synchroniser les informations de localisation et l’affichage des augmentations. Il ne compense pas la latence mais donne les moyens de comprendre et d’analyser les sources de latence. Une analyse complète de ces dernière a par ailleurs été faite par Holloway [Holloway, 1995]. Nous nous contenterons d’une version simplifiée de son modèle pour aider à la compréhension du problème de la latence.

Si nous prenons un capteur de localisation quelconque, avant que nous puissions afficher les entités virtuelles, il nous faut acquérir les données par le biais du capteur, transmettre ces dernières du capteur

Latence totale du système Temps Transmission des données Filtrage Rendu de la scène 3D Affichage

Acquisition des données

FIG. 5.1 – Décomposition du temps de latence global du système

au système informatique, calculer le point de vue de l’opérateur à partir de ces données, effectuer le rendu de la scène virtuelle en 3 dimensions et enfin l’afficher comme ceci est représenté sur la figure 5.1.

Dans le cadre du système de localisation que nous avons développé au chapitre 3.4 page 95, en sachant que l’acquisition de l’image, suivie de la localisation et du rendu de la scène s’effectue à la cadence de 18 images par secondes environ, le temps de latence global du système est d’au mieux 55 millisecondes. Sachant que le mouvement de la tête d’un opérateur peut atteindre en moyenne 2 radians par seconde, il est possible d’obtenir un décalage angulaire d’environ 20o entre l’objet visualisé et l’image affichée, ce qui représente environ 10 centimètres d’erreur à 1 mètre de distance. Il devient donc capital de compenser la latence dans le cadre d’un système de réalité augmentée en vision directe si l’on souhaite conserver l’alignement de la scène virtuelle avec l’environnement réel observé par l’opérateur quel que soient les mouvements de celui-ci. Avant de proposer nos propres solutions à ce problème, nous allons voir quelles sont les méthodes de compensation existantes dans la littérature.