Simulation de l’environnement

Bien que la réalisation d’expériences sur la véritable plateforme robotique constitue un des objectifs finaux du projetMaRDi, compte tenu du coût élevé que représente la mise en place de telles interactions mais aussi afin de faciliter la réalisation des expé-riences sur les divers sites partenaires, nous avons adopté une solution dans laquelle le système des dialogue multimodal est couplé avec un logiciel de simulation robotique 3D⁶.

Choix du simulateur robotique

Le recours à des logiciels de simulation est souvent nécessaire en robotique. En uti-lisant des simulateurs, il est possible d’évaluer et de valider certaines propositions et développements avant toute tentative d’intégration coûteuse et risquée sur la véritable plateforme robotique. Ainsi, de nombreux simulateurs sont disponibles. Nous pouvons citer par exemple la suiteGazebo(Koenig et Howard,2004), la plate-forme de simula-tion intégréeOpenHRP(Nakaoka et al., 2007) ou encore la simulateur commercial V-REP(Freese et al.,2010). Cependant, peu de solutions sont véritablement adaptées pour l’HRI par exemple en limitant l’intégration de l’homme (contrôle limité) dans l’environ-nement virtuel. Ceci explique en partie pourquoi les études HRI faisant l’usage de la simulation ont longtemps été menées de façon télé-opérées, où seuls le robot et l’en-vironnement sont modélisés dans l’enl’en-vironnement virtuel. Les simulateurs robotiques USARSim(Lewis et al.,2007) etMORSE⁷(Echeverria et al.,2011,2012) sont tous deux utilisés dans plusieurs dizaines de travaux en HRI en raison de leur support explicite de l’homme. Cependant, la seconde solution dispose de nombreux avantages pour notre contexte d’étude qui ont motivé sa sélection dans nos travaux.

MORSE la plateforme de simulation open-sourceMORSEest une solution de simu-lation robotique libre qui a pour contributeur principal le LAAS-CNRS. Cet outil pré-sente l’avantage de pouvoir prendre en charge de nombreuxmiddleware(comme ROS , YARP⁸) mais aussi de permettre au robot virtuel d’interagir avec son environnement virtuel grâce à des capteurs/actionneurs modélisés de façon réaliste pour faciliter le déploiement ultérieur vers une véritable plateforme robotique. Cet outil propose éga-lement des capteurs/actionneurs de haut niveau pour alléger la tâche du développeur en lui simplifiant la mise en place de certaines chaînes de traitements pour qu’il puisse

6. Il est important de signifier que le terme simulation employé ici ne se réfère pas à la problématique de la « simulation d’utilisateurs » introduite dans la section??. En effet, l’objectif visé par l’outil considéré est de reproduire le plus fidèlement possible l’environnement dans lequel va se dérouler l’interaction (de même que le robot et l’utilisateur) et non les comportements d’un utilisateur face aux réponses du système.

7. https ://www.openrobots.org/wiki/morse/

8. http ://wiki.icub.org/yarp/

se concentrer sur des problématiques plus pertinentes. Par exemple,MORSE dispose à la fois d’un capteur de type caméra RGB-D et d’une caméra sémantique, alors que le premier capteur fournit une image non traitée en sortie (pixels), la seconde extrait directement le nom et la position des objets apparaissant dans son champ de vision.

La solutionMORSE repose actuellement sur leBlender Game Engineintégré au lo-giciel libre Blender⁹. Ce faisant, elle propose un rendu graphique 3D avancé (shaders OpenGL) intégrant des principes de physique tel que la gravité par l’intermédiaire du moteurBullet Physicspour offrir une représentation réaliste de l’environnement dans lequel se déroule l’interaction. Dans notre contexte, une réplique virtuelle de l’apparte-ment de trois pièces dans lequel devraient s’effectuer les tests finaux du projet a été mise à notre disposition ainsi que celle du PR2 qui elle fait partie des plateformes robotiques pré-intégrées dansMORSE.

Un contrôle immersif d’un avatar humain (voir la figure 6.8) est également mis à disposition. Ce dernier fait usage soit d’une interface classique clavier/souris mais éga-lement d’une interface ASUS Xtion/Wiimote. Quel que soit son choix, l’utilisateur au travers de son avatar peut se déplacer¹⁰, observer et interagir à les éléments de l’envi-ronnement. Par exemple, il peut saisir et relâcher un objet si ce dernier est manipulable et à sa portée.

Simulation pour la tâcheMaRDi

Avant toute interaction, un script est chargé de positionner les différents objets dans l’environnement sur les positions d’intérêt (comme livingroom_coffeetable ou kit-chen_table). Il est en serait de même dans des conditions réelles (hors scénarios pré-définis) sauf que ce serait à l’expérimentateur de préparer l’environnement. Au fil des interactions, et selon la configuration choisie, ces objets vont progressivement changer de position du fait de l’exécution des commandes par le robot. C’est pourquoi un suivi est également fait sur l’environnement courant. Il permet de générer de façon automa-tique des buts pertinents (ne pas proposer de déplacer un objet à une position qu’il occupe déjà).

Pour le PR2, il peut être démarré soit avec un ensemble de faits symboliques pré-chargés, soit dans une configuration plus réaliste, où il doit déterminer ces faits de manière autonome grâce à ses capacités de raisonnement spatial.

