Interfaces multimodales Mini-projet Pilotage Nao

Transcription

1 Interfaces multimodales Mini-projet Pilotage Nao Master of science in engineering, Semestre d été 2010 Groupe de projet Joël Dumoulin, Julien Jeanneret, Beat Wolf, Dominic Wyler 1/25

2 Table des matières 1 Introduction Contexte Objectifs Interaction Matériel utilisé Analyse Modalités utilisées Sortie Entrée Modèles CASE + CARE Modèle CASE : types de communication Modèle CARE : propriétés d utilisabilité Fusion et fission Fusion Fission Conception Approche Schéma Pilotage du robot Prise en main Choregraphe Webots Wiimote Guidage Retour utilisateur Reconnaissance vocale Pourquoi Sphinx Architecture Implémentation Module central : coordination et pilotage du robot Reconnaissance vocale Grammaire Application : NaoVocalCommander Résultats Reconnaissance de gestes Librairie Libwiimote Librairie Qt Application : Contrôleur Wiimote WiiBot Résultats Evaluation Méthode Sélection des utilisateurs /25

3 5.3 Analyse et interprétation Conclusion Résultats Améliorations Impressions Références /25

4 1 Introduction Contexte Ce mini projet s inscrit dans le cadre du cours «Interfaces multimodales» dans le cursus Master of Science in Engineering. Il a pour but de réaliser un système de petite envergure faisant intervenir plusieurs modalités, ainsi que de mettre en œuvre certains principes qui ont été traités dans la partie théorique du cours. 1.2 Objectifs L'idée de ce mini projet est de piloter le robot Nao à l'aide de deux Wiimotes. Il est possible de piloter le robot à distance, de lui faire faire des actions simples telles que déplacer des objets légers, presser des boutons. De cette manière, le robot servira pour atteindre et interagir avec des objets là où la présence humaine n est pas possible, par exemple un endroit contaminé par des gaz toxiques ou sur un terrain miné (vu la légèreté du robot, celui-ci devrait pouvoir y marcher sans provoquer d explosion). 1.3 Interaction L'utilisateur tient dans chacune de ses mains une Wiimote. Par reconnaissance vocale, il associe une Wiimote donnée à une partie du robot qui peut être articulée. Voici la liste des parties du corps du robot qui sont pilotées : - bras gauche - bras droit Les Wiimotes sont donc utilisées pour la reconnaissance des gestes de l'utilisateur, mais uniquement sur les axes verticaux et horizontaux. On utilise l inclinaison des manettes pour guider le robot, et non pas des gestes. Ceci permet une utilisation naturelle et surtout instantané. De plus, il est possible de faire se déplacer le robot à l aide des flèches directionnelles de la Wiimote (avancer, reculer, se tourner à gauche, se tourner à droite). Finalement, l utilisateur peut également effectuer des commandes vocales, afin de réaliser des actions simples : - Demander au robot de dire «oui» - Demander au robot de dire «non» - Demander au robot de danser 4/25

5 1.4 Matériel utilisé Un robot Nao Développé par Aldebaran Robotics [1]. Le robot sera piloté à distance par un ordinateur via Wifi. Deux Wiimotes Manette pour la console de jeux Wii de Nintendo. Contient des accéléromètres permettant de déterminer son inclinaison sur les trois axes dans l espace. Un microphone Utilisé pour la reconnaissance de la voix de l utilisateur pour effectuer certaines commandes. 2 Analyse 2.1 Modalités utilisées Cette section mentionne les différentes modalités qui sont utilisées dans le projet. La distinction est faite entre les modalités d entrée et de sortie, du point de vue de l être humain Sortie Modalité gestuelle: mouvements des Wiimotes L utilisateur effectue des mouvements avec les Wiimotes dans les mains pour contrôler les mouvements du robot. Modalité vocale: association d une Wiimote à un membre du robot et commandes d actions simples L utilisateur donne des commandes au système en parlant dans un microphone. Modalité actionnelle: boutons des Wiimotes En pressant les boutons directionnels des Wiimotes, l utilisateur peut faire tourner, avancer ou reculer le robot Entrée Modalité tactile: feedback Wiimote sélectionnée Lorsqu une manette Wiimote a été associée à un membre du robot, celle-ci vibre et donne ainsi un feedback sous forme de retour de force à l utilisateur pour lui indiquer clairement quelle manette a été associée 5/25

