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

se concentrer sur des problématiques plus pertinentes. Par exemple,MORSEdispose

à 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.

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/

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.

F

IGURE

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

en haut et en bas)

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é.

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_coffeetableou

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.positiondans l’ontologie du domaineMaRDiutilisée pour

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

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.

Dans le document Apprentissage automatique en ligne pour un dialogue homme-machine situé (Page 186-189)