SimpsonsMM

Projet dans le cadre du cours MMI
SimpsonsMM
Simpsons multimodal arcade-game
Rapport
Baudin Sébastien
Maillard Martin
Price Oliver
Département :
Technologie de l’Information et de la Communication
Filière :
Informatique
Mot-clé :
MMI, multimodale, voix, geste, wiimote, sphinx
Date :
Février 2010 – avril 2010
Sommaire
Introduction ....................................................................................................................................... 3
Le projet ............................................................................................................................................... 3
Matériel employé .............................................................................................................................. 5
Modalités ............................................................................................................................................. 6
Geste ....................................................................................................................................................... 6
Voix .......................................................................................................................................................... 6
Choix de conception ......................................................................................................................... 7
Langage et environnement de développement ...................................................................................... 7
MVC simplifié .......................................................................................................................................... 7
Choix du vocabulaire ............................................................................................................................... 7
Librairies utilisées ........................................................................................................................... 7
Wiimote ................................................................................................................................................... 7
Intégration de motej dans notre projet ............................................................................................... 8
Reconnaissance vocale .......................................................................................................................... 10
Intégration de sphinx dans notre projet ............................................................................................ 10
Son ......................................................................................................................................................... 12
Conclusion ........................................................................................................................................ 12
Introduction
Dans le cadre du cours MMI, nous avons du développer un logiciel multimodale. Notre premier choix
s’était porté sur une application de dessin, mais un autre groupe avait un projet similaire. Vu que
nous avions déjà commencé à développer notre application, nous avons choisi un autre projet avec
les mêmes modalités, les gestes et la voix.
Le projet
Notre projet est un jeu d’arcade, l’objectif est de tuer le plus possible d’Homer (personnage
mythique des Simpson) et de Raptorjesus sans qu’un seul puisse manger le Donut. Notre Donut se
déplace tout le temps, il est possible de changer sa direction à tout moment. A chaque Homer ou
Raptorjesus tué, notre score s’améliore (1 point par Homer et 5 par Raptorjesus). La vitesse du jeu
augmente par tranche de 10 points obtenus (modifiable via une constante) jusqu’à ce que le donut
se fasse manger.
Ci-dessous l’écran de démarrage qui nous fait patienter jusqu’au moment où la Wiimote et la
reconnaissance vocale sont détectées et enclenchées.
Ci-dessous l’image que nous avons lorsque nous jouons.
Les personnages sont :
Donut
Homer
Raptorjesus
Le donut est en perpétuel mouvement et sa direction peut être modifier par la voix (ou le clavier).
Les homer et raptorjesus apparaissent des 4 côtés de l’écran et se déplacent aléatoirement, mais
ayant un certain pourcentage de chance de se diriger dans la direction du donut. Par défaut, les
homer se dirigeront 25% du temps en direction du donut et les raptorjesus 75% du temps (ceci est
bien sûr modifiable via des constantes).
Matériel employé
Wiimote plus, muni d’une caméra qui détecte des points infrarouge et possède quelques boutons
utilisés par notre application.
Wiibar (on a couvert une partie de la barre pour ne pas avoir plusieurs points affichés à l’écran), qui
permet à la wiimote de détecter le mouvement que l’on fait avec celle-ci.
Headset de la marque Plantronics, utilisé pour pour les déplacements et quitter/démarrer notre
application.
Modalités
Geste
Pour détecter les mouvements nous avons employé une Wiimote, la célèbre manette de Nintendo.
Sur la manette nous avons employé le pointage, grâce à la Wiibar, ainsi que les boutons B, + et -.
Cela nous permet d’éliminer, en appuyant sur B, les Homer et les Raportjesus afin de survivre le plus
longtemps possible dans ce monde de brutes.
Les boutons + et – permettent d’accélérer ou de ralentir le jeu.
La wiimote est équipée d’une caméra infrarouge qui permet de détecter des sources de lumière
infrarouge. Dans notre cas, notre source de lumière infrarouge est la Wiibar. Celle-ci est équipée de
10 émetteurs infrarouges, légèrement courbés vers l’intérieur, ce qui permet de détecter un seul
point (d’une bonne intensité) à plusieurs mètres. Vu que nous avons développé notre application
pour pouvoir y jouer sur notre ordinateur (donc à une distance de 20-50 cm), nous avons réduit le
nombre d’émetteurs infrarouges afin de ne pas détecter de multiples points.
Voix
Nous avons choisi la voix comme deuxième modalité parce que c’est celle qui nous paraissait le plus
naturel pour les besoins que nous avions dans l’application de départ, à savoir le programme de
dessin. Elle était originellement destinée à choisir les formes/couleurs/etc. du panel d’outils du
logiciel.
Lors du changement d’application, nous avons décidé de garder la voix et de l’utiliser pour diriger le
« donut », ainsi que pour quelques commandes comme le lancement d’une nouvelle partie ou la
fermeture du jeu.
Durant le développement, nous avons remarqué que la librairie de reconnaissance vocale
« Sphinx4 », en plus de donner des résultats assez peu précis pour les commandes courtes (un mot
de peu de syllabes, comme « left », « up », …), entraîne un délai très long entre le moment où le mot
est prononcé, et celui ou il est reconnu par la machine. Cela ne pose aucun problème dans le cas des
commandes pour recommencer ou quitter le jeu, mais en devient un gros lorsqu’il s’agit de diriger le
« donut » en temps réel afin d’éviter les « homer ».
Nous avons tout de même implémenté ces fonctionnalités, mais en l’état actuel des choses, il est très
difficile de jouer une partie avec la voix. Pour palier à ce problème, nous avons implémenté une
version clavier pour pouvoir déplacer le donut (à l’aide des touches w,a,s,d). La façon idéale d’emploi
de notre application est d’utiliser la wiimote pour cibler/tirer sur les ennemis, de bouger le donut
avec le clavier et de démarrer/quitter le jeu avec la voix.
Choix de conception
Langage et environnement de développement
Nous avons développé avec Eclipse en Java. Nous avons choisi ce langage car nous avons l’habitude
de travailler avec.
MVC simplifié
Notre projet ayant que très peu de données, nous n’avons pas représenté le côté « Model » du
modèle MVC. La partie vue s’occupe d’afficher le splashscreen (fenêtre de démarrage), l’interface
principale du jeu et la fenêtre du score final. En outre, elle s’occupe des actions lancées quand on
active les boutons « nouveau jeu » et « quitter l’application ».
La partie contrôleur s’occupe de la génération et déplacements des personnages et la détection des
collisions. De plus, il s’occupe de la gestion de la cible (efface le personnage si celui-ci a été touché).
Choix du vocabulaire
La voix intervient dans notre application dans 2 contextes assez différents : d’une part, nous
l’employons pour diriger le donut, ce qui doit être fait en temps réel et donc rapidement. De ce fait,
nous avons choisi d’employer une commande courte par direction (move up, move down, move left,
move right), pour une utilisation naturelle et réactive. D’autre part, nous employons la voix pour
démarrer un nouveau jeu et quitter l’application. Pour ces 2 actions, l’utilisateur a le temps
d’intéragir, car l’application restera dans son état actuel jusqu’à ce que l’utilisateur ait dit quelque
chose. Nous avons encore une fois deux mots par action (new game, quit game), mais il aurait été
possible, si besoin était, d’utiliser des commandes plus longues.
D’une manière générale, plus on a de mots pour une action, plus on aura une détection fiable. Dans
notre cas, nous ne pouvions pas faire de longues phrases pour déplacer le donut, vu le contexte
« temps réel » de ces actions. La conséquence de ceci est une détection très peu fiable par Sphinx, ce
qui nous a conduit à conclure que la voix n’est pas la meilleure modalité pour ce genre d’utilisation.
Librairies utilisées
Wiimote
La librairie utilisée est « motej 0.9 ».
Il s’agit d’une librairie de gestion de la communication entre un ordinateur et une Wiimote, écrite en
Java et distribuée sous license ASL 2.0 (license Apache).
Les fichiers nécessaires peuvent être trouvés à l’adresse suivante :
http://sourceforge.net/projects/motej/files/
Pour communiquer avec la Wiimote, il faut avoir un driver bluetooth installé sur son ordinateur. Du
côté de notre application, il faut ajouter quelques librairies au projet pour pouvoir communiquer
correctement avec le bluetooth. Celles-ci sont les suivantes :
-
bluecove 2.1.0 (http://sourceforge.net/projects/bluecove/files/) qui est une librairie java qui
permet d’interfacer plusieurs types de stack bluetooth
-
slf4j-api-1.5.11 et slf4j-simple-1.5.11 (http://www.slf4j.org/download.html) qui est employé
par bluecove
Voici la liste des fichiers jar nécessaires pour faire fonctionner la wiimote avec notre ordinateur :
L’illustration ci-dessous est issue de la documentation de Motej et indique où se place cette librairie
par rapport à notre application.
Multimodal Simpsons
Motej-extras-0.9.jar
Motej-library-0.9.jar
Bluecove-2.1.0.jar
slf4j-api-1.5.11.jar
slf4j-simple-1.5.11.jar
Intégration de motej dans notre projet
Au démarrage de notre application, nous affichons un spashscreen qui fait patienter l’utilisateur
pendant que l’application détecte la Wiimote et la reconnaissance vocale. Côté code, on instantie un
nouvel objet « Wiimote ».
Le constructeur de cet objet fait des appels à des méthodes permettant de détecter une wiimote via
bluetooth :
SimpleMoteFinder simpleMoteFinder = new SimpleMoteFinder();
mote = simpleMoteFinder.findMote();
Une fois la wiimote détectée, on lui assigne un IrCameraListener, qui permet de gérer les
événements générés par la caméra infrarouge de notre wiimote. A chaque fois que la wiimote bouge,
la méthode irImageChanged() est lancée et va mettre à jour la position de notre cible.
mote.addIrCameraListener(new IrCameraListener() {
public void irImageChanged(IrCameraEvent evt) {
game.setP0(evt.getIrPoint(0));
game.repaint();
}
});
De plus, on ajoute un coreButtonListener qui sera appelé quand l’utilisateur pèse sur un des boutons
de la wiimote. Pour notre application, nous détections le bouton « B » (gachette), les boutons « + »
et « - (vitesse du jeu) et le bouton « Home » (quitter l’application).
mote.addCoreButtonListener(new CoreButtonListener() {
public void buttonPressed(final CoreButtonEvent evt) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
if (evt.isButtonBPressed()){
ctrl.actionClick(new
Rectangle(Constante.MAX_WIDTH(int)((game.getP0().getX()/1024.0)*Constante.MAX_WIDTH
)+40,(int)((game.getP0().getY()/768)*Constante.MAX_HEI
GHT)+40,2,2));
}
if (evt.isButtonHomePressed()){
mote.disconnect();
System.exit(0);
}
if (evt.isButtonMinusPressed())
ctrl.addTime();
if (evt.isButtonPlusPressed())
ctrl.removeTime();
}
});
}
});
Pour déconnecter correctement la wiimote, il faut impérativement appeler la méthode
« disconnect() » (et pas seulement quitter l’application). Si ceci n’est pas fait, le stack bluetooth n’est
pas libéré correctement et génère une erreur qui, dans certains cas, nécessite le redémarrage de
l’application pour pouvoir reconnaître à nouveau la wiimote.
Finalement, la dernière ligne de code dans cette classe indique à la vue que la wiimote a été détectée
et est prête à être utiliser. Ceci pour effet de cacher le splashscreen et de démarrer le jeu (pour
autant que la reconnaissance vocale soit aussi prête).
view.wiiMoteReady();
Remarque :
Les coordonnées obtenues par le capteur infrarouge ne correspondent pas au point affiché à l’écran.
En effet, motej détecte des coordonnées à l’intérieur d’un rectangle de 1024*768, ayant le x=0 tout à
droite. Pour que ceci fonctionne correctement avec n’importe quelle résolution d’écran, on fait le
calcul suivant :
Coordonnée x : largeur de l’écran – (position x / 1024) * largeur de l’écran
Coordonnée y : (position y / 768) * hauteur de l’écran
A ceci s’ajoute 40 pixels, qui représente la moitié de la taille de notre cible (le but étant de générer
un petit rectangle au centre de la cible qui sera employé pour détecter s’il y a eu une collision avec
un ennemi).
Reconnaissance vocale
La librairie utilisée est « Sphinx 4 ».
Il s’agit d’une librairie de reconnaissance vocale entièrement écrite en Java.
Sa mise en place est relativement aisée. La marche à suivre est décrite à cette adresse :
http://cmusphinx.sourceforge.net/sphinx4/#download_and_install. Il suffit donc d’ajouter quelques
librairies au projet Java. Note : le package « src » de sphinx4 contient plusieurs applications démo
utiles pour la suite.
La documentation de sphinx4 conseille de se baser sur les démos présentes sur le site pour
l’utilisation de la librairie dans un projet. Il faut donc choisir la démo utilisant la reconnaissance
vocale de la manière la plus proche que dans le projet (commandes vocales, conversation continue,
longues phrases, etc.).
Intégration de sphinx dans notre projet
Deux classes sont chargées de l’utilisation de sphinx4 : VoiceInterface.java et VoiceCtrl.java.
Deux fichiers de configuration sont également nécessaires : commands.gram et sphinx.config.xml
VoiceInterface.java est un Thread, démarré au lancement de l’application, chargé d’écouter sur le
périphérique d’entrée de la machine. Lorsqu’un mot est entendu, il va lancer un algorithme de
reconnaissance vocale est tenter de faire correspondre le mot entendu avec un des mots contenu
dans commands.gram. Lorsqu’un mot de la grammaire est compris, il va appeler la méthode
« comand » de VoiceCtrl.java.
while (true) {
Result result = recognizer.recognize();
if (result != null) {
String resultText = result.getBestResultNoFiller();
if(!resultText.equals("")){
ctrl.command(resultText);
System.out.println("You said: " + resultText + '\n');
}
else{
System.out.println("I Can't recognize what you said.");
}
}
}
Code « d’écoute » de la classe VoiceInterface.java
Lorsqu’un mot est reconnu, il va appeler la méthode « command() » de VoiceCtrl.java
VoiceCtrl.java fait la correspondance entre les mots reçus et les commandes de l’application. Une
fois la correspondance faite, il appelle les méthodes du contrôleur de l’application, ou de l’interface.
Commands.gram contient la grammaire définie pour le programme. Il est rédigé dans une syntaxe
spécifique à sphinx permettant de définir un langage. Dans notre cas, le fichier est assez simple
puisqu’il contient uniquement une liste de commandes courtes :
grammar commands;
public <greet> = ( left | right | up | down | new game | quit game );
Extrait du fichier commands.gram
Sphinx.config.xml est le fichier de configuration de sphinx4. Comme conseillé dans la documentation
de la librairie, nous avons copié le fichier de configuration de la démo la plus ressemblante à notre
projet et l’avons modifié afin d’utiliser les bons fichiers de grammaire. Voilà les parties modifiées :
<!-- ******************************************************** -->
<!-- The Grammar configuration
-->
<!-- ******************************************************** -->
<component name="jsgfGrammar" type="edu.cmu.sphinx.jsgf.JSGFGrammar">
<property name="dictionary" value="dictionary"/>
<property name="grammarLocation" value="resource:/sphinxconf/"/>
<property name="grammarName" value="commands"/>
<property name="logMath" value="logMath"/>
</component>
<!-- ******************************************************** -->
<!-- The Dictionary configuration
-->
<!-- ******************************************************** -->
<component name="dictionary"
type="edu.cmu.sphinx.linguist.dictionary.FastDictionary">
<property name="dictionaryPath"
value="resource:/WSJ_8gau_13dCep_16k_40mel_130Hz_6800Hz/dict/cmudict.
0.6d"/>
<property name="fillerPath"
value="resource:/WSJ_8gau_13dCep_16k_40mel_130Hz_6800Hz/dict/fillerdi
ct"/>
<property name="addSilEndingPronunciation" value="false"/>
<property name="allowMissingWords" value="false"/>
<property name="unitManager" value="unitManager"/>
</component>
Extrait du fichier sphinx.config.xml
Note : Sphinx4 demande beaucoup de mémoire disponible dans la JVM. Pour pouvoir lancer le
projet, il faut utiliser l’option -Xms500M -Xmx500M , définissant des tailles minimale et maximale de
500Mo pour la JVM.
Son
La librairie utilisée pour jouer des MP3 est « JLayer 1.0.1 ». Voici le lien pour télécharger cette
librairie http://www.javazoom.net/javalayer/javalayer.html. Nous avons eu besoin de cette librairie
car de base Java ne peut lire les fichiers MP3.
Conclusion
Ce projet nous a permis de mettre en pratique ce qu’on a vu en théorie pendant les cours. L’aspect
multimodale nous a laissé une grande liberté quand au type d’application que nous allions réaliser,
ce que nous avons fortement apprécié.
Quand aux modalités utilisées, nous avons été surpris :


En bien, pour ce qui concerne la précision du détecteur infrarouge de la wiimote, ce qui nous
a permis de pouvoir jouer à notre jeu avec la wiimote avec la même aisance qu’avec la
souris.
En mal, pour ce qui concerne la reconnaissance vocale dans une application en temps réel
ainsi que la précision médiocre de la librairie Sphinx.
Si nous avions à refaire l’application, nous aurions certainement pas choisi la voix pour des actions de
déplacement, qui doivent être faites en temps réels.