Ma recherche - mes principales réalisations

Art-e

Art-e est un avatar, créé en 2009 lors du projet ANR Emotirob, en ActionScript 3 et existant sous la forme d'un fichier FLV. L'objectif de mon travail était de travailler sur la dynamique des émotions d'un robot ourson développé dans le projet pour apporter du réconfort psychologique à des enfants fragilisés. L'objectif, à moyen terme, était donc d'améliorer la qualité du lien affectif entre l'enfant et le robot en s'intéressant aux émotions, aux humeurs et aux sentiments de l'enfant.
L'avatar devait être la conscience du robot, et un compagnon virtuel pour l'enfant. Ainsi le robot et l'avatar devaient pouvoir communiquer et se coordonner émotivement. L'avatar devait donc pouvoir suivre l'enfant partout et être déployée a posteri sur un appareil mobile.
J'ai développé un avatar, ressemblant à un petit garçon pour que les enfants puissent le percevoir plus facilement comme une entité avec laquelle communiquer, avec la contrainte très forte que les expressions faciales de l'avatar devaient être les mêmes que celles du robot.
Art-e possédait donc deux sourcils et une bouche. Mais il possédait également des dégrés de liberté supplémentaire qui lui permettaient d'exprimer des émotions à sa manière. Par exemple, il a été pourvu d'yeux et d'un tronc permettant de jouer sur davantage de paramètres pour exprimer des émotions.
Art-e était capable de :

  • cliquer des yeux
  • respirer plus ou moins fort
  • regarder les mouches voler
  • avoir des rictus

La vidéo ci-dessous montre un exemple de trois instances d'Art-e en train de regarder un extrait de Bambi, lors d'un passage particulièrement triste. Les trois personnages virtuels ont un caractère différent, et expriment donc les émotions d'une manière différente.

Nestor

Au début de ma thèse, je devais travailler sur un robot d'aide à domicile. Il fallait que le robot ait des capacités émotionnelles afin d'apporter du bien-être aux personnes. J'ai donc passé quelques mois à fabriquer un prototype de robot destiné au partenaire industriel en charge de la fabrication du robot.
Nous avons décidé de faire un robot pingouin pour la raison suivante. L'apparence du robot est déterminante car les personnes ont des attentes spécifiques liées à l'apparence du robot. Plus l'incarnation du robot représente un être familier, plus l'utilisateur est exigeant face aux capacités du robot, et plus il a de risques d'être déçu que le robot ne reproduise pas exactement le bon comportement. Pour maximiser l'acceptabilité du robot, nous avons décidé de faire un robot pingouin, qui n'est pas un animal familier dans notre culture. Ainsi, il est possible de créer des expressions qui ne sont pas fidèles au vrai animal sans prendre le risque que le robot se fasse rejeter.
Ce robot a été fabriqué en utilisant :

  • Du bois pour porter les moteurs, le visage, et pour faire les bras
  • Des moteurs Dynamixel empruntés au robot Bioloïd
  • Des câbles de frein pour faire bouger les éléments du robot
  • Des engrenages pour permettre de passer de la rotation des moteurs à l'action linéaire des câbles
  • De la résine Epoxy pour faire le visage
  • Du tissu pour faire la peau

La vidéo ci-dessous montre les différents degrés de liberté que nous avions prévu pour la première version du robot.

Pour cette première version, il était prévu de faire une expérimentation pour tester ses capacités expressifs. La vidéo ci-dessous montre quelques expressions faciales de ce robot.

NabazFrame

Le logiciel NabazFrame est un logiciel développé en Java et qui permet de créer des chorégraphies pour le robot Nabaztag ou de lui faire jouer des sons incluant de la synthèsr vocale. Le Nabaztag a peu de capacité et il est difficile de lui faire exprimer des émotions. Ses oreilles peuvent effectuer des rotations. Il possède quatre diodes sur son visage et son corps qui peuvent prendre n'importe quelle couleur exprimée par RVG.
L'avantage de ce robot est qu'il est suffisamment simple pour être attractif et ne pas susciter la méfiance des personnes. Le logiciel et le robot ont été utilisé dans quelques expérimentations (du laboratoire LUSAGE et du Lab-STICC).

L'image ci-dessous montre l'interface graphique que j'ai developpé pour piloter le Nabaztag.

Capture d'écran de NabazFrame

ArCo

Le compagnon artificiel

Chaque jour un utilisateur est entouré par un certain nombre d'objets numériques :

  • Des capteurs qui acquièrent des informations sur l'environnement et la personne
  • Des actionneurs qui agissent sur l'environnement

Aujourd'hui

