Projet étudiant : Le robot assistant de l’Atelier !

Actualité ekino -

Article paru le :
Projet étudiant : Le robot assistant de l’Atelier !
Article paru le :

Aaaah les robots … Ce condensé de technologie nous accompagnant dans notre vie de tous les jours, notre assistant personnel toujours à l’écoute, quel rêve ! Au cours de mon parcours je me suis trouvé cette passion pour la robotique. Je cherchais donc une structure ne freinant pas mon amour inconditionnel envers nos amis à boulons et travaillant profondément la relation homme/robot. C’est ainsi que j’ai rejoint ekino, plus précisément l’Atelier, où le projet étudiant de créer un robot de service est né.

Imaginez un instant côtoyer un robot sur votre lieu de travail … Quelle meilleure manière de tester la relation homme-robot que de la vivre ? Il s’agit aussi d’expérimenter sur les écosystèmes de robots en intégrant Pepper à l’équation !

L’idée

La première étape était d’imaginer notre système, comment notre compagnon va évoluer au sein de l’Atelier ? Quels types d’interactions va-t-il développer ? C’est en se posant ces questions que nous sommes arrivé au schéma principal suivant : notre assistant doit avoir un langage corporel le plus complet possible, comprendre ce qu’on lui demande ainsi que reconnaître les personnes en face de lui et se tourner vers elles. Il évoluera sur une table, il ne doit par conséquent pas en tomber. Enfin il doit posséder un rapport volume/espace bien proportionné pour faciliter ses interactions avec les utilisateurs sans les gêner.

Un choix a été fait, celui que notre assistant ne s’exprime que par onomatopées, contrairement à Pepper qui défend une vision plus anthropomorphique des relations sociales. Notre assistant aurait donc de multiples interactions mais garderait totalement son identité de robot. Il faut avouer que la perspective de travailler avec son propre R2D2 est plutôt cool !

De plus cela le spécifie : En ne s’exprimant pas oralement, notre robot est défini en tant que robot d’action et non d’information.

Derrière ce choix se cache un autre point important que soulève l’expérience utilisateur. Emuler une voix correspondant parfaitement au design et à l’image que renvoie le robot est complexe. Or dans une expérience telle que celle-ci, le ressenti de l’utilisateur ne doit pas être parasité par un élément qui semble en décalage par rapport à son attente. Ce serait comme voir un bon film avec un mauvais doublage. La perspective de ne pas avoir de voix entraine donc un challenge : celui de par la gestuelle, les couleurs et les sons, synthétiser des comportements, des émotions ressenties par l’utilisateur. Vous l’aurez compris, ce défi rentre totalement dans la problématique de la relation homme-robot !

L’équipe

L’Atelier a su s’entourer de stagiaires aux multiples horizons et parcours afin de mener à terme ce projet étudiant.

Benjamin Laschkhar, 7ème Dan de programmation, en charge du haut niveau :

  • Architecture,
  • Linux et Raspberry Pi,
  • Caméra et reconnaissance faciale,
  • Micro et reconnaissance vocale

Géraud D’Agrain, ceinture noire de robotique, en charge du bas niveau :

  • Moteurs,
  • Asservissement,
  • Les capteurs optiques,
  • Gyroscope,
  • Arduino

Et enfin moi-même, Jean-François Marchal, participant pleinement aux deux parties. Je devais assurer la reprise du travail de Géraud, qui nous quittait dans la semaine de mon arrivée. Une passation de connaissances s’est donc effectuée. Je l’ai aussi épaulé dans sa dernière semaine à terminer l’entièreté du bas niveau, à deux ça va tout de suite plus vite.

Le design

Le concept de robot de table est né ! Notre assistant sera capable de se déplacer sur un bureau sans gêner l’utilisateur. Nous avons d’abord cherché un design qui nous paraissait coller avec l’esprit de l’atelier et le rôle que nous voulions donner à ce robot.

Il devait être agréable et utilitaire. Ce nouveau compagnon va nous épauler dans les tâches simples du quotidien au sein de l’atelier : contrôler les stores et les lumières, prévenir en cas de danger comme une imprimante 3D non éteinte, ou encore … « BIBOPBOOOOUH !! », 11h15 l’heure de ma réunion, je vous laisse, je reviens juste après !

Nous nous sommes tournés vers un jouet représentant un célèbre et sympathique robot comme base. Sans compter que sa forme cubique est parfaite pour intégrer tous ses composants.

Une fois vidé de ses composants basiques, le projet peut commencer.

Le bas niveau (Arduino)

Le robot étant un jouet en plastique, il n’était pas suffisamment stable et solide pour supporter les deux moteurs à courant continu qui entraînent ses déplacements. Nous avons renforcé l’axe des chenilles par une tige en acier et la structure du robot par une plaque d’époxy. Quelques pièces imprimées en 3D ont permis d’élargir l’écart des chenilles pour que les moteurs tiennent. Les moteurs DC sont vissés directement sur la plaque. Nous avons donc une base roulante solide et qui ne dépend plus de la structure en plastique.

