Rapport de robotique sociale Mohammed-Amine Chemami ; Ieva Dubinskaitė ; Nader Hassine ; William N. Havard ; Alican Kocabıyıkoğlu ; Aymen Ltifi ; Dhiffallah Othman ; Anne-Laure Piat-Marchand ;

Doriane Simonnet ; Pauline Soutrenon ; Louise Tarrade M2 IDL

Introduction Nous avons eu l’opportunité au cours de ce semestre de travailler au FabLab et

notamment sur le projet “Rob’air”. “Rob’air” est un robot de téléprésence qui permet aux enfants malades ne pouvant pas se déplacer à l’école pendant une longue période, d’assister à leurs cours depuis leur chambre d'hôpital et ne pas briser leur lien social avec la classe. Nous détaillons dans cette synthèse les étapes de notre travail, ainsi que les choix que nous avons pris.

Choix de la nouvelle fonctionnalité Lorsque nous avons dû choisir une nouvelle fonctionnalité à ajouter, notre choix s’est rapidement porté sur la deixis. La deixis est “un mode particulier d'actualisation qui utilise soit le geste (deixis mimique), soit des termes de la langue appelés déictiques (deixis verbale)” (Dubois, 2012). La première raison pour laquelle nous nous sommes orientés vers cette composante est que la deixis est un comportement qui apparaît très tôt dans le développement de l’enfant.

“En fait, d’après leurs observations (Butcher et Goldin-Meadow, 2000; Goldin-Meadow et Butcher, 2003), vers 12 mois environ, l’enfant commence par utiliser des gestes seuls, qui sont d’ailleurs la plupart du temps des gestes déictiques (exemple : l’enfant pointe du doigt un objet et regarde alternativement la mère et l’objet afin de signifier à sa mère qu’il le veut), puis, à partir de 14 mois, des combinaisons bimodales composées d’un geste et d’un mot (exemple : l’enfant pointe du doigt vers un référent tout en prononçant le mot correspondant)”.

Comme on le voit, puisque l’enfant ne peut pas communiquer par des mots, il utilise en premier lieu des gestes afin de communiquer avec son entourage. Lorsqu’il arrive à maîtriser le langage oral, l’enfant va alors utiliser des mots en plus des gestes. Ainsi, la communication par geste est le premier acte de langage de tous les humains. Le fait de permettre à la personne contrôlant le robot de pouvoir communiquer par des gestes permet de prendre en compte l’aspect multimodal du langage. En effet, comme le note (M. Arbib, 2011) “The performance of language is multimodal, not confined to speech ”. La communication ne se fait donc pas uniquement par la parole mais par le biais d’autres modalités, comme les gestes par exemple : “adult speakers normally accompany all their speech with expressive manual gestures “ (M. Arbib, 2011). Le fait de pouvoir désigner n’est pas l’apanage de l’homme seulement. En effet, les animaux sont également capables de pointer des objets. (M. Arbib, 2011) rapporte que les primates sont également capables de communiquer par des gestes : “The use of manual and bodily

gestures to communicate with other conspecifics has been reported for several species of nonhuman primates “ (M. Arbib, 2011). Selon (Pika, 2011) les corbeaux seraient aussi capables de communiquer par des gestes :”Ravens also use distinct object-oriented behaviours to mainly direct conspecific’s attention to a third entity triadically and referentially ” (Arbib et al., 2008). La deixis apparaît donc comme une composante élémentaire et primordiale dans la communication. Il nous a donc semblé important de donner la possibilité aux enfants hospitalisés de pouvoir l’utiliser en téléprésence.