6 MMI Mini projet Semestre d'été Modèles CASE + CARE Modèle CASE : types de communication Notre système s inscrit dans la catégorie «Alterné» du modèle CASE. 1) nous utilisons la voix, les gestes et les boutons de manière alternée 2) la modalité vocale fait référence à la modalité gestuelle a. lors de l assignation par commande vocale d une Wiimote à un membre du robot Modèle CARE : propriétés d utilisabilité Ce projet se trouve dans le cas «Complémentaire» des propriétés d utilisabilité, pour les raisons suivantes : 1) aucune modalité, prise seule, ne permet d atteindre le but qui est de piloter le robot. Nous avons besoin de plusieurs modalités. 2) les modalités vocale, tactile et gestuelles doivent être utilisées séquentiellement dans le temps 2.3 Fusion et fission Fusion La fusion, dans notre système, s effectue au niveau de décision : nous fusionnons les informations de haut niveau provenant de la reconnaissance vocale (les mots reconnus), et les informations des boutons et mouvements de la Wiimote pour ensuite faire bouger le robot Fission Pour la fission, nous utilisons la modalité visuelle comme moyen d output pour l utilisateur. Lorsque l on donne une commande au robot, que ce soit par modalité tactile (boutons de la Wiimote), gestuelle (mouvements de la Wiimote) ou vocale, l utilisateur voit directement le robot effectuer les actions : il bouge ses membres, il se déplace, il dance, ou il fait «oui» ou «non» de la tête. 6/25

7 3 Conception 3.1 Approche Comme mentionné dans le chapitre précédent, notre système effectue une fusion des modalités au niveau de décision. Notre application contient un module central qui coordonne les informations transmises par les manettes Wiimotes et la reconnaissance vocale, et fait bouger le robot en conséquence. L application se découpe donc en trois grandes partie : le module central de coordination & pilotage du robot, un module de contrôle des Wiimotes et un module de reconnaissance vocale. Pour interagir, ces modules communiquent par envoi de messages UDP. Les messages envoyés contiennent le type de l action à effectuer (par exemple, bouger le bras droit du robot) et si nécessaire une valeur associée (angle auquel il faut bouger le bras en question). De ce fait, les modules peuvent être installés sur des ordinateurs différents. Le module central communique avec le robot par WiFi. L architecture de notre système est illustrée dans la Figure 1 de la section suivante. 7/25

8 3.2 Schéma Module central: coordination & pilotage Reconnaissance vocale Contrôleur Wiimote Figure 1: Architecture générale de l'application 8/25

9 3.3 Pilotage du robot Prise en main La version du robot Nao est , ce document ne concerne donc pas la nouvelle version 1.6.x. La documentation concernant cette version est disponible dans le répertoire doc de l'installation de NaoQI. Cette documentation offre une source importante d'information sur les modules disponibles (blue doc) mais aussi sur le robot (red doc). Afin de faciliter la correspondance entre ce document et la documentation de la partie rouge du robot, le nom des sections de ce document correspond à ceux de la documentation officielle. Robot software NaoQI est un framework et comprendre son fonctionnement est vital pour l utilisation du robot. Il offre la possibilité d'avoir un système multiplateforme et multi-langage (C++, Python, Urbi). Il permet d'exécuter les méthodes de manière parallèle (bouger la tête et le bras en même temps), séquentielle ou déclenché par un événement. Les appels des méthodes sont donc gérés par le framework qu'ils soient distants ou locaux. Le framework utilise des Brokers, c'est un exécutable qui écoute, sur une adresse et un port, les commandes qui doivent être exécutées. Il y a ensuite des modules qui sont des classes qui contiennent des fonctions qui agissent sur le robot (mouvement, synthèse vocale,...). Un module est toujours lié à un broker. Ensuite pour accéder à un module, un Proxy est utilisé, c'est donc un accès à un module. Si le broker sur lequel le robot est connecté crashe, le robot peut tomber et subir des dégâts, il est donc recommandé de déployer les modules créés dans un autre broker. La figure suivante montre l'architecture conseillée: 9/25