L'utilisateur interagit indépendamment avec chacun de ces objets numériques. Chaque objet numérique utilise uniquement ses propres fonctionnalités.

Oui... mais !

Et si l'utilisateur pouvait interagir avec l'ensemble des objets numériques en même temps ? Et si chaque objet numérique pouvait bénéficier des fonctionnalités des autres objets numériques ?

Demain

L'utilisateur interagit avec son environnement et donne des ordres de hauts niveaux. Les objets numériques s'organisent de façon autonome pour répondre à ces ordres.

Et le Compagnon Artificiel, c'est quoi ?

Le Compagnon Artificiel, c'est l'ensemble des objets numériques de l'environnement. Mais ce n'est pas n'importe quel ensemble !
Le Compagnon Artificiel :

  • Coordonne les objets numériques
  • Gère l'ensemble des données en provenance des capteurs
  • Gère l'ensemble des données à destination des actionneurs

Mais à quoi ça sert ?

  • Le Compagnon Artificiel sert à simplifier la vie de l'utilisateur en l'assistant dans son quotidien.
  • Il permet à l'utilisateur de combiner les fonctionnalités des capteurs et des actionneurs.
  • L'utilisateur peut programmer tout son environnement. Il peut décider de toutes les actions que les actionneurs doivent effectuer en fonction des informations acquis par les capteurs.

Organisation générale d'ArCo

Schéma de l'architecture ArCo

