Rapport de projet

Rapport Final - Intéractions 2D/3D à base de
gestes en utilisant la Wiimote
Enes de Carvalho Miguel
Al Hossri Laurent
Augereau Julien
Lahaye Fabien
7 avril 2009
Chargé de TD : Marchand Sylvain
Clients : Levet Florian & Schlick Christophe
Université Bordeaux 1
Projet de Programmation 2008-2009
1
Table des matières
Introduction au domaine
5
1 Les débuts de la Motion Capture
5
2 L’arrivée de la console Wii
6
3 Démocratisation de la Wiimote
8
Descriptif du projet
10
Inventaire de l’existant
11
1 Les bibliothèques et scripts existants
11
2 Les
2.1
2.2
2.3
logiciels fournis par
Logiciel 2D . . . . .
Logiciel 3D . . . . .
Bibliothèque Wiigee
les clients
12
. . . . . . . . . . . . . . . . . . . . . . . 12
. . . . . . . . . . . . . . . . . . . . . . . 13
. . . . . . . . . . . . . . . . . . . . . . . 14
Etude des besoins
16
1 Besoins Fonctionnels
1.1 Fonctionnalités du logiciel 2D . . . . . . . . . . . . . . . . . .
1.2 Fonctionnalités du logiciel 3D . . . . . . . . . . . . . . . . . .
1.3 Fonctionnalités communes . . . . . . . . . . . . . . . . . . . .
16
16
16
18
2 Besoins Non Fonctionnels
19
Architecture du projet
21
1 Communications Bluetooth
21
2 Controleurs
21
2.1 Souris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Wiimote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2
3 Listeners et Events
3.1 Interface matérielle . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Reconnaissance de gestes . . . . . . . . . . . . . . . . . . . . .
3.3 Programme final . . . . . . . . . . . . . . . . . . . . . . . . .
23
23
24
24
Travail Réalisé et Problèmes Rencontrés
25
1 Travail préliminaire
25
2 Interfaçage et Utilisation des Controlleurs
26
3 Mise en place du module de Reconnaissance de Gestes
27
4 Modification du logiciel Wii2D
28
4.1 ControllerListener et gestureListener . . . . . . . . . . . . . . 28
4.2 Graphisme et fonctionnalités . . . . . . . . . . . . . . . . . . . 29
5 Modification du logiciel Wii3D
29
5.1 ControllerListener et gestureListener . . . . . . . . . . . . . . 29
5.2 Graphisme et fonctionnalités . . . . . . . . . . . . . . . . . . . 30
Installation et Fonctionnement
31
1 Installation et Matériel
31
1.1 Matériel et drivers . . . . . . . . . . . . . . . . . . . . . . . . 31
1.2 Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Utilisation du logiciel
32
2.1 Interface de Wii2D/Wii3D . . . . . . . . . . . . . . . . . . . . 32
2.2 Utilisation des périphériques . . . . . . . . . . . . . . . . . . . 32
2.3 Interface d’apprentissage . . . . . . . . . . . . . . . . . . . . . 33
Définition et Réalisation des tests
34
1 Test de la fonction Curseur
et du déplacement
34
Test de la fonction Curseur . . . . . . . . . . . . . . . . . . . . . . 34
2 Test des logiciels
35
Test de la fonction Curseur . . . . . . . . . . . . . . . . . . . . . . 35
3
Améliorations et réutilisations possibles
38
Améliorations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Réutilisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Conclusion
40
Bibliographie
41
Annexes
43
4
Introduction au domaine
L’étude des interfaces proposées à l’homme dans le domaine informatique
a toujours donné lieu à de nombreuses expérimentations. Les utilisateurs
d’ordinateurs sont aujourd’hui habitués à l’utilisation du “classique” couple
clavier/souris, et ce dans tous les domaines impliquant l’informatique, alors
même que de nombreux autres périphériques de contrôle, plus adaptés à des
utilisations spécifiques, existent.
Beaucoup d’innovations dans le domaine de l’interfaçage homme/machine
ont été découvertes et développées dans le cadre d’expérimentations liées à la
réalité virtuelle. En effet, ce domaine requiert une interaction forte, immersive
et instinctive avec l’utilisateur, caractéristiques recherchées également dans le
contrôle de toute application informatique. Lors de l’apparition de la notion
de réalité virtuelle furent créés plusieurs périphériques, comme par exemple
l’Ultimate Display, tout premier casque capable de reproduire, dans une simulation informatique, les mouvements de la tête du porteur. Mais ce qui fut
un véritable moteur pour ces développements est sans doute l’utilisation par
la NASA dans son programme VIVED du concept de réalité virtuelle et le
développement d’un casque affichant, en fonction des mouvements du porteur, un environnement virtuel pour l’entraı̂nement aux missions spatiales.
1
Les débuts de la Motion Capture
La motion capture fit son apparition au début des années 80, révolutionnant la reconnaissance de mouvements. Cette technique, se résumant dans
un premier temps à la fixation de potentiomètres sur le corps du sujet afin
de mesurer les angles de flexion des articulations, va ensuite évoluer pour
faire intervenir un système de diodes réflexives dont la position est triangulée par une série de caméras permettant ainsi un rendu en 3D sur ordinateur des mouvements de l’individu. Par la suite, d’autres techniques seront
développées comme par exemple des gants permettant la capture des mouvements des doigts pour permettre de jouer virtuellement de la musique.
De nos jours, ces périphériques ont évolué et la capture de mouvement
est plus précise, les outils moins invasifs et surtout leur coût a été réduit. On
trouve principalement deux types d’outils : ceux impliquant une acquisition
d’ordre visuel (techniques optiques) et ceux impliquant des capteurs sur l’individu (techniques mécaniques).
5
Les techniques optiques sont caractérisées par la présence d’une ou plusieurs caméras ou capteurs qui vont permettre de reconnaitre la position
de marqueurs sur le sujet. Ces derniers peuvent être passifs, réfléchissant la
lumière rouge ou infrarouge émise par des caméras sensibles à ce seul type
de rayonnement, ou actifs, émettant eux même un rayonnement capté par les
caméras ou cellules photosensibles, cette téchnique permettant d’éviter tout
problème de parallaxe lié à l’utilisation d’une lentille. Dans les deux cas, les
données des différentes caméras/cellules (au moins 2), sont combinées afin
de déterminer les coordonnées dans l’espace de chacun des marqueurs qui
seront exploitées par l’utilisateur dans la procédure de reconnaissance de
mouvements.
Les techniques mécaniques fonctionnent, quant à elles, grâce à une série
de capteurs. Dans le cadre de captures mécaniques, l’individu dispose d’un
exosquelette sur lequel se trouve, à chaque articulation, un capteur angulaire
dont les données sont ensuite exploitées par un ordinateur. Pour des captures
magnétiques, un champ est émis en un point fixe et des capteurs sont placés
aux points stratégiques du corps du sujet sous forme de bobines de fil qui,
créant des perturbations dans ce champ, peuvent être localisées par une série
de calculs. Il s’agit cette fois-ci, plutôt d’une capture de mouvement que de
position, les outils ne permettant pas la récupération de données précises
quand à la position dans l’espace des capteurs.
La plupart des techniques énoncées ci-dessus ont trouvé des applications
dans de nombreux domaines : de la création de films ou de jeux vidéos dans
laquelle on capture les mouvements d’un acteur afin de générer des personnages en 3D aux gestes réalistes, à l’archéologie, où la reconstitution virtuelle
de vestiges est facilitée par la simplicité de manipulation des outils. Ces techniques ont toutes pour principal avantage la retranscription en temps réel du
mouvement et ce, de manière extrêmement réaliste, mais leur intégration dans
un projet nécessite un financement conséquent de par le coût du matériel et
des logiciels, empêchant jusqu’ici leur démocratisation et leur utilisation dans
des travaux de petite envergure.
2
L’arrivée de la console Wii
La miniaturisation des composants et la production en chaı̂ne de ceux-ci
a cependant, aujourd’hui, changé la donne. En effet, depuis 2006 est apparue
6
la console Wii de Nintendo et sa manette de jeux particulière : la Wiimote.
Ce périphérique a été conçu de manière à procurer au joueur une sensation
d’immersion dans le jeu en offrant une expérience de mimétisme gestuel par
des mécanismes de reconnaissance de mouvements et de détection dans l’espace. De la simulation de bowling, au jeu de tir, la Wiimote et la Wii ont
conquis les joueurs et la console est aujourd’hui installée dans de nombreux
foyers. Etonnament, bien que propriétaire, la wiimote est utilisatrice de standards informatiques et matériels et exempte de tout cryptage ou protection :
technologie Bluetooth pour la transmission des données à la console, caméra
infrarouge pour la détection dans l’espace et accéléromètre standard pour la
détection de mouvements, permettant d’envisager une alternative accessible
et bon marché aux solutions industrielles existantes.
La wiimote comporte un accéléromètre, sensible sur 3 axes (Voir Figure
1), qui va être au coeur de la reconnaissance de mouvements. Son fonctionnement est simple : une masse flottante va se déplacer et exercer une pression
plus ou moins forte sur les parois de l’accéléromètre qui sont équipées de capteurs de pression : si la pression est forte vers le bas, la Wiimote a effectué un
mouvement vers le haut par exemple. Ces données vont permettre d’obtenir
des valeurs d’accélération dans les trois dimensions en fonction du temps, qui
seront ensuite exploitées pour reconnaitre un mouvement.
La caméra infrarouge de la wiimote permet, quant à elle, la reconnaissance de la position de la wiimote par rapport à l’écran (équipé alors d’une
sensor bar, dispositif électronique émettant deux points distants en lumière
infrarouge). La caméra, si elle est orientée vers l’écran, capte deux points de
lumière qui vont lui permettre de déterminer l’éloignement de la manette en
fonction de la taille des points (plus la manette est proche, plus les points
seront grands), l’inclinaison de la manette avec l’alignement des deux points
(si les deux points forment une ligne horizontale, la Wiimote est à plat, si la
ligne est verticale, elle est sur le côté) et l’endroit visé par l’utilisateur sur
l’écran avec la position de ces points, cette dernière information permettant
principalement la projection d’un curseur sur l’écran et l’interaction avec les
éléments de l’application comme on le ferait avec une souris.
L’ensemble de ces données, ajoutées à celles de périphériques supplémentaires pouvant être connecté en dessous de la wiimote (nunchuck, instrument
de musique, manette classique, ...), est ensuite transmis en Bluetooth à la
console qui les interprète en temps réel. La technologie Bluetooth, principalement utilisée par les téléphones mobiles, permet la transmission radio de
données sans fil avec un débit d’environ 1Mbit/s et fonctionne par connexion
7
Fig. 1 – Caractéristiques de la Wiimote
ponctuelle pour l’envoi de données (envoi d’images entre téléphones par exemple) ou via une connexion constante, nommée apairage, pouvant être ou
non sécurisée (la Wiimote utilise un apairage non sécurisé).
3
Démocratisation de la Wiimote
L’ensemble de ces technologies rend l’utilisation détournée de la Wiimote
des plus simples, et il n’a pas fallu longtemps pour que des amateurs décident
de s’intéresser à l’utilisation de cette manette sur des ordinateurs. De nombreuses expériences ont été effectuées et aujourd’hui, des bibliothèques sont
trouvables dans de nombreux langages de programmation pour permettre
d’utiliser la wiimote comme contrôleur principal d’applications diverses. Le
faible coût du périphérique, induit par une production à grande échelle, et sa
capacité à se substituer efficacement à tout autre contrôleur (souris, tablette
graphique, ...) permet d’envisager un nombre impressionnant d’applications.
Des individus tel Johny Chung Lee, docteur en informatique dans le domaine
des interactions Homme/Machine, a réalisé de nombreuses expériences utilisant les composants bon marché de la wiimote : du contrôle d’une interface
“du bout des doigts” grâce à la caméra infrarouge, à la sensor bar et à
8
des marqueurs réfléchissants sur ses doigts, à la réalisation d’une application
prenant en compte les mouvements de l’individu en temps réel pour générer,
sur un écran normal, un environnement perçu comme holographique par le
sujet.
9
Descriptif du projet
Comme on a pu le voir, le périphérique Wiimote est bien plus qu’une
manette de jeu et s’avère particulièrement adapté à une utilisation dans le
domaine du traitement d’images. Nos clients souhaitent pouvoir, à l’aide de
la Wiimote, effectuer des opérations au sein de deux logiciels, l’un dédié au
traitement de multiples vignettes 2D, l’autre à la manipulation d’objets 3D.
Ces logiciels sont déstinés à la manipulation d’images médicales.
Le projet sera ainsi divisé en deux parties ayant pour noyau commun
l’implémentation d’un dispositif d’apprentissage des mouvements et de reconnaissance de ceux-ci. Les clients nous fournissent deux exemplaires simplifiés
de ses logiciels codés en Java. Nous devrons modifier ceux-ci afin de rendre
visuellement compte des opérations commandées par les mouvements et proposer une interface graphique adaptée au périphérique (sélection aisée, menus
déroulants, ...). La Wiimote sera donc à la fois utilisée en remplacement de
la souris grâce aux données de sa caméra infrarouge et en périphérique de
reconnaissance de mouvements grâce à son accéléromètre.
Le logiciel 2D présente un espace de travail où sont disposées des vignettes
d’images. La Wiimote sera utilisée pour interagir avec ces vignettes, permettant de réaliser des glisser/déposer, des sélections, et des opérations sur les
images sélectionnées via des gestes (la capture de ceux-ci étant conditionnée
par l’appui sur l’un des boutons de la manette).
Le logiciel 3D présente une sphère avec laquelle il sera nécessaire d’intéragir
au moyen de la Wiimote. Nous pensons mettre en place un déplacement de la
caméra selon les mouvements de la Wiimote ou, si nous en avons le temps, via
un nunchuk relié à la Wiimote. Les interactions proposées par les clients (extrusion, coupe) impliquent la prise en compte du capteur infrarouge uniquement.
Les clients demandent que notre projet permette l’interfaçage, avant la
phase de reconnaissance de mouvements, d’un autre type de périphérique que
la Wiimote, par exemple une tablette graphique, via l’implémentation d’une
classe héritée.
10
Inventaire de l’existant
Dans le cadre de notre projet, l’existant est particulièrement important.
En effet, la Wiimote étant propriétaire et Nintendo ne fournissant, en dehors
des développeurs de jeux, aucune documentation ou information sur l’utilisation et le fonctionnement de la manette, notre seule source d’information
pour le développement se situe dans les documents réalisés par les communautés existantes autours du sujet, en particulier sur le web. Nous aurons
également à analyser en détails les logiciels fournis par les clients, la modification et l’interaction avec ceux-ci constituant la majeure partie de notre
projet.
1
Les bibliothèques et scripts existants
De nombreuses bibliothèques, logiciels et scripts ont été développés par
des amateurs en se basant sur la lecture des trames reçues de la Wiimote
une fois celle-ci connectée au PC. Le plus utilisé de ces logiciels est sans
doute GlovePie, permettant de controler n’importe quel logiciel à partir de
périphériques divers : joystick, souris, périphérique MIDI ou Wiimote. Il propose un langage de script spécifique permettant beaucoup d’utilisations divertissantes mais ne permettant pas d’implémenter aisement la reconnaissance
de mouvements, et encore moins de l’intégrer sous forme de plugin à un programme existant.
Il existe également un certain nombre de bibliothèques dans des langages
variés mais, le logiciel des clients étant en Java, nous nous contenterons de
celles qui sont compatibles. La bibliothèque MoteJ nous propose de nombreuses classes et méthodes visant à simplifier la communication avec la
Wiimote (données infrarouge, gestion des vibrations et leds, données de
l’accéléromètre, ...). La bibliothèque WiiGee nous propose les mêmes fonctions de contrôle de la wiimote auxquelles s’ajoute un module d’apprentissage/reconnaissance de gestes. Notre choix se portera donc sur cette dernière
afin de nous simplifier la tâche.
11
2
Les logiciels fournis par les clients
2.1
Logiciel 2D
Les clients nous fournissent un logiciel 2D qui va nous servir de support de
travail. Celui-ci, simple partie du logiciel final des clients présente une fenêtre
contenant un certain nombre de carrés de couleur symbolisant des vignettes
d’images. Le but de notre projet sera de modifier ce logiciel afin d’y inclure
un plugin permettant la connexion à la Wiimote ou tout autre périphérique
dédié à la reconnaissance de gestes et d’implémenter une interface intuitive
adaptée. Le logiciel est un projet Java, dont les trois classes principales :
WiiMote2D, ImageIcon et GLRectangleEntity ont les rôles suivants :
– WiiMote2D : Il s’agit de la classe principale qui contient dans son
constructeur, les instructions relatives à la création de l’environnement
de travail (fênetre, composant GLCanvas pour gérer le dessin et utiliser
OpenGL). Un listener de type Renderer est également créé permettant
l’interraction avec les éléments OpenGL. La classe Renderer présente les
fonctions liées à la souris : MouseDragged, MousePressed ainsi qu’une
fonction d’interraction avec le clavier : KeyPressed et les methodes init,
display, reshape, drawScene nécessaires à OpenGL. L’appel au “main”
se termine ensuite par la création des vignettes représentées par des
objets ImageIcon.
– ImageIcon : Cette classe permet la création et la gestion des vignettes d’images sur lesquelles nous effectuerons les actions induites
par notre projet et la reconnaissance de gestes. L’objet comprend deux
champs, l’un correspondant au nom et l’autre, “rec”, contenant la forme
représentant la vignette.
– GLRectangleEntity : Il s’agit de la classe définissant la forme prise
par les vignettes. Les formes définies dans cette classe sont en 3D et
non en 2D de manière à gérer efficacement la profondeur des vignettes
sur le plan de travail.
12
Fig. 2 – Diagramme du logiciel client WiiMote2D
2.2
Logiciel 3D
Le logiciel 3D fournit par les clients présente un espace de travail OpenGL
dans lequel se situe une sphère. Un trackball logiciel nous permet de faire pivoter celle-ci autours de son centre de gravité. Comme pour le logiciel 2D, il
s’agit d’un projet Java qui présente, pour sa part, les classes principales :
WiiMote3D, Vec3d et Quaternion dont les rôles sont les suivants :
– WiiMote3D : Comme pour le logiciel 2D, il sagit de la classe principale qui a pour but de mettre en place l’environnement de travail.
– Quaternion : Cette classe contient les interactions possibles avec l’objet 3D en particulier l’implémentation de la méthode trackball.
– Vec3d : Cette classe gère la création et la manipulation de vecteurs
3D au sein de l’environnement OpenGL.
13
Fig. 3 – Diagramme du logiciel client WiiMote3D
2.3
Bibliothèque Wiigee
La bibliothèque WiiGee nous a semblé la plus adaptée à notre projet
par son intégration de mécanismes d’apprentissage/reconnaissance de gestes
nous offrant ainsi la possibilité de ne pas recoder ces fonctions mathématiques
complexes et nous permettant ainsi de nous concentrer sur les fonctionnalités
du logiciel. Cette bibliothèque se décompose en quatre packages qui sont :
– Device : sert de passerelle entre l’ordinateur et la Wiimote. En effet, on
trouve au sein de celui-ci deux classes : Wiimote et WiimoteStreamer.
– Wiimote : cette classe représente les fonctions basiques de la Wiimote. Son constructeur permet d’ajouter une nouvelle Wiimote au
sein de l’application en se basant sur l’adresse mac de celle-ci. On
trouve également toutes les fonctions nécessaires à l’interactions avec
la wiimote via la création d’un listener, addWiimoteListener, qui permet de détecter les mouvements simples et les actions de l’utilisateur
(pressions de boutons). S’ajoute à ce dernier un second listener, addGestureListener qui lui se charge de la reconnaissance de gestes
préalablement acquis. Pour finir, on trouve des fonctions permettant
de faire vibrer la Wiimote, d’allumer les leds de celle-ci ou encore des
accès plus techniques permettant de lire l’EPROM (Erasable Pro-
14
grammable Read Only Memory : rom de petite capacité effaçable et
programmable) de la console.
– WiimoteStreamer : Cette classe sert d’interprêteur aux commandes
émises par la Wiimote. En effet, après réception et traitement des
données les actions correspondantes sont effectuées : pour exemple,
lorsque le bouton A est pressé sur la Wiimote, celle-ci emet un signal capté par WiimoteStreamer qui l’interprete et lance la routine
associée. On retouve donc, en plus des actions pour les bouton (A,
B, home...), des actions suite à une nouvelle accélération détecté par
la Wiimote.
– Control : gère la recherche, la connexion et le controle des Wiimotes.
Pour ce faire, le package utilise deux classes : DeviceDiscovery et Wiigee.
– DeviceDiscovery : cette classe permet de découvrir les Wiimotes environnante au lancement de l’application. Une fois la découverte
achevée, l’association entre la Wiimote et l’ordinateur est effectuée.
Cette étape est soumise à de nombreux paramètres comme la version
du driver gérant le dongle Bluetooth ou encore la version de la pile
utilisée pour la communication entre le dongle et les applications.
– Wiigee : cette classe est la base de la bibliothèque. En effet, c’est elle
qui gère les différentes Wiimotes trouvées lors du balayage et définit
les listeners ou encore les bouton par défaut.
– Event : regroupe les classes correspondant aux évenements potentiel
de la Wiimote : l’appui sur un bouton, le relâchement d’un bouton, ou
encore la détection d’une nouvelle accélération.
– Logic : regroupe les classes liées aux opérations mathématiques de la
reconnaissance de mouvements.
– AccelerationStreamAnalyzer : cette classe analyse les évènements de
type WiimoteAccelerationEvent (classe du package Event gérant les
accélérations de la Wiimote) puis gère la création et le traitement
des modèles résultant du geste enregistré.
– Gesture : cette classe représente un geste et stocke les valeurs d’accélération correspondant à celui-ci en fonction du temps.
– HMM : Cette classe est une implémentation du Modèle caché de
Markov qui fournit les algorithmes utilisés pour l’entraı̂nement et la
reconnaissance de gestes.
15
Etude des besoins
Nous allons présenter dans ce rapport les besoins fonctionnels communiqués par nos clients ainsi que ceux, non-fonctionnels, résultant des obligations techniques induites par l’utilisation prévue des logiciels.
Les besoins fonctionnels se divisent en trois catégories : ceux spécifiques
au logiciel 2D, ceux du logiciel 3D et enfin, les besoins communs aux deux.
Par la suite, nous tenterons d’analyser les besoins non fonctionnels inhérents
au projet.
1
Besoins Fonctionnels
1.1
Fonctionnalités du logiciel 2D
Les besoins du logiciel 2D sont uniquement de l’ordre de la reconnaissance et de l’interprétation de gestes, le traitement des images devant être
géré ultérieurement par le logiciel des clients. Le rendu visuel des différentes
fonctionnalités devra être clair et ergonomique. Les actions gérées par notre
projet seront :
– Sélection/Déplacement d’images : possibilité de sélectionner / désélectionner / déplacer une ou plusieurs images à la fois grâce au curseur
de la Wiimote (Voir Figure 4). La sélection pourra être effectuée en
mode cadre ou de manière successive (maintiens de la touche SHIFT).
– Actions sur une image : il doit être possible via des actions du
contrôleur d’effectuer un traitement (négation par exemple) ou de supprimer une image sélectionnée.
– Actions sur plusieurs images : on doit pouvoir, pour plusieurs images sélectionnées, réaliser des actions groupées (suppression, traitements individuels) mais également des actions entre les images : addition, soustraction, multiplication, ... d’images (Voir Figure 5).
1.2
Fonctionnalités du logiciel 3D
Le logiciel 3D ne nous présentant qu’un unique objet, les actions possibles
sont beaucoup moins nombreuses qu’avec le logiciel 2D. Comme précédemment
le traitement de l’objet sera géré ultérieurement par le logiciel des clients.
Seul un rendu visuel représentatif de l’opération à effectuer sera mise en
16
Fig. 4 – Déplacement d’une image au sein du logiciel 2D
Fig. 5 – Exemples de mouvements reconnaissables par le logiciel 2D
place. Plus précisément, les actions gérées par notre projet seront :
17
– Déplacement de l’objet : le déplacement de l’objet sera normalement
gérée par les clients grâce à un trackball logiciel. Nous allons interfacer
celui-ci à la Wiimote. (Voir Figure 6).
Fig. 6 – Déplacement de l’objet 3D autours de son centre de gravité.
– Actions sur l’objet : l’utilisation de la Wiimote devra nous permettre
de réaliser des actions sur l’objet (par exemple : extrusions, coupes, ...).
1.3
Fonctionnalités communes
La gestion de la reconnaissance de gestes ainsi que la volonté des clients
de disposer d’une architecture de projet permettant d’envisager le remplacement du contrôleur Wiimote par un autre périphérique (tablette graphique
par exemple), nous forcent à mettre en place un certain nombre de fonctionnalités communes aux deux logiciels qui sont :
– Module d’apprentissage de mouvement : ce module permettra
l’acquisition de mouvements en 2D ou en 3D ainsi que leur sauvegarde
dans l’optique de leur reconnaissance au sein des logiciels.
– Gestion de profils utilisateurs : il devra être possible de créer et
basculer entre différents profils utilisateurs associant à chaque action
un mouvement personnalisé.
18
– Gestion du curseur : il sera nécessaire de prendre en charge la caméra
infrarouge de la Wiimote afin de gérer le déplacement du curseur à
l’écran (Voir Figure 7).
Fig. 7 – Gestion du curseur souris via la caméra infrarouge
– Stockage des mouvement : notre module d’apprentissage devra gérer
l’enregistrement des données de chaque mouvement pour son stockage
dans le système de gestion de profils utilisateurs afin de permettre la
reconnaissance dudit geste par les logiciels finaux.
– Gestion de plusieurs Wiimotes : nous devons mettre en place une
identification stricte de chaque contrôleur associé à l’ordinateur de
manière à empêcher toute intervention d’une autre Wiimote dans le
travail de l’utilisateur.
– Modularité de l’architecture du projet : comme expliqué ci-dessus
nous devrons nous assurer de la possibilité d’utiliser un autre type de
contrôleur lors de la reconnaissance des gestes.
2
Besoins Non Fonctionnels
Il existe également de nombreux besoins non fonctionnels à satisfaire lors
de l’implémentation de notre projet. Ces besoins, implicites dans la demande
19
des clients, sont les suivants :
– Instantanéité : l’intéractivité du logiciel et l’utilisation de la Wiimote comme périphérique de contrôle et de pointage rendent nécessaire
l’aspect “temps réel” de notre application, excluant ainsi tout algorithme coûteux en temps.
– Fiabilité : l’application finale des clients étant destinée au milieu médical
implique une optimum fiabilité de nos modules.
– Flexibilité : il est nécessaire que notre application s’adapte aux différents
utilisateurs et à leurs caractéristiques : gestes amples ou réduits, mouvements précis ou tremblements, ...
– Ergonomie : la prise en main, tout comme l’utilisation régulière de
l’application, doivent se faire de la manière la plus simple, rapide, et la
moins fatigante possible.
20
Architecture du projet
1
Communications Bluetooth
La communication entre deux périphériques Bluetooth est bien plus complexe qu’une connexion filaire. En effet, là où un périphérique comme une
souris se contente normalement d’un driver et d’une bibliothèque spécifique
au matériel et au langage, le Bluetooth ajoute une pile (ou stack ) qui va
se placer entre le driver et la bibliothèque. Ainsi, afin de faire communiquer une Wiimote avec un ordinateur, toute information va devoir transiter
par le dongle Bluetooth, être gérée par le driver puis par le stack et enfin
par la bibliothèque qui permettra l’exploitation des données dans le langage
choisi.(Voir Figure 8)
La bibliothèque BlueCove est donc utilisée comme point d’entrée des
données issues du Bluetooth et se charge de lancer les deux connexions
L2CAP nécessaires respectivement à l’envoi et à la réception de données.
Certaines classes de Bluecove sont alors implémentées par Wiimote et WiimoteStreamer qui vont pouvoir interpréter les données propres à la wiimote
et rendre moins ”bas niveau” la communication avec ce périphérique.
On peux voir sur le schéma la mention Wiigee qui correspond en fait à la
partie communication avec la Wiimote de WiiGee que nous avons décomposé.
2
Controleurs
La gestion de multiples périphériques d’interface utilisateur est une des
parties principales de notre projet. Il doit être possible pour les clients de
rajouter aisement le support d’un contrôleur à son application grâce à l’architecture de nos réalisations. Nous avons implémenté le support de deux
contrôleurs : la Wiimote et la souris et nous allons détailler leur structure.
2.1
Souris
La classe controlMouseListener dédiée à la souris ne présente pas de
véritable complexité. En effet, elle se contente, pour la plupart des actions, de
relayer l’information à partir des mouseListener habituels. Il faut cependant
remarquer la nécessité, pour interfacer la souris avec le module de reconnais21
Fig. 8 – Fonctionnement global de la communication Wiimote/Projet.
sance de gestes, d’une conversion des coordonnées de celle-ci vers des données
d’accélération en 3 dimensions, tâche accomplie par la classe abstraite Controller2D que controlMouseListener étends. Le reste des opérations tiens
principalement du mappage de boutons ou de la conversion de coordonnées
de pointeur.
2.2
Wiimote
La classe controlWiimoteListener dédiée à la Wiimote est, elle, beaucoup
plus complexe. En effet, l’utilisateur habitué au périphérique répandu qu’est
la souris va d’instinct chercher à retrouver les sensations de cette dernière
dans tout périphérique de contrôle utilisateur. Il a donc été nécessaire de
conserver la notion de pointeur, chose facilitée par les fonctions infrarouge
proposées par la manette. Il a donc suffit de récupérer les coordonnées des
deux points observés par la caméra IR de celle-ci afin d’obtenir un point
central que l’on projette sur la scène OpenGL.
De la même manière que pour la souris, le mappage des boutons en des
identifiants standardisés par notre classe ControlListener est effectué lors des
différents appuis et relachements afin de de procéder au transfert des évents
22
reçus vers les listeners existants. La reconnaissance des gestes reçoit quand
à elle les données directement issues des accéléromètres.
3
Listeners et Events
Comme nous avons pu le voir, la gestion des Contrôleurs passe principalement par un système de listeners et events que nous avons décidé d’étendre à
tout notre projet. Notre architecture va donc avoir pour rôle de retransmettre, en les ayant uniformisés, les events des différents périphériques jusqu’à
notre application finale (Wii2D ou Wii3D dans notre cas).
Fig. 9 – Structure des Listeners et Events
3.1
Interface matérielle
Comme on peux le voir sur la Figure 9 la communication avec le matériel
s’effectue via des classes héritées de l’interface ControllerListener (par exemple ControlWiimoteListener ou ControlMouseListener ) qui implémentent un
certain nombre de constructeurs spécifiques au périphérique dont ils vont recevoir les events. Ces derniers, faisant écho des changements de coordonnées,
d’accélérations ou d’appuis sur les boutons, vont être traités par la classe
23
de type ControllerListener puis renvoyés, pour les appuis de boutons et
l’évolution des coordonnées, au logiciel final sous la forme de ControlEvent,
et, pour les accelerations et lors de l’appui sur le bouton dédié à la reconnaissance de gestes ou lors du relachement d’un bouton, au module GestureRecognizer sous la forme de ControlAccelerationEvent pour leur interprétation.
3.2
Reconnaissance de gestes
Le module de reconnaissance de gestes, GestureRecognizer, traite donc les
events de type ControlAccellerationEvent sous deux forme : gestureStart et
gestureEnd. Les events gestureStart correspondent à l’acquisition des données
d’accélération et à leur stockage tandis que gestureEnd se charge de lancer la
reconnaissance du mouvement à partir des données enregistrées et de transmettre un GestureEvent correspondant au geste reconnu (ou à GestureListener.GESTURE NONE en cas d’echec), à destination du programme final.
3.3
Programme final
Le programme final implémente les interfaces ControllerListener et GestureListener et va donc traiter les ControlEvent et GestureEvent qu’il reçoit
en y associant les actions souhaitées.
24
Travail Réalisé et Problèmes
Rencontrés
1
Travail préliminaire
Notre travail a dans un premier temps consisté à tester la capacité de
la Wiimote à être connectée à un ordinateur. En effet, malgré les vidéos de
démonstration de plusieurs individus, la compatibilité avec l’implémentation
d’une application java n’étais aucunement garantie, l’ensemble des développements et tests étant effectués par des amateurs sans documentation sur le
matériel.
Nous avons choisi dans un premier temps une configuration Ubuntu et un
dongle Bluetooth nous appartenant, le choix de travailler sur les machines
du CREMI nous paraissant le plus judicieux. Plusieurs problèmes se sont
alors posés : malgré la possibilité de reconnaitre la Wiimote au moyen des
applications Bluetooth de Linux (Voir Annexe 1), un problème de droits est
apparu à chaque tentative d’appairage avec le périphérique. Le superviseur
du réseau nous ayant refusé ces autorisations supplémentaires, nous avons
alors dû choisir de travailler sur nos propres machines.
Nous avons alors choisi d’utiliser un environnement Windows Vista et
nous sommes heurtés au problème du choix d’un stack bluetooth. En effet,
contrairement à Linux où seul BlueZ est utilisé, il existe une multitude de
piles Bluetooth sous Windows. Quelques recherches et essais nous ont montré
que la bibliothèque choisie pour nos développements (Wiigee) ne pouvait
fonctionner qu’avec une pile de l’éditeur Widcomm (la Wiimote nécessite
une double connexion de type L2CAP supportée par cette seul pile). Le
site de l’éditeur ne proposant actuellement pas le téléchargement du logiciel, nous avons dû nous lancer dans la recherche de versions téléchargeables
en d’autres emplacements. Plusieurs versions nous ont posé des problèmes
de fonctionnalités liés à leur ancienneté, d’autres n’étaient pas compatibles
avec la Wiimote. Après plusieurs dizaines de versions testées nous sommes
parvenus à trouver la version 5.0.1.801, fonctionnelle mais provoquant de
fréquents freezes de notre système. Nous avons alors expérimenté la version
bêta de Windows Seven qui a présenté les mêmes symptomes puis les distributions Debian et Ubuntu où nous avons pu constater l’incompatibilité de la
pile BlueZ.
25
Nous avons enfin installé Windows XP qui s’est avéré des plus stables
avec ce stack nous permettant de débuter le travail de programmation.
2
Interfaçage et Utilisation des Controlleurs
Lors de la recherche d’un stack compatible, les tentatives d’utilisation
de la wiimote avec wiigee ont soulevé un nouveau problème. En effet, la
récupération de toutes les données de la manette passe par l’accès à des
valeurs de PSM inférieures à 0x1001, rendue impossible par la spécification
JSR-82 (Voir Figure 10). Une recherche sur des forums utilisateurs et dans
la documentation de la bibliothèque Bluecove, chargée de la gestion du Bluetooth en Java, nous a permis de découvrir un paramètre permettant de
forcer cet accès. Il nous a alors suffit d’ajouter un fichier de paramètre bluecove.jsr82.psm minimum off contenant la valeur 1 à la racine de notre projet.
java.lang.IllegalArgumentException: PCM values restricted
by JAR82 to minimum 4097
Fig. 10 – Erreur rencontrée liée à la spécification JSR-82
Notre travail a ensuite porté principalement sur la compréhension du fonctionnement de WiiGee et des communications Bluetooth avec la Wiimote.
Une étude des exemples de trames reçues par l’ordinateur nous a permis par
la suite de modifier WiiGee afin, par exemple, de prendre en compte la taille
des points observés par la caméra infrarouge. Nous avons choisi d’exploiter
le mode Extended de l’infrarouge qui présente une trame (Voir Figure 11)
contenant les coordonnées de 4 points de lumière infrarouge repérés par la
caméra et leurs tailles respectives.
Comme on peux le voir dans ce tableau, chaque répétition de ce schéma
nous fournit les données d’un des points. Les coordonnées X et Y sont divisées en deux parties (bits de 0-7 et bits 8-9 séparés), encodées chacune sur
10 bits et la largeur du point, encodée sur 4 bits. Une simple manipulation
bit-a-bit au sein du code nous as permis simplement de rassembler les deux
parties de chaque coordonnée.
26
Fig. 11 – Trame renvoyée par la Wiimote concernant sa caméra Infrarouge
3
Mise en place du module de Reconnaissance de Gestes
Une fois la Wiimote interfacée, nous avons dû réfléchir à l’intégration des
mécanismes dédiés à la reconnaissance de gestes au sein de notre architecture de manière à pouvoir prendre en compte à la fois des périphériques nous
fournissant des accélérations en 3 dimensions (la Wiimote par exemple) et
des périphériques nous fournissant de simples coordonnées 2D (comme une
souris).
Nous avons décidé d’implémenter, à destination de la classe ControlMouseListener et de toute autre classe fonctionnant en deux dimensions
(tablette graphique par exemple), une classe abstraite Controller2D fournissant le nécessaire à la conversion en temps réel des coordonnées en accélérations ainsi exploitables par notre gestureRecognizer.
La reconnaissance de gestes récupère ainsi systématiquement en entrée
trois accélérations x, y et z (la dernière étant à 0 pour les périphériques 2D)
et va retourner, à la fin du geste, un identifiant de geste reconnu à tous les listeners enregistrés. L’envoi de données à gestureRecognizer se fait uniquement
27
lors de l’appui sur le bouton secondaire du contrôleur, ou, selon les critères
fixés lors de l’implémentation de la classe de ce dernier. La fin de l’appui
sur ce bouton, ou toute autre action choisie, envoie un event de fin d’action
à gestureRecognizer qui lance alors l’analyse de l’objet de type gesture enregistré au fil des accélérations reçues. En mode learning, déclenché par le
logiciel final, le mouvement est alors ajouté à un gestureModel au lieu d’être
analysé afin d’agrandir la base de gestes qui permettra la reconnaissance en
mode normal.
Etant donné notre choix de conserver la structure de reconnaissance de
gestes utilisée au sein de WiiGee, principalement en raison du temps perdu
à la configuration matérielle de la connexion Bluetooth, nous n’avons rencontré aucun problème hormis de compréhension, au sein de cette partie du
développement.
4
Modification du logiciel Wii2D
Les modifications du logiciel Wii2D ont principalement porté sur deux
points : l’adaptation du logiciel à notre architecture de contrôleurs et de
reconnaissance de gestes et l’ajout d’un rendu graphique et d’une interface
légère reflétant nos futures actions.
4.1
ControllerListener et gestureListener
Notre travail a dans un premier temps porté sur l’adaptation du logiciel
fourni par les clients à notre système permettant l’interfacage de plusieurs
périphériques. Il a suffit pour celà d’implémenter le modèle ControllerListener, ajoutant les contrôleurs de périphérique en fonction des choix de l’utilisateur et de permettre à ce dernier de changer de contrôleur de manière
simple et intuitive.
Sont donc effectué à chaque changement de périphérique, la suppression
de tous les listeners courants, l’ajout d’un listener de type ControllerListener
correspondant au choix de l’utilisateur et celui d’un GestureListener adapté
au matériel sélectionné.
La gestion des évènements se fait au sein de l’application de la même
manière que l’implémentation d’un mouseListener classique.
28
4.2
Graphisme et fonctionnalités
Nous avons ensuite travaillé sur le rendu graphique des actions, comme
demandé par les clients, et sur l’amélioration de l’interface utilisateur. Aucun
d’entre nous n’ayant jamais été formé sur l’utilisation d’OpenGL, nous avons
du nous documenter sur chaque aspect de l’application afin d’en comprendre
le fonctionnement et de trouver des solutions adaptées à nos développements.
La bibliothèque choisie par les clients, JOGL, nous a cependant posé
quelques ennuis. En effet, celle-ci n’étant pas standard, son installation et
son utilisation ont présenté quelques erreurs que nous avons pu résoudre en
intégrant directement au sein du projet, jogl.jar et gluegen-rt.jar.
Nous avons ensuite été confrontés aux notions de gestion du contexte,
modification des axes et repères ou création de formes, chacune nous ayant
demandé de nombreuses recherche et un apprentissage autodidacte.
Nous avons enfin dû nous intéresser à la réalisation d’un menu contextuel,
les clients souhaitant avoir la possibilité de choisir d’effectuer les actions à
l’aide du curseur ou à l’aide de la reconnaissance d’un geste. Nous étant, dans
un premier temps, penchés sur l’utilisation d’un glutCreateMenu, le peu de
documentation et la quasi impossibilité de reçycler le code de cette méthode
nous ont encouragé à tenter de réaliser un menu contextuel à base de formes
et de textes. L’utilisation de gluBitmapString nous permettant de générer
un bitmap à partir de texte puis de l’insérer dans le contexte OpenGL, nous
avont pu mener à bien cette tâche.
La mise en place de la reconnaissance de gestes implique bien entendu
un certain rendu graphique des différentes commandes souhaitées par les
clients. En effet, il ne nous est pas demandé de gérer chacune des actions
mais uniquement de prévoir leur exécution. Nous avons donc choisi des effets
simples rendant bien compte des différentes opérations à effectuer sur l’image.
5
5.1
Modification du logiciel Wii3D
ControllerListener et gestureListener
De même que pour Wii2D, Wii3D permet l’utilisation d’autres types de
périphériques que la souris et le clavier. Nous pouvons interagir avec l’objet
3D (en l’occurence une sphère) et effectuer des opérations de bases décrites
29
par les clients. Nous n’avons pas trouvé nécessaire d’effectuer de reconnaissance de mouvements sur ce logiciel, car une précision certaine est recommandée pour le bon rendu des actions implémentées.
5.2
Graphisme et fonctionnalités
Wii3D s’est vu doté de nouvelles fonctionnalités disposant ainsi d’un
rendu visuel pour satisfaire les attentes des clients. Ces fonctions sont la
coupe et l’extrusion. Etant donné que la réalisation de ces fonctions ne constitue pas l’objectif du projet et notre manque d’expérience en OpenGL,
nous avons donc créé des fonctions simples permettant de visualiser l’interaction entre l’utilisateur et l’application. Nous avons cependant essayé
d’améliorer nos rendus, notemment en voulant avoir une vraie acquisition
des coordonnées 3D en passant par la fonction Convert2D3D, dont la manipulation s’est avéré trop difficile. En effet, celle-ci propose de retourner un
vecteur 3D en prenant en paramêtre une abscisse et une ordonnée, seulement
l’influence des contextes nous a bloqué.
30
Installation et Fonctionnement
Notre projet impliquant un périphérique peu commun, la Wiimote, il
est sujet à un grand nombre de disfonctionnements tant au niveau matériel
qu’au niveau logiciel. Nous allons donner ci-dessous des instructions afin de
procéder à l’installation d’un environnement de travail et/ou d’utilisation.
1
Installation et Matériel
Nous avons dû, lors des tests préliminaires, faire de nombreux essais afin
de trouver un environnement de travail fonctionnel. Notre choix s’est finalement porté sur le système d’exploitation Windows XP, seul à présenter une
certaine stabilité face à la contrainte logicielle du Bluetooth (stack ), les versions Vista et Seven de Windows ainsi que Debian et Ubuntu présentant des
problèmes de stabilité ou de paramétrage matériel (incompatibilité du stack
ou problèmes de communication matériel/logiciel).
1.1
Matériel et drivers
Afin de pouvoir utiliser la Wiimote, il est nécessaire de procéder à l’installation d’un stack, ou pile logicielle Bluetooth, qui se chargera des fonctions de
connexion et de communication entre périphériques et récepteur. Notre choix
s’est porté sur la version 5.0.1.801 du stack Widcomm associé à un dongle
USB Bluetooth Sitecom CN-502. La compatibilité stack/dongle étant relativement chaotique, d’autres modèles de clefs Bluetooth peuvent cependant
fonctionner. Il est important de noter qu’il est parfois nécessaire de remplacer
dans le Gestionnaire de Périphériques, le driver installé automatiquement par
Windows lors du branchement de la clef par celui fourni en même temps que
le stack.
1.2
Interface graphique
Afin de faire fonctionner les logiciels des clients il est nécessaire d’installer
la bibliothèque OpenGL choisie par ce dernier. Nous avons donc ajouté la
version 1.1.2 pour Windows x86 de JOGL au sein de l’environnement de
développement de notre IDE.
31
2
2.1
Utilisation du logiciel
Interface de Wii2D/Wii3D
Les interfaces des logiciels des clients présentent une scène sur laquelle
se trouvent les objets à manipuler (vignettes pour Wii2D ou sphère pour
WIi3D). Un menu présent en haut de la fênetre permet de paramétrer, à la
souris, plusieurs des composants de notre projet.
Le menu Profile propose trois fonctionnalités liées aux profils de gestes :
New, Open et Save qui permettent respectivement de créer un nouveau profil, ouvrir un fichier de profil et sauvegarder le profil courant sous un fichier.
Les gestes étant spécifiques à un individu, il permet donc à plusieurs usagers
d’utiliser l’application selon ses préférences.
Le menu Gesture permet de lancer, via Learning, l’ajout ou le remplacement du geste correspondant à une fonctionnalité dans le profil courant.
Le menu Devices propose de choisir le contrôleur actuellement activé au
sein de l’application. Lors de la première sélection du contrôleur Wiimote, la
procédure d’appairage est lancée et des instructions détaillées sont fournies à
l’écran. Une erreur d’activation de la Wiimote nécessite le retour à un autre
contrôleur avant une nouvelle tentative et il n’est possible d’utiliser qu’un
seul contrôleur à la fois.
2.2
Utilisation des périphériques
L’utilisation des périphériques se base sur une utilisation commune des
boutons. Pour la souris, le clic gauche est le bouton principal et le clic droit
le secondaire. Pour la Wiimote, le (A) correspond au bouton principal et le
(B) au bouton secondaire.
L’appui sur le bouton principal d’un périphérique correspond au clic
habituel d’une souris. Il est donc possible de réaliser une sélection par un
simple clic ou de sélectionner plusieurs vignettes par un rectangle de sélection
dans Wii2D ou bien de déplacer la caméra autours de la sphère par un cliquerdéplacer sous Wii3D.
L’appui sur le bouton secondaire est lui dédié à la reconnaissance de geste.
Il suffit alors d’appuyer et de maintenir le bouton pendant la réalisation du
32
geste pour ensuite le relacher et que celui-ci soit reconnu (ou enregistré en
mode Apprentissage).
Pour les périphériques possédant plus de boutons, d’autres fonctionnalités
sont disponibles, il s’agit de celles présentes dans la barre de menu en haut
des applications. Pour la Wiimote, par exemple, le bouton (-) va lancer l’enregistrement du profil courant, le bouton (+) va lancer le chargement d’un
fichier de profil et le bouton (1) lancer l’interface d’apprentissage d’un geste.
On notera que l’utilisation de la Wiimote nécessite une sensor-bar placée
au bord d’un écran ou d’un meuble et un éloignement de quelques mètres
de celle-ci pour assurer le bon fonctionnement du capteur infrarouge de la
manette. Il sera alors possible de déplacer le curseur dans la scène de l’application en dirigeant la Wiimote vers l’écran.
2.3
Interface d’apprentissage
L’interface d’apprentissage permet l’ajout d’un geste au profil courant et
son association avec une fonction disponible au sein de l’application finale.
La fênetre ouverte présente des instructions détaillées invitant l’utilisateur à
répéter le geste désiré un certain nombre de fois (10 par défaut) et l’invite
ensuite à choisir la fonction associée.
33
Définition et Réalisation des
tests
Dans le cadre de notre projet, la réalisation de tests est quelque peu particulière. En effet, bien qu’il nous soit possible de tester une série de valeurs
pré-enregistrées, la bonne exécution ne nous donnerais aucune indication concernant le bon fonctionnement de notre application : notre programme a pour
but de reconnaitre les gestes humains dans leur diversité et doit donc, pour
ses tests, passer entre les mains d’individus réels.
Nous allons donc tenter de décrire quelques procédures visant à tester les
fonctionnalités de notre application et la bonne prise en main de celle-ci par
l’utilisateur.
1
Test de la fonction Curseur
et du déplacement
Comme prévu lors de l’étude des besoins, la souris et la wiimote, périphériques choisis pour notre développement, doivent permettre de contrôler un
curseur sur la scène OpenGL de l’application des clients. On peux considérer le test comme intuitif pour la souris mais il nécessite, pour la wiimote,
quelques précisions.
Il est nécessaire dans un premier temps de procéder à l’activation et à
l’appairage de la wiimote avec le PC. Pour celà, l’utilisateur doit activer la
fonction Wiimote du menu Controllers, puis suivre les instructions afin de
procéder à l’association de la manette. Dès la fin de cette procédure, il est
possible pour l’utilisateur d’orienter sa wiimote vers l’emetteur infrarouge
et de contrôler le curseur en déplaçant le périphérique. Il est cependant
nécessaire, en raison de contraintes techniques, de s’éloigner de quelques
mètres de l’emetteur afin d’obtenir une utilisation fluide.
En cliquant sur une vignette avec la touche principale du contrôleur,
l’utilisateur peut ainsi déplacer le carré de couleur et le relacher où il le
souhaite.
34
Fig. 12 – Screen de l’application Wii2D : Exemple de déplacement de vignette
2
Test des logiciels
Le but de notre projet étant l’intéraction entre différents contrôleurs et
une application, il est normale de présenter dans cette partie, des tests qui
mettent en évidence cette intéraction. Par le biais des fonctions implémentées
au sein des logiciels 2D/3D, nous disposons d’un rendu visuel
– Fonctions basiques :
Nous avons développé, au sein des différents logiciels fournis par les
clients, des fonctions permettant d’intéragir directement avec les objets
présents sur la scène. Ainsi, nous avons implémenté des actions telles
que l’ajout, la suppression, la fusion, la négation, etc. Par exemple la
suppression d’images s’effectue en plusieurs étapes : dans un premier
temps, il s’agit de sélectionner à l’aide de la Wiimote (appui bref sur
le bouton (A) au dessus d’une image ou maintient du bouton (A) pour
utiliser le rectangle de sélection) les images désirées. L’instruction de
suppression est ensuite donnée par la reconnaissance de gestes, il faut
donc appuyer sur le bouton (B) et dessiner une croix (voir figure 14).
35
Fig. 13 – Screen de l’application Wii2D : Exemple d’ajout de vignettes
Fig. 14 – Screen de l’application Wii2D : Exemple de suppression de vignettes
36
– Apprentissage d’un mouvement et reconnaissance :
Le point crucial de ce projet est l’intéraction avec n’importe quel périphérique et notamment la reconnaissance de geste. Afin d’effectuer cette
dernière, il est avant tout nécessaire de procéder à l’enregistrement d’un
geste, fonctionnalité qui devient alors forcément l’objet d’un test par
sa place centrale au sein de l’architecture. Ce test prouve le bon fonc-
Fig. 15 – Screen de l’application Wii2D : Exemple de reconnaissance de geste
tionnement du module d’apprentissage de mouvements et la possibilité
de définir facilement des profils de mouvements à utiliser au sein des
logiciels.
37
Améliorations et réutilisations
possibles
Nous avons tenté lors de la réalisation de notre projet de respecter des
principes de programmation offrant la possibilité de réutiliser aisément notre
code dans d’autre applications. Nous avons également pu remarquer de nouvelles voies de développement qui permettraient l’amélioration ou l’ajout de
fonctionnalités mais qui, faute de temps ou d’intérêt pour les clients, n’ont pas
été implémentées. Nous allons vous exposer quelques unes des améliorations
ou réutilisations possibles.
Améliorations
– Amélioration de la classe ControlMouseListener : Nous nous
sommes contentés lors de l’élaboration de ce module de traiter les
données d’une souris basique (à trois boutons). Il est cependant à noter
que l’on trouve de plus en plus de souris possédant de multiples boutons
qu’il serait intéressant d’exploiter. La diversité des configurations et l’utilisation répandue de drivers propriétaires fait qu’il sera nécessaire de
traiter le matériel au cas par cas.
– Création de nouvelles classes de périphériques : Etant donné
que notre implémentation permet, en théorie, l’utilisation de n’importe
quel périphérique d’interface utilisateur (HID), l’amélioration de notre
application passe par la création de nouveaux modules spécifiques à
chaque type de matériel existant (tablette graphique, gant, etc).
– Amélioration de la prise en charge des contrôleurs : Lors de
la mise en place de notre architecture de contrôleurs, nous avons été
confrontés à plusieurs choix d’implémentations et avons décidé de ne
répondre qu’aux besoins des clients. Cependant, il aurait été possible
d’améliorer le système en proposant par exemple la possibilité d’utiliser
plusieurs contrôleurs à la fois (risque de conflits lors de l’utilisation) ou
de permettre l’ajout “à la volée” d’une nouvelle classe de périphérique.
Il serait aussi intéressant de proposer pour chaque contrôleur un ensemble de données de reconnaissance de gestes par defaut.
38
– Amélioration de l’interface utilisateur : La plus grande partie
de notre travail a porté sur des soucis d’ordre matériel ou liés à la
réalisation de notre architecture de projet, délaissant ainsi quelque peu
l’aspect graphique de l’application. Un travail visuel ou lié à l’ergonomie
de notre interface pourra donc faire partie des points d’amélioration,
avec par exemple une interface plus intuitive pour l’association d’une
Wiimote, ou encore des menus au sein de la scène OpenGL.
– Ajout d’une interface de configuration : La majorité des paramétrages de notre appplication se font actuellement par la modification de
variables globales au sein des differentes classes. L’introduction d’une
interface permettant la configuration des paramètres principaux de nos
modules serait donc une amélioration possible (modification du nombre
de répétitions pour l’acquisition d’un geste ou encore choix des boutons
associés aux actions).
Réutilisations
– Utilisation dans une autre application : Les modules de notre
projet sont implémentés de manière à pouvoir être intégrés à n’importe
quelle application tirant habituellement parti de la souris. La simple
implémentation de nos ControlListener et GestureListener au sein d’un
programme permet ainsi d’y inclure la reconnaissance de gestes et le
support de plusieurs types de contrôleurs.
– Mise en place au niveau de l’OS : Il serait possible de réaliser une
couche applicative afin de fournir des fonctionnalités avancées concernant les periphériques d’interface utilisateur au sein du système d’exploitation (reconnaissance de gestes ou utilisation de boutons supplémentaire par exemple) en se basant sur le code de notre projet.
39
Conclusion
Le travail que nous avons eu à fournir lors de ce projet de PDP nous a
procuré de nombreux enseignement au niveau de la tenue d’un projet, de la
communication avec un client, du travail en équipe mais aussi en programmation en nous permettant de manipuler de nouvelles notions et fonctions.
Nous avons du travailler à la lisibilité de notre code et en conséquent, à sa
maintenabilité ce qui nous a dans le même temps permis de mieux nous approprier le code, autorisant chacun des membres du groupe à comprendre
l’ensemble des processus mis en jeu.
Le sujet particulièrement intéressant nous a permis de travailler sur un objet assez mystérieux au premier abord et d’en découvrir la majorité des secrets
de fonctionnement et nous espérons tomber sur des projets aussi intéressants
lors de notre entrée dans la vie professionnelle.
40
Bibliographie
Commentaire
Le document [1] est le site officiel de la bibliothèque Java JOGL, qui permet l’utilisation de l’OpenGL.
Le document [2] est un site fournis par les clients présentant une multitude de tutoriels pour l’OpenGL. Contient des codes sources commenté dans
différents langages dont JOGL qui est utilisé dans notre projet. Il présente
aussi des exemples d’utilisation des fonctions glut.
Le document [3] présente une librairie Java permettant la reconaissance
de mouvements par l’intermédiaire de la Wii Mote. Ce site comprend un tutoriel pour ajouter la librairie à un projet, quelques explications au niveau
de la reconnaissance de mouvements ainsi qu’une JavaDoc de la librairie.
Le document [4] est un livre qui est la référence en matière de programmation OpenGL en langage C. Complément aux tutoriels de NeHe, de nombreux
exemples de code sont disponibles.
Le documents [5] est un rapport de recherche présentant une étude orientée utilisateur dont le but est de tester les interactions 3D. Cette approche
s’appuie sur un prototype léger et facilement extensible constitué principalement d’un gant comme périphérique 3D. De plus, le rapport évoque également
l’ajout d’un deuxième périphérique tel qu’une WiiMote pour la facilité de
contrôle de l’application.
Le document [6] est un wiki contenant les bases de compéhension des
accéléromêtres de la Wii Mote. Il contient également différents drivers qui
sont fonctionnels, écrit dans des langages variés. Ce site nous servira principalement pour les drivers puisque qu’il en propose une assez grande séléction.
Nous devrons choisir celui qui correspond le mieux aux objectifs de notre projet.
Le documents [7] est une thèse sur la détection, suivi et reconnaissance
des formes et du mouvement par modèles probabilistes d’apparence.
Le documents [8] est un article qui explique les expériences menées par
des chercheurs de l’université de Oldenburg sur la reconnaissance de mouve41
ments par l’intermédiaire d’accéléromêtres. L’analyse est faites de plusieurs
étapes qui sont détaillées (notemment au niveau de la l’acquisition des mouvements effectués par la Wii Mote) ainsi que la méthode de filtrage de mouvement utilisée. Les chercheurs indiquent aussi les résultats obtenus avec leurs
méthodes au niveau de la bonne identification des mouvements effectués.
Références
[1] Jogl : https ://jogl.dev.java.net/.
[2] Nehe productions : http ://nehe.gamedev.net. 1997.
[3] Wiili : www.wiili.org. 2006.
[4] Jackie Neider Tom Davis Dave Shreiner, Mason Woo. The opengl programming guide - sixth edition/the redbook. 2007. version HTML :
http ://www.glprogramming.com/red/.
[5] Philippe Renevier Anne-Marie Pinna-Déry1 Julien Soula Michel Riveill
Diane Lingrand, Sébastien Meunier. Gestaction 3d : combiner commandes
gestuelles et interactions 3d. In Rapport de recherche isrn, Novembre
2006.
[6] Benjamin Poppinga and Thomas Schlömer. Wiigee : www.wiigee.org.
2008.
[7] Fabrice Heitz Rouf Hamdan. Détection, suivi et reconnaissance des
formes et du mouvement par modèles probabilistes d’apparence. PhD thesis, Strasbourg I, 2001.
[8] Niels Henze Susanne Boll Thomas Schlömer, Benjamin Poppinga. Gesture recognition with a wii controller. In Proceedings of the 2nd International Conference on Tangible and Embedded Interaction, February 2008.
42
Annexes
43