10 Le framework utilise aussi des smart pointers. Ces pointeurs ont l'avantage de ne pas avoir besoin d'être détruits. De plus, les méthodes du framework retournent toujours ce type de pointeur, mais il n'est pas nécessaire de les utiliser. Comme expliqué précédemment, le proxy permet donc d'accéder à un module. Il est possible d'obtenir un proxy, qui pointe sur un module qui peut être distant ou local, par le broker. Un broker peut retourner un proxy d'un module à condition d'être connecté au broker qui a effectivement déployé le module. Dans la figure précédente Module 1 est déployé dans le Main Broker et mymodule dans mybroker. Comme mybroker et Main Broker sont connectés (précisé avec les paramètres de la ligne de commande lors du lancement de mybroker) mymodule peut obtenir un proxy de Module 1 par mybroker. Il est toujours possible de connecter un proxy à un broker pas connecté en précisant l'adresse et le port lors de la création, ce qui est nécessaire si le broker n'est pas connecté au broker ayant déployé le module. Programmation Cette section explique comment créer un nouveau module en utilisant l'outil de ModuleGenerator. Tout est bien expliqué dans la documentation. Un aspect important lors de la génération d'un nouveau module est de savoir s'il est remote. Lorsqu'il est remote, le module sera un exécutable, qui a donc son propre broker. Il est conseillé de faire un module en remote, surtout au départ, car cela permet de pouvoir débugger le module et aussi cela réduit le risque que le robot tombe en cas de crash. L'outil utilise cmake pour la création du projet. Il est possible d'indiquer à cmake de générer un projet qui peut être ouvert avec l'environnement de développement de votre choix. L'utilisation de l'outil de génération de module permet de créer des projets qui fonctionnent rapidement et lors de la compilation du module, le résultat se trouve directement dans les bons dossiers. Autre Dans la red doc, beaucoup d'informations très utiles sont disponibles. Par exemple la partie Motion aide à comprendre comment il est possible de commander les mouvements du robot, ou la partie Audio system pour la partie audio. Suivant les besoins du programme du robot, consulter ces sections permet d'avoir rapidement un aperçu de la technique au lieu de lire la partie blue doc qui répertorie les méthodes de chaque module Choregraphe Choregraphe est un programme qui permet de contrôler un robot avec une interface graphique assez confortable. En interagissant avec le programme, on peut bouger les différentes parties articulables du robot. Ce qui est intéressant avec ce programme c'est qu'il est possible d'obtenir le code généré par une série de mouvements. Cela permet donc, pour la création de mouvements, d'avoir un aperçu graphique à disposition Webots Webots est un programme qui permet de simuler un robot. C'est très pratique de pouvoir simuler ce qui se passe avant de tester sur le robot, surtout que nous n'étions pas en possession du robot pour effectuer les tests. 10/25

11 Pour pouvoir communiquer avec le robot de simulation, il est nécessaire de lancer naoqi dans le dossier bin sur la machine auparavant et de configurer que les robots de la simulation sont en remote. Pour configurer ceci, il faut changer ce paramètre dans le fichier simulator.xml qui se trouve dans le dossier preferences. Le dossier bin et preferences sont dans le dossier qui vient de l'installation de NaoQI (normalement la variable d environnement AL_DIR pointe à cet endroit). Le robot webots1 doit avoir la valeur remote mise à on. Une fois ceci effectué et webots démarré, un proxy peut être établit sur les modules déployés par le naoqi. Attention : en simulation, tous les modules ne sont pas disponibles, celui du motion est disponible mais pas celui du audio system par exemple. 3.4 Wiimote Guidage Pour guider le robot, nous avons décidé d'utiliser les manettes de la console de jeux Wii de Nintendo. La wiimote contient des accéléromètres, qui nous permettent de savoir à tout moment l'inclinaison de la manette. Ceci nous permet de donner des commandes au robot pour mettre ces bras dans la même position que la personne qui tient les manettes. En plus, la manette nous permet d'utiliser des boutons pour tourner le robot à gauche et à droite, et de le faire avancer ou reculer Retour utilisateur Pour un feedback à l'utilisateur, les LEDs des manettes sont utilisées pour indiquer quelle manette est la première et laquelle est la deuxième, ce qui est important pour affecter une manette aux bras du robot. La fonction «force feedback» de la wiimote est utilisée pour indiquer à l'utilisateur que l'affectation de la manette a bien été effectuée. 3.5 Reconnaissance vocale Pourquoi Sphinx-4 Le robot Nao possède déjà une reconnaissance vocale intégrée, avec un micro placé sur le robot. Cependant, le robot peut se trouver dans un environnement bruité, et nous voulons pouvoir être en mesure de le piloter à distance. Pour cette raison, nous utiliserons un système de reconnaissance qui sera externe au robot, de manière à ce que l on puisse utiliser le système à distance dans un lieu isolé du bruit. 11/25