Un utilisateur est entouré par un certain nombre d’objets numériques qui sont des capteurs et des actionneurs.
Chaque capteur est géré par un programme appelé Entité Agissante Perceptive et chaque actionneur est géré par un programme appelé Entité Agissante Active. L’ensemble des entités agissantes forme l’image informatique de l’environnement.
Les entités agissantes perceptives envoient des perceptions simples qui sont des données sur l’environnement (quelqu'un est entré, une personne est tombée, on a appuyé sur un bouton, etc.). L’ensemble des perceptions simples est envoyé à un interpréteur de perception symbolique, qui est une perception de haut niveau composée d'une association de perceptions simples. Par exemple, la perception symbolique "la personne est tombée", peut être représentée par "la caméra a détectée que la personne est en position horizontale et la personne est sur le sol et le micro ne capte aucun bruit".
L'interpréteur interprète un scénario de perceptions symboliques qui calcule des perceptions de plus haut niveau. Toutes les perceptions sont envoyées à des interpréteurs de scénario d’interaction AmbiLive qui interprètent chacun un scenario. Les scenarii sont écrits par un prestataire à l’aide d’un outil appelé AmbiProg.
Les scenarii peuvent générer des actions à destination des entités agissantes actives. Ces actions sont arbitrées par un programme appelé AmbiCop afin de résoudre des conflits potentiels. Les entités agissantes, AmbiLive et Ambicop fonctionnent sur un exécutif MICE et est mis en place par un concepteur.

Présentation officielle d'ArCo

La vidéo ci-dessous montre la première vidéo de présentation de l'architecture ArCo.

La vidéo ci-dessous montre la deuxième vidéo de présentation de l'architecture ArCo.

Gestion des conflits entre les périphériques

La vidéo ci-dessous montre le travail réalisé par Germain Lemasson, lors de son stage de Master Recherche. Il avait pour objectif de créer un gestionnaire de conflits pour éviter d'envoyer des ordres contradictoires au même objet numérique ou de relayer l'information au bon objet numérique.

Intégration rapide avec d'autres systèmes

Lors d'un concours de robotique, Robofesta, nous avons fusionné l'architecture ArCo avec le système développé par le LIG. Nous voyons sur la vidéo ci-dessous le personnage virtuel de la plateforme MARC et le robot bioloïd réagir émotionnellement à des réponses de l'utilisateur.

AmbiProg

AmbiProg est un logiciel qui permet de créer des scénarii d'interaction avec l'environnement d'une personne. A titre d'exemple, les jeux sérieux StimCards et NaoSimon ont été créés avec AmbiProg.
AmbiProg est un langage de programmation visuelle qui permet de manipuler des concepts tels que les conditions, les itérations, le parallélisme, et les événéments. Il permet donc de créer des algorithmes complexes.
Ce langage de programmation existait avant ma thèse, sous le nom de KitRobot. Mon travail a consisté à l'adapter à mon contexte et à créer un interpréteur qui est capable de lire et d'interpréter le programme en temps réel.

La vidéo ci-dessous montre la façon dont on peut programmer des scénarios avec l'interface de programmation visuelle.

StimCards

StimCards est un jeu multimodal de questions/réponses entièrement configurable et créé avec l'architecture ArCo, ce qui implique qu'il est possible d'y intégrer des agents virtuels, des robots, des tablettes tactiles, des manettes de jeux, etc. Il est possible de brancher tout type de dispositifs numériques d'entrées et de sorties.

Un fort potentiel en accessibilité

Et cela en fait un important outil d'accessibilité, car une fois que le scénario est démarré, l'architecture utilise les périphériques disponibles. Ces périphériques peuvent varier, et le scénario continue à se dérouler. Par exemple, dans le cas où un agent numérique interagit avec l'utilisateur, il est possible de brancher un personnage virtuel, un robot, un haut-parleur. Dans tous les cas, le scénario utilise le périphérique disponible. C'est la même chose pour les périphériques d'entrée. Si l'utilisateur doit appuyer sur un bouton pour répondre à une question, l'appui peut venir d'un vrai bouton, d'une validation orale, d'un tablette, d'une validation gestuelle avec une Kinect, etc.
Ainsi, le scénario utilise des actions et des perceptions de haut niveau comme, par exemple, "dire" et "appui sur un bouton". Tous les périphériques capables d'effectuer ces actions et perceptions peuvent être utilisés par le scénario. Ainsi, un même scénario peut être utilisé par des personnes en situation de handicap en utilisant les périphériques adaptés aux capacités de la personne.

L'intérêt d'un jeu

Je m'intéresse aux jeux sérieux numériques car ils ont de nombreux intérêts. Premièrement, les jeux sont intéressants car sous couvert d'être une activité ludique, ils représentent un processus d'apprentissage intéressant. Les utilisateurs en tirent des bénéfices cognitifs sans avoir l'impression de faire des efforts.

Deuxièmement, les jeux qui utilisent les nouvelles technologies apportent plus de plaisirs aux utilisateurs que les jeux sur papier par exemple. Cela augmente donc leur motivation et leur engagement. Cela permet d'augmenter les bénéfices des rééducations, réhabilitations, entrainements cognitifs, etc.

Principe du jeu

StimCards s'utilise de la façon suivante :

  1. Un utilisateur dispose d’un paquet de cartes de jeux. Le visuel de chaque carte contient un code-barre appelé code QR. Lorsque le joueur présente une carte à la caméra, celle-ci détecte le code QR et décode son contenu. Son contenu est une fiche XML qui contient des informations sur l’exercice (type d’exercice, questions, proposition de réponses, indices…). Les exercices peuvent être des questions ouvertes, à choix multiples etc.
  2. Si l’interface de StimCards est active, elle affiche la question et des propositions de réponses s’il y en a. En l’absence d’interface, un robot ou un personnage virtuel peut énoncer la question. (Cette possibilité est laissé libre à l’utilisateur qui configure lui-même son scénario de jeu).
  3. L’utilisateur saisit sa réponse avec le dispositif actif (cela peut être une tablette tactile, une manette de jeu, une boîte de réponse…).
  4. La réponse est analysée et l’utilisateur configure le comportement de StimCards en cas de bonne ou de mauvaise réponse.

Démonstrations

La vidéo ci-dessous montre la présentation officielle de StimCards.

La vidéo ci-dessous montre un exemple de partie. Le comportement du robot est très répétitif. Cela n'est pas imputable à StimCards. C'est le scénario qui a été créé de manière à être répétitif. En retravaillant le scénario, il est possible de donner plusieurs réactions possibles au robot de manière à diminuer les possibilités d'ennui de l'utilisateur.

NaoSimon

NaoSimon une adaptation du célèbre jeu "Simon's game". Cette version du jeu a permis de tester l'apport du robot dans un jeu de mémoire, afin de vérifier si le fait de jouer avec un robot augmentait la charge cognitive.
Le jeu a été déclinée en trois versions :

  • Le jeu sur une tablette seule. L'utilisateur joue contre l'ordinateur.
  • Le jeu avec le robot et la tablette. L'utilisateur joue contre le robot qui utilise la tablette (voir la photo ci-dessous)
  • Le jeu avec le robot seul qui montre des panneaux de couleurs.

La configuration qui donne le plus de plaisir aux joueurs est celle qui contient le robot. Avec la tablette seule, les participants étaient très sérieux et très concentrés. Mais la charge cognitive n'a pas varié en fonction de la configuration.

Photo de Nao jouant avec la tablette

La vidéo ci-dessous montre un extrait d'une partie.

La vidéo ci-dessous montre un extrait d'une partie plus courte où l'utilisateur perd rapidement. C'est intéressant de voir la réaction du robot à ce moment-là.