Synopsis

7.1.1.1 Le projet Romeo

Le projet Romeo était un projet FUI nancé par la région Ile de France par l'inter- médiaire de Cap Digital. De nombreux partenaires industriels et laboratoires ont parti- cipé à la réalisation de ce projet piloté par Aldebaran¹, leader. L'objectif nal était de construire un robot humanoïde doté d'un certain nombre de capacités motrices, cogni- tives et de communication. Nous nous sommes intéressés plus spéciquement aux axes traitant de l'analyse audio du signal. Le robot ROMEO a été conçu pour évoluer dans un environnement domestique chez une personne en perte d'autonomie. Le public visé est très large : des enfants, adultes et personnes âgées (dont des mal-voyants). L'Institut de la Vision, localisé à Paris, était un des partenaires du projet et avait pour objectif de proposer à des personnes mal-voyantes de participer au projet. C'est entre autres, grâce

1. www.aldebaran-robotics.com

en couronne autour de la tête. Le partenaire Telecom Paris Tech devait également fournir au robot un signal relativement propre et non-bruité, contenant une seule source (et donc un seul locuteur). Ce second volet n'a pas encore vu le jour, nous n'avons donc pas pu travaillé directement avec les signaux audio issus de la capture du robot. Pour des raisons pratiques (enregistrements de corpus, analyse ne, etc.), nous avons préféré travailler sur des signaux de bonne qualité enregistrés sur micro-cravate.

