FR2989209A1 - Robot apte a integrer des dialogues naturels avec un utilisateur dans ses comportements, procedes de programmation et d'utilisation dudit robot - Google Patents

Abstract

L'invention concerne un robot humanoïde, ledit robot étant apte à dialoguer avec au moins un utilisateur, ledit dialogue utilisant deux modes de reconnaissance vocale, l'un ouvert et l'autre fermé, le mode fermé étant défini par un concept caractérisant une séquence de dialogue. Le dialogue peut également être influencé par des évènements qui ne sont ni des paroles ni un texte. Le robot de l'invention est apte à exécuter des comportements, à générer des expressions et des émotions. L'invention procure par rapport aux robots de l'art antérieur l'avantage de réduire considérablement le temps de programmation et la latence de l'exécution des séquences du dialogue, ce qui procure une fluidité et un naturel proches des dialogues humains.

Description

ROBOT APTE A INTEGRER DES DIALOGUES NATURELS AVEC UN UTILISATEUR DANS SES COMPORTEMENTS, PROCEDES DE PROGRAMMATION ET D'UTILISATION DUDIT ROBOT La présente invention appartient au domaine des systèmes de programmation de robots. Plus précisément, elle permet de doter un robot humanoïde déjà doté d'aptitude à exécuter des comportements de capacités de dialogue avancées avec un utilisateur humain. Un robot peut être qualifié d'humanoïde à partir du moment où il possède certains attributs de l'apparence et des fonctionnalités de l'homme: une tête, un tronc, deux bras, éventuellement deux mains, deux jambes, deux pieds... Dans le cadre de la présente invention, la caractéristique humanoïde la plus importante est cependant la capacité d'expression orale en dialogue avec un humain, ladite capacité d'expression devant être la plus coordonnée possible avec l'expression gestuelle et/ou symbolique de la personnalité et des émotions du robot. On imagine le développement d'applications du type « robot compagnon », c'est-à-dire un robot qui soit en mesure de prendre en charge, notamment pour le compte d'un ou plusieurs êtres humains en état de dépendance, un certain nombre de fonctions d'assistance dans la vie quotidienne, tout en apportant auxdits humains une présence qui puisse être considérée comme un substitut émotionnellement quasi-équivalent à la présence d'un assistant personnel humain. Pour cela, il est indispensable de développer l'aptitude desdits robots humanoïdes à dialoguer avec des êtres humains de la manière la plus proche possible des comportements humains. En particulier, il est nécessaire que le robot puisse interpréter des questions ou affirmations de l'être humain, émettre des répliques en mode conversationnel, avec une richesse d'expression correspondant à celle d'un être humain et des modes d'expression qui soient en synergie avec des types de comportements et d'émotions qui sont normalement ceux d'un être humain. Des premiers pas dans cette voie ont été accomplis grâce aux procédés de programmation de robots humanoïdes de marque NaoTM commercialisés par le demandeur de la présente demande de brevet et divulgués dans la demande internationale de brevet publiée sous le n °W02012/000927 relative à un robot joueur et dans la demande internationale de brevet publiée sous le n °W02012/010451 relative à un robot humanoïde doté d'une interface de dialogue naturel. Cependant, les robots divulgués par ces documents ne peuvent exécuter qu'un nombre limité et prédéterminé d'éléments de dialogue, ou tout au 5 moins, si l'on souhaitait multiplier lesdits éléments de dialogue vers une diversité correspondant au comportement normal d'un être humain, la combinatoire deviendrait rapidement inaccessible à un. Pour pouvoir fournir notamment les services d'assistance à la personne indiquée ci-dessus, il est donc nécessaire de doter les robots humanoïdes d'une aptitude 10 conversationnelle plus riche que celle des robots de l'art antérieur. Pour ce faire, la présente invention implante dans ledit robot un agent conversationnel, des outils de reconnaissance vocale et des outils d'analyse des comportements des êtres humains avec lesquels le robot converse. 15 A cet effet, la présente invention divulgue un robot comprenant au moins un capteur choisi dans un groupe comprenant des premiers capteurs de type sonore et des deuxièmes capteurs d'au moins un deuxième type d'évènements générés par au moins un utilisateur dudit robot, au moins un 20 module de reconnaissance d'évènements en sortie dudit au moins un capteur et au moins un module de génération d'évènements vers ledit au moins un utilisateur, ledit robot étant caractérisé en ce qu'il comprend en outre un module de dialogue avec ledit au moins un utilisateur, ledit module de dialogue recevant en entrée des sorties dudit au moins un module de 25 reconnaissance et produisant des sorties vers ledit module de génération d'évènements choisies dans un groupe comprenant des paroles, des mouvements, des expressions et des émotions. Avantageusement, ledit au moins un module de reconnaissance 30 d'évènements reçoit des entrées en provenance d'au moins deux capteurs appartenant à au moins deux types différents, et en ce que ledit au moins un module de génération d'évènements en sortie dudit module de dialogue est apte à produire en sortie des évènements prenant en compte lesdites entrées en provenance desdits au moins deux capteurs. 35 Avantageusement, ledit au moins un module de reconnaissance est apte à structurer les entrées en concepts selon un arbre hiérarchique dynamique. Avantageusement, une entrée dans ledit au moins un module de 5 reconnaissance s'applique à des entrées textuelles ou vocales et active une grammaire dans ledit module de dialogue. Avantageusement, une entrée dans ledit au moins un module de reconnaissance active/désactive la reconnaissance de ladite entrée. 10 Avantageusement, ledit au moins un module de reconnaissance comprend un premier et un deuxième sous-modules, le premier sous-module opérant sur une liste fermée de mots rattachés à au moins un concept et le deuxième sous-module opérant sur une liste ouverte de mots. 15 Avantageusement, une sortie du premier sous-module est seule fournie au module de dialogue. Avantageusement, une sortie du deuxième sous-module est seule fournie au 20 module de dialogue. Avantageusement, une sortie du premier sous-module et une sortie du deuxième sous-module sont conjointement fournies au module de dialogue. 25 Avantageusement, une sortie du premier sous-module est d'abord seule fournie au module de dialogue, ladite sortie du premier sous-module étant confirmée dans le module de dialogue par une sortie du deuxième sous-module. 30 Avantageusement, aucune des sorties des premier et deuxième sous-modules ne génère de sortie du module de dialogue et en ce que ledit robot propose au moins une entrée audit au moins un utilisateur. Avantageusement, le module de dialogue reçoit en outre en entrée des 35 éléments dynamiques en provenance d'une application.

Avantageusement, au moins une sortie du module de dialogue est fournie à un module apte à exécuter une fonction choisie dans un groupe de fonctions de génération d'au moins une expression dudit robot, de décision de génération d'au moins un comportement dudit robot et de génération d'au moins une émotion dudit robot. Avantageusement, ladite fonction de génération d'au moins un comportement prend en compte les contraintes du système dudit robot.