12 MMI Mini projet Semestre d'été 2010 La librairie Sphinx-4 a donc été retenue pour la réalisation de la reconnaissance vocale. Les raisons principales qui ont motivé ce choix sont les suivantes : - Librairie open-source - Ecrite en Java o Contrairement à d'autres librairies, le fait qu'elle soit écrite en Java permet de développer l'application sur Linux - Relative simplicité à mettre en place et à créer une application simple - Reconnaissance basée sur une grammaire, ce qui est totalement adapté à l'élaboration d'une application de commande vocale Architecture Cette section décrit l architecture du reconnaisseur vocal Sphinx-4. La Figure 2 ci-dessous donne la vue d ensemble du système avec les principales parties qui le constituent. De notre point de vue, l application que nous développerons est labelée «Application» dans le schéma ci-dessous et interagira avec le reconnaisseur avec les parties «Input»,«Control» et «Result». Figure 2: Architecture de Sphinx-4 Sphinx-4 a été développé pour être hautement flexible et modulaire. De cette manière, chaque module peut facilement être remplacé sans devoir modifier les autres parties du système. La structure interne est composée de 3 parties différentes : FrontEnd, Linguist et Decoder. 12/25

13 MMI Mini projet Semestre d'été 2010 FrontEnd Le but du FrontEnd est de paramètriser le signal d entrée (Input) et d en extraire une série de caractéristiques (Features). Comme illustré dans la Figure 3, le traitement effectué sur le signal d entré est composé d un ou de plusieurs DataProcessors qui peuvent être connectés en série pour en ressortir des caractéristiques utiles. Figure 3: Extraction de caractéristiques Typiquement, les caractéristiques qui sont extraites du son donné en entrée sont des «Mel- Frequency Cepstral Coefficients»(MFCCs). Linguist Cette partie génère un SearchGraph qui sera utilisé par le décodeur pendant la recherche des mots reconnus par le système. Typiquement, l implémentation de la partie Linguist se fait à l aide d un modèle de langage (LanguageModel) et d un modèle acoustique (AcousticModel). Un dictionnaire (Dictionary) est utilisé afin de mettre en correspondance les mots du modèle de langage en des suites d éléments du modèle acoustique. A. LanguageModel Le modèle de langage est décrit par un graphe. Deux variantes possibles sont des grammaires en graphe et les modèles stochastiques N-Grams. Dans la variante utilisant la grammaire, chaque mot est un nœud du graphe et possèdent des transitions vers d autres mots avec une certaine probabilité. Dans le cas du modèle stochastique N-Gram, le modèle donne une probabilité de détecter un mot en se basant sur l observation des n 1 mots précédant. B. Dictionary Le dictionnaire fournit la prononciation des mots qui se trouvent dans le modèle de langage. La prononciation est découpée en une séquence d unités définies par le modèle acoustique. C. AcousticModel Le modèle acoustique utilise les chaînes de Markov cachées (HMM : Hidden Markov Models) pour traiter une unité de parole et les caractéristiques (Features) correspondantes. Ainsi, le modèle acoustique permet de calculer un «score» aux Features provenant du FrontEnd. Le contexte et le positionnement peuvent être pris en compte. Par exemple, dans le cas des triphones, le contexte représente les phonèmes placés sur la droite et sur la gauche du phonème en question, et la position défini si le triphone se trouve en début, milieu ou fin de mot. 13/25