Deux amplificateurs de puissance sont chargés de gérer les moteurs DC. Pour ceux qui se posent la question, non, on ne peut pas relier les moteurs directement à la carte Arduino, question de voltage. Les moteurs fonctionnent sous 12V alors que la carte Arduino n’envoie que du 5V maximum. Ensuite, c’est le meilleur moyen pour générer dans les moteurs une charge magnétique qui devra, à un moment ou à un autre, se décharger… grillant le module Arduino au passage !

Une roue codeuse, modélisé et imprimée en 3D, placée au centre du robot lui permet de calculer ses déplacements au millimètre près. Couplée à un gyroscope, et à une carte Arduino Nano, Géraud et moi-même avons pu développer un asservissement qui fonctionne au-delà de toute attente.

Des capteurs optiques sont placés des deux côtés du robot. Ils vont détecter le vide s’il s’approche trop près du bord de la table. Il est nécessaire de placer ces capteurs sur le module Arduino pour qu’elle puisse prendre en compte rapidement le danger. Le microcontrôleur stoppera alors immédiatement le déplacement.

Enfin, les servomoteurs vont contrôler la tête et les bras. Une pièce imprimée en 3D joint les deux servomoteurs de l’épaule.

Le haut niveau (Raspberry Pi)

Les cartes Arduino et Raspberry Pi communiquent par le port série, via un protocole maison. La carte Raspberry était un choix naturel vu son faible encombrement et sa caméra parfaite pour nos besoins. Benjamin a créé une architecture en Python sur laquelle nous n’avons plus qu’à ajouter les services et les commandes associées.

Cette architecture est chargée de synchroniser l’ensemble des comportements. Inspirés par Naoqi de SoftBank Robotics, nous avons séparé ceux-ci en deux catégories :

  •  les applications
  •  la vie autonome, les comportements individuels, qui sont lancés lorsque le robot n’est pas sollicité, lui donnant cette touche de vie.

Grâce à la caméra, le robot est capable de détecter les visages dans son champ de vision et de se tourner vers eux. Rien que ce petit ajout nous donne l’impression qu’il cherche à créer le contact visuel avec ses admirateurs.

Le haut niveau gère également les yeux du robot, essentiel pour communiquer les émotions et les informations visuelles importantes comme « J’ai bien compris la commande » ou encore « Oui ? Je t’écoute … ».

Une carte son, un micro et une enceinte ont également été ajoutés lui permettant de comprendre ce qu’on lui demande et d’y répondre.

L’une des parties les plus importantes est la reconnaissance vocale, elle fait le lien entre l’utilisateur et notre compagnon. Elle est composée d’un noyau en script sh qui fonctionne de la manière suivante : notre robot va attendre qu’on l’appelle, ce processus est lancé en local. Dès qu’il se reconnaît, il va se mettre à nous écouter puis la trame audio sera envoyée au STT (Speech To Text) de Google Cloud Platform. La chaîne de caractères en sortie sera envoyée au Behavior Manager où un traitement sera effectué afin de déterminer si une application correspond à la commande.

Nous avons mis en place un algorithme de calcul de distance de Levenshtein afin de palier à une éventuelle mauvaise interprétation du STT. Imaginons que je veuilles allumer les lumières de l’Atelier, je vais donc appeler mon assistant et lui dire « Turn on the lights ». Cette trame audio va être analysée par le STT, et manque de chance il renvoie « Turn on the Flights ». L’algorithme va comparer cette chaîne de caractères aux différentes commandes. Il va alors détecter une distance de Levenshtein de 1 avec la fonction « Turn off the lights ». Il va exécuter l’application car cette distance est inférieure au seuil maximum choisi, pratique !

L’alimentation du robot

Nous avons calculé la consommation du robot pour un fonctionnement à plein régime pendant une heure. Impossible à ce moment-là de définir une utilisation moyenne quotidienne de cette petite chose. Nous nous sommes alors tournés vers une batterie Lithium-Potassium de trois cellules (11V). Un réducteur de tension 11v vers 5v fait la passerelle entre la batterie et la carte Raspberry Pi qui alimente elle-même le module Arduino. Un bouton éteint proprement la carte Raspberry Pi via un script sh et un autre coupe l’ensemble de l’alimentation. Nous avons pu mesurer une autonomie de 5h ce qui est très correct.

Mon ressenti sur cette expérience

Au cours du développement de notre compagnon et de ses applications, j’ai constaté à quel point la robotique de service est un champ à fort potentiel. Le robot incarne le service plus que n’importe quelle interface. Ce fut une des expériences les plus enrichissante que j’ai pu vivre en robotique, très formatrice, elle m’a ouvert sur ce monde de possibilités, mêlant le futur et le présent de la robotique au quotidien. J’ai eu tout le loisir de constater les avantages que représentent de tels assistants ainsi que les problématiques soulevées sur notre relation avec les machines. Notre robot assistant a de beaux jours devant lui, il a tout sauf à craindre de prendre la poussière !

La suite

Nous avons maintenant une belle base de travail. Le robot est autonome et n’attend que le développement de nouveaux services pour intégrer l’équipe de l’atelier !

Dans un prochain article, nous reviendrons sur l’architecture et les services qui font le cerveau de notre compagnon. Nous reviendrons aussi sur nos retours après quelques semaines de collaboration avec lui. La relation homme-robot est un sujet complexe que l’Atelier approfondira au-delà de cette expérience déjà riche.

En attendant, on l’aime déjà !