Avantageusement, ladite fonction de génération d'au moins une émotion est apte à générer une suite d'expressions prédéfinies entre un état neutre et un état prédéfinie en réponse à des évènements en entrée.

Avantageusement, le robot humanoïde de l'invention comprend en outre un module de reconnaissance visuelle, ledit module étant apte à interpréter au moins un signe dudit au moins un utilisateur comme un commencement ou une fin d'une séquence d'un dialogue.

Avantageusement, ledit module de dialogue comprend un sous-module d'analyse lexicale et un sous-module d'interprétation des sorties dudit sous-module d'analyse lexicale apte à générer des concepts auxquels sont rattachés les mots du dialogue courant.

Avantageusement, ledit module de dialogue est apte à traiter des questions et des commandes dudit au moins un utilisateur relatives à l'état de son système physique et/ou logique. L'invention divulgue également un procédé de dialogue entre un robot humanoïde et au moins un utilisateur, comprenant au moins une étape de reconnaissance d'entrées en provenance d' au moins un capteur choisi dans un groupe comprenant des premiers capteurs de type sonore et des deuxièmes capteurs d'au moins un deuxième type visuel d'évènements générés par ledit au moins un utilisateur et une étape de génération d'évènements vers ledit au moins un utilisateur, ledit procédé étant caractérisé en ce qu'il comprend en outre une étape de dialogue avec ledit au moins un utilisateur' ladite étape de dialogue recevant en entrée des sorties de ladite au moins une étape de reconnaissance et produisant des sorties vers ladite étape de génération d'évènements choisies dans un groupe comprenant des paroles, des mouvements, des expressions et des émotions. Avantageusement, ledit robot dialogue avec au moins deux utilisateurs, des paramètres caractérisant lesdits au moins deux utilisateurs étant stockés 10 dans une mémoire dudit robot pour être utilisés quand ledit robot reconnaît un des au moins deux utilisateurs. L'invention divulgue également un programme d'ordinateur embarqué sur un robot humanoïde comprenant des instructions de code de programme 15 permettant l'exécution du procédé de l'invention lorsque le programme est exécuté sur un ordinateur, ledit programme étant adapté pour gérer un dialogue entre ledit robot humanoïde et au moins utilisateur, ledit programme d'ordinateur comprenant un au moins un module de reconnaissance d'évènements en sortie d'au moins un capteur choisi dans un groupe 20 comprenant des premiers capteurs de type sonore et des deuxièmes capteurs d'au moins un deuxième type visuel d'évènements générés par ledit au moins un utilisateur, au moins un module de génération d'évènements vers ledit au moins un utilisateur, ledit programme étant caractérisé en ce qu'il comprend en outre un module de dialogue avec ledit au moins un 25 utilisateur, ledit module de dialogue recevant en entrée des sorties dudit au moins un module de reconnaissance et produisant des sorties vers ledit module de génération d'évènements choisies dans un groupe comprenant des paroles, des mouvements, des expressions et des émotions. 30 L'invention divulgue également un programme d'ordinateur comprenant des instructions de code de programme configurées pour générer un programme d'ordinateur embarqué sur un robot humanoïde comprenant des instructions de code de programme permettant l'exécution du procédé de l'invention et le transmettre à au moins un robot humanoïde. 35 L'invention permet l'utilisation de langages de programmation déjà en usage dans le domaine des agents conversationnels, la syntaxe desdits langages étant déjà connue d'une communauté importante de programmeurs qui seront ainsi disponibles pour développer de nouvelles applications mettant en oeuvre la présente invention. Mis en oeuvre dans le cadre de la présente invention, les agents conversationnels de l'art antérieur voient leurs possibilités accrues de manière considérable grâce à l'intégration de fonctionnalités évoluées de reconnaissance de la parole, ainsi qu'à la prise en compte des informations en provenance d'autres capteurs du robot, notamment de reconnaissance visuelle, qui lui permettent de détecter les situations d'activation des dialogues et ses interlocuteurs. Un dialogue selon le procédé de l'invention pourra être adapté à différentes catégories d'éléments de conversation avec des personnalités de robots différentes qui seront fonction des préférences de leur utilisateur. Le robot pourra exprimer des émotions en adéquation avec lesdits éléments de conversation avoir des comportements également synchronisés avec lesdits éléments, ce qui permettra la création de scenarios fluides d'échanges entre un utilisateur et son ou ses robots. En outre, le robot pourra fournir des informations sur l'état d'un certain nombre d'éléments de son système (durée restante d'autonomie de la batterie, par exemple) et recevoir des commandes système dans un mode dialogue avec un utilisateur, ce qui améliore grandement l'ergonomie d'usage dudit robot.

L'invention sera mieux comprise et ses différentes caractéristiques et avantages ressortiront de la description qui suit de plusieurs exemples de réalisation et de ses figures annexées dont : - La figure 1 représente un robot humanoïde apte à mettre en oeuvre l'invention dans plusieurs de ses modes de réalisation ; - La figure 2 représente un organigramme général des traitements selon plusieurs modes de réalisation de l'invention; - La figure 3 représente les blocs de traitement d'un module de gestion d'un comportement dialogue et d'un module de reconnaissance vocale selon plusieurs modes de réalisation de l'invention; - La figure 4 représente un exemple d'arborescence de plusieurs niveaux de dialogues selon plusieurs modes de réalisation de l'invention; - La figure 4a représente un arbre de concepts selon plusieurs modes de réalisation de l'invention; - La figure 5 représente un organigramme simplifié des traitements du module de reconnaissance vocale dans plusieurs modes de réalisation de l'invention ; - La figure 6 représente le flot de données entre plusieurs modules logiciels configurés pour mettre oeuvre l'invention dans plusieurs de ses modes de réalisation ; - La figure 6a illustre le fonctionnement d'un moteur d'émotion dans certains modes de réalisation de l'invention ; - La figure 6b illustre le fonctionnement d'un moteur de décision dans certains modes de réalisation de l'invention ; - La figure 7 représente les différentes fonctions en entrée et en sortie du module de gestion d'un dialogue pour mettre oeuvre l'invention dans plusieurs de ses modes de réalisation ; - La figure 8 représente le modèle de données d'un module d'analyse et d'interprétation de dialogues pour mettre en oeuvre l'invention dans plusieurs de ses modes de réalisation ; - La figure 9 représente l'architecture des modules logiciels implantés sur un robot configuré pour mettre oeuvre l'invention dans plusieurs de ses modes de réalisation.

La figure 1 représente un robot humanoïde apte à mettre en oeuvre l'invention dans plusieurs de ses modes de réalisation. Ce robot humanoïde est représenté sur la figure dans un mode de réalisation de l'invention. Un tel robot a été divulgué notamment dans la demande de brevet W02009/124951 publiée le 15/10/2009. Cette plateforme a servi de base aux améliorations qui ont conduit à la présente invention. Dans la suite de la description, ce robot humanoïde peut être indifféremment désigné sous cette appellation générique ou sous sa marque commerciale NAOTM, sans que la généralité de la référence en soit modifiée.