Le signal audio devait être traité par le LIMSI pour la reconnaissance des émotions et la caractérisation (ou l'identication) du locuteur. Voxler², partenaire industriel, pour l'ajout d'applications de jeux (reconnaissance de chansons), de transcription automatique mais surtout de segmentation du signal en locuteur et en pseudo-phrases. A un autre niveau, Spirops³, également partenaire industriel, devait s'occuper du cerveau du robot, c'est-à-dire lui donner la capacité de prendre des décisions à partir d'entrées fournies.

Spirops devait également créer des applications type agenda, appel téléphonique.

Dans le cadre du projet, nous avons mis en place un module de reconnaissance automa- tique des émotions et de caractérisation du locuteur. Etant donné le caractère ambitieux du projet Romeo et de l'ensemble des recherches qui devaient y être menées, il est évident qu'un certain nombre de contraintes se sont imposées assez rapidement. La plus impor- tante concerne la qualité des signaux audio. Nous n'avons pas eu accès à des échantillons de signal capturés directement avec les microphones du futur robot, il a donc fallu tra- vailler en déporté. Nous n'avions pas accès non plus aux ltres amont qui étaient censés rendre le signal plus propre. C'est pourquoi nous avons du faire des choix an de pouvoir construire nos modules dans les meilleures conditions. Nous avons travaillé avec le robot NAO d'Aldebaran pour tout ce qui est intégration et communication avec les diérents modules, mais la capture audio n'a pas pu être réalisée avec les microphones du petit robot.

7.1.1.2 Eléments de contexte

L'élaboration de SysRELL est un compromis entre les derniers résultats des recherches du groupe et une mise en oeuvre ecace. C'est-à-dire que nous souhaitons mettre en place un système intégré pour pouvoir étudier l'inence des variabilités liées à l'interaction sur le système complet. An de limiter la complexité des variabilités, nous choisirons de xer celles correspondant à la tâche, la capture du son est également xée, par contre l'environnement acoustique reste variable.

1. Tâche xe : nous avons choisi une tâche de jeu émotion où le locuteur doit acter une émotion qui doit être reconnue par le robot NAO, suivant le même protocole que la collecte du corpus JEMO [Brendel et al. 10]. Le public visé est alors un public

2. www.voxler.eu 3. www.spirops.com

Figure 7.1 Interaction entre le robot NAO et une expérimentatrice

d'adultes actifs français (étudiants, chercheurs, industriels, etc.), nous nous plaçons alors hors de situations extrêmes (voix âgées, voix pathologiques). Les modèles de genre, de locuteurs et d'émotions seront construits sur la même base de données JEMO. Le choix d'un corpus acté permet de pouvoir s'adapter de manière plus ecace à l'application nale souhaitée (voir chapitre 5). L'application nale, inter- facée avec le module de Spirops est conçue pour s'adapter à plusieurs types de tâche (jeu, scénario de la vie quotidienne par exemple le réveil du matin, etc.). D'après les résultats du chapitre 5, l'utilisation d'un corpus d'apprentissage de plus grande taille (ou une conbinaison de plusieurs corpus) devrait permettre au système d'être plus adaptatif. Nous n'avons testé qu'une seule tâche et donc réduit la quantité de données à traiter pour l'apprentissage en nous limitant au corpus JEMO.

2. Capture xe : l'utilisation des microphones du robot lui-même apporte plusieurs problématiques nouvelles : la gestion de la distance entre le locuteur et le robot, le ltrage amont des signaux pour supprimer les bruits du robot lui-même (articula- tion, ventilation, etc.). Nous avons décidé de conserver le micro-cravate de bonne qualité (AKG PT40 Pro Flexx) utilisé pour la collecte de nos corpus. Ce choix per- met de ne pas prendre en compte les problèmes liés à la distance entre le locuteur et le robot qui seront évidemment à étudier lors de l'utilisation des microphones du robot. Nos micro-cravate sont de type cardioïde, cela signie qu'une partie du champ réverbéré est capturé avec la voix. Nous verrons que dans certains lieux, cela peut poser des problèmes importants.

Nous sommes donc dans une situation d'interaction entre un humain et un robot (gure 7.1), la capture du son ést réalisée avec un micro-cravate. Nous avons considéré qu'il n'y a pas de superposition de voix, c'est-à-dire que la situation ou deux personnes parleraient en même temps au robot n'est pas envisagée.

Figure 7.2 Architecture globale de SysRELL 7.1.1.3 Architecture du système

Le module SysRELL a été implémenté en interne en C++ lors du stage de Guillaume Dulin (Master Pro), mais également par Mariette Soury, alors ingénieur informatique.

C'est un executable autonome capable de tourner sur un PC. SysRELL (gure 7.2) permet d'analyser en temps réel un ux audio entrant :

1. de le segmenter,

2. d'identier le genre et si le locuteur fait partie de la base de locuteurs connus ou non, si oui, le l'identité du locuteur,

3. de reconnaître l'émotion exprimée par le locuteur parmis 4 états émotionnels : neutre, colère, joie et tristesse, cette reconnaissance est plus performante lorsqu'une normalisation au genre lui est associée.

Les sorties de SysRELL sont alors : le genre du locuteur (homme ou femme), son nom (base de données de 8 locuteurs, inconnu sinon), l'état émotionnel (neutre, colère, joie ou tristesse), la valence (neutre, positive ou négative) et l'activation (actif ou passif).

Segmentation La segmentation du ux audio est réalisée par la PME Voxler en fonction de l'activité vocale (intensité du signal et énergie dans les hautes fréquences). Si un silence de plus de 800 ms est détecté ou si plus de 5 s de données sont collectées, le système traite le segment capté. La durée maximale d'un segment a été xée à 5 s : c'est un compromis entre les capacités mémoire du système et la durée nécessaire pour une re- connaissance du locuteur satisfaisante. La librairie de Voxler permet également d'extraire plusieurs séries temporelles sur le segment (F0, Energie RMS, MFCCs et∆MFCCs, ZCR, FFT).

Identication du genre et du locuteur Un module parallèle cherche à identier le genre pour déterminer la norme à appliquer. Il permet également de reconnaître un locuteur si il appartient à la base de locuteurs connus.

Reconnaissance de l'état émotionnel Nous calculons 144 descripteurs à partir des séries temporelles extraites par la librairie Voxler. La sélection de ces descripteurs est un compromis entre un coup relativement bas en temps de calcul (et donc un re- lativement faible nombre de descripteurs) et la disponibilité des séries temporelles (par exemple, les formants ne font pas partie des séries temporelles extraites par la librairie Voxler, nous n'avons donc pas pu ajouter nos descripteurs d'articulation). Cet ensemble de 144 descripteurs peut encore être optimisé, certains fonctions doivent être ajoutées et d'autres supprimées. Les 144 descripteurs sont ensuite normalisés selon le genre du locuteur reconnu et utilisés pour identier l'émotion, la valence et le niveau d'activation selon des modèles construits avec libSVM [Chang and Lin 11]. An de pouvoir utiliser un système de détection automatique des émotions en application réaliste, il faut qu'il puisse eectuer ses calculs en temps réel (on considère un temps inférieur à 3 s acceptable pour l'application visée, un jeu). Dans notre application, le calcul des 144 descripteurs acous- tiques et la classication coûtent en moyenne 2,3 s (processeur intelcore2 Duo 1,6 gHz, 3,45 Go de mémoire), alors que la durée moyenne d'un segment dans le corpus JEMO est d'environ 1,9 s.