14 MMI Mini projet Semestre d'été 2010 D. SearchGraph Le SearchGraph est la principale structure utilisée pendant le processus de décodage pour la reconnaissance de mots. A titre d exemple, la Figure 4 ci-dessous montre le graphe de recherche pour la reconnaissance des mots «one» et «two», avec les phonèmes, les triphones et leur HMMs associés. Figure 4: Graphe de recherche pour les mots "one" et "two" Decoder Le Decoder utlise les Features données par le FrontEnd en entrée en conjonction avec le SearchGraph qui a été mis en place, pour fournir des hypothèses de résultat de reconnaissance (Result). A chaque étape du processus, le SearchManager crée un object Result pour chaque entrée qui a atteint un nœud final dans le SearchGraph Installation et création d une nouvelle application Concernant l installation de Sphinx-4 sur linux, le site web de Sphinx-4 [2] décrit toutes les étapes nécessaires. Une fois l environnement prêt à être utilisé, une nouvelle application peut être créé au sein de la structure de Sphinx-4 (par exemple dans le package «demo»). La librairie étant gérée par le moteur de production de compilation «ant», il faut rajouter les parties nécessaires dans les fichiers de configuration (xml) et dans le fichier «build.xml» afin qu «ant» puisse correctement compiler et générer le «jar» de notre application. Finalement, après avoir lancé le processus de build d «ant», notre application (fichier «jar») est créé dans le répertoire «bin». 14/25

15 4 Implémentation 4.1 Module central : coordination et pilotage du robot La partie centrale du programme s'occupe d'interagir avec le robot. Le programme est simple, dans une boucle principale il contrôle s'il a reçu un paquet de la partie vocale ou de la partie qui gère les wiimotes. Si c'est le cas, il consomme le message et fais le traitement nécessaire du message reçu. Le programme est simple car il n'y pas de problème de concurrence possible, tout est géré dans un thread. Pour l'échange de messages, une structure a été mise en place. Lors de chaque envoi, donc pour chaque réception aussi, deux entiers de 32 bits sont envoyés. Le premier indique la commande, et le second la valeur de la commande. Ces deux entiers sont tout le temps envoyés même si la commande n'a pas de valeur associée. Voici un tableau montrant les différentes valeurs ainsi que leur but et le sens de la communication: Commande Valeur Action Sens 1 {1 2} Assigne le bras gauche à la Vocal -> Central manette {1 2} 2 {1 2} Assigne le bras droit à la Vocal -> Central manette {1 2} 3 Ignoré Bouge la tête et dit "yes" Vocal -> Central 4 Ignoré Bouge la tête et dit "non" Vocal -> Central 5 Ignoré Danse Vocal -> Central 50 {1 2} Vibre la manette {1 2} Central -> Wii 51 Angle (en ) L'angle horizontal de la manette Wii -> Central 1 52 Angle (en ) L'angle horizontal de la manette Wii -> Central 2 53 Angle (en ) L'angle vertical de la manette 1 Wii -> Central 54 Angle (en ) L'angle vertical de la manette 2 Wii -> Central 90 Longueur (en dm), valeur Avance le robot de la longueur Wii -> Central négative représente l'arrière spécifiée 91 L'angle de rotation (en 30 Tourne le robot de l'angle Wii -> Central horaire), négatif tourne l'autre spécifié côté Pour la création du projet nous avons utilisé le Modulegenerator, dans le but de n avoir aucun souci sur les includes et d'avoir le programme qui s'installe directement dans le bon dossier après la compilation. Comme nous ne créons pas un nouveau module, nous ne faisons que d'en utiliser, la plupart du code a été supprimé. Lors de la création des proxys pour les mouvements et la synthèse vocale, nous précisons directement l'adresse IP du robot. 15/25

