ECAMI

Co-encadrement de M. Timoth´ee R´eau, ing´enieur d’´etudes

_{Etude et d´}´ _{eveloppement d’un dispositif d’interaction multimodale pour l’aide et assistance `a domicile}

P´eriode : mai - aoˆut 2014

Financement : projet MSHS-T ECAMI

Le projet ECAMI, pour ´Etude de l’ACcessibilit´e dans une Maison Intelligente a permis notre premi`ere ´etude, d´eveloppement et tests de dispositifs d’interaction Homme-Maison. L’axe de recherche de ce projet ´etait de proposer un service d’interaction multimodale (tactile par tablettes, et vocal par une synth`ese vocale ambiante et une reconnaissance vocale avec un microphone port´e) et contextuellement enrichi par les informations remont´ees par les capteurs environnementaux de la plate-forme MIB (capteurs de mouvements, sur les portes et les meubles, etc.). La probl´ematique ´etudi´ee est donc tr`es large, depuis les probl´ematiques de l’IHM jusqu’aux capteurs et actionneurs de l’habitat intelligent, en passant par les aspects r´eseaux. Le projet comportait ´egalement un volet concernant l’acceptabilit´e des solutions technologiques. Plus largement, le projet ECAMI a constitu´e un terrain pratique pour le test des protocoles exp´erimentaux d´evelopp´es par les chercheurs, test impliquant l’utilisateur r´eel.

Dans le cadre de ce projet, nous avons essentiellement contribu´e sur les aspects r´eseaux : sans fil, sur la partie r´eseau de capteurs, et filaire, pour le transport des informations vocales (synth`ese et reconnaissance vocale). Dans cet objectif et en nous appuyant sur le middleware MiCom cit´e plus haut, nous avons propos´e une architecture o`u l’ensemble des donn´ees issues des dispositifs (domotiques, capteurs environnementaux et vocaux) convergeaient sur IP, plus pr´ecis´ement sur un bus logicielIVY, alors tr`es populaire dans le domaine de l’IHM. Cette architecture est repr´esent´ee sur la figure 3.6.

Un r´eseau de capteurs bas´e sur WiNo/OpenWiNo pr´esent´e au chapitre 1, a ´et´e d´eploy´e dans la MIB, et grˆace `a l’´ecosyst`eme Arduino, une grande vari´et´e de capteurs a pu ˆetre mise en place, en collaboration avec le Pr. Eric Campo du LAAS/CNRS :

- capteurs de mouvements infrarouge,

- contacts Reed dans les portes, les fenˆetres, un placard et le frigo, - capteurs de force (FSR) dans le lit et le fauteuil,

- capteurs de choc (vibration) sur le plancher pour la d´etection de chutes.

Le d´eploiement de ce r´eseau de capteurs `a la MIB, qui a perdur´e plusieurs ann´ees, a ´egalement permis d’´eprouver OpenWiNo et les protocoles impl´ement´es, en situation de d´eploiement r´eel. Il a ´egalement ´et´e

Figure 3.6 – Architecture des r´^{eseaux pr´esents sur la MIB}

l’occasion d’impl´ementer des protocoles sp´ecifiques, comme laMAC TDMA slott´ee bas´ee sur la synchro-nisationSiSP´evoqu´ee au §1.3.3.3qui est aujourd’hui encore utilis´ee `a la MIB.

Le bus IVY, qui est un bus logiciel fonctionnant sur IP multicast, a ´et´e d´eploy´e, en collaboration avec l’´equipe IHM. IVY transporte des chaˆınes de caract`eres et contrairement `a MQTT, ne propose pas d’organisation des donn´ees transport´ees (pas d’arbre, pas de topic) mais permet un abonnement simple par Expressions R´eguli`eres (Regexs). Classiquement en IHM, le bus IVY permet l’interconnexion d’agents de reconnaissance vocale et d’agents de synth`ese vocale, en lien avec leContrˆoleur de Dialogue (CdD)1. Nous y avons ´egalement connect´e les informations issues du r´eseau de capteurs via un agent d´eploy´e sur la gateway WSN.

Ce projet a ´egalement permis une forte interaction avec Dr. Nadine Vigouroux et Dr. Fr´ed´eric Vella de l’´equipe ELIPSE (IHM) du laboratoire. Dans ce cadre, nous avons co-encadr´e M. Timoth´ee R´eau, ing´enieur d’´etudes, qui a contribu´e au d´eveloppement d’un CdD enrichi par le r´eseau de capteurs sans fil. L’objectif ici est de renforcer la connaissance duCdDpour augmenter sa pertinence dans l’interaction avec l’utilisateur. Par exemple, si l’utilisateur demande `a la maisond’allumer la lumi`ere, si leCdDest capable de d´eterminer la pi`ece dans laquelle se trouve l’utilisateur grˆace `a la connaissance apport´ee par les capteurs de mouvements, alors leCdDpourra d´eduire la bonne lumi`ere `a allumer. Cet enrichissement du CdD peut ´egalement permettre l’augmentation de la robustesse de la reconnaissance vocale, en cas d’enregistrement bruit´e par exemple. L’architecture du contrˆoleur de dialogue enrichi par le r´eseau de capteurs est repr´esent´ee en figure3.7: on y voit le r´eseau de capteurs remonter des informations au nœud sink, qui les transmet au contrˆoleur de dialogue. A ce stade, nous n’avions pas de base de donn´ees : le contrˆoleur de dialogue ´etait charg´e d’assurer son propre historique, ce qui introduisait une grande limitation.

Un premier mod`ele de contrˆoleur de dialogue a ´et´e propos´e et le sc´enario  lever du lit  a ´et´e impl´ement´e dans unCdDsimple, via un automate d’´etat fini. Le sc´enario ´etait le suivant :

1. ´El´ement central dans le syst`eme d’interaction, qui, `a partir des interactions pass´ees, d´ecide de l’interaction suivante propos´ee `a l’utilisateur. LeCdDpeut ˆetre indirectement connect´e au monde physique pour connaˆıtre le contexte (via des capteurs) ou d´eclencher des actions sur l’environnement (via des actionneurs).

Figure 3.7 – ^{Architecture contrˆoleur de dialogue et dispositifs d’interaction enrichi par le r´eseau de} capteurs

- l’habitant, pr´ealablement couch´e, se l`eve de son lit. L’action est d´etect´ee par le capteur sous le tapis au pied du lit. LeCdDest donc pr´evenu que l’habitant se l`eve,

- le CdDsalue l’habitant, lui indique l’heure, et lui demande dans quelle pi`ece il veut se rendre via un message vocal. Il attend une ´eventuelle r´eponse de l’habitant via la reconnaissance vocale, - en fonction de la r´eponse (cuisine, salle de bain, toilettes, ...) le CdD se pr´epare `a allumer les

lumi`eres des diff´erentes pi`eces, au fur et `a mesure du d´eplacement de l’habitant dans la maison. L’information de d´eplacement est l`a-encore remont´ee par les capteurs et l’allumage des diff´erentes lumi`eres est r´ealis´e par leCdD.

- une fois l’habitant dans la cuisine et la d´etection de la pr´eparation de son petit d´ejeuner (ouverture des placards, du frigo, etc.), le CdD propose `a l’habitant d’ouvrir les volets par un message vocal et attend une r´eponse par la reconnaissance vocale. Si la r´eponse est positive, le CdD d´eclenche l’ouverture des volets.

Ces premiers travaux se sont r´ev´el´es fort structurants pour l’´equipe pluridisciplinaire. Ils ont permis la publication de plusieurs articles [94], [95] et [96] et une vid´eo de d´emonstration a ´et´e produite [REF]. Nous alors clairement identifi´e nos compl´ementarit´es et les perspectives de nos travaux. Tout d’abord, vis `a vis de l’´etat de l’art, notreCdDenrichi ´etait alors une vraie originalit´e. Cependant, son impl´ementation devenait tr`es complexe si nous visions plusieurs situations (plusieurs sc´enarios). En effet, si l’automate d’´etats finis avait permis la finalisation de la preuve de concept, sa structuration ne permettait ni l’impl´ementation d’un sc´enario complexe ni, encore moins, de s’affranchir de la notion mˆeme de sc´enario. Pourtant, l’´equipe souhaitait pouvoir proc´eder `a une ´evaluation de ces briques technologiques avec de vrais habitants, pour en ´evaluer l’int´erˆet, ce que nous pr´esenterons dans la section suivante.

D’un point de vue strictement R´eseaux et Protocoles, ´emergeait une perspective li´ee aux probl´ematiques ´evoqu´ees dans le chapitre 1 de ce document : la question de la latence introduite par la mise en veille des capteurs et les rendez-vousMAC, et de leur impact sur la r´eactivit´e du syst`eme d’interaction : comment traiter dynamiquement ces temps, suffisamment courts pour ˆetre n´egligeables devant le temps de l’interac-tion (humain, relativement lent), c’est-`a-dire n’introduisant aucune d´egradation perceptible par l’usager en interaction, mais tout en pr´evoyant des temps de veille n´ecessairement longs et fr´equents pour maxi-miser l’autonomie ´energ´etique des capteurs autonomes d´eploy´es. En effet, dans l’hypoth`ese d’un r´eseau d´eploy´e en dehors de la MIB, par exemple en suivant une approche TLL (True Life Lab), c’est-`a-dire chez un habitant en conditions r´eelles, les nœuds capteurs devaient pouvoir tenir plusieurs semaines voire plusieurs mois sans aucune maintenance des batteries. Nous savions [6] que pour atteindre cette dur´ee

en assurant une r´eactivit´e inf´erieure `a la seconde avec des batteries de dimension raisonnable, il fallait pouvoir jouer sur la dynamicit´e des protocoles.

Conf´erence : Adrien Van den Bossche, Eric Campo, Nadine Vigouroux, and Fr´ed´eric Vella. R´eseau de capteurs sans fil distribu´es pour le monitoring des activit´es de vie au sein d’une maison intelligente. In Journ´ees francophones Mobilit´e et Ubiquit´e (UbiMob), Sophia Antipolis, France, juin 2014

Conf´erence : Fr´ed´eric Vella, Nadine Vigouroux, Adrien Van den Bossche, Eric Campo, Blandine Boudet, and Pierre Rumeau. Etude de l’ACcessibilit´e de l’interaction dans une Maison Intelligente par des personnes fragilis´ees pour une meilleure autonomie `a domicile. In Journ´ees Annuelles de la Soci´et´e Fran¸caise de G´eriatrie et G´erontologie (JASFGG), Paris, France, octobre 2013