Choix de la manière d’implémenter la deixis Plusieurs moyens ont été évoqués afin de faire en sorte que l’utilisateur du robot puisse désigner quelque chose. Le premier moyen auquel nous avons pensé est d’utiliser un laser. Nous n’avons pas retenu cette option, et ce pour plusieurs raisons. Tout d’abord, un laser peut être dangereux si une personne le reçoit dans les yeux. On ne peut écarter le fait que la personne contrôlant le robot peut être mal intentionnée et pourrait envoyer le laser directement dans les yeux de quelqu’un. Outre cela, il peut toujours arriver que le laser atteigne les yeux de quelqu’un par accident. Le point lumineux du laser est également très petit et il faudrait en permanence le chercher du regard afin de savoir si l’élève pointe ou non quelque chose. De plus, l’utilisation d’un laser n’est pas du tout discrète, et par conséquent dès que la personne utilisant le robot pointe quelque chose, l’ensemble de l’auditoire peut le voir. Cela n’est absolument pas souhaitable. La personne contrôlant le robot peut en effet vouloir désigner quelque chose de manière discrète à une seule personne et non à tout un auditoire. Nous trouvions avantageux l’utilisation d’un laser car il permet de désigner les choses avec une grande précision. Toutefois, une telle précision n’est pas nécessaire car l’humain interprétant la direction contextualise toujours ce que la personne a souhaité désigner. Notre seconde idée consistait à implémenter un bras articulé sur le robot. Nous avons toutefois également écarté cette idée. En effet, un bras articulé est très coûteux et très long à fabriquer. Nous n’aurions donc eu ni les moyens, ni le temps de le faire. De plus, cette idée pose également d’autres problèmes. Tout d’abord, il y a des risques que le bras heurte une autre personne et la blesse. Le second élément qui nous a dissuadé d’utiliser un bras est que celui-ci aurait été difficilement contrôlable. En effet, afin de pouvoir contrôler correctement ses membres, l’humain dispose de la proprioception. C’est à dire qu’il a à tout moment conscience de la position de ses membres les uns par rapport aux autres. De la sorte, l’humain peut coordonner ses mouvements. Sans proprioception il aurait été complètement impossible de pouvoir contrôler le bras. En effet, l’élève n’aurait pas su où se trouvait le bras afin de pouvoir l’amener dans la direction voulue.

Notre troisième idée était d’utiliser le regard. Ainsi, le robot aurait tourné la tête afin de désigner un objet. Cette idée a également été abandonnée. En effet, il faut un signal afin que les personnes autour du robot sachent que la personne contrôlant le robot est en train de désigner quelque chose. C’est la dernière idée qui a été retenue : fixer une “corne” sur le robot. Cela présente de nombreux avantages. Tout d’abord, la corne permet de matérialiser la direction vers laquelle regarder, tout comme un bras l’aurait fait. Toutefois, celle-ci ne se révèle pas dangereuse puisqu’elle ne risque pas de heurter quelqu’un. Afin de signaler aux personnes autour du robot que la personne contrôlant le robot pointe quelque chose, nous avons eu l’idée de mettre des LED à l’intérieur de la corne. Ainsi, dès que la personne désigne quelque chose, la corne s’allume. Afin de nous abstraire du problème causé par la proprioception, nous avons décidé que la corne resterait fixe. Nous avons décidé de positionner la corne juste au dessus de la caméra de la tablette. Cela a toutefois une limitation : l’élève ne peut pointer que ce qui se trouve dans l’angle de vision de la caméra. S’il souhaite pointer quelque chose derrière le robot, il doit déplacer le robot de sorte à ce que ce qu’il souhaite désigner se retrouve dans l’angle de vue de la caméra.

Réalisation de la corne Le groupe ayant réalisé la corne a d’abord utilisé le logiciel Google SketchUp . En effet, ce logiciel permet de construire aisément des modèles qui peuvent être lus par une imprimante 3D. Après concertation avec le groupe, nous avons choisi de faire une corne de 4cm de diamètre et 17cm de hauteur. Nous pensons que la corne sera assez grande pour être vue, sans toutefois être prépondérante. Il ne fallait pas, en particulier, qu’elle apparaisse dans le champ de vue de la webcam afin de ne pas gêner la vision qu’aura l’enfant sur son écran. Toutefois, le choix de la taille a été faite de manière tout à fait empirique, et un test terrain serait nécessaire afin de savoir si nos choix étaient les bons. La première corne devait avoir une épaisseur de 2mm afin qu’elle soit suffisamment solide. Toutefois, suite à une erreur dans la construction du modèle 3D, l’épaisseur de 2mm n’a pas été maintenue sur toute la hauteur de la corne. Elle était donc tronquée au bout et trop petite. Une seconde corne a donc été faite par Germain (du FabLab) grâce au logiciel OpenCAD qui permet de créer des modèles 3D à partir d’un langage de programmation particulier. Celle-ci avait la taille voulue mais n’avait pas une épaisseur de 2mm ce qui fait qu’elle est relativement fragile.

La corne a par la suite été coupée à la base afin de pouvoir être fixée à la coque du robot. Nous l’avons maintenue provisoirement avec de la Patafix. Toutefois, pour une fixation définitive il faudrait la coller, mais nous n’avons pas eu assez de temps pour parvenir à ce stade. De plus, nous avons ajouté un bout de mousse au bout de la corne, afin de limiter le danger de blessure en cas de collision avec le robot. Cela n’est certainement pas suffisant, et nous pensons qu’une matière plus flexible pour l’ensemble de la corne serait une bonne solution pour pallier, en partie, à ce problème.