16 4.2 Reconnaissance vocale Grammaire Voici la grammaire réalisée pour notre application : #JSGF V1.0; /** * JSGF Grammar for nao commander program */ grammar nao; public <command> = <startpolite> (<cmdwii> <cmdhead> <cmddance> please) <endpolite>; public <cmdwii> = Link (One Two) With (Left Right) Arm; public <cmdhead> = Say (Yes No); public <cmddance> = Dance; <startpolite> = (please could you dear robot) *; <endpolite> = [ please thanks thank you for me ]; On remarque à quel point la syntaxe permet de facilement réaliser des commandes simples, voire également un peu plus abouties. En effet, la grammaire créée ci-dessus nous permet par exemple d'utiliser des formules de politesse pour commencer ou terminer une commande, mais cela n'est pas obligatoire. 16/25

17 Voici un graphe illustrant cette grammaire : 17/25

18 MMI Mini projet Semestre d'été Application : NaoVocalCommander Si dans l'idéal une application de reconnaissance vocale ne devrait pas avoir d'interface utilisateur, nous avons tout de même décidé d'en réaliser une. En effet, comme les commandes reconnues par Sphinx-4 ne sont pas toujours les bonnes, nous avons décidé de mettre en place une petite interface permettant à son utilisateur de visualiser lorsque la commande qu'il souhaite effectuer à été reconnue, ce qui lui permet de la valider, et ainsi transmettre au robot uniquement les bonnes commandes. Nous en avons également profité pour ajouter une vue permettant de configurer les paramètres réseaux (adresse IP et port du server), et également une vue de test, composée de bouton, qui permet de plus facilement tester les commandes sur le robot en cas d'extinction de voix! Ainsi, l'interface se compose de trois onglets : Figure 5 : Centre de commande Figure 6 : Options réseaux Figure 7 : Centre de test 18/25

19 L'interface indique si une commande vocale comprise est invalide. Si la commande est valide, elle est colorée en rouge, et est en attente de validation. Pour valider une commande, l'utilisateur doit prononcer la formule magique qui est simplement "please". L'interface indique alors que la commande a bien été validée et transmise au robot en la colorant en vert. L'affectation des mannettes aux bras du robot y est également mise à jour. Figure 8 : Commande invalide Figure 9 : Commande valide Figure 10 : Commande en attente de validation Figure 11 : Commande validée Résultats Les résultats au niveau de la reconnaissance vocale sont plutôt mitigés. Dans un environnement non bruité, en parlant proche du micro de manière bien distincte, les commandes sont dans la majorité des cas correctement interprétée. Malheureusement, il ne faut pas grand-chose pour qu'un "say yes" se transforme en "dance", alors même que phonétiquement la ressemblance entre ces deux commandes ne semble que très relative! Il est également à noter qu'un très bon accent anglais est requis, sans quoi les longues phrases telles "Dear robot could you please link one with right arm thank you" seront difficilement réalisables. 19/25

20 MMI Mini projet Semestre d'été Reconnaissance de gestes Librairie Libwiimote Pour communiquer avec la wiimote, nous utilisons la librairie libwiimote que l on peut télécharger à l'adresse suivante [3]. Libwiimote est une librarie C qui tourne sous linux. Elle est disponible sous la licence GPL, ce qui va très bien pour notre projet de recherche. La librarie nous permet d'accéder a toutes les fonctionnalités de la wiimote que nous avons besoin pour ce projet, et en plus elle est inclue dans la plus part des distributions linux actuelles, comme (K)ubuntu. La documentation n'est malheureusement pas très bonne, on pourrait dire inexistante et il faut lire les fichier headers pour utiliser la librairie, mais quand cette étape est passée, la libraire marche très bien Librairie Qt Pour l'implémentation de cette partie du projet, nous avons décidé d'utiliser la libraire Qt, qui est une librairie C++. Qt est développée par Nokia, et est utilisée par diverses applications très connues, comme Google Earth, Mathematica, Virtualbox, VLC, KDE et bien d'autres. La licence est du LGPL, et on peut donc aussi l utiliser pour des projets closed source, ce qui n'est pas le cas dans notre projet de recherche. La raison pour ceci est qu'on a du faire une communication en réseau, ce que Qt rend très facile, et une petite interface de control était aussi nécessaire pour développer l'application, ce que Qt rend aussi très facile à faire. L'intégration d'une librairie C dans du Code C++ était très facile et marchait sans problèmes, et aussi autrement, l'expérience de travailler avec Qt était très positive, aussi grâce au très bon IDE de Nokia qui permet de travailler avec Qt (mais aussi d'autres projets C/C++) Application : Contrôleur Wiimote WiiBot La tâche principale de l'application qui relie les wiimotes avec le reste du système, est de trouve l'angle horizontal, et vertical de la wiimote. La wiimote nous donne l'accélération des axes x,y, et z. Seul les axes x et y nous intéressent dans ce projet. L'accélération X représentant l'angle horizontal, et l'accélération Y l'angle vertical. Les valeurs d'accélération sont des valeurs entre 0 et 255. Ce qui est intéressant à savoir est que les valeurs minimales et maximales, pour les angles minimaux et maximaux de la wiimote, ne sont pas identiques entre deux wiimotes. Il faut donc calibrer les wiimotes avant de pouvoir les utiliser. Pour que ceci ne soit pas nécessaire à chaque fois qu'on utilise notre application, les valeurs minimales et maximales des deux axes ont été enregistrées pour chaque manette. 20/25