Ce robot comprend environ deux douzaines de cartes électroniques de commande de capteurs et d'actionneurs qui pilotent les articulations. La carte électronique de contrôle comporte un microcontrôleur du commerce. Ce peut être par exemple un DSPICTM de la société Microchip. C'est un MCU 16 bits 5 couplé à un DSP. Ce MCU a un cycle d'asservissement en boucle d'une ms. Le robot peut également comporter d'autres types d'actionneurs, notamment des LED (Diodes électroluminescentes) dont la couleur et l'intensité peuvent traduire les émotions du robot. Celui-ci peut également comporter d'autres types de capteurs de position, notamment une centrale inertielle, des FSR 10 (Capteurs de pression au sol), etc.... La tête 110 comporte l'intelligence du robot, notamment la carte qui exécute les fonctions de haut niveau qui permettent au robot d'accomplir les missions qui lui sont assignées, notamment, dans le cadre de la présente invention, pour l'exécution de dialogues écrits par un utilisateur. La tête comportera 15 avantageusement également des cartes spécialisées, notamment dans le traitement de la parole (synthèse et reconnaissance) ou de la vision. S'agissant de la reconnaissance de la parole, dans l'architecture de traitement des signaux audio actuellement utilisée, lesdits signaux audio sont capturés par quatre microphones et traités de manière logicielle dans des 20 modules spécialisés qui sont décrits en commentaires à la figure 9. La direction de provenance des sons peut être déterminée analyse des différences de date d'arrivée des signaux sonores sur les quatre capteurs. Les paroles sont reconnues par un logiciel de reconnaissance vocale à moteur grammatical (par exemple du type commercialisé par la société 25 NuanceTM) ou à interpréteur de langage naturel. La tête comporte également une ou plusieurs cartes spécialisées dans le traitement d'entrées/sorties de service, comme l'encodage nécessaire à l'ouverture d'un port pour établir une communication à distance sur un réseau étendu WAN (Wide Area Network). Le processeur de la carte peut 30 être un processeur x86 du commerce. On choisira de manière privilégiée un processeur à basse consommation, par exemple un ATOMTM de la société Intel (32 bits, 1600 MHz). La carte comporte également un ensemble de mémoires RAM et flash. Cette carte gère également les communications du robot avec l'extérieur (serveur de comportements, autres robots...), 35 normalement sur une couche de transmission WiFi, WiMax, éventuellement sur un réseau public de communications mobiles de données avec des protocoles standards éventuellement encapsulés dans un VPN. Le processeur est normalement piloté par un OS standard ce qui permet d'utiliser les langages de haut niveau usuels (C, C++, Python, ...) ou les langages spécifiques de l'intelligence artificielle comme URBI (langage de programmation spécialisé dans la robotique) pour la programmation des fonctions de haut niveau. Le robot va pouvoir exécuter des comportements pour lesquels il pourra avoir été programmé à l'avance, notamment par un code généré selon l'invention divulguée dans la demande de brevet internationale publiée sous le n °W02012/010451 déjà citée, ledit code ayant été créé par un programmeur dans une interface graphique. Selon cette invention et dans la suite de la présente description, un comportement est une combinaison d'actions (mouvements, paroles) et éventuellement d'évènements. Ces comportements peuvent également avoir été agencés dans un scenario créé par un utilisateur qui n'est pas un programmeur professionnel en utilisant l'invention divulguée dans la demande de brevet W02011/003628. Dans le premier cas, il peut s'agir de comportements articulés entre eux selon une logique relativement complexe dans laquelle les séquences de comportements sont conditionnées par les évènements qui se produisent dans l'environnement du robot. Dans ce cas, un utilisateur qui doit disposer d'un minimum de compétences de programmeur peut utiliser l'atelier ChorégrapheTM, dont les principaux modes opératoires sont décrits dans la demande citée. Dans le deuxième cas, la logique de déroulement du scenario n'est pas en principe adaptative. Selon la présente invention, un programmeur est en mesure de produire un scenario complexe comprenant des ensembles de comportements comprenant des gestes et mouvements divers, des émissions de signaux sonores ou visuels, et surtout des dialogues naturels entre le robot et un être humain ou un autre robot, lesdits dialogues étant coordonnés avec la personnalité et les émotions du robot et le contexte sémantique et évènementiel de la conversation. La figure 2 représente un organigramme général des traitements selon 35 plusieurs modes de réalisation de l'invention. -10- Selon l'invention, un module 210 d'écriture de dialogues implanté sur une une station de travail, par exemple un PC, distincte du robot est destinée à programmer des scenarios de dialogues. Lesdits dialogues pourront avoir plusieurs personnages, un ou plusieurs robots et un ou plusieurs locuteurs.

Ledit module est avantageusement implanté dans l'atelier logiciel ChorégrapheTM qui permet de programmer des comportements du robot, les dialogues étant mixés au sein de scenarios avec des comportements à exécuter par le robot en relation avec les éléments des dialogues. Un module de reconnaissance vocale 220 dont les fonctionnalités ont été indiquées en commentaire à la figure 1 est implanté sur le robot. Il est destiné à interpréter les éléments des dialogues créés dans le module 210 d'écriture de dialogues, lesdits éléments de dialogues étant transmis au robot par une interface de communication filaire ou sans fil, selon les modalités décrites plus haut en commentaire à la figure 1. Les éléments des dialogues transmis au module 220 sont compilés par exemple dans un langage utilisant la syntaxe normalisée BNF (Backus Normal Form). Par exemple, une suite de mots sera interprétée comme un « ET » logique, un « OU » logique devant être symbolisée de manière différente, par exemple par un « I ». Le fonctionnement du module 220 de reconnaissance vocale est détaillé plus loin dans la description en commentaire à la figure 5. Les éléments en provenance du module 210 d'écriture des dialogues et les sorties du module 220 de reconnaissance vocale sont passés à un module moteur de dialogue 230. Ledit moteur génère des paroles, émotions, expressions, comportements et évènements créés dans le module 210, selon des modalités expliquées en commentaire aux figures 6 et 7. Un comportement est une suite de gestes définissant un mouvement composé (se lever, jouer au football, etc...). Une expression est un comportement d'un type particulier défini pour un dialogue donné par un couple parole/action. Une action peut être une combinaison de mouvements et/ou de signes émis par exemple par le LED du robot. Un procédé de création de scénarios constitués de suites d'expressions a été divulgué par la demande internationale publiée sous le n°W02011/003628. Une émotion est une suite d'expressions définie par une expression terminale et une suite d'expressions qui tendent vers l'expression terminale. A titre d'exemple, on peut définir les émotions E;,, suivantes : « heureux/triste », « fatigué », « effrayé », « excité », « curieux », chaque expression Ei,,,pour i variant de 1 à n étant une expression intermédiaire entre un état de référence et l'expression En,n. Si le robot est dans un état Ebp p différend de n, une liste d'évènements définies pour provoquer l'émotion n fera passer le robot de l'état Ebp à un état Ebn. Le langage de description des dialogues est dérivé du langage ChatScript (http://chatscriptsourceforge.net/). Dans la syntaxe ChatScript, on écrit un scénario comme un ensemble de règles. Par exemple : ? : VIANDE (vous aimez la viande) Oui Une règle complète comprend généralement : - un type, « ?: » dans l'exemple, qui indique une question ; - une étiquette, « VIANDE » dans l'exemple, qui peut être omise, mais qui, lorsqu'elle est présente, permet des appels par d'autres dialogues ; - une entrée caractérisée par un motif indiqué entre parenthèses, « (vous aimez la viande) » dans l'exemple, phrase à laquelle seront rattachées les phrases comprenant ces trois mots dans cet ordre, mais également d'autres mots : « Albert, vous aimez la viande », Albert, vous aimez la viande rouge », ; - une sortie, « Oui » dans l'exemple Selon l'invention, le langage est adapté pour mixer les éléments de dialogues avec des comportements du robot. Des exemples non limitatifs d'adaptation sont donnés dans la suite de la description.

