Le matériel

Pour mener à bien ce projet, du matériel était mis à notre disposition. Ainsi qu'une API permettant d'utiliser ce matériel facilement.

Nous présentons ici les outils que nous avons utilisés: une brève description du matériel, comment nous l'avons utilisé et pourquoi nous l'avons choisi.

HMD (Head Mounted Display)

Le HMD a été utilisé pour monter au joueur l'environnement virtuel tout autour de lui. Nous avons préféré le casque opaque car nous voulions immerger totalement la personne dans une cabine de navire de guerre (ou quelque chose dans le genre).

Fonctionnement

Le HMD, utilisé dans notre projet, est relié au PC uniquement par ses écrans, sur les ports VGA (cf schéma). Il faut bien penser à appuyer plusieurs fois sur le bouton commutateur de mode afin d'obtenir uniquement les diodes de droites d'état du HMD d'allumées. Si les diodes clignotent, le PC n'envoie aucun signal aux écrans (est-il allumé...?), sinon, elles sont allumées de façon continues et cela indique que les écrans sont bien branchés.

Il s'agit en fait de deux écrans, au sens stricte du terme. Il est donc indispensable d'être muni d'une carte graphique ayant deux sorties vidéo pour l'utiliser. Le casque contient aussi deux caméra que l'on peut utiliser pour avoir un retour de l'environnement réel tout autour du joueur. Nous ne les avons pas utilisé pour la raison mentionnée plus avant. Les deux écrans fonctionnent avec une résolution de 800x600 cadencée à 60Hz. Le gros de la configuration à faire pour utiliser le périphérique est donc au niveau du serveur X (des drivers nvidia dans notre cas). En effet, nous avons choisi de définir la résolution du buffer d'affichage de X à 1600x600 et de répartir ce buffer sur deux écrans (un à gauche, un à droite) qu'on cadence à 60Hz. Ainsi, naturellement, chaque écran contiendra la partie de l'œil concerné. Vous pouvez trouver dans nos sources le fichier Xorg.conf qui fonctionne parfaitement avec les machines de la salle de RV. Pensez particulièrement à consulter le fichier (encore une fois, dans nos sources) README_Xorg qui explique comment bien installer le fob car le serveur X nécessite d'être démarré avec le casque déjà branché, ce qui implique une petite partie de manipulation avec aucun retour visuel.

Difficultés

Nous avons été un peu déboussolé quand nous avons reçu ce matériel entre les mains. Car en effet aucun test ne l'utilise (les tests qui prennent en compte le HMD sont sur le casque semi-transparent). Et pour cause, rien n'est à tester ou calibrer, puisqu'il s'agit uniquement d'écrans. C'est de notre initiative personnelle que nous avons choisi de considérer une seule grande image de taille 1600x600.

Glove

Pour prendre les bateaux ou tirer sur la grille adverse, il était indispensable que le joueur ait une sorte d'alternative au "clic" de souris (Puisqu'il n'était pas question d'utiliser une souris ou un clavier).
Nous avons choisi d'utiliser le Glove, un gant muni de capteurs de position. Ainsi, l'utilisateur peut, par des mouvements de la main et des doigts, indiquer une action au système. Dans notre cas, on détecte qu'il veut prendre un bateau quand il sert le poing, ou qu'il veut tirer quand il colle son pouce à son index.

Fonctionnement

Le Glove est muni de 18 capteurs de position, un sur chaque articulation. En gros, il y en a 3 par doigt (un entre chaque phalange), 1 entre chaque doigt (donc 4 supplémentaire), et 2 pour détecter l'orientation du poignet.
L'API-ARV nous permet de récupérer les informations de chaque articulation, et de les traiter pour définir des "états" de la main: Prendre, Lacher, Tirer.

Difficultés

La difficulté ici est de définir les différents états en fonction des positions des articulations. Par exemple dans notre cas, on sait que si tous les doigts sont pliés, la main "prend" un objet, si tous les doigts sont tendus, la main "lache" ce qu'elle tenait.
Mais que dire alors si deux doigts sont tendus et 3 sont repliés ?
Nous aurions pu utiliser un réseau de neurones pour apprendre les différentes configurations à notre programme. Mais notre cas étant très simple (seulement 3 états différents), nous avons préféré définir les états simplement, et considérer les états indéfinis comme correspondants à l'état "lacher".

Caméra + Pattern