21 MMI Mini projet Semestre d'été 2010 Ensuite, chaque changement de 10 est envoyé par le réseau à travers un socket UDP à l'application contrôleur. Pour éviter qu'un tel changement soit envoyé trop souvent, par exemple si l'accélération se trouve juste sur le point entre 10 et 20 et qu'on voit donc tout le temps un changement entre ces deux angles, venant du fait que les accéléromètres ne sont pas parfaitement précis, et que la main de la personne qui navigue le robot n'est pas totalement stable, nous avons ajouté une condition, qu'après chaque changement d'angle, la wiimote doit bouger un minimum pour redéclancher un changement d'angle. Ceci a en effet évité des tremblements trop importants sur le robot. Il est aussi important de noter que nous nous intéressions pas aux gestes de la personne, mais que nous utilisons la position exacte de la wiimote et la transmettons au robot. Ceci a pour effet que la réaction est immédiate, et l'utilisation est très naturelle, car l'utilisateur a vraiment l'impression de bouger les bras du robot et non pas de juste le commander. Pour contrôler ce qui ce passe et pouvoir debugger l'application sans avoir besoin du robot, une interface utilisateur simple mais efficace a été développée, où nous pouvons voir l'état de connexion des deux manettes, et de leur deux angles (horizontal et vertical) Résultats Les résultats sont très satisfaisants, car tout a marché comme prévu. C'était aussi étonnant comme la reconnaissance de l'angle des wiimotes marchait bien et rapidement, et permettait ainsi un pilotage du robot très naturel. 21/25

22 5 Evaluation Une fois le premier prototype en place, nous pouvons songer à effectuer une évaluation du système en faisant intervenir des utilisateurs. 5.1 Méthode Pour évaluer notre système, nous choisissons une méthode qualitative, qui nous permettra d observer les utilisateurs et identifier les points forts et les points faibles du système, pour ensuite pouvoir l améliorer. Notre but est de savoir si le système est assez intuitif, s il est possible de l utiliser sans connaissances particulières préalables et si la prise en main et les mouvements semblent naturels. Pour ce faire, nous prenons donc la méthode d observation directe : un évaluateur observe l utilisateur interagir avec le système. On demandera aux utilisateurs de penser à haute voix et de dire ce qu ils font et pourquoi, ainsi que leurs réactions à chaud et leur interprétation des actions du système pendant l utilisation. Chaque session sera enregistrée sur vidéo, on filmera simultanément l utilisateur tenant les manettes dans ses mains ainsi que le robot lui-même. Un évaluateur sera présent, il observe l utilisateur sans intervenir ni faire de commentaire. Il utilisera une «coding-sheet» qui lui permettra de noter les évènements importants et quand ils sont survenus. Ceci permettra de retrouver les moments importants pour visionner ensuite la vidéo après coup. On donnera une courte liste prédéfinie de tâches simples à effectuer, par exemple : assigner une manette à un bras, déplacer le robot, bouger les bras du robot d une certaine manière. Le temps pour mener à bien chaque tâche sera mesuré par l évaluateur au moyen d un chronomètre et ce temps sera noté sur la «coding-sheet». L ordre des tâches à réaliser sera aléatoire pour chaque utilisateur testé, pour éviter d inclure un quelconque biais dans nos mesures dû par exemple à l apprentissage du système par l utilisateur. Une fois le test terminé, on effectuera une rapide entrevue avec l utilisateur pour visionner les vidéos aux moments clé de la session. Cela permettra de discuter avec l utilisateur pour avoir son avis plus précis sur certains aspects du système, pourquoi il a agit de telle ou telle manière et entendre ses éventuelles suggestions d améliorations. Méthode qualitative, direct observation, think-aloud+ constructive interaction, in field. Scénarios spécifiques avec des tâches précises, dans un ordre aléatoire. Mesurer le temps pour effectuer les différentes tâches. 22/25