Par exemple, un comportement sera défini par une chaîne de caractères unique (par exemple: « échec », « football », « taïchi », etc..). Une émotion également, étant entendu qu'un code indiquera qu'il s'agit d'une émotion (on peut par exemple utiliser une initiale majuscule : « Heureux/Triste », « Fatigué », « Effrayé », « Excité », « Curieux »,...).Le langage utilisé permet d'écrire simplement plusieurs formulations pour une phrase de l'utilisateur (différentes formulations de 'bonjour' par exemple). Une entrée peut être une phrase de l'entité dialoguant avec le robot (un « utilisateur » qui peut être un être humain ou un autre robot), un évènement ou les deux (je dis bonjour en avançant la main vers le robot). Pour une phrase de l'utilisateur, ce langage permet d'exprimer plusieurs réponses possibles sous forme de phrases, -12- d'émotions, d'évènements ou de comportements. Un comportement de dialogue peut par exemple être du type dans lequel le robot suit l'utilisateur du regard et analyse les mouvements de l'utilisateur pour réaliser des réponses plus naturelles (par exemple ne pas parler en même temps que l'utilisateur). Chaque élément du langage de dialogue est retranscrit dans son équivalent dans le module 220 comprenant le moteur de reconnaissance vocale, ledit moteur n'étant apte qu'à reconnaître de manière sûr qu'un nombre de mots limité. Grâce à cette transformation, nous avons la garantie que chaque phrase reconnue possède une réponse. A l'écriture du dialogue, pas à l'exécution, nous générons donc l'ensemble des dialogues et l'ensemble des entrées du dialogue au format de la reconnaissance vocale. Il est donc important que le langage de description de dialogues possède un équivalent dans la reconnaissance vocale, ce qui n'est pas le cas d'un dialogue au clavier qui est le contexte connu d'utilisation du langage ChatScript. La grammaire du langage de description des dialogues comporte notamment les fonctionnalités suivantes : 1) Reconnaissance de motifs (ou pattern matching) : Certains motifs sont signalés dans le script du dialogue par un signe : `Ou' accepte une liste de mots possibles, par exemple : [salut bonjour] ; `Et' cherche une liste exacte de mots, par exemple : le suis content' ; Mots optionnels, par exemple : salut f mon robot'} ; Mots interdits, par exemple : je suis !pas content ; le mot pas ne vérifie pas l'entrée ; Mots inconnus, par exemple : mon nom est * ; on ne connait pas le nom de l'utilisateur ; 2) Contexte dans un dialogue ; on passe d'un dialogue à l'autre à l'aide de phrases trigger, par exemple : - Ut : (parlons de voiture) ; cette phrase va provoquer le lancement du dialogue sur les voitures ; -13- 3) Sous-dialogue ; un sous dialogue est activé sur certaines phrases et peut s'enchainer en cascades, par exemple : - U : (comment vas-tu ?) Je vais bien et toi ? A : (je ne vais pas bien) ha bon pourquoi ? B: (je suis malade) Ho dommage, veux tu un médicament ? A : (je vais bien) super Cette fonctionnalité de sous-dialogue peut par exemple donner lieu à un dialogue du type: Humain : Comment vas-tu ? Robot : je vais bien et toi ? Humain : Je ne vais pas bien Robot : ha bon, pourquoi ? Humain : Je suis malade 4) Evènements : La prise en compte d'évènements comme entrée d'un dialogue au même titre que les paroles captées par le robot donne à l'agent conversationnel de l'invention des potentialités qui n'existent pas dans l'art antérieur. En particulier, la reconnaissance visuelle du robot lui permet de détecter une personne dans son environnement et de lui adresser un salut, comme ce sera le cas lorsque la personne s'adresse à lui : - U : ([e :faceDetected salut]) salut toi Si le robot voit une personne ou si quelqu'un dit 'salut', alors le robot répond 'salut toi'. Un évènement peut être également déclenché en sortie d'un dialogue, éventuellement par le lancement d'une application : - U : (j'ai faim) $userstate='faim' $userstate='faim' va à la fois affecter la faim à userstate et lancer un évènement [userstate,faim] sur lequel une application peut s'abonner ; 5) Sélection de comportements implicites ou explicites : - U : (tu me reconnais ?) [$faceRecognized==" run :faceRecognition je ne te reconnais pas mais je vais me souvenir de toi la prochaine fois] -14- 6) Propositions ; lorsque le robot ne comprend pas ou comprend mal ce que dit l'utilisateur, alors il consomme une proposition du dialogue courant afin de le préciser, par exemple : - Proposai : quel âge as-tu ? - U : (j'ai [5 6 7 8] ans) tu es jeune ! 7) Variables ; le dialogue peut stocker des informations de l'utilisateur, par exemple : - U : (j'ai _[5 6 7 8] ans) $age=$1 tu es jeune ! 8) Eléments dynamiques ; variables et listes (mp3, applications, préférences...) peuvent être intégrés au dialogue en entrée et en sortie, par exemple : - U : (que sais tu faire ?) Je sais applications - U : (quel est ton nom ?) mon nom est $nom - U : ({lance lis raconte} * _-application) ok je lance $1 $application peut etre par exemple (`trois mousquetaires', 'le monde') 9) Emotions, SAD, HAPPY, CURIOUS, SCARED, TIRED (ou TRISTE, HEUREUX, CURIEUX, EFFRAYE, FATIGUE), soit: - U : (je ne t'aime pas !) ça me rend triste TRISTE 10) Règles d'effacement ; une entrée peut être désactivée ou activée afin d'éviter un phénomène de répétition dans les réponses ; la même entrée peut ainsi être répétée dans le dialogue ou dans plusieurs dialogues, les règles d'effacement permettront à l'ensemble des entrées d'être interprétées, par exemple : - U : delete (comment vas-tu) je vais bien - U : (comment vas-tu nao) tu te souviens de mon nom ! je vais bien - U : (comment vas-tu) comme tout à l'heure 11) Règles de réponse ; on peut faire produire plusieurs sorties possibles par le robot entre lesquelles le choix est déterminé en fonction des entrées qu'il reçoit du ou des utilisateurs de manière déterministe (toujours la même sortie, ou la sortie d'un rang donné dans la liste, quelle que soit l'entrée), aléatoire, séquentielle (l'entrée i+1 déclenche la sortie j+1 si l'entrée i déclenche la sortie j) ou conditionnelle. Le module de dialogue a accès à l'ensemble de la mémoire du robot et -15- peut donc donner une réponse en fonction de valeurs de la mémoire du robot; les sorties peuvent être effacées après avoir été utilisées pour ajouter de la variété au dialogue ; à titre d'exemple :. - U : (comment vas-tu ) ['je vais bien' je te l'ai déjà dis'] # séquentiel par défaut - U : (comment vas-tu) Arandom ['je vais bien' je vais très bien' je vais super bien'] - U : (quel est ton nom) ^first ['mon nom est $name"je n'ai pas de nom'] # Ici 'mon nom est $name' est affichable uniquement si $name existe. - U : (comment vas-tu) ^delete je vais bien # effacer la règle après l'affichage de la réponse 12)Lancer un sous-dialogue, topic: - U : (je veux parler de voitures) topic :cars La figure 3 représente les blocs de traitement d'un module de gestion d'un comportement dialogue et d'un module de reconnaissance vocale selon plusieurs modes de réalisation de l'invention.

Lorsqu'un dialogue est exécuté par le runtime embarqué sur le robot, le moteur de dialogue 230 agit à la fois sur le réseau et les listes de dialogues 310, 330 et sur la reconnaissance vocale 220. Le réseau de dialogue 310 est l'ensemble structuré des dialogues qui indique la façon de les articuler : d'abord une introduction puis un autre dialogue par exemple. Le réseau donne un sens aux dialogues. La liste 330 est la liste non structurée des dialogues actifs qui est présente à la fois dans le moteur de dialogue et dans le moteur de reconnaissance vocale. Un dialogue peut être activé ou désactivé (ce qui affecte simultanément toutes ses entrées 340). L'activation/désactivation peut être déclenchée de manière automatique par un trigger (ut :) ou de manière manuelle par un utilisateur. Le fait de minimiser le nombre de dialogues actifs à un moment donné permet d'optimiser les performances de la reconnaissance vocale en qualité et temps de traitement. On peut paramétrer les dialogues dans l'éditeur de manière à ce qu'ils restent actifs même en cas d'ouverture d'un nouveau dialogue, la solution par défaut étant que l'ouverture d'un nouveau -16- dialogue ferme le dialogue précédent. Une entrée d'un dialogue peut également être activée/désactivée individuellement, soit par branchement sur un sous-dialogue soit par effacement effectué pour éviter une répétition d'un élément du dialogue en cours. Le moteur de dialogue 230 comprend un module de reconnaissance de motifs 320 dont le fonctionnement a été illustré en commentaire à la figure 2 (point 1). Il comprend également un arbre de concepts dynamiques 350. Un concept est une liste de mots que l'on définit comme sémantiquement équivalents dans un dialogue donné. A titre d'exemple, la phrase « j'habite » est considérée dans un dialogue donné comme sémantiquement équivalente aux phrases « je vis » « je loge » « j'habite », « moi, je vis » «moi, je loge » « moi j'habite »...Nous allons donc définir un concept (habiter) et un concept (je) Concept :(habiter) (vis loge habite habiter vivre loger) Concept : (je) (moi je j'ai) La phrase s'écrira donc à plusieurs endroits dans les dialogues : U : (-je habiter) Un arbre de concept dynamique groupe plusieurs concepts organisés hiérarchiquement. Il sera également possible de modifier la liste des phrases rattachées à un concept à l'exécution. A titre d'exemple, le concept « nourriture » regroupe les concepts « fruits » et « viande » et le concept « fruits » regroupe « banane » et « orange »: Concept :(nourriture) (fruit viande) Concept :(fruit) (banane orange) Il sera possible d'ajouter de nouveaux fruits pendant les dialogues. Les dialogues suivants pourront ainsi être réalisés : U : ( connais tu _{de la des} _nourriture ) oui je connais $1 $2 Ce qui donne à l'exécution : Utilisateur : connais tu la banane ? Robot : oui je connais la banane U : (indique moi un fruit) fruit est un fruit -17- Utilisateur : indique moi un fruit Robot : banane est un fruit L'entrée dans un dialogue de la liste 330 active une grammaire dans la liste 5 de grammaires 360 du module de reconnaissance vocale 220. La liste d'entrées 370 du module de reconnaissance vocale est activée/désactivée de manière synchronisée avec la liste d'entrées 340 du module de dialogue. La modification d'un concept dans l'arbre des concepts dynamiques 350 du module de dialogue 230 entraîne une adaptation des entrées dynamiques 10 380 du module de reconnaissance vocale. La figure 4 représente un exemple d'arborescence de plusieurs niveaux de dialogues selon plusieurs modes de réalisation de l'invention. Plusieurs dialogues sont représentés sur la figure. Ils peuvent tourner en 15 parallèle (avec une pile de priorités), un dialogue pouvant en remplacer un autre. Un dialogue comprend trois niveaux logiques dans le module moteur de dialogue 230 embarqué sur le robot: - Un niveau 410 comprenant les dialogues actifs par défaut : des 20 dialogues généraux 4110 (salutation, présentation, humeur) et un dialogue dit « système » 4120 permettant de connaitre l'état du robot (batterie, température, configuration...) ou donner des commandes élémentaires (se lever, marcher...) ; la possibilité non seulement d'obtenir des informations sur l'état des fonctions vitales du robot, 25 mais de pouvoir en commander certaines (se mettre en mode veille, se brancher à une prise d'alimentation...) permet d'abaisser la barrière psychologique ressentie par des utilisateurs non techniciens dans leur confrontation à des robots ; - Un niveau 420 comprenant les routines de sélection des dialogues en 30 fonction des entrées de l'utilisateur, ladite sélection pouvant être déclenchée par un trigger Ut :; plusieurs sélections 4210, 4220, 4230, 4240, par exemple, peuvent être programmées ; - Un niveau 430 comprenant des applications 4310, 4320, 4330, par exemple, qui sont des enchaînements de dialogues ou des fichiers et -18- sont susceptibles d'être lancés automatiquement ou manuellement par un utilsateur. Par défaut un dialogue contenant des généralités et des commandes systèmes (`parle plus fort' par exemple) sont chargés. Des phrases trigger 5 peuvent alors déclencher le chargement d'autres dialogues par exemple pour : - Changer de sujet de discussion (parler de voitures, de sa journée...) ; - Expliquer ce que le robot sait faire (le sais raconter une histoire') ; 10 cette partie contient des éléments dynamiques : mp3 installés, applications installées ; toute application pouvant être lancée par la reconnaissance vocale doit contenir des informations : son thème (jeu, informations...) et optionnellement un dialogue précisant l'application (Le robot peut indiquer qu'Alice au pays des 15 merveilles est une histoire avec une petite fille...) ; - Lancer le dialogue d'une application (une histoire interactive par exemple) Un choix peut être proposé: deviner une personne célèbre, sélectionner un comportement, choisir un produit, chercher une personne dans une 20 entreprise... Le choix peut être fait soit par le robot (l'humain doit comprendre ce que veut le robot), soit par l'humain (le robot doit comprendre le choix du robot). Ce choix peut être réalisé avec un dialogue comme décrit précédemment mais ce dialogue implique de répéter souvent les même phrases ce qui rend 25 le dialogue difficile à écrire : U : (devine à qui je pense) c'est un homme ? A : (oui) c'est une femme ? B : (oui) ... 30 B : (non) ... A : (non) c'est un personnage de fiction ? La notion de concept permet de parcourir un arbre des possibles. Un concept est un mot lié à d'autres mots, phrases ou concepts. 35 Concept : (homme) ['il respire' c'est un humain'] -19- Concept: (superman) [homme superhero -vole cape] Concept : (halliday) [chanteur homme] Concept: (tous) [superman -halliday] La nature hiérarchique de l'arbre des possibles est illustrée sur la figure 4a 5 pour l'exemple ci-dessus. Les mots représentent les feuilles de l'arbre. Les concepts représentent les noeuds de l'arbre. Les noeuds et les feuilles sont des éléments du pattern matching (reconnaissance de motif). 10 Avec une seule entrée: U :([`sait il' est il' superman) oui Nous pourrons matcher : Sait il voler 15 Est-il un homme Est-il superman Nous pourrons aussi proposer : U : (aide moi) superman 20 Ici nous affichons une des feuilles de l'arbre. Utilisateur : aide moi Robot : il respire. 25 Pour que l'humain devine superman, il suffit d'écrire : U : (c'est superman ?) oui tu as trouvé ! U : (-superman) oui Proposai : non, ce n'est pas lui. 30 Pour que le robot devine un personnage, il suffit d'écrire : U : (devine à qui je pense) ?tous La figure 5 représente un organigramme simplifié des traitements du module de reconnaissance vocale dans un mode de réalisation de l'invention. 35 Deux niveaux de reconnaissance vocale sont superposés : - 20 - - Un premier niveau 510 comprend un nombre de mots reconnaissables limité ; les mots reconnus doivent impérativement figurer dans une liste fermée ; des exemples de logiciel de reconnaissance vocale de ce type sont fournis par les sociétés NuanceTM (marque VoconTM), AcapellaTM et, pour les logiciels utilisant un langage naturel, Dragon TM ; - Un deuxième niveau 520 de reconnaissance vocale est de type ouvert, c'est-à-dire que la diversité des mots reconnus est beaucoup plus importante ; des exemples de logiciel de reconnaissance vocale de ce type sont fournis notamment par la société NuanceTM sous la marque NMSPTM ; ces logiciels permettent de gérer des mots qui ne sont pas connus à l'avance qui seront désignés par un joker numéroté $x. Une architecte de reconnaissance vocale de ce type, comprenant deux 15 niveaux, l'un fermé 510 et l'autre ouvert 520 (par exemple du type dictée vocale) permet d'optimiser le couple vitesse/qualité de reconnaissance La figure 5 illustre la manière dont sont fusionnés les deux types de reconnaissance vocale : - Cas 530 : le robot est dans le même contexte que celui de l'utilisateur 20 et ce qu'il dit est reconnu par la reconnaissance limitée ; alors la dictée vocale n'est pas nécessaire ; - Cas 540: le robot n'est pas dans le même contexte que celui de l'utilisateur (l'utilisateur parle de voiture mais le robot pense qu'il parle de nourriture) ; alors les phrases reconnues par la dictée vocale 25 peuvent être rapprochées d'un dialogue ; - Cas 550: la reconnaissance de type 520 complète la reconnaissance de type 510 ; - Cas 560: la reconnaissance ouverte confirme un choix possible de la reconnaissance fermée ; 30 - Cas 570 : le robot ne comprend pas ce que dit l'utilisateur ; il fait une proposition pour valider le domaine du dialogue ou passer à un autre sujet, les cas ci-dessus 530 à 560 pouvant alors s'enchaîner sur cette relance du robot. - 21 - La figure 6 représente le flot de données entre plusieurs modules logiciels configurés pour mettre oeuvre l'invention dans plusieurs de ses modes de réalisation. La figure indique les échanges de données entre les évènements en entrée 5 610, le dialogue 620, les évènements en sorties 630 et un moteur d'intelligence artificielle embarqué sur le robot 640: - Le dialogue 620 attend en entrée des évènements (par exemple un sourire 6130 ou de la parole de l'utilisateur 6120 ; - Le moteur de dialogue peut dynamiquement charger de nouveaux 10 dialogues 6240 ou des données dynamiques 6230 (par exemple un fichier mp3 ou une application installés sur le) ; - Il formule sa réponse sous forme de parole expressive 6310, autrement-dit, une parole comportant des informations sur la façon d'interpréter le texte (une didascalie pour le robot), comportement 15 6320, émotion 6330, évènement 6340 ; - Les sorties du dialogue peuvent être envoyées à différents modules d'intelligence artificielle 640: ^ La parole et les expressions sont traitées par un moteur de traitement de l'expression 6410, Narrateur, utilisant les 20 mouvements et la synthèse vocale, selon les modalités décrites notamment dans le demande de brevet internationale publiée sous le n ° W02011/003628; ^ Les émotions sont traitées par un moteur émotionnel 6420 qui fait évoluer l'émotion du robot pour les stabiliser dans le temps ; 25 ^ Un moteur de décision 6430 décide de lancer ou non un comportement et peut indiquer la décision au moteur de dialogue sous forme d'évènement ; le robot peut refuser de se lever si les conditions ne sont pas vérifiées pour le faire. 30 Ce comportement peut le choix d'utiliser la reconnaissance vocale ou le clavier en entrée, comme explicité plus haut en commentaire à la figure 4 ; le comportement déclenche la parole et l'interruption de la parole en fonction des actions de l'utilisateur, par exemple, ouvrir la bouche, tourner les talons, tourner la tête, etc... 35 Le dialogue comprend un interpréteur 6230 et un modèle de dialogue 6240. -22- Un modèle de dialogue comprend : - Un réseau de dialogues ainsi que les dialogues actifs ; - L'ensemble des entrées des dialogues ainsi que les entrées actives ; - L'ensemble des sorties des dialogues ; - L'ensemble des propositions des dialogues. Les références 6310, 6320, 6330, 6340 représentent les sorties du moteur de dialogue sous forme d'évènements. La figure 6a illustre le fonctionnement d'un moteur d'émotion dans certains 10 modes de réalisation de l'invention. Comme expliqué ci-dessus en commentaire à la figure 2, l'émotion du robot est un point dans un espace multidimensionnel des émotions (par exemple TRISTE, CONTENT, FURIEUX, FATIGUE...). Le moteur de dialogue,mais pas seulement le moteur de dialogue par 15 exemple, son état de batterie, des visages rencontrés, l'heure sont également source d'évolution de l'émotion, envoie une impulsion au moteur émotionel qui déplace son émotion courante. Cette émotion se stabilise vers l'émotion neutre (0,0,0,0,0,0.) avec le temps. 20 La figure 6b illustre le fonctionnement d'un moteur de décision dans certains modes de réalisation de l'invention. Le moteur de décision prend en compte l'ensemble des demandes d'exécution de comportements et l'ensemble des contraintes du robot sous forme de ressources disponibles. Une demande d'exécution du moteur de 25 dialogue n'est qu'un élément de la décision. L'ensemble des variables/évènements du robot participe à la décision (batterie, température, émotions...). La figure 7 représente les différentes fonctions en entrée et en sortie du 30 module de gestion d'un dialogue pour mettre oeuvre l'invention dans plusieurs de ses modes de réalisation. La figure illustre qu'un dialogue 710 prend en entrée aussi bien le résultat de la reconnaissance vocale 730 que des entrées clavier 740 ou des évènements 720. Des données dynamiques 750, telles que des fichiers mp3 35 ou un applicatif peuvent également être prises en compte. - 23 - Avantageusement, à partir du traitement des images reçues par une caméra embarquée sur le robot, le module de dialogue analyse la position de la tête du/des locuteurs pour savoir si on s'adresse à lui. De même, il peut évaluer les positions des lèvres pour savoir si l'utilisateur parle ou non et par conséquent, s'il faut écouter ou s'il peut parler (élément 760). Egalement, la reconnaissance de visage permet, au même titre que la parole elle-même, d'indiquer le nom du locuteur courant. Une réponse 'parole' du moteur de dialogue peut être donnée par la voix du robot ou sur un écran 7A0 (ou les deux).

Comme déjà indiqué, le module dialogue est en mesure de déclencher l'exécution de comportements (élément 7B0). La figure 8 représente le modèle de données d'un module d'analyse et d'interprétation de dialogues pour mettre en oeuvre l'invention dans plusieurs 15 de ses modes de réalisation. L'analyseur 810 retrouve des mots d'un lexique 8110 dans des dialogues 8120 qui lui sont fournis en entrée. Les dialogues en entrée ont le modèle de données 8140. Des librairies 8130 « Libparser.so » de parsing du contenu des dialogues réalisent cette fonction. Il permet de construire en mémoire, 20 pour l'interpréteur 820 un modèle de dialogues et l'ensemble des entrées de ces dialogues. A l'exécution, l'interpréteur maintient une pile 8210 de dialogues actifs ainsi que l'ensemble des entrées actives pour chaque utilisateur. Les dialogues « parsés » en entrée de l'interpréteur ont la forme 8220 et le modèle de données 8240. L'interpréteur comporte des librairies 25 8240 « Libinterpreter.so » pour remplir ses fonctions d'interprétation. En effet, concepts, variables et dialogues courants peuvent être rendus dépendants de l'utilisateur. Ainsi, les règles suivantes permettent de changer d'utilisateur : U : (e :faceRecognition ) ($name = $faceRecognition) 30 U: (mon nom est _*) ($name = $1) Dans ce cas les variables dépendant de l'utilisateur (préférences, âge, taille...) sont automatiquement réinitialisées ou affectées selon l'historique de l'utilisateur. Les comportements 830 ont un modèle de données 8310 de variables d'état. 35 - 24 - La figure 9 représente l'architecture des modules logiciels implantés sur un robot configuré pour mettre oeuvre l'invention dans plusieurs de ses modes de réalisation. Un robot tel que NAO est avantageusement doté de logiciels de haut niveau 5 permettant le pilotage des fonctions du robot dans un mode de réalisation de l'invention. Une architecture logicielle de ce type, dénommée NAOQI, a été divulguée notamment dans la demande de brevet W02009/124955 publiée le 15/10/2009. Elle comporte les fonctions de base de gestion des communications entre un robot et un PC ou un site distant et d'échange de 10 logiciels qui fournissent l'infrastructure logicielle nécessaire à la mise en oeuvre de la présente invention. NAOQI est un framework optimisé pour les applications robotiques ; il supporte plusieurs langages, notamment C++, Python, Urbi, java, matlab. Dans le cadre de la présente invention, sont particulièrement utiles les 15 modules de NAOQI suivants : - le module ALMemory, 910, gère une mémoire partagée entre les différents modules de NAOQI ; - le module ALMotion, 920 gère les mouvements du robot ; - le module Synthèse vocale, 930, génère les paroles du robot ; 20 - le module Reconnaissance fermée, 940, réalise les fonctions de la référence 510 de la figure 5 ; - le module Reconnaissance ouverte, 950, réalise les fonctions de la référence 520 de la figure 6 ; - le module ALDialog, 960, réalise les fonctions du module moteur 25 de dialogue de référence 230 sur la figure 2 ; - le module Narrateur, 970, réalise les fonctions de la référence 6410 de la figure 6 ; - le module Moteur de décision, 980, réalise les fonctions de la référence 6420 de la figure 6 ; 30 - le module Moteur d'émotion, 990, réalise les fonctions de la référence 6430 de la figure 6. Ces modules sont avantageusement codés en C++. La figure indique également les flots de données entre modules. - 25 - Comme indiqué en commentaire à la figure 2, les dialogues sont générés dans un module d'édition de dialogue 9A0 implanté sur un ordinateur standard. Ils peuvent également être générés dans l'atelier Chorégraphe. La cohérence entre les dialogues du module ALDialog 960 et ceux du module d'édition 9A0 est assurée.Le flot de données entre l'analyseur 810 et l'interpréteur 820 (qui sont représentés sur la figure 8) du moteur de dialogue 960 est produit à la fois sur l'ordinateur au moment de l'édition et sur le robot à l'exécution.

L'analyseur peut lire un fichier de description de dialogue u : (....) L'interpréteur construit, à partir du résultat de l'analyseur (un dialogue écrit sans erreur de syntaxe), le modèle de dialogue en mémoire. Les exemples décrits ci-dessus sont donnés à titre d'illustration de modes de 15 réalisation de l'invention. Ils ne limitent en aucune manière le champ de l'invention qui est défini par les revendications qui suivent.

Claims (22)

1. REVENDICATIONS1. Robot humanoïde (110) comprenant au moins un capteur choisi dans un groupe comprenant des premiers capteurs de type sonore et des deuxièmes capteurs d'au moins un deuxième type d'évènements générés par au moins un utilisateur dudit robot, au moins un module (610) de reconnaissance d'évènements en sortie dudit au moins un capteur et au moins un module (630) de génération d'évènements vers ledit au moins un utilisateur, ledit robot étant caractérisé en ce qu'il comprend en outre un module (620) de dialogue avec ledit au moins un utilisateur, ledit module de dialogue recevant en entrée des sorties dudit au moins un module de reconnaissance et produisant des sorties vers ledit module de génération d'évènements choisies dans un groupe comprenant des paroles, des mouvements, des expressions et des émotions.
2. 2. Robot humanoïde selon la revendication 1, caractérisé en ce que ledit au moins un module de reconnaissance d'évènements reçoit des entrées en provenance d'au moins deux capteurs appartenant à au moins deux types différents, et en ce que ledit au moins un module de génération d'évènements en sortie dudit module de dialogue est apte à produire en sortie des évènements prenant en compte lesdites entrées en provenance desdits au moins deux capteurs.
3. 3. Robot humanoïde selon l'une des revendications 1 à 2, caractérisé en ce que ledit au moins un module de reconnaissance est apte à structurer les entrées en concepts selon un arbre hiérarchique dynamique.
4. 4. Robot humanoïde selon l'une des revendications 1 à 3, caractérisé en ce qu'une entrée dans ledit au moins un module de reconnaissance s'applique à des entrées textuelles ou vocales et active une grammaire dans ledit module de dialogue.35- 27 -
5. 5. Robot humanoïde selon la revendication 4, caractérisé en ce qu'une entrée dans ledit au moins un module de reconnaissance active/désactive la reconnaissance de ladite entrée.
6. 6. Robot humanoïde selon l'une des revendications 4 à 5, caractérisé en ce que ledit au moins un module de reconnaissance comprend un premier et un deuxième sous-modules, le premier sous-module opérant sur une liste fermée de mots rattachés à au moins un concept et le deuxième sous-module opérant sur une liste ouverte de mots.
7. 7. Robot humanoïde selon la revendication 6, caractérisé en ce qu'une sortie du premier sous-module est seule fournie au module de dialogue.
8. 8. Robot humanoïde selon la revendication 6, caractérisé en ce qu'une sortie du deuxième sous-module est seule fournie au module de dialogue.
9. 9. Robot humanoïde selon la revendication 6, caractérisé en ce qu'une sortie du premier sous-module et une sortie du deuxième sous-module sont conjointement fournies au module de dialogue.
10. 10. Robot humanoïde selon la revendication 6, caractérisé en ce qu'une sortie du premier sous-module est d'abord seule fournie au module de dialogue, ladite sortie du premier sous-module étant confirmée dans le module de dialogue par une sortie du deuxième sous-module.
11. 11. Robot humanoïde selon l'une des revendications 6 à 10, caractérisé en ce qu'aucune des sorties des premier et deuxième sous-modules ne génère de sortie du module de dialogue et en ce que ledit robot propose au moins une entrée audit au moins un utilisateur.
12. 12. Robot humanoïde selon l'une des revendications 1 à 11, caractérisé en ce que le module de dialogue reçoit en outre en entrée des éléments dynamiques en provenance d'une application.35- 28 -
13. 13. Robot humanoïde selon l'une des revendications 1 à 12, caractérisé en ce qu'au moins une sortie du module de dialogue est fournie à un module apte à exécuter une fonction choisie dans un groupe de fonctions de génération d'au moins une expression dudit robot, de décision de génération d'au moins un comportement dudit robot et de génération d'au moins une émotion dudit robot.
14. 14. Robot humanoïde selon la revendication 13, caractérisé en ce que ladite fonction de génération d'au moins un comportement prend en compte les contraintes du système dudit robot.
15. 15. Robot humanoïde selon la revendication 13, caractérisé en ce que ladite fonction de génération d'au moins une émotion est apte à générer une suite d'expressions prédéfinies entre un état neutre et un état prédéfinie en réponse à des évènements en entrée.
16. 16. Robot humanoïde selon l'une des revendications 1 à 15, caractérisé en ce qu'il comprend en outre un module de reconnaissance visuelle, ledit module étant apte à interpréter au moins un signe dudit au moins un utilisateur comme un commencement ou une fin d'une séquence d'un dialogue.
17. 17. Robot humanoïde selon l'une des revendications 3 à 16, caractérisé en ce que ledit module de dialogue comprend un sous-module d'analyse lexicale et un sous-module d'interprétation des sorties dudit sous-module d'analyse lexicale apte à générer des concepts auxquels sont rattachés les mots du dialogue courant.
18. 18. Robot humanoïde selon l'une des revendications 1 à 17, caractérisé en ce que ledit module de dialogue est apte à traiter des questions et des commandes dudit au moins un utilisateur relatives à l'état de son système physique et/ou logique.
19. 19. Procédé de dialogue entre un robot humanoïde et au moins un utilisateur, comprenant au moins une étape de reconnaissance d'entrées- 29 - en provenance d' au moins un capteur choisi dans un groupe comprenant des premiers capteurs de type sonore et des deuxièmes capteurs d'au moins un deuxième type visuel d'évènements générés par ledit au moins un utilisateur et une étape de génération d'évènements vers ledit au moins un utilisateur, ledit procédé étant caractérisé en ce qu'il comprend en outre une étape de dialogue avec ledit au moins un utilisateur' ladite étape de dialogue recevant en entrée des sorties de ladite au moins une étape de reconnaissance et produisant des sorties vers ladite étape de génération d'évènements choisies dans un groupe comprenant des paroles, des mouvements, des expressions et des émotions.
20. 20. Procédé de dialogue selon la revendication 19, caractérisé en ce que ledit robot dialogue avec au moins deux utilisateurs, des paramètres caractérisant lesdits au moins deux utilisateurs étant stockés dans une mémoire dudit robot pour être utilisés quand ledit robot reconnaît un des au moins deux utilisateurs.
21. 21. Programme d'ordinateur embarqué sur un robot humanoïde comprenant des instructions de code de programme permettant l'exécution du procédé selon la revendication 19 lorsque le programme est exécuté sur un ordinateur, ledit programme étant adapté pour gérer un dialogue entre ledit robot humanoïde et au moins utilisateur, ledit programme d'ordinateur comprenant un au moins un module de reconnaissance d'évènements en sortie d'au moins un capteur choisi dans un groupe comprenant des premiers capteurs de type sonore et des deuxièmes capteurs d'au moins un deuxième type visuel d'évènements générés par ledit au moins un utilisateur, au moins un module de génération d'évènements vers ledit au moins un utilisateur, ledit programme étant caractérisé en ce qu'il comprend en outre un module de dialogue avec ledit au moins un utilisateur, ledit module de dialogue recevant en entrée des sorties dudit au moins un module de reconnaissance et produisant des sorties vers ledit module de génération d'évènements choisies dans un groupe comprenant des paroles, des mouvements, des expressions et des émotions.35- 30 -
22. 22. Programme d'ordinateur comprenant des instructions de code de programme configurées pour générer un programme d'ordinateur selon la revendication 21 et le transmettre à au moins un robot humanoïde.5