Rapport Final - Interactions 2D/3D ` a base de

gestes en utilisant la Wiimote

Enes de Carvalho Miguel
Al Hossri Laurent
Augereau Julien
Lahaye Fabien
7 avril 2009
Charge de TD : Marchand Sylvain
Clients : Levet Florian & Schlick Christophe
Universite Bordeaux 1
Projet de Programmation 2008-2009
1
Table des mati`eres
Introduction au domaine 5
1 Les debuts de la Motion Capture 5
2 Larrivee de la console Wii 6
3 Democratisation de la Wiimote 8
Descriptif du projet 10
Inventaire de lexistant 11
1 Les biblioth`eques et scripts existants 11
2 Les logiciels fournis par les clients 12
2.1 Logiciel 2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Logiciel 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Biblioth`eque Wiigee . . . . . . . . . . . . . . . . . . . . . . . 14
Etude des besoins 16
1 Besoins Fonctionnels 16
1.1 Fonctionnalites du logiciel 2D . . . . . . . . . . . . . . . . . . 16
1.2 Fonctionnalites du logiciel 3D . . . . . . . . . . . . . . . . . . 16
1.3 Fonctionnalites communes . . . . . . . . . . . . . . . . . . . . 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 23
3.1 Interface materielle . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Reconnaissance de gestes . . . . . . . . . . . . . . . . . . . . . 24
3.3 Programme nal . . . . . . . . . . . . . . . . . . . . . . . . . 24
Travail Realise et Probl`emes Rencontres 25
1 Travail preliminaire 25
2 Interfacage et Utilisation des Controlleurs 26
3 Mise en place du module de Reconnaissance de Gestes 27
4 Modication du logiciel Wii2D 28
4.1 ControllerListener et gestureListener . . . . . . . . . . . . . . 28
4.2 Graphisme et fonctionnalites . . . . . . . . . . . . . . . . . . . 29
5 Modication du logiciel Wii3D 29
5.1 ControllerListener et gestureListener . . . . . . . . . . . . . . 29
5.2 Graphisme et fonctionnalites . . . . . . . . . . . . . . . . . . . 30
Installation et Fonctionnement 31
1 Installation et Materiel 31
1.1 Materiel et drivers . . . . . . . . . . . . . . . . . . . . . . . . 31
1.2 Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Utilisation du logiciel 32
2.1 Interface de Wii2D/Wii3D . . . . . . . . . . . . . . . . . . . . 32
2.2 Utilisation des peripheriques . . . . . . . . . . . . . . . . . . . 32
2.3 Interface dapprentissage . . . . . . . . . . . . . . . . . . . . . 33
Denition et Realisation des tests 34
1 Test de la fonction Curseur
et du deplacement 34
Test de la fonction Curseur . . . . . . . . . . . . . . . . . . . . . . 34
2 Test des logiciels 35
Test de la fonction Curseur . . . . . . . . . . . . . . . . . . . . . . 35
3
Ameliorations et reutilisations possibles 38
Ameliorations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Reutilisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Conclusion 40
Bibliographie 41
Annexes 43
4
Introduction au domaine
Letude des interfaces proposees `a lhomme dans le domaine informatique
a toujours donne lieu ` a de nombreuses experimentations. Les utilisateurs
dordinateurs sont aujourdhui habitues `a lutilisation du classique couple
clavier/souris, et ce dans tous les domaines impliquant linformatique, alors
meme que de nombreux autres peripheriques de controle, plus adaptes `a des
utilisations speciques, existent.
Beaucoup dinnovations dans le domaine de linterfacage homme/machine
ont ete decouvertes et developpees dans le cadre dexperimentations liees ` a la
realite virtuelle. En eet, ce domaine requiert une interaction forte, immersive
et instinctive avec lutilisateur, caracteristiques recherchees egalement dans le
contr ole de toute application informatique. Lors de lapparition de la notion
de realite virtuelle furent crees plusieurs peripheriques, comme par exemple
lUltimate Display, tout premier casque capable de reproduire, dans une sim-
ulation informatique, les mouvements de la tete du porteur. Mais ce qui fut
un veritable moteur pour ces developpements est sans doute lutilisation par
la NASA dans son programme VIVED du concept de realite virtuelle et le
developpement dun casque achant, en fonction des mouvements du por-
teur, un environnement virtuel pour lentranement aux missions spatiales.
1 Les debuts de la Motion Capture
La motion capture t son apparition au debut des annees 80, revolution-
nant la reconnaissance de mouvements. Cette technique, se resumant dans
un premier temps ` a la xation de potentiom`etres sur le corps du sujet an
de mesurer les angles de exion des articulations, va ensuite evoluer pour
faire intervenir un syst`eme de diodes reexives dont la position est trian-
gulee par une serie de cameras permettant ainsi un rendu en 3D sur ordina-
teur des mouvements de lindividu. Par la suite, dautres techniques seront
developpees comme par exemple des gants permettant la capture des mou-
vements des doigts pour permettre de jouer virtuellement de la musique.
De nos jours, ces peripheriques ont evolue et la capture de mouvement
est plus precise, les outils moins invasifs et surtout leur co ut a ete reduit. On
trouve principalement deux types doutils : ceux impliquant une acquisition
dordre visuel (techniques optiques) et ceux impliquant des capteurs sur lin-
dividu (techniques mecaniques).
5
Les techniques optiques sont caracterisees par la presence dune ou plu-
sieurs cameras ou capteurs qui vont permettre de reconnaitre la position
de marqueurs sur le sujet. Ces derniers peuvent etre passifs, reechissant la
lumi`ere rouge ou infrarouge emise par des cameras sensibles `a ce seul type
de rayonnement, ou actifs, emettant eux meme un rayonnement capte par les
cameras ou cellules photosensibles, cette technique permettant deviter tout
probl`eme de parallaxe lie ` a lutilisation dune lentille. Dans les deux cas, les
donnees des dierentes cameras/cellules (au moins 2), sont combinees an
de determiner les coordonnees dans lespace de chacun des marqueurs qui
seront exploitees par lutilisateur dans la procedure de reconnaissance de
mouvements.
Les techniques mecaniques fonctionnent, quant `a elles, grace ` a une serie
de capteurs. Dans le cadre de captures mecaniques, lindividu dispose dun
exosquelette sur lequel se trouve, `a chaque articulation, un capteur angulaire
dont les donnees sont ensuite exploitees par un ordinateur. Pour des captures
magnetiques, un champ est emis en un point xe et des capteurs sont places
aux points strategiques du corps du sujet sous forme de bobines de l qui,
creant des perturbations dans ce champ, peuvent etre localisees par une serie
de calculs. Il sagit cette fois-ci, plut ot dune capture de mouvement que de
position, les outils ne permettant pas la recuperation de donnees precises
quand `a la position dans lespace des capteurs.
La plupart des techniques enoncees ci-dessus ont trouve des applications
dans de nombreux domaines : de la creation de lms ou de jeux videos dans
laquelle on capture les mouvements dun acteur an de generer des person-
nages en 3D aux gestes realistes, ` a larcheologie, o` u la reconstitution virtuelle
de vestiges est facilitee par la simplicite de manipulation des outils. Ces tech-
niques ont toutes pour principal avantage la retranscription en temps reel du
mouvement et ce, de mani`ere extremement realiste, mais leur integration dans
un projet necessite un nancement consequent de par le co ut du materiel et
des logiciels, empechant jusquici leur democratisation et leur utilisation dans
des travaux de petite envergure.
2 Larrivee de la console Wii
La miniaturisation des composants et la production en chane de ceux-ci
a cependant, aujourdhui, change la donne. En eet, depuis 2006 est apparue
6
la console Wii de Nintendo et sa manette de jeux particuli`ere : la Wiimote.
Ce peripherique a ete concu de mani`ere `a procurer au joueur une sensation
dimmersion dans le jeu en orant une experience de mimetisme gestuel par
des mecanismes de reconnaissance de mouvements et de detection dans les-
pace. De la simulation de bowling, au jeu de tir, la Wiimote et la Wii ont
conquis les joueurs et la console est aujourdhui installee dans de nombreux
foyers. Etonnament, bien que proprietaire, la wiimote est utilisatrice de stan-
dards informatiques et materiels et exempte de tout cryptage ou protection :
technologie Bluetooth pour la transmission des donnees `a la console, camera
infrarouge pour la detection dans lespace et accelerom`etre standard pour la
detection de mouvements, permettant denvisager une alternative accessible
et bon marche aux solutions industrielles existantes.
La wiimote comporte un accelerom`etre, sensible sur 3 axes (Voir Figure
1), qui va etre au coeur de la reconnaissance de mouvements. Son fonction-
nement est simple : une masse ottante va se deplacer et exercer une pression
plus ou moins forte sur les parois de laccelerom`etre qui sont equipees de cap-
teurs de pression : si la pression est forte vers le bas, la Wiimote a eectue un
mouvement vers le haut par exemple. Ces donnees vont permettre dobtenir
des valeurs dacceleration dans les trois dimensions en fonction du temps, qui
seront ensuite exploitees pour reconnaitre un mouvement.
La camera infrarouge de la wiimote permet, quant ` a elle, la reconnais-
sance de la position de la wiimote par rapport `a lecran (equipe alors dune
sensor bar, dispositif electronique emettant deux points distants en lumi`ere
infrarouge). La camera, si elle est orientee vers lecran, capte deux points de
lumi`ere qui vont lui permettre de determiner leloignement de la manette en
fonction de la taille des points (plus la manette est proche, plus les points
seront grands), linclinaison de la manette avec lalignement des deux points
(si les deux points forment une ligne horizontale, la Wiimote est ` a plat, si la
ligne est verticale, elle est sur le cote) et lendroit vise par lutilisateur sur
lecran avec la position de ces points, cette derni`ere information permettant
principalement la projection dun curseur sur lecran et linteraction avec les
elements de lapplication comme on le ferait avec une souris.
Lensemble de ces donnees, ajoutees ` a celles de peripheriques supplemen-
taires pouvant etre connecte en dessous de la wiimote (nunchuck, instrument
de musique, manette classique, ...), est ensuite transmis en Bluetooth `a la
console qui les interpr`ete en temps reel. La technologie Bluetooth, princi-
palement utilisee par les telephones mobiles, permet la transmission radio de
donnees sans l avec un debit denviron 1Mbit/s et fonctionne par connexion
7
Fig. 1 Caracteristiques de la Wiimote
ponctuelle pour lenvoi de donnees (envoi dimages entre telephones par ex-
emple) ou via une connexion constante, nommee apairage, pouvant etre ou
non securisee (la Wiimote utilise un apairage non securise).
3 Democratisation de la Wiimote
Lensemble de ces technologies rend lutilisation detournee de la Wiimote
des plus simples, et il na pas fallu longtemps pour que des amateurs decident
de sinteresser `a lutilisation de cette manette sur des ordinateurs. De nom-
breuses experiences ont ete eectuees et aujourdhui, des biblioth`eques sont
trouvables dans de nombreux langages de programmation pour permettre
dutiliser la wiimote comme controleur principal dapplications diverses. Le
faible co ut du peripherique, induit par une production ` a grande echelle, et sa
capacite `a se substituer ecacement ` a tout autre controleur (souris, tablette
graphique, ...) permet denvisager un nombre impressionnant dapplications.
Des individus tel Johny Chung Lee, docteur en informatique dans le domaine
des interactions Homme/Machine, a realise de nombreuses experiences util-
isant les composants bon marche de la wiimote : du contr ole dune interface
du bout des doigts gr ace ` a la camera infrarouge, `a la sensor bar et `a
8
des marqueurs reechissants sur ses doigts, ` a la realisation dune application
prenant en compte les mouvements de lindividu en temps reel pour generer,
sur un ecran normal, un environnement percu comme holographique par le
sujet.
9
Descriptif du projet
Comme on a pu le voir, le peripherique Wiimote est bien plus quune
manette de jeu et sav`ere particuli`erement adapte ` a une utilisation dans le
domaine du traitement dimages. Nos clients souhaitent pouvoir, `a laide de
la Wiimote, eectuer des operations au sein de deux logiciels, lun dedie au
traitement de multiples vignettes 2D, lautre `a la manipulation dobjets 3D.
Ces logiciels sont destines ` a la manipulation dimages medicales.
Le projet sera ainsi divise en deux parties ayant pour noyau commun
limplementation dun dispositif dapprentissage des mouvements et de recon-
naissance de ceux-ci. Les clients nous fournissent deux exemplaires simplies
de ses logiciels codes en Java. Nous devrons modier ceux-ci an de rendre
visuellement compte des operations commandees par les mouvements et pro-
poser une interface graphique adaptee au peripherique (selection aisee, menus
deroulants, ...). La Wiimote sera donc ` a la fois utilisee en remplacement de
la souris gr ace aux donnees de sa camera infrarouge et en peripherique de
reconnaissance de mouvements grace ` a son accelerom`etre.
Le logiciel 2D presente un espace de travail o` u sont disposees des vignettes
dimages. La Wiimote sera utilisee pour interagir avec ces vignettes, perme-
ttant de realiser des glisser/deposer, des selections, et des operations sur les
images selectionnees via des gestes (la capture de ceux-ci etant conditionnee
par lappui sur lun des boutons de la manette).
Le logiciel 3D presente une sph`ere avec laquelle il sera necessaire dinteragir
au moyen de la Wiimote. Nous pensons mettre en place un deplacement de la
camera selon les mouvements de la Wiimote ou, si nous en avons le temps, via
un nunchuk relie ` a la Wiimote. Les interactions proposees par les clients (ex-
trusion, coupe) impliquent la prise en compte du capteur infrarouge unique-
ment.
Les clients demandent que notre projet permette linterfacage, avant la
phase de reconnaissance de mouvements, dun autre type de peripherique que
la Wiimote, par exemple une tablette graphique, via limplementation dune
classe heritee.
10
Inventaire de lexistant
Dans le cadre de notre projet, lexistant est particuli`erement important.
En eet, la Wiimote etant proprietaire et Nintendo ne fournissant, en dehors
des developpeurs de jeux, aucune documentation ou information sur lutili-
sation et le fonctionnement de la manette, notre seule source dinformation
pour le developpement se situe dans les documents realises par les commu-
nautes existantes autours du sujet, en particulier sur le web. Nous aurons
egalement ` a analyser en details les logiciels fournis par les clients, la modi-
cation et linteraction avec ceux-ci constituant la majeure partie de notre
projet.
1 Les biblioth`eques et scripts existants
De nombreuses biblioth`eques, logiciels et scripts ont ete developpes par
des amateurs en se basant sur la lecture des trames recues de la Wiimote
une fois celle-ci connectee au PC. Le plus utilise de ces logiciels est sans
doute GlovePie, permettant de controler nimporte quel logiciel ` a partir de
peripheriques divers : joystick, souris, peripherique MIDI ou Wiimote. Il pro-
pose un langage de script specique permettant beaucoup dutilisations diver-
tissantes mais ne permettant pas dimplementer aisement la reconnaissance
de mouvements, et encore moins de lintegrer sous forme de plugin ` a un pro-
gramme existant.
Il existe egalement un certain nombre de biblioth`eques dans des langages
varies mais, le logiciel des clients etant en Java, nous nous contenterons de
celles qui sont compatibles. La biblioth`eque MoteJ nous propose de nom-
breuses classes et methodes visant `a simplier la communication avec la
Wiimote (donnees infrarouge, gestion des vibrations et leds, donnees de
laccelerom`etre, ...). La biblioth`eque WiiGee nous propose les memes fonc-
tions de contr ole de la wiimote auxquelles sajoute un module dapprentis-
sage/reconnaissance de gestes. Notre choix se portera donc sur cette derni`ere
an de nous simplier la t ache.
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 nal des clients presente une fenetre
contenant un certain nombre de carres de couleur symbolisant des vignettes
dimages. Le but de notre projet sera de modier ce logiciel an dy inclure
un plugin permettant la connexion ` a la Wiimote ou tout autre peripherique
dedie ` a la reconnaissance de gestes et dimplementer une interface intuitive
adaptee. Le logiciel est un projet Java, dont les trois classes principales :
WiiMote2D, ImageIcon et GLRectangleEntity ont les roles suivants :
WiiMote2D : Il sagit de la classe principale qui contient dans son
constructeur, les instructions relatives ` a la creation de lenvironnement
de travail (fenetre, composant GLCanvas pour gerer le dessin et utiliser
OpenGL). Un listener de type Renderer est egalement cree permettant
linterraction avec les elements OpenGL. La classe Renderer presente les
fonctions liees ` a la souris : MouseDragged, MousePressed ainsi quune
fonction dinterraction avec le clavier : KeyPressed et les methodes init,
display, reshape, drawScene necessaires `a OpenGL. Lappel au main
se termine ensuite par la creation des vignettes representees par des
objets ImageIcon.
ImageIcon : Cette classe permet la creation et la gestion des vi-
gnettes dimages sur lesquelles nous eectuerons les actions induites
par notre projet et la reconnaissance de gestes. Lobjet comprend deux
champs, lun correspondant au nom et lautre, rec, contenant la forme
representant la vignette.
GLRectangleEntity : Il sagit de la classe denissant la forme prise
par les vignettes. Les formes denies dans cette classe sont en 3D et
non en 2D de mani`ere ` a gerer ecacement 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 presente un espace de travail OpenGL
dans lequel se situe une sph`ere. Un trackball logiciel nous permet de faire piv-
oter celle-ci autours de son centre de gravite. Comme pour le logiciel 2D, il
sagit dun projet Java qui presente, pour sa part, les classes principales :
WiiMote3D, Vec3d et Quaternion dont les roles sont les suivants :
WiiMote3D : Comme pour le logiciel 2D, il sagit de la classe princi-
pale qui a pour but de mettre en place lenvironnement de travail.
Quaternion : Cette classe contient les interactions possibles avec lob-
jet 3D en particulier limplementation de la methode trackball.
Vec3d : Cette classe g`ere la creation et la manipulation de vecteurs
3D au sein de lenvironnement OpenGL.
13
Fig. 3 Diagramme du logiciel client WiiMote3D
2.3 Biblioth`eque Wiigee
La biblioth`eque WiiGee nous a semble la plus adaptee `a notre projet
par son integration de mecanismes dapprentissage/reconnaissance de gestes
nous orant ainsi la possibilite de ne pas recoder ces fonctions mathematiques
complexes et nous permettant ainsi de nous concentrer sur les fonctionnalites
du logiciel. Cette biblioth`eque se decompose en quatre packages qui sont :
Device : sert de passerelle entre lordinateur et la Wiimote. En eet, on
trouve au sein de celui-ci deux classes : Wiimote et WiimoteStreamer.
Wiimote : cette classe represente les fonctions basiques de la Wi-
imote. Son constructeur permet dajouter une nouvelle Wiimote au
sein de lapplication en se basant sur ladresse mac de celle-ci. On
trouve egalement toutes les fonctions necessaires ` a linteractions avec
la wiimote via la creation dun listener, addWiimoteListener, qui per-
met de detecter les mouvements simples et les actions de lutilisateur
(pressions de boutons). Sajoute `a ce dernier un second listener, ad-
dGestureListener qui lui se charge de la reconnaissance de gestes
prealablement acquis. Pour nir, on trouve des fonctions permettant
de faire vibrer la Wiimote, dallumer les leds de celle-ci ou encore des
acc`es plus techniques permettant de lire lEPROM (Erasable Pro-
14
grammable Read Only Memory : rom de petite capacite ea cable et
programmable) de la console.
WiimoteStreamer : Cette classe sert dinterpreteur aux commandes
emises par la Wiimote. En eet, apr`es reception et traitement des
donnees les actions correspondantes sont eectuees : pour exemple,
lorsque le bouton A est presse sur la Wiimote, celle-ci emet un sig-
nal capte par WiimoteStreamer qui linterprete et lance la routine
associee. On retouve donc, en plus des actions pour les bouton (A,
B, home...), des actions suite `a une nouvelle acceleration detecte par
la Wiimote.
Control : g`ere la recherche, la connexion et le controle des Wiimotes.
Pour ce faire, le package utilise deux classes : DeviceDiscovery et Wi-
igee.
DeviceDiscovery : cette classe permet de decouvrir les Wiimotes en-
vironnante au lancement de lapplication. Une fois la decouverte
achevee, lassociation entre la Wiimote et lordinateur est eectuee.
Cette etape est soumise `a de nombreux param`etres comme la version
du driver gerant le dongle Bluetooth ou encore la version de la pile
utilisee pour la communication entre le dongle et les applications.
Wiigee : cette classe est la base de la biblioth`eque. En eet, cest elle
qui g`ere les dierentes Wiimotes trouvees lors du balayage et denit
les listeners ou encore les bouton par defaut.
Event : regroupe les classes correspondant aux evenements potentiel
de la Wiimote : lappui sur un bouton, le rel achement dun bouton, ou
encore la detection dune nouvelle acceleration.
Logic : regroupe les classes liees aux operations mathematiques de la
reconnaissance de mouvements.
AccelerationStreamAnalyzer : cette classe analyse les ev`enements de
type WiimoteAccelerationEvent (classe du package Event gerant les
accelerations de la Wiimote) puis g`ere la creation et le traitement
des mod`eles resultant du geste enregistre.
Gesture : cette classe represente un geste et stocke les valeurs daccele-
ration correspondant `a celui-ci en fonction du temps.
HMM : Cette classe est une implementation du Mod`ele cache de
Markov qui fournit les algorithmes utilises pour lentranement et la
reconnaissance de gestes.
15
Etude des besoins
Nous allons presenter dans ce rapport les besoins fonctionnels commu-
niques par nos clients ainsi que ceux, non-fonctionnels, resultant des obliga-
tions techniques induites par lutilisation prevue des logiciels.
Les besoins fonctionnels se divisent en trois categories : ceux speciques
au logiciel 2D, ceux du logiciel 3D et enn, les besoins communs aux deux.
Par la suite, nous tenterons danalyser les besoins non fonctionnels inherents
au projet.
1 Besoins Fonctionnels
1.1 Fonctionnalites du logiciel 2D
Les besoins du logiciel 2D sont uniquement de lordre de la reconnais-
sance et de linterpretation de gestes, le traitement des images devant etre
gere ulterieurement par le logiciel des clients. Le rendu visuel des dierentes
fonctionnalites devra etre clair et ergonomique. Les actions gerees par notre
projet seront :
Selection/Deplacement dimages : possibilite de selectionner / dese-
lectionner / deplacer une ou plusieurs images ` a la fois gr ace au curseur
de la Wiimote (Voir Figure 4). La selection pourra etre eectuee en
mode cadre ou de mani`ere successive (maintiens de la touche SHIFT).
Actions sur une image : il doit etre possible via des actions du
contr oleur deectuer un traitement (negation par exemple) ou de sup-
primer une image selectionnee.
Actions sur plusieurs images : on doit pouvoir, pour plusieurs im-
ages selectionnees, realiser des actions groupees (suppression, traite-
ments individuels) mais egalement des actions entre les images : addi-
tion, soustraction, multiplication, ... dimages (Voir Figure 5).
1.2 Fonctionnalites du logiciel 3D
Le logiciel 3D ne nous presentant quun unique objet, les actions possibles
sont beaucoup moins nombreuses quavec le logiciel 2D. Comme precedemment
le traitement de lobjet sera gere ulterieurement par le logiciel des clients.
Seul un rendu visuel representatif de loperation `a eectuer sera mise en
16
Fig. 4 Deplacement dune image au sein du logiciel 2D
Fig. 5 Exemples de mouvements reconnaissables par le logiciel 2D
place. Plus precisement, les actions gerees par notre projet seront :
17
Deplacement de lobjet : le deplacement de lobjet sera normalement
geree par les clients grace ` a un trackball logiciel. Nous allons interfacer
celui-ci `a la Wiimote. (Voir Figure 6).
Fig. 6 Deplacement de lobjet 3D autours de son centre de gravite.
Actions sur lobjet : lutilisation de la Wiimote devra nous permettre
de realiser des actions sur lobjet (par exemple : extrusions, coupes, ...).
1.3 Fonctionnalites communes
La gestion de la reconnaissance de gestes ainsi que la volonte des clients
de disposer dune architecture de projet permettant denvisager le remplace-
ment du controleur Wiimote par un autre peripherique (tablette graphique
par exemple), nous forcent ` a mettre en place un certain nombre de fonction-
nalites communes aux deux logiciels qui sont :
Module dapprentissage de mouvement : ce module permettra
lacquisition de mouvements en 2D ou en 3D ainsi que leur sauvegarde
dans loptique de leur reconnaissance au sein des logiciels.
Gestion de prols utilisateurs : il devra etre possible de creer et
basculer entre dierents prols utilisateurs associant ` a chaque action
un mouvement personnalise.
18
Gestion du curseur : il sera necessaire de prendre en charge la camera
infrarouge de la Wiimote an de gerer le deplacement du curseur ` a
lecran (Voir Figure 7).
Fig. 7 Gestion du curseur souris via la camera infrarouge
Stockage des mouvement : notre module dapprentissage devra gerer
lenregistrement des donnees de chaque mouvement pour son stockage
dans le syst`eme de gestion de prols utilisateurs an de permettre la
reconnaissance dudit geste par les logiciels naux.
Gestion de plusieurs Wiimotes : nous devons mettre en place une
identication stricte de chaque contr oleur associe ` a lordinateur de
mani`ere ` a empecher toute intervention dune autre Wiimote dans le
travail de lutilisateur.
Modularite de larchitecture du projet : comme explique ci-dessus
nous devrons nous assurer de la possibilite dutiliser un autre type de
contr oleur lors de la reconnaissance des gestes.
2 Besoins Non Fonctionnels
Il existe egalement de nombreux besoins non fonctionnels ` a satisfaire lors
de limplementation de notre projet. Ces besoins, implicites dans la demande
19
des clients, sont les suivants :
Instantaneite : linteractivite du logiciel et lutilisation de la Wi-
imote comme peripherique de contr ole et de pointage rendent necessaire
laspect temps reel de notre application, excluant ainsi tout algo-
rithme co uteux en temps.
Fiabilite : lapplication nale des clients etant destinee au milieu medical
implique une optimum abilite de nos modules.
Flexibilite : il est necessaire que notre application sadapte aux dierents
utilisateurs et `a leurs caracteristiques : gestes amples ou reduits, mou-
vements precis ou tremblements, ...
Ergonomie : la prise en main, tout comme lutilisation reguli`ere de
lapplication, doivent se faire de la mani`ere la plus simple, rapide, et la
moins fatigante possible.
20
Architecture du projet
1 Communications Bluetooth
La communication entre deux peripheriques Bluetooth est bien plus com-
plexe quune connexion laire. En eet, l`a o` u un peripherique comme une
souris se contente normalement dun driver et dune biblioth`eque specique
au materiel et au langage, le Bluetooth ajoute une pile (ou stack) qui va
se placer entre le driver et la biblioth`eque. Ainsi, an de faire communi-
quer une Wiimote avec un ordinateur, toute information va devoir transiter
par le dongle Bluetooth, etre geree par le driver puis par le stack et enn
par la biblioth`eque qui permettra lexploitation des donnees dans le langage
choisi.(Voir Figure 8)
La biblioth`eque BlueCove est donc utilisee comme point dentree des
donnees issues du Bluetooth et se charge de lancer les deux connexions
L2CAP necessaires respectivement ` a lenvoi et `a la reception de donnees.
Certaines classes de Bluecove sont alors implementees par Wiimote et Wi-
imoteStreamer qui vont pouvoir interpreter les donnees propres ` a la wiimote
et rendre moins bas niveau la communication avec ce peripherique.
On peux voir sur le schema la mention Wiigee qui correspond en fait ` a la
partie communication avec la Wiimote de WiiGee que nous avons decompose.
2 Controleurs
La gestion de multiples peripheriques dinterface utilisateur est une des
parties principales de notre projet. Il doit etre possible pour les clients de
rajouter aisement le support dun controleur `a son application gr ace ` a lar-
chitecture de nos realisations. Nous avons implemente le support de deux
contr oleurs : la Wiimote et la souris et nous allons detailler leur structure.
2.1 Souris
La classe controlMouseListener dediee ` a la souris ne presente pas de
veritable complexite. En eet, elle se contente, pour la plupart des actions, de
relayer linformation ` a partir des mouseListener habituels. Il faut cependant
remarquer la necessite, pour interfacer la souris avec le module de reconnais-
21
Fig. 8 Fonctionnement global de la communication Wiimote/Projet.
sance de gestes, dune conversion des coordonnees de celle-ci vers des donnees
dacceleration en 3 dimensions, tache accomplie par la classe abstraite Con-
troller2D que controlMouseListener etends. Le reste des operations tiens
principalement du mappage de boutons ou de la conversion de coordonnees
de pointeur.
2.2 Wiimote
La classe controlWiimoteListener dediee ` a la Wiimote est, elle, beaucoup
plus complexe. En eet, lutilisateur habitue au peripherique repandu quest
la souris va dinstinct chercher ` a retrouver les sensations de cette derni`ere
dans tout peripherique de contr ole utilisateur. Il a donc ete necessaire de
conserver la notion de pointeur, chose facilitee par les fonctions infrarouge
proposees par la manette. Il a donc sut de recuperer les coordonnees des
deux points observes par la camera IR de celle-ci an dobtenir un point
central que lon projette sur la sc`ene OpenGL.
De la meme mani`ere que pour la souris, le mappage des boutons en des
identiants standardises par notre classe ControlListener est eectue lors des
dierents appuis et relachements an de de proceder au transfert des events
22
recus vers les listeners existants. La reconnaissance des gestes re coit quand
` a elle les donnees directement issues des accelerom`etres.
3 Listeners et Events
Comme nous avons pu le voir, la gestion des Controleurs passe principale-
ment par un syst`eme de listeners et events que nous avons decide detendre ` a
tout notre projet. Notre architecture va donc avoir pour r ole de retransmet-
tre, en les ayant uniformises, les events des dierents peripheriques jusqu`a
notre application nale (Wii2D ou Wii3D dans notre cas).
Fig. 9 Structure des Listeners et Events
3.1 Interface materielle
Comme on peux le voir sur la Figure 9 la communication avec le materiel
seectue via des classes heritees de linterface ControllerListener (par exem-
ple ControlWiimoteListener ou ControlMouseListener) qui implementent un
certain nombre de constructeurs speciques au peripherique dont ils vont re-
cevoir les events. Ces derniers, faisant echo des changements de coordonnees,
daccelerations ou dappuis sur les boutons, vont etre traites par la classe
23
de type ControllerListener puis renvoyes, pour les appuis de boutons et
levolution des coordonnees, au logiciel nal sous la forme de ControlEvent,
et, pour les accelerations et lors de lappui sur le bouton dedie ` a la reconnais-
sance de gestes ou lors du relachement dun bouton, au module GestureRec-
ognizer sous la forme de ControlAccelerationEvent pour leur interpretation.
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 `a lacquisition des donnees
dacceleration et ` a leur stockage tandis que gestureEnd se charge de lancer la
reconnaissance du mouvement `a partir des donnees enregistrees et de trans-
mettre un GestureEvent correspondant au geste reconnu (ou ` a GestureLis-
tener.GESTURE NONE en cas dechec), ` a destination du programme nal.
3.3 Programme nal
Le programme nal implemente les interfaces ControllerListener et Ges-
tureListener et va donc traiter les ControlEvent et GestureEvent quil recoit
en y associant les actions souhaitees.
24
Travail Realise et Probl`emes
Rencontres
1 Travail preliminaire
Notre travail a dans un premier temps consiste `a tester la capacite de
la Wiimote `a etre connectee ` a un ordinateur. En eet, malgre les videos de
demonstration de plusieurs individus, la compatibilite avec limplementation
dune application java netais aucunement garantie, lensemble des develop-
pements et tests etant eectues par des amateurs sans documentation sur le
materiel.
Nous avons choisi dans un premier temps une conguration Ubuntu et un
dongle Bluetooth nous appartenant, le choix de travailler sur les machines
du CREMI nous paraissant le plus judicieux. Plusieurs probl`emes se sont
alors poses : malgre la possibilite de reconnaitre la Wiimote au moyen des
applications Bluetooth de Linux (Voir Annexe 1), un probl`eme de droits est
apparu ` a chaque tentative dappairage avec le peripherique. Le superviseur
du reseau nous ayant refuse ces autorisations supplementaires, nous avons
alors d u choisir de travailler sur nos propres machines.
Nous avons alors choisi dutiliser un environnement Windows Vista et
nous sommes heurtes au probl`eme du choix dun stack bluetooth. En eet,
contrairement `a Linux o` u seul BlueZ est utilise, il existe une multitude de
piles Bluetooth sous Windows. Quelques recherches et essais nous ont montre
que la biblioth`eque choisie pour nos developpements (Wiigee) ne pouvait
fonctionner quavec une pile de lediteur Widcomm (la Wiimote necessite
une double connexion de type L2CAP supportee par cette seul pile). Le
site de lediteur ne proposant actuellement pas le telechargement du logi-
ciel, nous avons d u nous lancer dans la recherche de versions telechargeables
en dautres emplacements. Plusieurs versions nous ont pose des probl`emes
de fonctionnalites lies ` a leur anciennete, dautres netaient pas compatibles
avec la Wiimote. Apr`es plusieurs dizaines de versions testees nous sommes
parvenus ` a trouver la version 5.0.1.801, fonctionnelle mais provoquant de
frequents freezes de notre syst`eme. Nous avons alors experimente la version
beta de Windows Seven qui a presente les memes symptomes puis les distri-
butions Debian et Ubuntu o` u nous avons pu constater lincompatibilite de la
pile BlueZ.
25
Nous avons enn installe Windows XP qui sest avere des plus stables
avec ce stack nous permettant de debuter le travail de programmation.
2 Interfacage et Utilisation des Controlleurs
Lors de la recherche dun stack compatible, les tentatives dutilisation
de la wiimote avec wiigee ont souleve un nouveau probl`eme. En eet, la
recuperation de toutes les donnees de la manette passe par lacc`es `a des
valeurs de PSM inferieures `a 0x1001, rendue impossible par la specication
JSR-82 (Voir Figure 10). Une recherche sur des forums utilisateurs et dans
la documentation de la biblioth`eque Bluecove, chargee de la gestion du Blue-
tooth en Java, nous a permis de decouvrir un param`etre permettant de
forcer cet acc`es. Il nous a alors sut dajouter un chier de param`etre blue-
cove.jsr82.psm minimum o contenant la valeur 1 ` a la racine de notre projet.
java.lang.IllegalArgumentException: PCM values restricted
by JAR82 to minimum 4097
Fig. 10 Erreur rencontree liee `a la specication JSR-82
Notre travail a ensuite porte principalement sur la comprehension du fonc-
tionnement de WiiGee et des communications Bluetooth avec la Wiimote.
Une etude des exemples de trames recues par lordinateur nous a permis par
la suite de modier WiiGee an, par exemple, de prendre en compte la taille
des points observes par la camera infrarouge. Nous avons choisi dexploiter
le mode Extended de linfrarouge qui presente une trame (Voir Figure 11)
contenant les coordonnees de 4 points de lumi`ere infrarouge reperes par la
camera et leurs tailles respectives.
Comme on peux le voir dans ce tableau, chaque repetition de ce schema
nous fournit les donnees dun des points. Les coordonnees X et Y sont di-
visees en deux parties (bits de 0-7 et bits 8-9 separes), encodees chacune sur
10 bits et la largeur du point, encodee sur 4 bits. Une simple manipulation
bit-a-bit au sein du code nous as permis simplement de rassembler les deux
parties de chaque coordonnee.
26
Fig. 11 Trame renvoyee par la Wiimote concernant sa camera Infrarouge
3 Mise en place du module de Reconnais-
sance de Gestes
Une fois la Wiimote interfacee, nous avons d u reechir ` a lintegration des
mecanismes dedies ` a la reconnaissance de gestes au sein de notre architec-
ture de mani`ere ` a pouvoir prendre en compte ` a la fois des peripheriques nous
fournissant des accelerations en 3 dimensions (la Wiimote par exemple) et
des peripheriques nous fournissant de simples coordonnees 2D (comme une
souris).
Nous avons decide dimplementer, `a destination de la classe Control-
MouseListener et de toute autre classe fonctionnant en deux dimensions
(tablette graphique par exemple), une classe abstraite Controller2D four-
nissant le necessaire ` a la conversion en temps reel des coordonnees en accelera-
tions ainsi exploitables par notre gestureRecognizer.
La reconnaissance de gestes recup`ere ainsi systematiquement en entree
trois accelerations x, y et z (la derni`ere etant `a 0 pour les peripheriques 2D)
et va retourner, ` a la n du geste, un identiant de geste reconnu ` a tous les lis-
teners enregistres. Lenvoi de donnees `a gestureRecognizer se fait uniquement
27
lors de lappui sur le bouton secondaire du contr oleur, ou, selon les crit`eres
xes lors de limplementation de la classe de ce dernier. La n de lappui
sur ce bouton, ou toute autre action choisie, envoie un event de n daction
` a gestureRecognizer qui lance alors lanalyse de lobjet de type gesture en-
registre au l des accelerations recues. En mode learning, declenche par le
logiciel nal, le mouvement est alors ajoute `a un gestureModel au lieu detre
analyse an dagrandir la base de gestes qui permettra la reconnaissance en
mode normal.
Etant donne notre choix de conserver la structure de reconnaissance de
gestes utilisee au sein de WiiGee, principalement en raison du temps perdu
` a la conguration materielle de la connexion Bluetooth, nous navons ren-
contre aucun probl`eme hormis de comprehension, au sein de cette partie du
developpement.
4 Modication du logiciel Wii2D
Les modications du logiciel Wii2D ont principalement porte sur deux
points : ladaptation du logiciel ` a notre architecture de contr oleurs et de
reconnaissance de gestes et lajout dun rendu graphique et dune interface
leg`ere reetant nos futures actions.
4.1 ControllerListener et gestureListener
Notre travail a dans un premier temps porte sur ladaptation du logiciel
fourni par les clients ` a notre syst`eme permettant linterfacage de plusieurs
peripheriques. Il a sut pour cel`a dimplementer le mod`ele ControllerLis-
tener, ajoutant les contr oleurs de peripherique en fonction des choix de lu-
tilisateur et de permettre ` a ce dernier de changer de controleur de mani`ere
simple et intuitive.
Sont donc eectue `a chaque changement de peripherique, la suppression
de tous les listeners courants, lajout dun listener de type ControllerListener
correspondant au choix de lutilisateur et celui dun GestureListener adapte
au materiel selectionne.
La gestion des ev`enements se fait au sein de lapplication de la meme
mani`ere que limplementation dun mouseListener classique.
28
4.2 Graphisme et fonctionnalites
Nous avons ensuite travaille sur le rendu graphique des actions, comme
demande par les clients, et sur lamelioration de linterface utilisateur. Aucun
dentre nous nayant jamais ete forme sur lutilisation dOpenGL, nous avons
du nous documenter sur chaque aspect de lapplication an den comprendre
le fonctionnement et de trouver des solutions adaptees `a nos developpements.
La biblioth`eque choisie par les clients, JOGL, nous a cependant pose
quelques ennuis. En eet, celle-ci netant pas standard, son installation et
son utilisation ont presente quelques erreurs que nous avons pu resoudre en
integrant directement au sein du projet, jogl.jar et gluegen-rt.jar.
Nous avons ensuite ete confrontes aux notions de gestion du contexte,
modication des axes et rep`eres ou creation de formes, chacune nous ayant
demande de nombreuses recherche et un apprentissage autodidacte.
Nous avons enn d u nous interesser ` a la realisation dun menu contextuel,
les clients souhaitant avoir la possibilite de choisir deectuer les actions ` a
laide du curseur ou `a laide de la reconnaissance dun geste. Nous etant, dans
un premier temps, penches sur lutilisation dun glutCreateMenu, le peu de
documentation et la quasi impossibilite de recycler le code de cette methode
nous ont encourage `a tenter de realiser un menu contextuel `a base de formes
et de textes. Lutilisation de gluBitmapString nous permettant de generer
un bitmap `a partir de texte puis de linserer dans le contexte OpenGL, nous
avont pu mener `a bien cette t ache.
La mise en place de la reconnaissance de gestes implique bien entendu
un certain rendu graphique des dierentes commandes souhaitees par les
clients. En eet, il ne nous est pas demande de gerer chacune des actions
mais uniquement de prevoir leur execution. Nous avons donc choisi des eets
simples rendant bien compte des dierentes operations `a eectuer sur limage.
5 Modication du logiciel Wii3D
5.1 ControllerListener et gestureListener
De meme que pour Wii2D, Wii3D permet lutilisation dautres types de
peripheriques que la souris et le clavier. Nous pouvons interagir avec lobjet
3D (en loccurence une sph`ere) et eectuer des operations de bases decrites
29
par les clients. Nous navons pas trouve necessaire deectuer de reconnais-
sance de mouvements sur ce logiciel, car une precision certaine est recom-
mandee pour le bon rendu des actions implementees.
5.2 Graphisme et fonctionnalites
Wii3D sest vu dote de nouvelles fonctionnalites disposant ainsi dun
rendu visuel pour satisfaire les attentes des clients. Ces fonctions sont la
coupe et lextrusion. Etant donne que la realisation de ces fonctions ne con-
stitue pas lobjectif du projet et notre manque dexperience en OpenGL,
nous avons donc cree des fonctions simples permettant de visualiser lin-
teraction entre lutilisateur et lapplication. Nous avons cependant essaye
dameliorer nos rendus, notemment en voulant avoir une vraie acquisition
des coordonnees 3D en passant par la fonction Convert2D3D, dont la ma-
nipulation sest avere trop dicile. En eet, celle-ci propose de retourner un
vecteur 3D en prenant en parametre une abscisse et une ordonnee, seulement
linuence des contextes nous a bloque.
30
Installation et Fonctionnement
Notre projet impliquant un peripherique peu commun, la Wiimote, il
est sujet ` a un grand nombre de disfonctionnements tant au niveau materiel
quau niveau logiciel. Nous allons donner ci-dessous des instructions an de
proceder ` a linstallation dun environnement de travail et/ou dutilisation.
1 Installation et Materiel
Nous avons d u, lors des tests preliminaires, faire de nombreux essais an
de trouver un environnement de travail fonctionnel. Notre choix sest nale-
ment porte sur le syst`eme dexploitation Windows XP, seul ` a presenter une
certaine stabilite face `a la contrainte logicielle du Bluetooth (stack), les ver-
sions Vista et Seven de Windows ainsi que Debian et Ubuntu presentant des
probl`emes de stabilite ou de parametrage materiel (incompatibilite du stack
ou probl`emes de communication materiel/logiciel).
1.1 Materiel et drivers
An de pouvoir utiliser la Wiimote, il est necessaire de proceder ` a linstal-
lation dun stack, ou pile logicielle Bluetooth, qui se chargera des fonctions de
connexion et de communication entre peripheriques et recepteur. Notre choix
sest porte sur la version 5.0.1.801 du stack Widcomm associe `a un dongle
USB Bluetooth Sitecom CN-502. La compatibilite stack/dongle etant rela-
tivement chaotique, dautres mod`eles de clefs Bluetooth peuvent cependant
fonctionner. Il est important de noter quil est parfois necessaire de remplacer
dans le Gestionnaire de Peripheriques, le driver installe automatiquement par
Windows lors du branchement de la clef par celui fourni en meme temps que
le stack.
1.2 Interface graphique
An de faire fonctionner les logiciels des clients il est necessaire dinstaller
la biblioth`eque OpenGL choisie par ce dernier. Nous avons donc ajoute la
version 1.1.2 pour Windows x86 de JOGL au sein de lenvironnement de
developpement de notre IDE.
31
2 Utilisation du logiciel
2.1 Interface de Wii2D/Wii3D
Les interfaces des logiciels des clients presentent une sc`ene sur laquelle
se trouvent les objets `a manipuler (vignettes pour Wii2D ou sph`ere pour
WIi3D). Un menu present en haut de la fenetre permet de parametrer, ` a la
souris, plusieurs des composants de notre projet.
Le menu Prole propose trois fonctionnalites liees aux prols de gestes :
New, Open et Save qui permettent respectivement de creer un nouveau pro-
l, ouvrir un chier de prol et sauvegarder le prol courant sous un chier.
Les gestes etant speciques `a un individu, il permet donc ` a plusieurs usagers
dutiliser lapplication selon ses preferences.
Le menu Gesture permet de lancer, via Learning, lajout ou le remplace-
ment du geste correspondant ` a une fonctionnalite dans le prol courant.
Le menu Devices propose de choisir le contr oleur actuellement active au
sein de lapplication. Lors de la premi`ere selection du controleur Wiimote, la
procedure dappairage est lancee et des instructions detaillees sont fournies ` a
lecran. Une erreur dactivation de la Wiimote necessite le retour `a un autre
contr oleur avant une nouvelle tentative et il nest possible dutiliser quun
seul contr oleur ` a la fois.
2.2 Utilisation des peripheriques
Lutilisation des peripheriques 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.
Lappui sur le bouton principal dun peripherique correspond au clic
habituel dune souris. Il est donc possible de realiser une selection par un
simple clic ou de selectionner plusieurs vignettes par un rectangle de selection
dans Wii2D ou bien de deplacer la camera autours de la sph`ere par un cliquer-
deplacer sous Wii3D.
Lappui sur le bouton secondaire est lui dedie `a la reconnaissance de geste.
Il sut alors dappuyer et de maintenir le bouton pendant la realisation du
32
geste pour ensuite le relacher et que celui-ci soit reconnu (ou enregistre en
mode Apprentissage).
Pour les peripheriques possedant plus de boutons, dautres fonctionnalites
sont disponibles, il sagit de celles presentes dans la barre de menu en haut
des applications. Pour la Wiimote, par exemple, le bouton (-) va lancer len-
registrement du prol courant, le bouton (+) va lancer le chargement dun
chier de prol et le bouton (1) lancer linterface dapprentissage dun geste.
On notera que lutilisation de la Wiimote necessite une sensor-bar placee
au bord dun ecran ou dun meuble et un eloignement de quelques m`etres
de celle-ci pour assurer le bon fonctionnement du capteur infrarouge de la
manette. Il sera alors possible de deplacer le curseur dans la sc`ene de lappli-
cation en dirigeant la Wiimote vers lecran.
2.3 Interface dapprentissage
Linterface dapprentissage permet lajout dun geste au prol courant et
son association avec une fonction disponible au sein de lapplication nale.
La fenetre ouverte presente des instructions detaillees invitant lutilisateur ` a
repeter le geste desire un certain nombre de fois (10 par defaut) et linvite
ensuite `a choisir la fonction associee.
33
Denition et Realisation des
tests
Dans le cadre de notre projet, la realisation de tests est quelque peu par-
ticuli`ere. En eet, bien quil nous soit possible de tester une serie de valeurs
pre-enregistrees, la bonne execution ne nous donnerais aucune indication con-
cernant le bon fonctionnement de notre application : notre programme a pour
but de reconnaitre les gestes humains dans leur diversite et doit donc, pour
ses tests, passer entre les mains dindividus reels.
Nous allons donc tenter de decrire quelques procedures visant `a tester les
fonctionnalites de notre application et la bonne prise en main de celle-ci par
lutilisateur.
1 Test de la fonction Curseur
et du deplacement
Comme prevu lors de letude des besoins, la souris et la wiimote, peripheri-
ques choisis pour notre developpement, doivent permettre de contr oler un
curseur sur la sc`ene OpenGL de lapplication des clients. On peux con-
siderer le test comme intuitif pour la souris mais il necessite, pour la wiimote,
quelques precisions.
Il est necessaire dans un premier temps de proceder ` a lactivation et ` a
lappairage de la wiimote avec le PC. Pour cel` a, lutilisateur doit activer la
fonction Wiimote du menu Controllers, puis suivre les instructions an de
proceder `a lassociation de la manette. D`es la n de cette procedure, il est
possible pour lutilisateur dorienter sa wiimote vers lemetteur infrarouge
et de contr oler le curseur en deplacant le peripherique. Il est cependant
necessaire, en raison de contraintes techniques, de seloigner de quelques
m`etres de lemetteur an dobtenir une utilisation uide.
En cliquant sur une vignette avec la touche principale du controleur,
lutilisateur peut ainsi deplacer le carre de couleur et le relacher o` u il le
souhaite.
34
Fig. 12 Screen de lapplication Wii2D : Exemple de deplacement de vi-
gnette
2 Test des logiciels
Le but de notre projet etant linteraction entre dierents controleurs et
une application, il est normale de presenter dans cette partie, des tests qui
mettent en evidence cette interaction. Par le biais des fonctions implementees
au sein des logiciels 2D/3D, nous disposons dun rendu visuel
Fonctions basiques :
Nous avons developpe, au sein des dierents logiciels fournis par les
clients, des fonctions permettant dinteragir directement avec les objets
presents sur la sc`ene. Ainsi, nous avons implemente des actions telles
que lajout, la suppression, la fusion, la negation, etc. Par exemple la
suppression dimages seectue en plusieurs etapes : dans un premier
temps, il sagit de selectionner ` a laide de la Wiimote (appui bref sur
le bouton (A) au dessus dune image ou maintient du bouton (A) pour
utiliser le rectangle de selection) les images desirees. Linstruction de
suppression est ensuite donnee par la reconnaissance de gestes, il faut
donc appuyer sur le bouton (B) et dessiner une croix (voir gure 14).
35
Fig. 13 Screen de lapplication Wii2D : Exemple dajout de vignettes
Fig. 14 Screen de lapplication Wii2D : Exemple de suppression de vi-
gnettes
36
Apprentissage dun mouvement et reconnaissance :
Le point crucial de ce projet est linteraction avec nimporte quel periphe-
rique et notamment la reconnaissance de geste. An deectuer cette
derni`ere, il est avant tout necessaire de proceder ` a lenregistrement dun
geste, fonctionnalite qui devient alors forcement lobjet dun test par
sa place centrale au sein de larchitecture. Ce test prouve le bon fonc-
Fig. 15 Screen de lapplication Wii2D : Exemple de reconnaissance de geste
tionnement du module dapprentissage de mouvements et la possibilite
de denir facilement des prols de mouvements `a utiliser au sein des
logiciels.
37
Ameliorations et reutilisations
possibles
Nous avons tente lors de la realisation de notre projet de respecter des
principes de programmation orant la possibilite de reutiliser aisement notre
code dans dautre applications. Nous avons egalement pu remarquer de nou-
velles voies de developpement qui permettraient lamelioration ou lajout de
fonctionnalites mais qui, faute de temps ou dinteret pour les clients, nont pas
ete implementees. Nous allons vous exposer quelques unes des ameliorations
ou reutilisations possibles.
Ameliorations
Amelioration de la classe ControlMouseListener : Nous nous
sommes contentes lors de lelaboration de ce module de traiter les
donnees dune souris basique (`a trois boutons). Il est cependant `a noter
que lon trouve de plus en plus de souris possedant de multiples boutons
quil serait interessant dexploiter. La diversite des congurations et lu-
tilisation repandue de drivers proprietaires fait quil sera necessaire de
traiter le materiel au cas par cas.
Creation de nouvelles classes de peripheriques : Etant donne
que notre implementation permet, en theorie, lutilisation de nimporte
quel peripherique dinterface utilisateur (HID), lamelioration de notre
application passe par la creation de nouveaux modules speciques ` a
chaque type de materiel existant (tablette graphique, gant, etc).
Amelioration de la prise en charge des controleurs : Lors de
la mise en place de notre architecture de contr oleurs, nous avons ete
confrontes ` a plusieurs choix dimplementations et avons decide de ne
repondre quaux besoins des clients. Cependant, il aurait ete possible
dameliorer le syst`eme en proposant par exemple la possibilite dutiliser
plusieurs controleurs ` a la fois (risque de conits lors de lutilisation) ou
de permettre lajout `a la volee dune nouvelle classe de peripherique.
Il serait aussi interessant de proposer pour chaque contr oleur un en-
semble de donnees de reconnaissance de gestes par defaut.
38
Amelioration de linterface utilisateur : La plus grande partie
de notre travail a porte sur des soucis dordre materiel ou lies `a la
realisation de notre architecture de projet, delaissant ainsi quelque peu
laspect graphique de lapplication. Un travail visuel ou lie ` a lergonomie
de notre interface pourra donc faire partie des points damelioration,
avec par exemple une interface plus intuitive pour lassociation dune
Wiimote, ou encore des menus au sein de la sc`ene OpenGL.
Ajout dune interface de conguration : La majorite des parame-
trages de notre appplication se font actuellement par la modication de
variables globales au sein des dierentes classes. Lintroduction dune
interface permettant la conguration des param`etres principaux de nos
modules serait donc une amelioration possible (modication du nombre
de repetitions pour lacquisition dun geste ou encore choix des boutons
associes aux actions).
Reutilisations
Utilisation dans une autre application : Les modules de notre
projet sont implementes de mani`ere ` a pouvoir etre integres ` a nimporte
quelle application tirant habituellement parti de la souris. La simple
implementation de nos ControlListener et GestureListener au sein dun
programme permet ainsi dy inclure la reconnaissance de gestes et le
support de plusieurs types de controleurs.
Mise en place au niveau de lOS : Il serait possible de realiser une
couche applicative an de fournir des fonctionnalites avancees concer-
nant les peripheriques dinterface utilisateur au sein du syst`eme dex-
ploitation (reconnaissance de gestes ou utilisation de boutons supplemen-
taire par exemple) en se basant sur le code de notre projet.
39
Conclusion
Le travail que nous avons eu `a fournir lors de ce projet de PDP nous a
procure de nombreux enseignement au niveau de la tenue dun projet, de la
communication avec un client, du travail en equipe mais aussi en program-
mation en nous permettant de manipuler de nouvelles notions et fonctions.
Nous avons du travailler `a la lisibilite de notre code et en consequent, ` a sa
maintenabilite ce qui nous a dans le meme temps permis de mieux nous ap-
proprier le code, autorisant chacun des membres du groupe ` a comprendre
lensemble des processus mis en jeu.
Le sujet particuli`erement interessant nous a permis de travailler sur un ob-
jet assez mysterieux au premier abord et den decouvrir la majorite des secrets
de fonctionnement et nous esperons tomber sur des projets aussi interessants
lors de notre entree dans la vie professionnelle.
40
Bibliographie
Commentaire
Le document [1] est le site ociel de la biblioth`eque Java JOGL, qui per-
met lutilisation de lOpenGL.
Le document [2] est un site fournis par les clients presentant une multi-
tude de tutoriels pour lOpenGL. Contient des codes sources commente dans
dierents langages dont JOGL qui est utilise dans notre projet. Il presente
aussi des exemples dutilisation des fonctions glut.
Le document [3] presente une librairie Java permettant la reconaissance
de mouvements par lintermediaire de la Wii Mote. Ce site comprend un tu-
toriel pour ajouter la librairie `a un projet, quelques explications au niveau
de la reconnaissance de mouvements ainsi quune JavaDoc de la librairie.
Le document [4] est un livre qui est la reference en mati`ere de programma-
tion OpenGL en langage C. Complement aux tutoriels de NeHe, de nombreux
exemples de code sont disponibles.
Le documents [5] est un rapport de recherche presentant une etude ori-
entee utilisateur dont le but est de tester les interactions 3D. Cette approche
sappuie sur un prototype leger et facilement extensible constitue principale-
ment dun gant comme peripherique 3D. De plus, le rapport evoque egalement
lajout dun deuxi`eme peripherique tel quune WiiMote pour la facilite de
contr ole de lapplication.
Le document [6] est un wiki contenant les bases de compehension des
accelerometres de la Wii Mote. Il contient egalement dierents drivers qui
sont fonctionnels, ecrit dans des langages varies. Ce site nous servira princi-
palement pour les drivers puisque quil en propose une assez grande selection.
Nous devrons choisir celui qui correspond le mieux aux objectifs de notre pro-
jet.
Le documents [7] est une th`ese sur la detection, suivi et reconnaissance
des formes et du mouvement par mod`eles probabilistes dapparence.
Le documents [8] est un article qui explique les experiences menees par
des chercheurs de luniversite de Oldenburg sur la reconnaissance de mouve-
41
ments par lintermediaire daccelerometres. Lanalyse est faites de plusieurs
etapes qui sont detaillees (notemment au niveau de la lacquisition des mou-
vements eectues par la Wii Mote) ainsi que la methode de ltrage de mouve-
ment utilisee. Les chercheurs indiquent aussi les resultats obtenus avec leurs
methodes au niveau de la bonne identication des mouvements eectues.
References
[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 pro-
gramming guide - sixth edition/the redbook. 2007. version HTML :
http ://www.glprogramming.com/red/.
[5] Philippe Renevier Anne-Marie Pinna-Dery1 Julien Soula Michel Riveill
Diane Lingrand, Sebastien Meunier. Gestaction 3d : combiner commandes
gestuelles et interactions 3d. In Rapport de recherche isrn, Novembre
2006.
[6] Benjamin Poppinga and Thomas Schlomer. Wiigee : www.wiigee.org.
2008.
[7] Fabrice Heitz Rouf Hamdan. Detection, suivi et reconnaissance des
formes et du mouvement par mod`eles probabilistes dapparence. PhD the-
sis, Strasbourg I, 2001.
[8] Niels Henze Susanne Boll Thomas Schl omer, Benjamin Poppinga. Ges-
ture recognition with a wii controller. In Proceedings of the 2nd Interna-
tional Conference on Tangible and Embedded Interaction, February 2008.
42
Annexes
43