Nous avions besoin de tracker la position de la tête et la position de la main du joueur. Cependant, au début du projet, un seul Flock of Bird (système de capture de position dans l'espace) fonctionnait, et même si le second se mettait à marcher, il n'y avait pas suffisament de prises VGA à l'arrière des ordinateurs pour brancher deux FOBS et un Glove en même temps.
Nous avons donc choisi une option alternative: l'utilisation de caméras et de trackers.

Fonctionnement

L'API-ARV fournit une surcouche de ARToolkit qui, lui, fournit une implémentation de reconnaissance de patterns sur une image filmée par une caméra branchée sur l'ordinateur. Ce système permet de détecter la position et l'orientation du pattern sur l'image filmée.

Difficultés

Le gros problème de ce système est la stabilité. En effet, dès que le pattern sort du champ de vision de la caméra, ou bien si l'éclairage change, ou même si une infime partie du pattern est cachée par l'utilisateur, alors le système ne détecte plus rien, et donc n'envoie plus d'informations sur la position du pattern. De plus, notre utilisation de ce système impliquait de nombreuses occlusions possibles (par la tête du joueur, par le cable du HMD ou du Bird, etc.)

Quand nous avons appris qu'il était envisageable d'utiliser deux FOBS, nous avons abandonné cette solution sans regret.

Flock Of Bird

Pour savoir à tout instant la position de la tête du joueur et de la main active, nous avons choisi la méthode Flock of Birds. Ce schéma d'acquisition des positions est beaucoup plus robuste et rapide que la solution tracker précédemment choisie.

Fonctionnement

Le matériel, qui communique sur le port série de l'ordinateur, fournit une matrice de transformation dans l'espace projectif situant le repère du bird par rapport à la base.

Pour pouvoir utiliser deux birds (un pour la main, un pour la tête), nous avons branché les unités en mode Master/Slave. Dans ce schéma, une seul unité est branché sur le port série (RS232) de l'ordinateur (c'est le master) et la deuxième unité est branchée sur le master via un câble ethernet sur le port FBB (c'est le slave). Chaque unité est relié à un bird mais c'est uniquement sur le master que l'on branche la base (sur le port XMTR). Il faut bien penser alors à changer les adresses des unités (via les interrupteurs DIP SWITCH sur l'arrière de l'unité) pour que le master soit à l'adresse 1 et le slave à l'adresse 2. On peut en fait, en branchant les slaves les uns sur les autres, avoir un master et 13 slaves dans le même genre de configuration, il faut alors bien penser à donner des adresses différentes à chaque unité, en mettant le master à l'adresse 1 quoiqu'il arrive. Un dernier point important est qu'il faut initialiser toutes les unités avant de commencer à utiliser le FOB.

Remarque : en mode stand alone (une unité+une base+un bird), l'adresse de l'unité doit être 0 et quelque soit le mode, l'adresse ne peut pas être 15 (adresse de broadcast). Tout ceci est expliqué dans la documentation fournie avec le matériel.

Une fois les fob correctement branchés. le fonctionnement est légèrement différent du mode stand alone. Chaque commande est envoyée sur le master qui sert de passerelle entre l'ordinateur et les autres unités. Pour éviter tout ambiguïté, la commande doit explicitement être précédée d'une commande qui indique à quelle unité on s'adresse (commande ToFbb suivie de l'adresse de l'unité). Nous avons dû apporter cette nouvelle fonctionnalité à l'ApiArv qui jusqu'à présent ne prenait en compte que le mode Master/Slaves sur ports RS232 séparés.

Bien que principalement dû à la contrainte sur le matériel, ce mode de fonctionnement nous a quand même permis d'avoir moins de calibration à faire, étant donné que deux birds sont situés par rapport à la même base.

Difficultés

La grosse difficulté a été de faire fonctionner le FOB en mode Master/Slave, puisqu'aucune fonction haut niveau ne le faisait. Nous avons donc du modifier l'ApiArv (les modules FobAlone et FobCommand principalement) pour implémenter notre solution. Le module FobCommand implémente toutes les opérations bas niveau sur à propos du FOB, donc la commande ToFbb était déjà connue. Il y avait cependant un léger soucis dans une des fonctions (SetAutoConfiguration) qui nécessitait (d'après la documentation) un délai de 600ms avant et après le lancement de la commande (temps de configuration du fob) et ne mettait pas à jour l'attribut de la classe FobCommand comme il aurait dû. Nous avons ré implémenté les fonctions initMaster et initSlave du module FobAlone pour permettre à l'Api d'être adaptée au mode Master/Slave (initSlave prend maintenant en argument l'adresse du slave) en les laissant rétro compatibles, de telle sorte que le code écrit pour le mode stand alone reste correct (tant qu'à faire!). Nous fournissons l'ensemble des patchs à appliquer à la racine de l'ApiArv (à partir de la version de base, disponible sur tous les PC de la salle RV dans /usr/local) correspondant à nos différentes corrections dans la rubrique téléchargement.