23 5.2 Sélection des utilisateurs Pour l évaluation du système, nous choisirons aléatoirement un nombre assez restreint (entre 5 et 10 utilisateurs) parmi la population cible des utilisateurs finaux du système. Nous définissons la population cible de manière assez générale, par les personnes travaillant dans l industrie, les technologies des sciences et de l information ainsi que dans le domaine militaire, car nous estimons ces gens susceptibles d utiliser un tel système de commande de robot à distance. Les personnes seront sélectionnées aléatoirement, d âge et de sexe différents. 5.3 Analyse et interprétation Une fois les tests terminés, nous prendrons les données de mesures de temps pour les différentes tâches. Nous effectuerons une analyse statistique en calculant la moyenne, la variance et l écart-type sur l ensemble des données, et ces données seront représentées sous forme de graphiques, afin connaître la répartition globale des expériences effectuées. Puis nous ferons des analyses supplémentaires en découpant les données pour chaque tâche différente, et par catégories (tranches d âge, sexe), pour estimer s il y a des différences significatives selon l âge ou le sexe pour la réalisation de telle ou telle tâche avec le système. Selon les résultats obtenus et en tenant comptes des remarques et suggestions des utilisateurs, nous pourrons identifier des pistes pour améliorer le système et s il y a lieu de faire des modifications spécifiques pour une certaine partie de la population des utilisateurs. 23/25

24 6 Conclusion 6.1 Résultats En résumé, voici les actions qu il est possible d effectuer avec notre système : Par commande vocale, assigner un bras du robot à une manette, o Feedback à l utilisateur par retour de force Bouger les bras du robot sur 2 axes en changeant l orientation des manettes Faire marcher/tourner sur lui-même le robot avec les flèches directionnelles des manettes Par commande vocale, faire dire au robot «yes» ou «no» par synthèse vocale o Le robot hoche la tête en conséquence Par commande vocale, faire danser le robot 6.2 Améliorations Comme mentionné précédemment, la reconnaissance vocale laisse parfois à désirer et il serait utile d évaluer et de tester d autres solutions. Le maniement des manettes pour bouger les bras du robot fonctionne bien et nous semble très naturelle et précise. On peut imaginer appliquer une fonction de lissage à la modification des angles pour obtenir des mouvements plus fluides. Il serait très intéressant d avoir la possibilité de sélectionner et de faire bouger des articulations supplémentaires, par exemple les coudes. Dans un futur projet, il serait peut-être intéressant d'utiliser la wiimotion plus, qui permet de savoir la position de la wiimote de manière encore plus précise. Mais ceci n'est malheureusement pas supporté pas la librairie utilisée, c'est à dire «libwiimotion». 6.3 Impressions Globalement, nous sommes satisfaits des résultats obtenus dans le cadre de ce mini projet. Le prototype réalisé fonctionne correctement selon les objectifs fixés. La prise en main du robot est assez compliquée et nécessite un certain temps d apprentissage avant de pouvoir utiliser le framework de Nao. Une fois la phase d apprentissage passée, il est assez facile et rapide d écrire une application qui contrôle le robot. Pour la reconnaissance vocale, Sphinx-4 est assez facile et rapide à mettre en place pour ensuite l utiliser dans notre application. Les résultats de reconnaissance ne sont pas toujours parfait, mais dans l ensemble ils se sont montrés suffisants pour pouvoir contrôler le robot sans trop de problème 24/25

25 7 Références [1] Aldebaran Robotics : [2] Sphinx-4 : [3] Librairie Libwiimote : 25/25