Réalisation du code de l’interface Pour la tâche d'allumage de la LED, il a fallu réaliser une interface en Javascript qui permet d'allumer la corne en vert ou en rouge. Pour ce faire, nous avons commencé par programmer deux boutons en HTML, ensuite nous avons codé les deux boutons en Javascript avec une fonction standard . Cette fonction permet d'allumer la corne en vert ou en rouge lors d'un clic sur l'un de deux boutons. Enfin, pour la partie connexion entre le code Javascript et Arduino nous avons utilisé le framework libre ROS notamment la bibliothèque Roslib afin de connecter la LED avec l'interface.

Réalisation du code d’allumage de la LED Afin d’illuminer l’extrémité de la corne Deixis du Rob’air, Il a fallu d’abord raccorder un composant électronique Arduino au socle principal du robot Rob’air. Ce raccordement a consisté à fixer trois fils LED au corps de l’Arduino en respectant les contraintes machine (positions). Ensuite, il a été nécessaire d’écrire des lignes de commande Arduino afin d’illuminer en vert ou en rouge l’extrémité de la corne. Cette manoeuvre a permis d’enrichir les fonctions à la console de pilotage du Rob’air.

La réalisation du code d’allumage des lumières LED s’est heurtée à quelques difficultés de notre côté. Se familiariser avec un composant standard en robotique, l’Arduino, sans connaissance préalable dans ce domaine n’est pas aisé d’entrée de jeu. Les membres du groupe n’ayant pas un parcours typé robotique-industrie mais plutôt informatique, français langue étrangère et sciences de l’éducation ont eu un temps d’adaptation. Une mise à niveau de nos connaissances des fréquences (nombre de fois par seconde qu'une action est faite) et des périodes s’est avérée nécessaire pour mener à bien l’allumage des LED de la corne. La prise en main laborieuse du langage de programmation Arduino au même titre que son interface est aussi à signaler. Il a fallu attendre quelques explications de Jérôme, l’ingénieur supervisant le travail de groupe ainsi qu’un effort de compréhension de notre part pour comprendre ce qu’est une bibliothèque open source ROX. Ce moment de flottement a duré une vingtaine de minutes avant la réalisation effective du code Arduino. La disponibilité limitée du logiciel Arduino sur un seul ordinateur portable tournant sous Mac OS X nous a également quelque peu bridé. Une fois le code fait, l’extinction des LED s’est avérée problématique. L’image ci-dessous donne une idée de ce qu’est un programme Arduino.

Critique sur le travail réalisé La deuxième séance de l’UE consacrée au brainstorming a été pénible. On a dû donner de nos personnes pour faire participer les étudiants ENSIMAG qui donnaient l’impression de s’ennuyer à haute voix. Plusieurs membres de notre groupe nous ont dit qu’ils ne comprenaient pas ce qu’ils faisaient dans ce cours. L’ensemble du travail avec les étudiants de l’ENSIMAG nous a semblé assez laborieux même si les tâches demandées ont été pleinement réalisées. En effet, un cahier des charges au format PDF à bien été transmis par mail à Mme. Catel trois jours après cette séance 2. Une fois le cahier des charges du futur robot pédagogique à destination d’un enfant hospitalisé transmis à Mme. Catel par mail, on a eu que peu de retours ou corrections de la part des étudiant Ensimag. Une seule remarque de la part des six étudiants indiquant une certaine incompréhension vis-à- vis de l’intitulé de ce travail mixte étudiants M2 IDL-étudiants ENSIMAG. Un travail de brainstorming d’emblée réservé aux seuls étudiants du Master IDL nous semble plus pertinent à l’avenir. Se greffer sur un projet en cours, celui du Rob’air, n’est pas facile en termes de positionnement. Penser un travail d’ingénierie et de robotique n’est pas donné. Néanmoins, le côté pluridisciplinaire de l’UE permet d’élargir son champ de vision vers d’autres savoirs, métiers et intelligences. La confrontation de méthodes de travail avec des ingénieurs et

autres professionnels en robotique permet de se remettre en question et de s’ajuster en vue de projets futurs. Être précis, solidaire envers les partenaires de travail sans être pédant constituent autant de compétences à méditer. Par ailleurs, la découverte d’un nouvel environnement de travail est toujours motivante comme le FabLab qui de par sa superficie offre de nombreuses possibilités. En somme, cette UE a constitué une respiration dans un emploi du temps chargé en semestre 1.

Points à améliorer Penser à programmer une séance de test supplémentaire notamment en ce qui concerne la partie Arduino à l’avenir. Un petit tour sur internet permet de connaître l’étendue des possibilités offertes par ce composant en robotique. Faire quelque chose de plus fourni et de plus sophistiqué semble être dans les cordes de certains étudiants dont le parcours en informatique offre une certaine souplesse d’esprit. De même, l’installation du logiciel Arduino sur plus de machines au FabLab et la mise à disposition d'exécutables compatibles windows sur des supports amovibles USB faciliterait la partie travail individuel sur nos propres PC. Cette option aurait aussi permis de gagner du temps et ainsi développer d’autres aspects du projet Rob’Air. Il reste de nombreux points à améliorer afin que notre corne soit pleinement fonctionnelle. Tout d’abord, l’élève ne sait pas précisément quel objet est pointé par la corne. Cette situation peut ainsi créer des cas d’ambiguïté, que l’enfant sera peut-être amené à résoudre au moyen d’une autre modalité (parole …). Il aurait été nécessaire d’indiquer cela par un point rouge sur la tablette de la personne contrôlant le robot. Pour ce faire, il nous aurait fallu mettre un laser dans le bout de la corne, regarder où était le point du laser et indiquer ce point sur le retour vidéo de la tablette de l’élève. Nous regrettons également que notre corne ne prenne pas en compte la portée de l’espace interactionnel voulu par l’enfant : en effet, par ce biais, il ne lui est pas possible de désigner quelque chose à seulement une ou plusieurs personnes parmi celles qui partagent son espace. Nous nous sommes également aperçus qu’il était impossible d’éteindre les LED une fois celles-ci allumées.Ceci est un énorme problème, et anéantit l’utilité de ces LED. Comme déjà mentionné, elles permettent d’indiquer aux personnes autour du robot que l’élève contrôlant le robot est en train de désigner quelque chose. Puisqu’elles restent allumées en permanence il est désormais impossible de savoir si l’élève pointe ou non quelque chose. Les LED placées à l’intérieur de la corne peuvent prendre deux couleurs : rouge et vert. Toutefois, nous n’avons défini aucune fonction spécifique aux couleurs de la corne. Pour dire vrai, nous ne savons pas si celles-ci présentent un intérêt pour l’élève. Seule l’expérience pourra dire de quelle manière l’élève utilisera les couleurs, s’il les utilise. S’il s’avère que l’élève ne se sert pas des différentes couleurs, elles pourront être supprimées. Si au contraire, le nombre de couleurs s’avère trop restreint selon les usages de l’élève, il serait envisageable d’en rajouter. Dans ce genre de projets, certains points méritent de prendre quelques précautions, comme, entre autres, la perception qu’auront les autres enfants du robot. Il ne faudrait pas,

par exemple, que les autres enfants ne perçoivent plus que le robot et plus l’enfant qui le contrôle, et que l'enfant se fasse ainsi supplanter par le robot auprès de ses camarades. On ne peut malheureusement pas prédire comment ils se comporteront dans une telle situation avant que cela soit réellement testé. Un autre élément auquel il est nécessaire de porter attention est également que le robot n’ait pas pour conséquence de déclencher chez l’enfant une sorte de « syndrome de superman ». Effectivement, il faut rester attentif à ne pas doter le robot de capacités plus développées que celles que l’enfant pourrait avoir dans son état normal. Quoi qu’il en soit, il faudrait confronter à l’expérience notre ajout au robot afin de vérifier nos hypothèses en termes d’utilité et d’utilisation concrète de la corne ; s’il s’avère que la corne est peu ou pas utilisée par l’enfant, il s’agirait de comprendre si cette non-utilisation est due à l’idée-même ou bien à la manière que nous avons eue de l’implémenter. Si, en revanche, l’enfant semble l’utiliser, il faudrait observer les circonstances dans lesquelles il en fait usage afin d’améliorer les aspects techniques.

Bibliographie

Arbib, M. A., Liebal, K., & Pika, S. (2008). Primate Vocalization, Gesture, and the Evolution of

Human Language. Current Anthropology , 49 (6), 1053‑1076.

Batista, A., & Le Normand, M.-T. (2010). Gestes, verbalisations et combinaisons bimodales dans

les productions d’enfants français âgés de 18 mois à 4 ans et demi. Lidil. Revue de

linguistique et de didactique des langues , (42), 55‑75.

Dubois, J. (Éd.). (2012). Le dictionnaire de linguistique et des sciences du langage: [les notions

et les termes fondamentaux, pour découvrir et comprendre, le fonctionnement et l’évolution

du langage] . Paris: Larousse.

Pika, S., & Bugnyar, T. (2011). The use of referential gestures in ravens (Corvus corax) in the

wild. Nature Communications , 2 , 560.