Pour pouvoir réaliser les actions non-verbales de façon transparente entre la véri-table plateforme robotique et le simulateur nous avons choisi de définir la liste d’actions abstraites qui suit :

— GoToLocation: déplace le robot vers une position d’intérêt passée en argument (on parlera également de zones de manipulations). Dans notre configuration ex-périmentale ces zones correspondent aux valeurs des concepts de haut niveau object.positionetmove.position dans l’ontologie du domaineMaRDiutilisée pour

9. https ://www.blender.org/

10. Dans notre contexte expérimental cette fonctionnalité ne sera pas exploitée car l’utilisateur est sup-posé être handicapé.

6.3. Conditions d’apprentissage et de tests en ligne de la politique d’interaction

FIGURE6.8 –Avatar humain dans le simulateur MORSE en première et troisième personne (resp.

en haut et en bas)

le dialogue. DansMORSEnous utilisons l’actionneurteleportqui permet de dé-placer instantanément le robot à une position spécifiée, l’objectif étant d’accélérer la durée de l’interaction pour faciliter la phase de collecte. Il est à noter que la plupart des déplacements seront simplifiés en simulation, seule une partie de la motricité fine (ici le déplacement des armatures du robot) est à ce jour réalisée à l’identique sur le robot et sur sa version simulée ;

— HeadScan : parcourt visuellement l’environnement grâce à un mouvement de tête circulaire du robot. En simulation, le robot dispose d’une caméra sémantique sur la tête qui lui permet de reconnaître les objets dès qu’il les a en visuel. Sur le PR2, pour simplifier leur détection, les objets sont identifiés par un code QR scotché dessus ;

— GraspObject : attrape un objet passé en argument si ce dernier est à portée. En simulation, le service grasp est employé. Ce dernier attache automatiquement l’objet (si à portée) à la main gauche du robot ;

— DropOnLocation : relâche l’objet que le robot a dans sa main sur la position d’intérêt passée en argument de la commande ;

— GiveToHuman: déplace le robot auprès de l’homme avant de tendre le bras vers

lui tout en abaissant la raideur de sa main pour que l’humain puisse se saisir de l’objet qui est à l’intérieur. Pour cela les actionneurs de l’armature liée au bras droit du robot sont utilisés.

De nombreux travaux dans le domaine de l’HRI située utilisent des scénarios d’in-teraction que l’on pourrait modéliser (si ce n’est déjà le cas) par l’intermédiaire d’un simulateur robotique 3D tel que celui adopté dans nos expériences (Byron et Fosler-Lussier,2006;Stiefelhagen et al.,2007;Lucignano et al.,2013). Néanmoins, très peu de travaux privilégient à ce jour la simulation pour réaliser un apprentissage RL en ligne de la politique d’interaction qu’ils emploient (même pour unbootstrap). En effet, la plu-part des travaux en HRI recourent pour cela à des expériences préliminaires en confi-guration de WoZ (où un utilisateur expert contrôle le robot à distance afin de jouer son rôle). On peut par exemple faire référence aux études réalisées dans (Prommer et al., 2006;Stiefelhagen et al.,2007;Rieser et Lemon,2008). Cependant, comme nous l’avons déjà mentionné dans les précédents chapitres, ce type d’approche est coûteux lors de sa réalisation (temps, recrutements de sujets) et pose la question de « quels comporte-ments l’expert doit-il faire jouer au robot pour garantir un bon apprentissage ». C’est pourquoi nous proposons directement d’apprendre et de tester les actions possibles en ligne mais dans une configuration virtuelle où les actions prises par le système auront des incidences et des temps d’exécution moindres.

Alternative fonctionnelle au simulateur robotique durant la conduite de nos expé-riences nous avons constaté que beaucoup de temps avait été perdu lors du lancement et du déroulement des interactions sur le simulateur, et ce malgré les simplifications apportées à ce dernier par rapport à la véritable plateforme robotique. En moyenne, il a été estimé que chaque interaction sur le simulateur prenait une durée allant de 7 à 10 minutes (initialisation de l’environnement, détections d’objets, mouvements du robot, déplacements, etc.).

Nous avons donc cherché une solution de contournement, sans perte en termes de fonctionnalité et de performance, pour une nouvelle fois accélérer l’interaction. L’ap-proche retenue est de recourir à une représentation « fixe » de la scène (une capture d’écran du point de vue de l’humain) dans une interface web multimodale où les objets manipulables et les positions d’intérêts (meubles) sont considérés comme cliquables pour pouvoir simuler les gestes déictiques en provenance de l’utilisateur. Dans cette configuration, la base des faits dynamiques est alimentée par un module dédié capable de générer les faits dynamiques qui auraient été produits par SPARK dans la confi-guration virtuelle standard tout au long de l’interaction dans le contexte d’interaction chargé au démarrage. Pour proposer un suivi de l’interaction par l’utilisateur lors du dialogue, l’affichage web (capture d’écran de la scène) est mis à jour quand une modifi-cation physique de l’environnement intervient (déplacement physique du robot et/ou d’un objet) pour refléter la réalité observable.

6.3. Conditions d’apprentissage et de tests en ligne de la politique d’interaction