MONCEAUX, Jérôme (6 rue Boussingault, Paris, Paris, F-75013, FR)
MAISONNIER, Bruno (57 rue Geoffroy Saint-Hilaire, Paris, Paris, F-75005, FR)
MONCEAUX, Jérôme (6 rue Boussingault, Paris, Paris, F-75013, FR)
| REVENDICATIONS 1 . Robot humanoïde comprenant au moins deux canaux de communication naturelle (521 , 522, 523, 531 , 532, 533) de messages avec au moins un interlocuteur (541 , 542) selon des modalités différentes, lesdits au moins deux canaux étant choisis chacun dans le groupe réception, émission, et un module de contrôle (510) des entrées/sorties desdits canaux, ledit robot étant caractérisé en ce que ledit module de contrôle est apte à améliorer la compréhension des messages reçus par ledit robot en exécutant au moins une fonction choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal. 2. Robot humanoïde selon la revendication 1 , caractérisé en ce que lesdits canaux de communication sont choisis dans le groupe des canaux de communication émettant et/ou recevant des messages sonores, visuels, tactiles, gestuels, positionnels ou symboliques. 3. Robot humanoïde selon la revendication 2, caractérisé en ce qu'un premier canal de communication est un canal d'émission sonore et un deuxième canal de communication est un canal de réception de gestes et/ou positions d'au moins une partie du robot par ledit au moins un interlocuteur, lesdits gestes et/ou positions étant représentatifs d'entrées communiquées par l'interlocuteur au robot, les spécifications desdites entrées étant définies par le robot à l'interlocuteur par le message émis sur le premier canal. 4. Robot humanoïde selon la revendication 3, caractérisé en ce qu'il comprend en outre un troisième canal de communication tactile par lequel l'interlocuteur valide les entrées effectuées sur le deuxième canal. 5. Robot humanoïde selon la revendication 2, caractérisé en ce qu'un premier canal de communication est un canal de réception de messages sonores et un deuxième canal de communication est un canal d'émission de messages sonores et en ce que ledit module de contrôle est apte à évaluer le niveau de confiance de la compréhension par ledit robot d'un premier message reçu sur ledit premier canal et à générer au moins un deuxième message sur ledit deuxième canal dont le contenu dépend dudit niveau de confiance. 6. Robot humanoïde selon la revendication 5, caractérisé en ce que le premier canal comprend un filtre de reconnaissance vocale des messages reçus par une liste d'expressions à chacune desquelles est associé un taux de reconnaissance attendu et en ce que le contenu dudit deuxième message est choisi par une heuristique dans le groupe comprenant demande de répétition dudit premier message sur le premier canal, demande de confirmation par un troisième message à émettre par l'interlocuteur sur le premier canal d'un sous-ensemble des expressions du filtre, demande d'émission par l'interlocuteur d'au moins un autre message sur au moins un troisième canal. 7. Robot humanoïde selon la revendication 6, caractérisé en ce qu'il est apte à émettre sur le deuxième canal un signal de début d'écoute sur le premier canal pour assurer le séquencement en mode half-duplex des messages sur le premier et le deuxième canal. 8. Robot humanoïde selon la revendication 6, caractérisé en ce que ladite heuristique de choix est une fonction de la position des taux de reconnaissance réels par rapport à des seuils déterminés à partir des taux de reconnaissance attendus. 9. Robot humanoïde selon la revendication 6, caractérisé en ce que ledit troisième canal est un canal de réception tactile ou de gestes d'une partie du robot. 10. Robot humanoïde selon l'une des revendications 5 à 9, caractérisé en ce qu'il comprend en outre un module d'interface avec une messagerie électronique, ledit module d'interface permettant à un titulaire d'un compte sur ladite messagerie d'utiliser ledit robot comme agent de réception/lecture des messages électroniques sur le deuxième canal, d'écriture/expédition sur le premier canal et d'administration dudit compte par dialogue en utilisant lesdits premier et deuxième canal. 1 1 . Robot humanoïde selon la revendication 6, caractérisé en ce que ledit troisième canal est un canal de réception visuelle d'images d'objets correspondant à la liste d'expressions du filtre du premier canal, lesdites images étant comparées à une base de données d'images desdits objets préalablement enregistrés avec lesdites expressions accessible par ledit module de contrôle des entrées/sorties desdits canaux de communication. 12. Robot humanoïde selon la revendication 2, caractérisé en ce qu'un premier canal de communication est un canal de réception de messages visuels et un deuxième canal de communication est un canal d'émission de messages sonores et en ce que ledit module de contrôle est apte à évaluer le niveau de confiance de la compréhension par ledit robot d'un premier message reçu sur ledit premier canal et à générer au moins un deuxième message sur ledit deuxième canal dont le contenu dépend dudit niveau de confiance. 13. Robot humanoïde selon la revendication 12, caractérisé en ce que le premier canal comprend un filtre de reconnaissance d'images des messages reçus par une liste d'expressions à chacune desquelles est associé un taux de reconnaissance attendu et en ce que le contenu dudit deuxième message est choisi par une heuristique dans le groupe comprenant demande de répétition dudit premier message sur le premier canal, demande de confirmation par un troisième message à émettre par l'interlocuteur sur un troisième canal de réception de messages sonores d'un sous-ensemble des expressions du filtre, demande d'émission par l'interlocuteur d'au moins un autre message sur au moins un quatrième canal. 14. Robot humanoïde selon l'une des revendications 1 à 13, caractérisé en ce qu'au moins un des canaux est un canal hybride recevant en entrées les sorties de deux canaux fusionnées par ledit module de contrôle des entrées et sorties. 15. Procédé de contrôle des communications d'un robot humanoïde avec au moins un interlocuteur comprenant au moins deux étapes de transmission de message par des canaux de communication utilisant des modalités différentes, lesdites deux étapes étant choisies chacune dans le groupe réception, émission, et une étape de contrôle des entrées/sorties desdits canaux, ledit robot étant caractérisé en ce que ladite étape de contrôle est apte à améliorer la compréhension des messages reçus par ledit robot en exécutant au moins une fonction choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal. 16. Programme d'ordinateur comprenant des instructions de code de programme permettant l'exécution du procédé selon la revendication 15 lorsque le programme est exécuté sur un ordinateur, ledit programme étant adapté pour permettre à un robot humanoïde comprenant au moins deux canaux de communication de messages avec au moins un interlocuteur selon des modalités différentes, lesdits au moins deux canaux étant choisis chacun dans le groupe réception, émission, et un sous-programme de contrôle des entrées/sorties desdits canaux, ledit programme d'ordinateur étant caractérisé en ce que ledit sous-programme de contrôle est apte à améliorer la compréhension des messages reçus par ledit robot en exécutant au moins une fonction choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal. 17. Procédé d'édition et de commande d'une interface de communication entre au moins un robot humanoïde et au moins un interlocuteur, ledit au moins un robot humanoïde comprenant au moins deux canaux de communication naturelle de messages avec le au moins un interlocuteur selon des modalités différentes, lesdits au moins deux canaux étant choisis chacun dans le groupe réception, émission, et un module de contrôle des entrées/sorties desdits canaux, ledit module de contrôle étant apte à améliorer la compréhension des messages reçus par ledit robot en exécutant au moins une fonction choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal, ledit procédé étant caractérisé en ce qu'il comprend une étape de programmation de ladite fonction choisie. 18. Procédé d'édition et de commande selon la revendication 17, caractérisé en ce que ladite étape de programmation de ladite fonction choisie comprend au moins une sous-étape de définition d'un premier canal de communication en tant que canal d'émission sonore et d'un deuxième canal de communication en tant que canal de réception d'au moins un geste imprimé à un membre du robot par ledit au moins un interlocuteur, une sous- étape de définition d'une correspondance entre ledit au moins un geste et une entrée communiquée par l'interlocuteur au robot, et une sous-étape de définition des spécifications desdites entrées par génération d'au moins un message à émettre par le robot à l'interlocuteur sur le premier canal. 19. Procédé d'édition et de commande selon la revendication 18, caractérisé en ce qu'il comprend en outre une sous-étape de définition d'un troisième canal de communication tactile par lequel l'interlocuteur valide les entrées effectuées sur le deuxième canal. 20. Procédé d'édition et de commande selon l'une des revendications 18 à 19, caractérisé en ce que ses étapes sont effectuées par l'intermédiaire d'au moins une Boîte de commande dans laquelle une Trame principale d'action à effectuer par ledit robot est reliée à au moins un événement choisi dans le groupe des événements antécédents et des événements successeurs à l'action à programmer et programmée pour se dérouler selon une contrainte temporelle prédéfinie par une Timeline. 21 . Procédé d'édition et de commande selon la revendication 17, caractérisé en ce ladite étape de programmation de ladite fonction choisie comprend au moins une sous-étape de définition d'un premier canal de communication en tant que canal de réception de messages sonores et d'un deuxième canal de communication en tant que canal d'émission de messages sonores, une sous-étape de définition d'une fonction d'évaluation d'un niveau de confiance de la compréhension par ledit robot d'un premier message reçu sur ledit premier canal et une sous-étape de définition de la génération d'au moins un deuxième message sur ledit deuxième canal dont le contenu dépend dudit niveau de confiance. 22. Procédé d'édition et de commande selon la revendication 21 , caractérisé en ce qu'il comprend en outre une sous-étape de définition d'un filtre de reconnaissance vocale des messages reçus sur le premier canal par une liste d'expressions à chacune desquelles est associé un taux de reconnaissance attendu et une sous-étape de définition du contenu dudit deuxième message par une heuristique choisie dans le groupe demande de répétition dudit premier message sur le premier canal, demande de confirmation par un troisième message à émettre par l'interlocuteur sur le premier canal d'un sous-ensemble des expressions du filtre, demande d'émission par l'interlocuteur d'au moins un autre message sur au moins un troisième canal. 23. Procédé de développement selon l'une des revendications 21 à 22, caractérisé en ce que ses étapes sont effectuées par l'intermédiaire d'au moins une Boîte de commande dans laquelle une Trame principale d'action à effectuer par ledit robot est reliée à au moins un événement choisi dans le groupe des événements antécédents et des événements successeurs à l'action à programmer et programmée pour se dérouler selon une contrainte temporelle prédéfinie par une Timeline, ladite Boîte de commande étant une Boîte de type Choix. 24. Programme d'ordinateur comprenant des instructions de code de programme permettant l'exécution du procédé selon la revendication 17 lorsque le programme est exécuté sur un ordinateur, ledit programme étant adapté pour permettre à un utilisateur de programmer un robot humanoïde comprenant au moins deux canaux de communication naturelle de messages avec au moins un interlocuteur selon des modalités différentes, lesdits au moins deux canaux étant choisis chacun dans le groupe réception, émission, et un sous-programme de contrôle des entrées/sorties desdits canaux, ledit programme d'ordinateur étant caractérisé en ce qu'il comprend un module de programmation dans le sous-programme de contrôle d'au moins une fonction à exécuter par le robot choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal. 25. Programme d'ordinateur selon la revendication 24, caractérisé en ce qu'il comprend en outre un module pour programmer le passage d'au moins un paramètre à une Boîte de commande. 26. Programme d'ordinateur selon la revendication 24, caractérisé en ce qu'il comprend en outre un module pour programmer le retour des entrées d'un canal de communication visuel du robot dans l'interface dudit programme. 27. Programme d'ordinateur selon la revendication 24, caractérisé en ce qu'il comprend en outre un module pour programmer des comportements du robot se déroulant en parallèle. |
La présente invention appartient au domaine des robots humanoïdes. Plus précisément, elle s'applique aux méthodes de programmation et d'emploi d'interfaces de dialogue avec un robot de ce type pour permettre l'exécution par ledit robot d'actions sur commande d'un utilisateur, la fourniture de réponses adéquates par ledit robot et, de manière plus générale, rétablissement de « relations humanoïdes » entre ledit robot et son ou ses interlocuteurs.
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...Au-delà de l'apparence, les fonctions qu'un robot humanoïde est capable de remplir vont dépendre de sa capacité à effectuer des mouvements, à parler et à « raisonner ». Des robots humanoïdes sont capables de marcher, de faire des gestes, avec les membres ou avec la tête. La complexité des gestes qu'ils sont capables d'effectuer augmente sans cesse.
Certains robots peuvent parler, en réponse à des stimuli de l'environnement. Le développement des outils de reconnaissance et de synthèse de la parole a également permis de développer des fonctions de dialogue de certains robots avec des humains qui enrichissent de manière importante les possibilités d'interactions. De telles interfaces hommes-robots utilisant la parole sont divulguées notamment par le brevet US 7,71 1 ,569 ainsi que par la demande publiée sous le numéro US2009/287678.
Dans ces documents de l'art antérieur, les imperfections inhérentes à la reconnaissance vocales sont palliées par le recours à des aides sémantiques et/ou contextuelles qui nécessitent l'accès à une base de données, un apprentissage et l'utilisation de ressources de calcul importantes pour être en mesure de lever les doutes de la reconnaissance - intervalle de confiance de la reconnaissance faible, faux positifs, faux négatifs.... L'utilisation de ces moyens n'est pas appropriée dans le cas d'un robot humanoïde multifonctions qui doit être économe de ses ressources de calcul pour gérer ses processus critiques tels que la locomotion.
Il serait avantageux de pouvoir disposer d'un robot humanoïde capable de réaliser la lever de doute de la reconnaissance effectuée par des capteurs et des logiciels qui resteront imparfaits de manière simple et efficace en utilisation des ressources de calcul embarquées sur ledit robot.
La présente invention résout ce problème en procurant une interface de dialogue avec un robot humanoïde qui utilise un mode naturel de confirmation des réponses.
A cet effet, la présente invention divulgue un robot humanoïde comprenant au moins deux canaux de communication de messages avec au moins un interlocuteur selon des modalités différentes, lesdits au moins deux canaux étant choisis chacun dans le groupe réception, émission, et un module de contrôle des entrées/sorties desdits canaux, ledit robot étant caractérisé en ce que ledit module de contrôle est apte à améliorer la compréhension des messages reçus par ledit robot en exécutant au moins une fonction choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal.
Avantageusement, lesdits canaux de communication sont choisis dans le groupe des canaux de communication émettant et/ou recevant des messages sonores, visuels, tactiles, de déplacements et/ou positions d'au moins une partie du robot, et numériques.
Avantageusement, un premier canal de communication est un canal d'émission sonore et un deuxième canal de communication est un canal de réception de déplacements et/ou positions d'au moins une partie du robot par ledit au moins un interlocuteur, lesdits déplacements et/ou positions étant représentatifs d'entrées communiquées par l'interlocuteur au robot, les spécifications desdites entrées étant définies par le robot à l'interlocuteur par le message émis sur le premier canal. Avantageusement, le robot de l'invention comprend en outre un troisième canal de communication tactile par lequel l'interlocuteur valide les entrées effectuées sur le deuxième canal.
Avantageusement, un premier canal de communication est un canal de réception de messages sonores et un deuxième canal de communication est un canal d'émission de messages sonores et en ce que ledit module de contrôle est apte à évaluer le niveau de confiance de la compréhension par ledit robot d'un premier message reçu sur ledit premier canal et à générer au moins un deuxième message sur ledit deuxième canal dont le contenu dépend dudit niveau de confiance.
Avantageusement, le premier canal comprend un filtre de reconnaissance vocale des messages reçus par une liste d'expressions à chacune desquelles est associé un taux de reconnaissance attendu et en ce que le contenu dudit deuxième message est choisi par une heuristique dans le groupe comprenant demande de répétition dudit premier message sur le premier canal, demande de confirmation par un troisième message à émettre par l'interlocuteur sur le premier canal d'un sous-ensemble des expressions du filtre, demande d'émission par l'interlocuteur d'au moins un autre message sur au moins un troisième canal.
Avantageusement, le robot de l'invention est apte à émettre sur le deuxième canal un signal de début d'écoute sur le premier canal pour assurer le séquencement en mode half-duplex des messages sur le premier et le deuxième canal.
Avantageusement, ladite heuristique de choix est une fonction de la position des taux de reconnaissance réels par rapport à des seuils déterminés à partir des taux de reconnaissance attendus.
Avantageusement, ledit troisième canal est un canal de réception tactile ou de déplacements d'une partie du robot. Avantageusement, le robot de l'invention comprend en outre un module d'interface avec une messagerie électronique, ledit module d'interface permettant à un titulaire d'un compte sur ladite messagerie d'utiliser ledit robot comme agent de réception/lecture des messages électroniques sur le deuxième canal, d'écriture/expédition sur le premier canal et d'administration dudit compte par dialogue en utilisant lesdits premier et deuxième canal.
Avantageusement, ledit troisième canal est un canal de réception visuelle d'images d'objets correspondant à la liste d'expressions du filtre du premier canal, lesdites images étant comparées à une base de données d'images desdits objets préalablement enregistrés avec lesdites expressions accessible par ledit module de contrôle des entrées/sorties desdits canaux de communication. Avantageusement, un premier canal de communication est un canal de réception de messages visuels et un deuxième canal de communication est un canal d'émission de messages sonores et en ce que ledit module de contrôle est apte à évaluer le niveau de confiance de la compréhension par ledit robot d'un premier message reçu sur ledit premier canal et à générer au moins un deuxième message sur ledit deuxième canal dont le contenu dépend dudit niveau de confiance.
Avantageusement, le premier canal comprend un filtre de reconnaissance d'images des messages reçus par une liste d'expressions à chacune desquelles est associé un taux de reconnaissance attendu et en ce que le contenu dudit deuxième message est choisi par une heuristique dans le groupe comprenant demande de répétition dudit premier message sur le premier canal, demande de confirmation par un troisième message à émettre par l'interlocuteur sur un troisième canal de réception de messages sonores d'un sous-ensemble des expressions du filtre, demande d'émission par l'interlocuteur d'au moins un autre message sur au moins un quatrième canal. Avantageusement, au moins un des canaux est un canal hybride recevant en entrées les sorties de deux canaux fusionnées par ledit module de contrôle des entrées et sorties. L'invention divulgue également un procédé de contrôle des communications d'un robot humanoïde avec au moins un interlocuteur comprenant au moins deux étapes de transmission de message par des canaux de communication utilisant des modalités différentes, lesdites deux étapes étant choisies chacune dans le groupe réception, émission, et une étape de contrôle des entrées/sorties desdits canaux, ledit robot étant caractérisé en ce que ladite étape de contrôle est apte à améliorer la compréhension des messages reçus par ledit robot en exécutant au moins une fonction choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal.
L'invention divulgue également un programme d'ordinateur comprenant des instructions de code de programme permettant l'exécution du procédé ci- dessus lorsque le programme est exécuté sur un ordinateur, ledit programme étant adapté pour permettre à un robot humanoïde comprenant au moins deux canaux de communication de messages avec au moins un interlocuteur selon des modalités différentes, lesdits au moins deux canaux étant choisis chacun dans le groupe réception, émission, et un sous- programme de contrôle des entrées/sorties desdits canaux, ledit programme d'ordinateur étant caractérisé en ce que ledit sous-programme de contrôle est apte à améliorer la compréhension des messages reçus par ledit robot en exécutant au moins une fonction choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal.
L'invention divulgue également un procédé de développement d'une interface de communication entre au moins un robot humanoïde et au moins un interlocuteur, ledit au moins un robot humanoïde comprenant au moins deux canaux de communication de messages avec le au moins un interlocuteur selon des modalités différentes, lesdits au moins deux canaux étant choisis chacun dans le groupe réception, émission, et un module de contrôle des entrées/sorties desdits canaux, ledit module de contrôle étant apte à améliorer la compréhension des messages reçus par ledit robot en exécutant au moins une fonction choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal, ledit procédé étant caractérisé en ce qu'il comprend une étape de programmation de ladite fonction choisie.
Avantageusement, ladite étape de programmation de ladite fonction choisie comprend au moins une sous-étape de définition d'un premier canal de communication en tant que canal d'émission sonore et d'un deuxième canal de communication en tant que canal de réception de déplacements d'au moins un membre du robot par ledit au moins un interlocuteur, une sous- étape de définition d'une correspondance entre lesdits déplacements et des entrées communiquées par l'interlocuteur au robot, et une sous-étape de définition des spécifications desdites entrées par génération d'au moins un message à émettre par le robot à l'interlocuteur sur le premier canal.
Avantageusement, le procédé de développement de l'invention comprend en outre une sous-étape de définition d'un troisième canal de communication tactile par lequel l'interlocuteur valide les entrées effectuées sur le deuxième canal.
Avantageusement, les étapes du procédé de développement de l'invention sont effectuées par l'intermédiaire d'au moins une Boîte de commande dans laquelle une Trame principale d'action à effectuer par ledit robot est reliée à au moins un événement choisi dans le groupe des événements antécédents et des événements successeurs à l'action à programmer et programmée pour se dérouler selon une contrainte temporelle prédéfinie par une Timeline.
Avantageusement, ladite étape de programmation de ladite fonction choisie comprend au moins une sous-étape de définition d'un premier canal de communication en tant que canal de réception de messages sonores et d'un deuxième canal de communication en tant que canal d'émission de messages sonores, une sous-étape de définition d'une fonction d'évaluation d'un niveau de confiance de la compréhension par ledit robot d'un premier message reçu sur ledit premier canal et une sous-étape de définition de la génération d'au moins un deuxième message sur ledit deuxième canal dont le contenu dépend dudit niveau de confiance.
Avantageusement, le procédé de développement de l'invention comprend en outre une sous-étape de définition d'un filtre de reconnaissance vocale des messages reçus sur le premier canal par une liste d'expressions à chacune desquelles est associé un taux de reconnaissance attendu et une sous- étape de définition du contenu dudit deuxième message par une heuristique choisie dans le groupe demande de répétition dudit premier message sur le premier canal, demande de confirmation par un troisième message à émettre par l'interlocuteur sur le premier canal d'un sous-ensemble des expressions du filtre, demande d'émission par l'interlocuteur d'au moins un autre message sur au moins un troisième canal. Avantageusement, les étapes du procédé de développement de l'invention sont effectuées par l'intermédiaire d'au moins une Boîte de commande dans laquelle une Trame principale d'action à effectuer par ledit robot est reliée à au moins un événement choisi dans le groupe des événements antécédents et des événements successeurs à l'action à programmer et programmée pour se dérouler selon une contrainte temporelle prédéfinie par une Timeline, ladite Boîte de commande étant une Boîte de type Choix.
L'invention divulgue également un programme d'ordinateur comprenant des instructions de code de programme permettant l'exécution du procédé de développement ci-dessus lorsque le programme est exécuté sur un ordinateur, ledit programme étant adapté pour permettre à un utilisateur de programmer un robot humanoïde comprenant au moins deux canaux de communication de messages avec au moins un interlocuteur selon des modalités différentes, lesdits au moins deux canaux étant choisis chacun dans le groupe réception, émission, et un sous-programme de contrôle des entrées/sorties desdits canaux, ledit programme d'ordinateur étant caractérisé en ce qu'il comprend un module de programmation dans le sous- programme de contrôle d'au moins une fonction à exécuter par le robot choisie dans le groupe combinaison de messages reçus/émis sur un premier canal et sur un deuxième canal, émission d'un deuxième message généré à partir d'un premier message reçu sur un canal.
Avantageusement, le programme d'ordinateur de l'invention comprend en outre un module pour programmer le passage d'au moins un paramètre à une Boîte de commande.
Avantageusement, le programme d'ordinateur de l'invention comprend en outre un module pour programmer le retour des entrées d'un canal de communication visuel du robot dans l'interface dudit programme.
Avantageusement, le programme d'ordinateur de l'invention comprend en outre un module pour programmer des comportements du robot se déroulant en parallèle. L'interface de l'invention présente en outre l'avantage d'offrir des modes de confirmation multimodaux qui peuvent être facilement adaptés à l'environnement dans lequel s'exécute le dialogue, par exemple si le bruit ambiant est trop élevé pour que la reconnaissance vocale puisse avoir une quelconque efficacité. L'utilisateur peut ainsi être invité à remplacer/confirmer des réponses ambiguës par un toucher, un geste ou l'affichage d'un symbole numérique, de couleur ou de forme particulière. Ainsi l'utilisateur a à sa disposition des moyens lui permettant de remplacer ou émuler de manière intuitive les interfaces traditionnelles qu'il est habitué à utiliser quand il est face à son ordinateur ou qu'il utilise un téléphone intelligent ou une tablette tactile.
En outre, les modes d'expression du robot peuvent eux-mêmes être multimodaux, en combinant notamment intonation, regard, geste pour retenir l'attention de son interlocuteur et lui communiquer des émotions ou des indices sur des réponses à fournir. De plus, en se rapprochant des modes de communication naturels entre humains, l'interface de l'invention contribue à améliorer les résultats du système de reconnaissance et à renforcer la qualité de l'expérience de l'utilisateur plongé dans une « virtualité réelle », c'est-à-dire celle d'un dialogue avec un avatar incarné physiquement.
L'invention fournit également un environnement de développement de ces interfaces, ergonomique et versatile, qui permet de créer très facilement et en très peu de temps de nouveaux scénarios d'interaction spécialement adaptés pour des utilisations du robot non imaginées par son concepteur.
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 est un schéma de l'architecture physique d'un robot humanoïde dans plusieurs modes de réalisation de l'invention ;
- La figure 2 illustre la tête d'un robot humanoïde comportant des capteurs utiles à la mise en œuvre de l'invention dans plusieurs de ses modes de réalisation ;
- La figure 3 est un schéma de l'architecture des logiciels de haut niveau permettant le pilotage des fonctions du robot dans plusieurs modes de réalisation de l'invention ;
- La figure 4 est un schéma de l'architecture fonctionnelle d'édition et de programmation des comportements/interactions d'un robot dans plusieurs modes de réalisation de l'invention ;
- La figure 5 est un organigramme fonctionnel des traitements appliqués de manière générale pour améliorer l'interprétation donnée par un robot humanoïde des réponse/stimuli qu'il reçoit dans plusieurs modes de réalisation de l'invention ;
- La figure 6 est un diagramme logique de programmation des comportements/interactions d'un robot dans plusieurs modes de réalisation de l'invention ;
- Les figures 7a, 7b et 7c représentent des chronogrammes illustrant la combinaison logique et temporelle des interactions d'une interface multimodale dans plusieurs modes de réalisation de l'invention;
- Les figures 8a, 8b, 8c, 8d et 8e représentent un enchaînement d'écrans permettant de programmer un dialogue avec un robot humanoïde avec choix binaire et option de changement de la langue d'interaction dans un mode de réalisation de l'invention;
- Les figures 9a, 9b, 9c, 9d et 9e représentent un enchaînement d'écrans permettant de programmer un dialogue avec un robot humanoïde avec choix choix dans une liste et option de changement de la langue d'interaction dans un mode de réalisation de l'invention;
- Les figures 10a, 10b, 10c et 10d représentent un enchaînement d'écrans permettant d'exécuter un test de reconnaissance vocale comparative entre plusieurs options d'une liste de choix dans un mode de réalisation de l'invention;
- Les figures 1 1 a et 1 1 b représentent un enchaînement d'écrans permettant de remplacer ou compléter des options d'une liste de choix et d'exécuter un nouveau test de reconnaissance vocale comparative entre plusieurs options dans un mode de réalisation de l'invention;
- Les figures 12a, 12b, 12c et 12d représentent un enchaînement d'écrans permettant d'exécuter un test de reconnaissance vocale comparative entre plusieurs options d'une liste de choix dans une langue différente de celle de la question dans un mode de réalisation de l'invention;
- Les figures 13a, 13b, 13c et 13d représentent un enchaînement d'écrans permettant de vérifier/modifier les seuils des tests de reconnaissance vocale comparative entre plusieurs options d'une liste de choix dans un mode de réalisation de l'invention.
La figure 1 illustre l'architecture physique d'un robot humanoïde dans un mode de réalisation de l'invention. Un tel robot a été divulgué notamment dans la demande de brevet WO2009/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 NAO™, sans que la généralité de la référence en soit modifiée. Ce robot comprend environ deux douzaines de cartes électroniques du type 1 10 de commande de capteurs et d'actionneurs qui pilotent les articulations. La carte 1 10 montrée sur la figure est celle qui contrôle le pied gauche. Une des vertus de l'architecture est que les cartes contrôlant les articulations sont pour la plupart interchangeables. Une articulation a normalement au moins deux degrés de liberté et donc deux moteurs. Chaque moteur est piloté en angle. L'articulation comporte également plusieurs capteurs de position, notamment des MRE (Magnetic Rotary Encoder). La carte électronique de contrôle comporte un microcontrôleur du commerce. Ce peut être par exemple un DSPIC™ de la société Microchip. C'est un MCU 16 bits 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 (Capteurs de pression au sol), etc....
La tête 160 comporte l'intelligence du robot, notamment la carte 130 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, laparticipation à des jeux. La carte 130 pourrait cependant être située ailleurs dans le robot, par exemple dans le tronc. On verra cependant que cette localisation, lorsque la tête est amovible, permet de remplacer ces fonctions de haut niveau et donc notamment de changer complètement l'intelligence du robot et donc ses missions très rapidement. Ou à l'inverse de changer un corps par un autre (par exemple un corps défectueux par un non défectueux) en gardant la même intelligence artificielle. La tête peut comporter également des cartes spécialisées, notamment dans le traitement de la parole ou de la vision ou également 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 130 peut être un processeur x86 du commerce. On choisira de manière privilégiée un processeur à basse consommation tel que le Géode™ de la société AMD (32 bits, 500 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...), normalement sur une couche de transmission WiFi, WiMax, éventuellement sur une 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.
Une carte 120 est logée dans le tronc du robot. C'est là que se situe le calculateur qui assure la transmission aux cartes 1 10 des ordres calculés par la carte 130. Cette carte pourrait être logée ailleurs dans le robot. Mais la localisation dans le tronc est avantageuses car elle se situe près de la tête et au carrefour des quatre membres, ce qui permet donc de minimiser la connectique reliant cette carte 130 à la carte 120 et aux cartes 1 10. Le calculateur de cette carte 120 est également un processeur du commerce. Ce peut avantageusement être un processeur 32 bits du type ARM 9™ cadencé à 100 MHz. Le type du processeur, sa position centrale, proche du bouton de marche/arrêt, sa liaison au contrôle de l'alimentation en font un outil bien adapté pour la gestion de l'alimentation du robot (mode veille, arrêt d'urgence, ...). La carte comporte également un ensemble de mémoires RAM et flash.
Cette architecture à trois niveaux est particulièrement avantageuse pour la mise en œuvre de la présente invention dans laquelle le robot doit pouvoir exécuter des mouvements coordonnés et d'autres actions tels que des lectures de capteurs et simultanément interpréter des paroles ou des signes émis dans son environnement et réagir ou répondre à ceux-ci. Les figures 2a et 2b représentent respectivement une vue de face et une vue de profil de la tête d'un robot humanoïde comportant des capteurs utiles à la mise en œuvre de l'invention dans plusieurs de ses modes de réalisation. La tête 160 de la figure 1 est améliorée en une tête 200a, 200b, de manière à doter le robot des capacités sensorielles et d'expressions qui sont utiles à la mise en œuvre de la présente invention.
NAO est doté de 4 microphones omnidirectionnels 21 1 a, 212a, 213a, 214a, par exemple de référence KEEG1540PBL-A fournis par Kingstate Electronics Corp, un 21 1 a à l'avant, un 214a à l'arrière et un 212a et 213a sur chaque côté de la tête (voir également figure 2b), dont seulement les trous d'accès à l'extérieur sont visibles sur les figures car ils sont répartis à l'intérieur de la tête. A partir des captures sonores effectuées par les microphones, un système d'analyse et de reconnaissance vocale, par exemple un système BabEAR™ fourni par la société Acapela™, reconnaît un corpus de mots prédéfinis qu'un utilisateur disposant des interfaces adéquates, présentées plus loin dans la description, peut enrichir avec ses propres termes. Ces mots permettent de déclencher les comportements de son choix, notamment des réponses à des questions interprétées par le robot. L'environnement logiciel supporte plusieurs langues, comme indiqué plus loin dans la description. NAO est également capable de détecter la provenance d'un son, ce qui lui permet de lever des ambiguïtés entre plusieurs locuteurs.
NAO voit à travers deux caméras CMOS 640x480, 220a, capables de capter jusqu'à 30 images par seconde, par exemple des caméras de marque Omnivision™ de référence 0V760 (capteur CMOS 1 /6 eme pouce : pixels de 3,6 μιτι). La première caméra placée au niveau du front, est pointée vers son horizon, alors que la seconde placée au niveau de la bouche, scrute son environnement immédiat. Le logiciel permet de récupérer des photos de ce que voit NAO ainsi que le flux vidéo. Pour percevoir et interpréter son environnement, NAO embarque un ensemble d'algorithmes de détection et de reconnaissance de visage, de formes, qui lui permettent de reconnaître son interlocuteur, de localiser une balle ainsi que des objets plus complexes.
Placé au sommet de son crâne, NAO est doté d'un capteur capacitif, 230a, divisé par exemple en trois sections et développé spécifiquement par la demanderesse pour cette application. Plus de trois sections pourraient être prévues pour des applications particulières. Il est ainsi possible de donner des informations à NAO par le toucher, par exemple en pressant une série de boutons permettant le déclenchement d'actions définies par l'application, qui peuvent être, dans le cadre de la présente invention des réponses différentes associées à chaque bouton, un déroulement dans une liste de choix proposés, l'accès à un menu d'aide, etc.. Le système est accompagné de LED qui indiquent s'il y a contact. NAO peut s'exprimer en lisant à voix haute n'importe quel fichier texte résidant localement dans son espace de stockage, par exemple programmé selon les modes explicités plus loin dans la description ou récupéré depuis un site web ou un flux RSS. Doté de 2 hauts parleurs, 210b, disposés de chaque coté de la tête, son système de synthèse vocale par exemple Acapela Mobility d'Acapela, est paramétrable, ce qui permet notamment des modifications de la vitesse et/ou de la tonalité de la voix.
Il est possible d'envoyer un fichier de musique à NAO et le lui faire jouer. NAO accepte par exemple les formats _.wav et _.mp3, ce qui permet, dans le cadre de la présente invention de prévoir des réponses musicales ou des sons personnalisés en accompagnement ou en substitutions de réponses vocales. D'autres formats de fichiers de musique peuvent être également acceptés. La figure 3 est un schéma de l'architecture des logiciels de haut niveau permettant le pilotage des fonctions du robot dans un mode de réalisation de l'invention.
Une architecture logicielle de ce type a été divulguée notamment dans la demande de brevet WO2009/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 logiciels qui fournissent l'infrastructure logicielle nécessaire à la mise en œuvre de la présente invention. Cette architecture est décrite ci-dessous de manière générique, sans mention spécifique des fonctions logicielles utilisées dans une application spécifique, étant entendu que ces fonctions sont traitées comme toute autre fonction logicielle de gestion des comportements du robot de la présente invention. Sur la figure 3 est représenté très schématiquement un premier robot humanoïde RH1 communiquant avec un premier terminal distant TD1 , par exemple par liaison sans fil pour des raisons de mobilité. On entend par terminal distant un terminal distant de la plate-forme serveur PFS, fournissant, par l'intermédiaire d'un réseau de communication, l'accès à un service web SW, dédié à ce type de robot humanoïde RH1 .
Bien entendu, les liaisons de communication entre éléments du système peuvent être filaires, et les terminaux mobiles peuvent être, en variante, des téléphones portables ou des ordinateurs portables. Un deuxième robot humanoïde RH2 communique avec un deuxième terminal distant TD2, par exemple également par liaison sans fil de manière à ne pas entraver la mobilité du robot humanoïde RH2.
Les terminaux distants TD1 et TD2 et la plateforme serveur PFS sont reliés en réseau par l'intermédiaire du réseau de communication RC. Pour le service web de la plateforme serveur PFS ainsi que pour les terminaux distants TD1 et TD2, et que pour les robots humanoïdes RH1 et RH2, un seul module respectif de mise en relation B5, B2, B4, B1 et B3 dédié à au moins un module comprenant au moins une série d'instructions mettant en œuvre une fonction logicielle par exécution par un processeur. Les modules respectifs M51 , M52, M21 , M22, M41 , M42, M1 1 , M12, M31 , M32 des modules de mise en relation B5, B2, B4, B1 et B3 sont sur cet exemple représentés au nombre de deux par module de mise en relation, mais ce nombre peut être différent et quelconque pour chaque module de mise en relation.
Nous allons maintenant illustrer un exemple nullement limitatif de fonctionnement du système imaginé par un utilisateur du premier terminal distant TD1 possédant le premier robot humanoïde RH1 . Il peut, par exemple, faire réaliser par son robot un certain nombre de fonctions au moyen d'une application logicielle embarquée sur le premier terminal distant TD1 , ou accessible sur la plateforme serveur PFS depuis le premier terminal distant TD1 .
Par exemple il réalise simplement, aux moyens d'outils graphiques de l'application logicielle, une application pour son robot, dans laquelle le robot va marcher pendant 10 secondes puis dire "Bonjour à tous". Cette application est par exemple téléchargée dans le premier robot humanoïde RH1 sous forme d'un module, par exemple le module M1 1 , puis déclenchée par l'utilisateur par l'intermédiaire du premier terminal distant TD1 .
Le premier robot humanoïde RH1 déclenche le module M1 1 qui doit utiliser en premier une fonction "Marche". Le module M1 1 utilise alors un module d'interface de connexion et d'appel de fonction ou proxy P1 qui effectue une requête au module de mise en relation B1 auquel est lié le module M1 1 . Le module de mise en relation B1 effectue des requêtes à destination de ses propres modules et des modules de mise en relation du réseau auquel il est directement relié (modules de mise en relation enfants) qui répètent cette opération de manière itérative, jusqu'à ce qu'un module de mise en relation du réseau réponde à la requête avec la localisation de la fonction appelée qu'il a dans un module. La réponse à la requête étant également transmise de manière itérative par les modules de mise en relation parents (en sens inverse) jusqu'au module de mise en relation B1 directement lié au proxy P1 ayant besoin de se connecter et d'appeler cette fonction. Par exemple, la fonction demandée pour la marche est localisée dans le module M41 du deuxième terminal distant TD2. En retour le module de mise en relation B4 a retourné les paramètres d'appels de la fonction "marche", qui, par exemple, contiennent un paramètre Durée de type entier en secondes représentant la durée pendant laquelle le robot va marcher, et un paramètre Exclusif, de type booléen, représentant la marche exclusive ou non du robot, i.e. si on autorise le robot à faire une autre action ou non pendant qu'il marche. Dans cet exemple, on appelle la fonction marche avec le paramètre Durée valant 10 et le paramètre Exclusif valant 1 , car on veut qu'il parle après avoir marché 10 seconde dans cet exemple.
Le module d'interface de connexion et d'appel P1 peut donc effectuer la connexion et l'appel de la fonction "marche" avec les paramètres souhaités, à distance, comme si elle était située en local. Les modules d'interface de connexion et d'appels de fonction utilisent un logiciel d'intercommunication capable d'appeler une fonction d'un module localisé sur un terminal ou serveur différent, la fonction pouvant être écrite par une série d'instructions dans un langage informatique différent de celui du module appelant. Les proxies utilisent, par exemple, le logiciel d'intercommunication SOAP. On a donc une architecture de communication inter-plateformes et inter-langages. Une fois cette fonction délocalisée "marche" effectuée, le module M1 1 doit faire appel à une fonction "parle". Un autre module d'interface de connexion et d'appel de fonction ou proxy P2 effectue une requête au module de mise en relation B1 auquel est lié le module M1 1 . Le module de mise en relation B1 effectue une requête à destination de ses propres modules M1 1 et M12 dans un premier temps, par l'intermédiaire d'une fonction réalisée sous la forme d'une suite d'instructions mémorisées, qui va, par exemple, retourner la présence de cette fonction "parle" dans le module M12. Le module de mise en relation B1 informe le module d'interface de connexion et d'appel de fonction P2 qui peut alors appeler directement, par un appel de type appel local la fonction "parle" du module M12, avec comme paramètre, par exemple, le texte à dire "bonjour", ce paramètre ayant été transmis au proxy P2 par le module de mise en relation B1 .
En outre, le système comprend un module de mémorisation et de gestion STM (diminutif de "Short Term Memory" en langue anglaise) de paramètres représentatifs de l'état du terminal mobile, en l'occurrence du robot humanoïde RH1 , adaptés pour mettre à jour les valeurs desdits paramètres sur réception d'un événement externe, et pour informer un module, sur demande préalable, d'une mise à jour d'un desdits paramètre mémorisé. Aussi le module prévenu pourra engager une action en fonction des modifications de paramètres dont il a été informé.
En relation avec l'exemple préalablement décrit, par exemple, le module de mémorisation et de gestion STM peut mémoriser l'état d'un paramètre représentatif de l'apparition de quelqu'un détecté par un détecteur de mouvement du robot RH1 . Lorsque ce paramètre passe d'un état représentatif de personne dans l'environnement immédiat du robot à un état représentatif de quelqu'un présent dans l'environnement immédiat du robot, sur demande effectuée préalablement par le module M1 1 , le module de mémorisation et de gestion STM prévient, par un événement ou signal ce changement de valeur. Le module M1 1 peut, alors par exemple, déclencher automatiquement le déclenchement successif décrit précédemment (les fonctions "marche" et "parle").
Dans l'exemple de la figure 3, le module de mémorisation et de gestion STM fait partie du terminal distant TD1 , mais, en variante, il peut faire partie de l'autre terminal distant TD2, de la plate-forme serveur PFS, ou d'un robot humanoïde RH1 ou RH2.
Le module de mémorisation et de gestion STM est également capable de stocker en mémoire une évolution temporelle de certains paramètres sur des intervalles de temps respectifs de référence. Ainsi, un module du système peut, en outre, avoir accès à l'évolution des valeurs de ces paramètres depuis une certaine durée, et tenir compte de ces évolutions dans les actions à mener.
En variante, les modules des fonctions appelées peuvent être localisée sur la plate-forme serveur PGS, sur un robot humanoïde RH1 , RH2 ou sur un terminal distant TD1 , TD2 du réseau de communication RC. Ainsi, la présente invention permet d'avoir un programme réparti sur le réseau, et un fonctionnement identique du terminal mobile, qu'il fasse un appel local ou distant à une fonction.
En outre, la présente architecture permet également d'avoir un ensemble de paramètres mémorisés représentatifs de l'état du terminal mobile, et de pouvoir tenir compte d'évolutions de cet état pour déclencher automatiquement certaines actions.
De surcroît, le module de mémorisation et de gestion peut également enregistrer une évolution de valeurs de paramètres durant un intervalle de temps prédéterminé, ce qui permet à un module d'avoir accès à un historique de l'évolution de ces paramètres.
Ces fonctions de communication et de mémorisation, qui constituent un système d'exploitation et de gestion des interfaces du robot, dénommé NAOQI, sont particulièrement utiles pour la mise en œuvre de la présente invention.
La figure 4 est un schéma de l'architecture fonctionnelle d'édition et de programmation des comportements d'un robot dans un mode de réalisation de l'invention.
Une telle architecture a été décrite par la demande de brevet PCT/EP2010/0571 1 1 déposée le 25/05/2010. Le logiciel d'édition et de programmation des comportements d'un robot humanoïde permettant de mettre en œuvre ladite architecture est commercialement dénommé Chorégraphe™, et peut être désigné indifféremment pas son nom générique ou par son nom commercial, sans altérer la généralité des références.
Le robot contrôlé par cette architecture peut être un robot humanoïde ayant une tête, un tronc et quatre membres, chacune des parties étant articulée, chaque articulation étant commandée par un ou plusieurs moteurs. Cette architecture permet à un utilisateur du système de commander un tel robot en créant des comportements simulés sur un robot virtuel et exécutés sur le robot réel relié au système par une liaison filaire ou sans fil.
Il s'agit de visualiser, de simuler et de faire exécuter des comportements (tels que la marche - tout droit, à droite ou à gauche de n pas ; un « hello » - mouvements d'un des bras au-dessus de la tête ; la parole, etc ..) et des mouvements (de la tête, d'une partie de membre, d'un angle donné) sur l'écran d'un ordinateur programmé pour ce faire.
La figure 4 est un organigramme des traitements qui illustre l'articulation des commandes déclenchées par des événements avec leur dimension temporelle. Les commandes déclenchées par des événements sont représentées dans la sémantique de l'invention par des Boxes ou « Boîtes » ou « Boîtes de commande » 410. Une Boîte est une structure de programmation arborescente qui peut comprendre un ou plusieurs des éléments ci-dessous qui sont définis ensuite:
- Une « Timeline » ou axe temporel de Trames 420;
- Un « Diagram » ou Diagramme de flux 470
- Un Script 490.
Les Boîtes de commande sont normalement reliées entre elles par des connections qui transmettent le plus souvent une information d'événement d'une Boîte à l'autre, comme détaillé plus loin dans la description. Toute Boîte est reliée directement ou indirectement à une « Boîte racine » ou Root qui initialise le scénario de comportement/mouvement du robot.
Un axe temporel de Trames 420 représente la contrainte temporelle à laquelle sont soumis les comportements et les mouvements du robot définis dans la Boîte dans laquelle le dit Axe temporel de Trames est inséré. Dans la suite de la description et des revendications, nous utiliserons la dénomination anglo-saxonne de Timeline, communément admise avec le même sens dans le monde de la programmation. La Timeline réalise ainsi la synchronisation des comportements et mouvements de la Boîte. Elle est découpée en frames (Trames) auxquelles est associée une vitesse de déroulement définie en nombre de Trames par seconde ou Frames Per Second (FPS). Le FPS de chaque Timeline est paramétrable par l'utilisateur. Par défaut, le FPS peut être fixé à une valeur donnée, par exemple 15 FPS. Une Timeline peut comprendre :
- Une ou plusieurs Behavior Layers ou « Couches de comportement » 430, comprenant chacune une ou plusieurs Behavior Key Frames ou « Trames principales de comportement » 450, qui peuvent comprendre elles-mêmes un ou plusieurs Diagrams ou « Diagrammes de flux » 470, qui sont en fait des ensembles de Boîtes qui peuvent également être rattachées directement à une Boîte de niveau supérieur, sans passer par une Couche de comportement ni une Timeline;
- Une ou plusieurs Motion Layers ou « Couches de mouvement » 440, comprenant chacune une ou plusieurs Motion Key Frames ou «Trames principales de mouvement » 460 qui peuvent comprendre un ou plusieurs Motion Screens ou « Ecrans de mouvement » 480.
Une Couche de comportement définit un ensemble de comportements du robot ou Trames principales de comportement. Plusieurs Couches de comportement peuvent être définies au sein d'une même Boîte. Elles seront alors programmées pour se dérouler de manière synchronisée par la Timeline de la Boîte.
Une Couche de comportement pourra comprendre un ou plusieurs Trames principales de comportement. Une Trame principale de comportement définit un comportement du robot, tel que la marche (« Walk »), la parole (« Say »), le jeu de musique (« Music »)... Un certain nombre de comportements sont pré-programmés dans le système de l'invention pour être directement insérés par l'utilisateur dans un simple « drag and drop » à partir d'une librairie comme détaillé plus loin dans la description. Chaque Trame principale de comportement est définie par un événement déclencheur qui est le début de la Trame à laquelle elle est insérée dans la Timeline. La fin de la Trame principale de comportement n'est définie que dans la mesure où une autre Trame principale de comportement est insérée à sa suite, ou si un événement de fin est défini.
Une Couche de mouvement définit un ensemble de mouvements du robot qui sont programmés par une ou plusieurs Trames principales de mouvement successives qui regroupent des mouvements des moteurs des articulations du robot. Ces mouvements à exécuter sont définis par les positions angulaires d'arrivée des dits moteurs qui peuvent être programmées par action sur des écrans de mouvement, lesdites actions étant détaillées plus loin dans la description. Toutes les Trames principales de mouvement d'une même Boîte sont synchronisées par la Timeline de la Boîte. Une Trame principale de mouvement est définie par une Trame d'arrivée. La Trame de départ est celle de fin de la Trame principale de mouvement précédente ou celle de l'événement de début de la Boîte. On désigne sous l'appellation commune de Trame principale d'action les Trames principales de comportement et les Trames principales de mouvement.
Il est possible d'exécuter en parallèle plusieurs Trames principales d'action (de comportement ou de mouvement), à condition qu'elles soient rattachées à la même Timeline.
Un Diagramme de flux est un ensemble de Boîtes connectées entre elles, comme détaillé plus loin. Chacune des Boîtes peut à son tour comprendre d'autres Timeline auxquelles sont rattachées de nouvelles Couches de comportement ou de mouvement.
Un script est un programme directement exécutable par le robot. Dans le cadre de la présente invention, les scripts sont de manière privilégiée écrits en langage C++. Une Boîte qui comprend un script ne comprend pas d'autre élément.
Le logiciel peut être implanté sur un PC ou une autre plateforme de type ordinateur personnel utilisant un système d'exploitation Windows™, Mac™ ou Linux™.
Le robot humanoïde de la présente invention sera généralement programmé pour pouvoir interagir avec un être humain en utilisant le logiciel Chorégraphe™. La combinaison des logiques temporelles et comportementales rendue possible par cette architecture de développement est particulièrement avantageuse pour la mise en œuvre de la présente invention. Un certain nombre d'outils, évoqués plus loin dans la suite de la description, ont été particulièrement développés pour la mise en œuvre d'un robot humanoïde disposant d'une interface de dialogue naturel dans le cadre de la présente invention.
La figure 5 est un organigramme fonctionnel des traitements appliqués de manière générale pour améliorer l'interprétation donnée par un robot humanoïde des réponse/stimuli qu'il reçoit dans plusieurs modes de réalisation de l'invention.
Au fil du temps, l'être humain a développé une grande variété de moyens pour interagir avec les machines. Ces moyens suivent l'évolution des technologies, ils sont donc de plus en plus performants. En tous cas, pour être efficace, l'interaction quelle qu'elle soit, doit être adaptée à la plateforme et aux besoins de l'utilisateur.
Les interfaces graphiques et environnements fenêtrés mettent ainsi à disposition d'un utilisateur un certain nombre d'éléments d'interface encore appelés composants d'interface graphique (en anglais : GUI Eléments ou Graphical User Interface Eléments), comme par exemple : zone de texte (Text Box en anglais), boutons OK/Cancel, cases à cocher (Check Box en anglais), boutons de radio (Radio Button en anglais), ou boîtes combinées (Combo Box en anglais). Ces éléments, adaptés à une interface graphique, ne peuvent pas être utilisés tels quels sur un robot humanoïde qui ne fournit pas en principe de retour visuel de type écran traditionnel. Or les échanges avec le robot devraient être au moins aussi riches que ceux avec l'interface graphique d'un ordinateur. On veut alors pouvoir choisir une option, épeler un mot, lancer ou quitter une application de la même façon qu'on cocherait une case, qu'on entrerait un texte au clavier, qu'on double-cliquerait sur une icône ou qu'on cliquerait sur la croix dans la fenêtre de l'application. On ne veut pas non plus copier simplement ces éléments existants justement puisqu'on veut une interface humanisée et naturelle pour l'utilisateur. Il faut donc trouver des éléments d'interface utilisateur qui soient adaptés à un robot humanoïde autonome.
Ces éléments doivent également être facilement paramétrables pour les créateurs de comportements de robots humanoïdes et permettre une adaptation facile à la langue de l'utilisateur. Les robots autonomes existants peuvent mettre en place des interfaces hommes-robots simples, comme de la reconnaissance vocale, mais, dans l'art antérieur, aucun élément d'interface utilisateur multimodal, régionalisé (permettant le multilinguisme) et gérant les échecs n'a été fourni aux utilisateurs ni aux développeurs.
En effet, aujourd'hui, le type de reconnaissance vocale qu'il est possible d'implanter sur un robot humanoïde de taille et de prix raisonnable, doté de capacités d'acquisition et de traitement multi-capteurs, de capacités de locomotion et d'un grand nombre de degrés de liberté de ses quatre membres, est nécessairement limité par les ressources informatiques et en énergie électrique qu'il est possible d'embarquer sur le robot. Ces ressources sont en effet nécessairement affectées par priorité aux traitements permettant d'assurer la sécurité et la fiabilité des captures de signaux et des commandes nécessaires à l'exécution des mouvements. Il est donc nécessaire de prévoir des éléments d'interface homme-robot permettant de corriger au mieux les imperfections inévitables, dans ce contexte, de la reconnaissance vocale et d'offrir à l'utilisateur une interaction réussie grâce notamment à des mécanismes de lever de doute sur l'interprétation que donne le robot aux messages qu'il reçoit de l'utilisateur et à des questions renvoyées par le robot qui s'inscrivent dans le cadre d'une séquence de dialogue qui converge.
On notera également que l'humain ne parle pas de façon naturelle à un robot parce qu'il ne retrouve pas ses références humaines, c'est-à-dire les gestes et les comportements qu'un humain aurait dans la même situation. L'interaction ne sera notamment pas naturelle si le robot ne regarde pas dans la direction de l'humain, interaction habituelle dans l'interaction Homme-Homme. De plus, contrairement à la communication humaine, le type de reconnaissance vocale compatible avec les ressources informatiques embarquées sur un robot humanoïde multifonctions ne permet pas de gérer à elle seule de manière efficace des interactions avec plusieurs utilisateurs. En outre, la plupart des robots utilisent peu ou pas le langage naturel, la synthèse vocale étant en général programmée avec des phrases pré-écrites par des humains, que ce soient une histoire inventée pour le robot ou un email écrit par un humain et que le robot va lire. Il manque donc des éléments permettant de rapprocher au mieux l'interaction Homme-robot d'une interaction Homme-Homme. Les interfaces homme-robot de l'art antérieur n'ont pas assez de multi-modalité ou de codes d'interaction permettant de simuler une interaction naturelle Homme-Homme et de contribuer à la réussite de l'interaction. De plus, si l'interface fait appel à des connaissances déjà acquises par l'utilisateur et même à celles qu'il utilise quotidiennement, l'expérience sera bien plus facile et ne nécessitera que peu d'apprentissage de la part de l'utilisateur. Ainsi, balayer des yeux une salle dans un monde virtuel se fera d'autant plus instinctivement avec un casque de réalité virtuelle en bougeant la tête qu'en appuyant sur les flèches d'un clavier d'ordinateur.
La solution de l'invention propose des éléments d'interface utilisateur, combinant software et hardware, adaptés à un robot humanoïde autonome. En transposant l'appellation GUI Eléments utilisée ci-dessus aux comportements d'un robot, on définit alors des BUI Eléments (Behavior User Interface Eléments), que l'on pourra ici appeler plus généralement et simplement des UlElements. De tels UlElements peuvent par exemple être définis pour coder de manière simple des actions telles que :
quitter une application à n'importe quel moment en tapant simultanément sur les trois capteurs tactiles de la tête du robot ; interpeller le robot en utilisant la reconnaissance vocale ; passer à l'étape suivante d'une application en tapant sur un des capteurs tactiles du robot.
Ces éléments simples sont ainsi de véritables codes d'interaction qui peuvent être implantés dans des bibliothèques génériques pour être disponibles dans tous les comportements et applications d'un robot ou créées en tant que ressources spécifiques d'un projet donné.
Les UlElements de l'invention sont des éléments utilisables et paramétrables facilement par un développeur de comportements. Ce sont principalement des boîtes Chorégraphe qui deviennent des GUI Eléments de base pour la programmation de comportements. Notamment, certaines de ces boîtes comprennent des plugins Chorégraphe, codés en C++ en utilisant une librairie de Widget produit par l'environnement Qt™ de développement de composants d'interfaces graphiques.
On a représenté sur la figure 5 une vue simplifiée d'une architecture fonctionnelle permettant la mise en œuvre de l'invention.
On aménage au sein de ou en connexion avec l'unité centrale 120 de la figure 1 un module de contrôle des entrées/sorties 510 des canaux de communication par lesquels le robot va échanger ses messages avec ses interlocuteurs. Ce module comprend, physiquement ou logiquement, les moyens de prétraitement émission/réception des canaux de communication spécialisés dont le robot est équipé.
Sans que cela soit limitatif, on a représenté sur la figure trois types de canaux de communication de messages, chaque type disposant d'un canal de réception et d'un canal d'émission.
Un canal récepteur 521 de type 1 correspond à l'ouïe humaine et permet à un robot d'acquérir des signaux sonores, de préférence des messages vocaux à contenu sémantique. Pour ce faire, le robot peut être équipé des microphones 210a représentés sur la figure 2a. Les sorties de ce canal sont normalement prétraitées par un processeur de traitement de signal spécialisé qui exécute des algorithmes de reconnaissance vocale. Ces algorithmes peuvent être plus ou moins complexes et d'efficacité variable selon l'environnement dans lequel ils sont utilisés (bruit ambiant, multi locuteurs...) et la réalisation d'un apprentissage spécifique plus ou moins complet. Dans toutes les configurations, des erreurs de reconnaissance sont cependant inévitables.
Un canal émetteur 531 de type 1 correspond à la parole humaine et permet à un robot de parler, c'est-à-dire de prononcer des messages vocaux à contenu sémantique, par exemple par l'intermédiaire de haut-parleurs 210b représentés sur la figure 2b. La langue, le timbre, le rythme et la tonalité de la voix peuvent être variés en fonction du contexte et pour exprimer un sentiment. Mais ces sons peuvent également être des bip, de la musique préenregistrée, étant entendu que les bip, en séquence morse par exemple, et la musique, selon des codes préétablis, peuvent avoir également un contenu sémantique.
Un canal récepteur 522 de type 2 correspond à la vision humaine et permet à un robot de repérer son environnement et d'acquérir des images qu'il peut ensuite reconnaître si elles sont stockées dans une mémoire qui lui est accessible. Pour ce faire, le robot peut être équipé par exemple des caméras CMOS 220a représentées sur la figure 2a. Une des caméras est de préférence dédiée à la vision lointaine, l'autre à la vision proche. Avantageusement, les algorithmes de reconnaissance d'image sont adaptés pour permettre une détection voire une reconnaissance des visages des interlocuteurs du robot. Là encore, quelles que soient les performances de la reconnaissance, des incertitudes ou des erreurs sont inévitables. La reconnaissance d'image peut également s'appliquer à des formes simples telles que des chiffres présentés au robot sur des visuels ou des marques, dont la signification peut être définie par un codage.
Un canal émetteur 532 de type 2 est un canal artificiel sans équivalent humain direct. Ce canal permet l'émission de signaux lumineux produits par des LED implantées sur le corps du robot. De nombreuses LED peuvent être prévues, notamment sur les yeux, les oreilles, le torse, les pieds. Elles peuvent avoir des couleurs différentes et être dotées d'une capacité de clignotement à fréquence variable. Ce canal dote le robot de moyens simples et puissants d'envoi de messages. En particulier un code particulier peut être défini et programmé par un utilisateur.
Un canal récepteur 523 de type 3 est un canal équivalent au toucher humain. Ce canal est cependant limité dans ses zones tactiles. Celles-ci peuvent par exemple être concentrées dans un capteur tactile tel que le capteur 230a représenté sur la figure 2a. L'interlocuteur du robot actionnera le capteur tactile pour communiquer un message au robot, de type binaire (validation d'une action) ou plus complexe. Les informations reçues par ce canal peuvent en effet correspondre à un code défini par l'utilisateur, soit unitaire (tape, caresse ayant respectivement une signification de punition et de récompense), soit séquentiel de type morse. Un capteur tactile spécifique n'est pas forcément nécessaire pour définir un canal de communication de ce type. Un canal de même type, dans la mesure où il reçoit une action de contact d'un interlocuteur, peut être défini dans lequel le capteur de message est un capteur analogique continu représenté par les positions des bras et/ou avant-bras du robot, lesdites positions étant représentatives de valeurs numériques communiquées par l'interlocuteur au robot, comme cela sera expliqué plus loin dans la suite de la description. En effet, le robot connaît à tout instant les positions angulaires de ses articulations et sait donc interpréter comme un message des variations de celles-ci provoquées par un déplacement sous l'action de l'interlocuteur, si la signification dudit déplacement a été définie à l'avance. Un simple toucher d'un membre (l'avant-bras par exemple) peut également être décelé par les capteurs de position angulaire des articulations du robot. Des mouvements plus brusques, tels que des secousses ou un soulèvement peuvent être détectés respectivement par la centrale inertielle du robot et ses capteurs de soles de pieds (FSR).
Un canal émetteur de type 533 de type 3 est équivalent au geste humain. La tête peut être dotée de deux degrés de liberté : déplacement en azimuth, mesuré par un angle de lacet (ou yaw en anglais) et déplacement en élévation, mesuré par un angle de tangage (ou pitch en anglais). Ces deux mouvements définissent traditionnellement des messages d'approbation (pitch) ou de dénégation (yaw). Ils permettent également au robot de diriger son regard vers l'interlocuteur avec qui il est en conversation. Les articulations épaules, coudes, poignets peuvent être respectivement dotées des degrés de liberté suivants : pitch et roll (roulis ou torsion droite/gauche) ; yaw ; yaw. La main peut être dotée de capacités d'ouverture et de fermeture. Des combinaisons des mouvements de ces articulations permettent de définir le contenu de messages à communiquer aux interlocuteurs du robot par ce canal.
D'autres canaux de communication de messages, non représentés sur la figure, existent ou peuvent également être définis. En particulier, le robot peut recevoir et émettre des signaux par liaison infrarouge, Bluetooth ou Wifi. Il est donc possible à un interlocuteur de transmettre des messages au robot par ce canal, notamment en utilisant une télécommande programmée à cet effet, par exemple un iPhone™ d'Apple™ ou un autre téléphone ayant des fonctionnalités de capture de mouvement et/ou de positionnement.
De même un robot peut envoyer des messages à un autre robot via ces ports de communication.
Selon l'invention, un canal de communication de messages peut être défini par fusion de canaux de type différents en un canal de type hybride. Ainsi, les sorties d'un canal sonore doté d'une reconnaissance de paroles et d'un canal visuel doté d'une reconnaissance d'images peuvent être combinées pour créer un nouveau canal dont les sorties seront améliorées par un processus de fusion de données, la sortie en sortie de ce canal étant a priori d'un niveau de confiance supérieur à ceux des deux sorties prises séparément.
Sont également représentés sur la figure 5 deux interlocuteurs 541 et 542 du robot. Naturellement, un seul ou plus de deux interlocuteurs sont possibles dans les scénarios de mise en œuvre de l'invention. En outre les interlocuteurs peuvent être situés à distance du robot, à la condition d'être reliés à la pièce où celui-ci se trouve par les liaisons de données permettant de transmettre les signaux sonores et/ou visuels nécessaires à l'échange des messages. Naturellement, dans ce cas, l'utilisation des canaux de communication de type 3 qui nécessitent un contact physique ne sera pas possible.
La position relative du robot par rapport à son/ses interlocuteurs et par rapport à son environnement peut également être mesurée par des capteurs particuliers (reconnaissance vocale associée à une localisation du locuteur ; reconnaissance d'images ; capteur ultrasonore, etc ..) et être interprétée, croisée par exemple avec une analyse de volume, de tonalité ou d'expression pour caractériser la nature du dialogue homme/robot et modifier éventuellement son déroulement. Ainsi, un interlocuteur qui se rapproche et qui parle fort pourra être vu par le robot comme une menace et déclencher différents comportements de protection, avec une gestuelle associée, voire une modification ou une interruption des interactions.
Le contrôle logique des entrées/sorties de ces différents canaux de communication est effectué par module 510.
Celui-ci permet à la fois, comme explicité plus loin dans la description, d'effectuer des levers de doute sur les entrées d'un canal récepteur d'un premier type (par exemple sonore), par des messages émis sur un canal émetteur du même premier type, lesdites actions de lever de doute pouvant être effectuées en réponse par l'interlocuteur sur un canal du même premier type ou sur un canal récepteur d'un second type (par exemple tactile). Les messages de demande de lever de doute sur un message reçu sur un canal d'un premier type (par exemple sonore) peuvent également être émis sur un canal d'un second type (par exemple visuel, par émission de LED), l'action de lever de doute de l'interlocuteur devant être effectuée sur un canal récepteur d'un troisième type (par exemple tactile). Ces combinaisons sont données à titre purement illustratif et non limitatif, une grande variété de combinaisons étant possible.
Le module de contrôle des entrées/sorties des canaux de communication 510 peut également être utilisé plus simplement pour combiner des entrées de messages, cette combinaison permettant de supprimer pratiquement toute possibilité de doute dans « l'esprit » du robot.
La programmation de la fonction de combinaison des entrées reçues par un canal récepteur et des sorties émises par un canal récepteur peut être réalisé de manière simple en utilisant des BUIEIements.
Nous décrirons plus loin un type de BUIEIements constitué par une Boîte de commande de type Choix ou Boîte Choix. Celle-ci représente une façon de faire un choix dans une liste fermée. Elle est surtout adaptée à la reconnaissance d'un nombre restreint de mots et phrases, dans le cadre d'un dialogue, le robot pouvant poser une question avant d'écouter le choix de l'utilisateur.
Nous décrivons ci-dessous un type de BUIEIement distinct d'un type différent d'une Boîte Choix.
Nous illustrons cette modalité par l'exemple du choix d'un nombre entier. Pour cet élément, le robot par exemple énonce sur son canal émetteur de type 1 , 531 , le nombre minimal et le nombre maximal disponible pour l'utilisateur, et tend à son interlocuteur un de ses bras, ce dernier étant en asservissement faible. Ce bras constituera le canal récepteur 523 de type 3 de la figure 5. La position basse du bras est associée au chiffre minimum, la position haute au chiffre maximal. L'utilisateur utilise ainsi le bras du robot comme un curseur afin de choisir son chiffre. Le robot connaît la position de son bras grâce aux senseurs disponibles sur l'articulation pitch de l'épaule (ShoulderPitch). Pour agrémenter cette interaction, le robot regarde sa main pendant que l'utilisateur lui bouge le bras. A chaque changement de position, le robot peut énoncer le chiffre choisi. L'utilisateur peut valider son choix en touchant le capteur tactile du milieu sur la tête du robot, utilisant un autre canal récepteur 523 de type 3. On peut également prévoir, notamment en cas de nombre trop important de chiffres par rapport à la précision des capteurs, qu'un bras permette de faire un réglage grossier, et le deuxième de choisir plus précisément. Des listes d'expressions ordonnées peuvent être représentées par des nombres. La procédure ci-dessus devient alors une modalité de choix dans un menu déroulant annoncé par le robot.
Une variante permettant d'effectuer le choix d'un chiffre consiste à utiliser uniquement le capteur tactile. Par exemple :
Taper sur le capteur de devant permet de descendre d'un cran dans la liste de chiffres ;
Taper sur celui de derrière permet d'avancer dans la liste de chiffres ;
- Laisser le capteur de devant ou de derrière appuyé permet d'accélérer le défilement dans la liste de chiffres ;
Le choix se ferait en touchant le capteur du milieu.
On voit qu'il est possible de varier de manière importante les combinaisons possibles en fonction des scénarios d'utilisation de l'invention. La figure 6 est un diagramme logique de programmation des comportements/interactions d'un robot dans plusieurs modes de réalisation de l'invention.
L'exemple illustré par la figure est un scénario où un robot dialogue avec un interlocuteur qui lui propose un choix dans une liste de mots, par exemple dans le cas d'un jeu de devinettes. Dans ce scénario, un canal récepteur de type 1 , un canal récepteur de type 3 et un canal émetteur de type 1 sont utilisés.
Les actions représentées par le code 610 sur la figure sont des actions d'un interlocuteur du robot : choix énoncé par l'utilisateur sur une liste par exemple précédemment énoncée par le robot ; timeout (ou absence de choix) ; réponse « oui/non » à une demande de confirmation de compréhension d'un ou plusieurs mots sur cette liste.
Les actions représentées par le code 620 sur la figure sont des actions du robot qui seront activées en fonction de l'état des variables internes représentées par le code 630. La signification de ces variables internes est la suivante :
r : taux de probabilité de reconnaissance par le robot du mot énoncé par l'utilisateur parmi ceux de la liste de choix ; - f : nombre cumulé d'échecs de reconnaissance ;
t : nombre de timeouts (ou absence de choix par l'interlocuteur au bout d'un temps prédéfini) ;
51 : seuil 1 de taux de probabilité de reconnaissance ;
52 : seuil 2 de taux de probabilité de reconnaissance ; - tmax : nombre maximal de timeouts possibles ;
fmax : nombre maximal d'échecs possibles.
La manière générale dont sont traités les timeout correspond à l'application au problème posé d'un principe simple de la vie humaine quotidienne : « Qui ne dit mot consent ... »
La logique générale des traitements représentés sur cette figure est décrite ci-dessous.
NAO écoute l'utilisateur/interlocuteur et les variables f et t sont initialisées à zéro. Si l'interlocuteur laisse passer le temps de timeout prédéterminé, le compteur de timeouts est incrémenté et si le nombre maximal de timeouts est atteint, la boucle d'interaction est interrompue. Cette application peut être initialisée soit dans un comportement dans un contexte déterministe où une action spécifique faite par l'utilisateur la déclenchera telle qu'une interpellation du robot, dans un jeu pour connaître le nombre de joueurs quand on le démarre ou par l'appui sur un des capteurs tactiles de la tête, soit dans le contexte d'une intelligence artificielle qui la déclenchera en fonction de paramètres tels que la présence détectée d'un être humain, l'heure de la journée ou plus généralement, l'historique des événements de la journée stocké par le robot. Par exemple, s'il détecte que l'utilisateur l'appelle, il déclenche une application lui permettant de savoir ce que l'utilisateur veut de lui et pourquoi il l'a appelé. Dans un autre contexte, il pourra déclencher lui-même une application pour proposer un jeu s'il détecte la présence d'un humain, qu'il a une forte envie de jouer et que ça fait longtemps qu'il n'a pas joué. Si l'interlocuteur énonce un choix avant l'expiration du timeout, le taux de probabilité de reconnaissance mesuré r est comparé à des seuils S1 et S2 (S1 < S2), de taux de probabilité de reconnaissance attendus dont on décrira plus loin la manière dont ils sont déterminés.
Si r < S1 , cette reconnaissance du mot est considérée comme un échec. Le compteur d'échecs est incrémenté. Si fmax est atteint, le mot est déclaré définitivement non reconnu et l'interaction est interrompue. Si fmax n'est pas atteint, on peut prévoir, comme illustré sur la figure, trois cas :
au premier échec (f =1 ), le robot indique à son interlocuteur « je n'ai pas compris » et active celle des fonctions « activateHelpWhenFailure » consistant à répéter la liste de choix ;
au deuxième échec, (f = 2), le robot indique également « je n'ai pas compris » et active une autre des fonctions « activateHelpWhenFailure » consistant à fournir à son interlocuteur la liste de choix et à demander à son interlocuteur d'utiliser son capteur tactile, en lui indiquant comment l'utiliser ; au-delà (3 < f < fmax), le robot peut prononcer des phrases indiquant à son interlocuteur que les conditions d'une conversation efficace ne sont pas remplies, telles que « il y a trop de bruit », ce qui normalement incitera ledit interlocuteur à mettre un terme à la conversation.
Si S1 < r < S2, le robot a un doute sur ce qu'il a effectivement entendu ; selon la procédure représentée sur la figure, il peut alors procéder à une action de lever de doute, en prononçant le mot ou l'expression qu'il pense avoir reconnu et en demandant à son interlocuteur « Est-ce correct ? » ; si l'interlocuteur répond « oui » ou ne répond pas au bout du timeout, le robot considère que la réponse est exacte. Si l'interlocuteur répond « non », le compteur d'échec est incrémenté ; si fmax est atteint, le robot indique définitivement qu'il n'a pas compris et l'interaction s'arrête ; si fmax n'est pas atteint:
au premier échec ( f = 1 ), le robot peut activer celle des fonctions « activateHelpWhenFailure » consistant à répéter la liste de choix ;
au deuxième échec (f = 2), active une autre des fonctions « activateHelpWhenFailure » consistant à fournir à son interlocuteur la liste de choix et à demander à son interlocuteur d'utiliser son capteur tactile, en lui indiquant comment l'utiliser ; - à partir du 3 eme échec et jusqu'à fmax, l'interlocuteur doit répéter le choix jusqu'à ce que le taux de probabilité de reconnaissance s'améliore.
De cette manière, il est ainsi possible de pallier grandement les imperfections de la reconnaissance vocale et de créer une fluidité améliorée dans la conversation entre le robot et son interlocuteur.
Les figures 7a, 7b et 7c représentent des chronogrammes illustrant la combinaison logique et temporelle des interactions d'une interface multimodale dans plusieurs modes de réalisation de l'invention.
Ces figures sont des vues des Boîtes Choix permettant de programmer les interactions du type de celle représentée sur le diagramme de la figure 6. Les Boîtes Choix sont des Boîtes telles que celles illustrées sous la rubrique 410 sur la figure 4, mais elles sont d'un type particulier permettant la programmation particulièrement efficace de comportements spécialisés pour un dialogue naturel.
Les significations des symboles de ces figures sont les suivantes :
sur la figure 7a,
- 710a désigne les actions/paroles du robot ou de son interlocuteur ;
720a désigne le capteur tactile ;
740a désigne un bip de reconnaissance ;
750a désigne les LED du visage du robot en position animée tournante;
751 a désigne les LED du visage du robot en position figée ;
760a désigne le flash des LED du visage du robot (qui peut être de différentes couleurs en fonction de la compréhension par le robot du message reçu) ;
- 770a désigne la fonction timeout ;
780a désigne la sortie de la Boîte Choix ;
790a désigne la fonction « Aller au menu capteur tactile » (figure 7b) ;
7A0 désigne la fonction « Aller au tri des choix » (figure 7c) ;
- 7B0 désigne la fonction « Aller au menu reconnaissance vocale » ;
R1 , R2 et R3 désignent respectivement un cas où le robot comprend sans ambiguïté, un cas où le robot comprend mais doute et un cas où le robot ne comprend pas du tout ; - Sur la figure 7c, 710c désigne la fonction « Revenir au menu précédent ».
La logique générale des traitements programmés dans la Boîte Choix est identique à celle déjà décrite. Les éléments supplémentaires ici décrits sont :
- L'utilisation des LED 750a du visage du robot, éventuellement du flash de LED pour ponctuer les échanges de questions et de réponses : les LED sont en position figée 751 a pour indiquer que le robot détecte la parole et l'analyse ;
L'utilisation d'un « bip » sonore émis par le robot pour indiquer le moment où il est prêt à reconnaître ; en effet, en raison des limitations de capacité de traitement et d'alimentation, et pour éviter également un bruitage de la reconnaissance, celle-ci n'est pas active en même temps que la synthèse vocale ; il ne faut donc pas que l'interlocuteur réponde trop tôt aux questions que lui pose le robot ; le « bip » donne le top pour commencer à répondre ;
La possibilité d'utiliser plusieurs niveaux d'aide qui dépendent de l'historique du robot et de son expérience cet utilisateur au cours de cet échange et des échanges précédents;
- La possibilité de naviguer entre plusieurs menus pour faciliter la programmation.
Les figures qui sont maintenant décrites sont des copies d'écrans sur lesquels un composant Boîte Choix du logiciel Chorégraphe décrit en commentaire à la figure 4 ci-dessus est utilisé pour programmer des interactions simples ou complexes entre un robot NAO et un interlocuteur en utilisant dans les exemples représentés des canaux de réception et d'émission de type 1 (échanges vocaux).
Les figures 8a, 8b, 8c, 8d et 8e représentent un enchaînement d'écrans permettant de programmer un dialogue avec un robot humanoïde avec choix binaire et option de changement de la langue d'interaction dans un mode de réalisation de l'invention;
Les figures 9a, 9b, 9c, 9d et 9e représentent un enchaînement d'écrans permettant de programmer un dialogue avec un robot humanoïde avec choix choix dans une liste et option de changement de la langue d'interaction dans un mode de réalisation de l'invention;
Les figures 10a, 10b, 10c et 10d représentent un enchaînement d'écrans permettant d'exécuter un test de reconnaissance vocale comparative entre plusieurs options d'une liste de choix dans un mode de réalisation de l'invention;
Les figures 1 1 a et 1 1 b représentent un enchaînement d'écrans permettant de remplacer ou compléter des options d'une liste de choix et d'exécuter un nouveau test de reconnaissance vocale comparative entre plusieurs options dans un mode de réalisation de l'invention; Les figures 12a, 12b, 12c et 12d représentent un enchaînement d'écrans permettant d'exécuter un test de reconnaissance vocale comparative entre plusieurs options d'une liste de choix dans une langue différente de celle de la question dans un mode de réalisation de l'invention;
Les figures 13a, 13b, 13c et 13d représentent un enchaînement d'écrans permettant de vérifier/modifier les seuils des tests de reconnaissance vocale comparative entre plusieurs options d'une liste de choix dans un mode de réalisation de l'invention. De manière générale, une Boîte Choix permet à un utilisateur de choisir une réponse parmi un ensemble prédéfini de choix. Elle fait appel à un composant de type tableau qui permet à un développeur d'écrire de façon intuitive et lisible son ensemble de choix possibles. La liste de choix peut également être mise en entrée de la boîte, si le développeur ne la connaît pas à l'avance. Ainsi, par exemple, dans le cas d'une application gérant les mails de l'utilisateur, le robot pourra lui faire choisir un contact dans son carnet d'adresse stocké dans un fichier à part. Ces Ul Eléments sont des outils très paramétrables. Les UlElements utilisant la reconnaissance et/ou la synthèse vocale sont ainsi régionalisés. Par exemple, la Boîte Choix est éditable en français et en anglais. Au niveau interface graphique pour sa programmation, le Widget Qt™ utilisé pour changer la langue d'édition de la boîte peut être une ComboBox.
Les entrées (et sorties) des boîtes Chorégraphe peuvent être de plusieurs types :
1 . "bang ": un signal est envoyé
2. number : l'entrée récupère un nombre, entier ou flottant
3. string : l'entrée récupère une chaîne de caractère
4. dynamic.
Une entrée (respectivement sortie) de type dynamic récupère (respectivement sort) une ALValue.
Les ALValue sont une réunion de types communs, décrits dans une librairie NAOQI, notamment : entiers, flottants, array, booléen, string, mais aussi "bang", qui est une ALValue non initialisée. Les entrées de type dynamic permettent de gérer les évolutions d'une application de manière très souple. En particulier le choix des modes de confirmation inter-modalités et/ou intra- modalités, la présentation d'aides sont fournies aux interlocuteurs du robot pour les activer peuvent dépendre du nombre des choix possibles.
Ainsi, on peut envoyer un tableau python (type array) en entrée d'une boîte Chorégraphe à condition que cette entrée soit de type dynamic.
Le logiciel Chorégraphe utilisé pour mettre en œuvre l'invention comprend des paramètres de boîtes de type booléen (Check Box), chaîne de caractères (Text Box), choix multiple de chaînes de caractères (Combo Box) éditables ou non par l'utilisateur final, nombre entier ou flottant flottant (Slider), ou autre. Par exemple, le programmeur qui utilise la Boîte Choix dans son comportement ou application a la possibilité de cocher ou décocher le paramètre booléen "Repeat validated choice" (en français, "Répéter le choix validé"). Cela aura une incidence sur le comportement de NAO pendant l'interaction puisqu'il définit si NAO répète systématiquement le choix validé par l'utilisateur ou non.
Pour pallier la déficience de la reconnaissance vocale, un outil de diagnostic permet de maximiser la réussite de l'interaction vocale. Ainsi, dans la Boîte Choix, quand le développeur a fini d'écrire sa liste de mots dans le tableau, il peut lancer cet outil qui va indiquer un pourcentage de reconnaissance de ces mots, 100% correspondant à un mot qui sera certainement reconnu par le robot, 0% à un mot que le robot ne reconnaîtra pas. Ce diagnostic est effectué en comparant le mot dit par la synthèse vocale (que l'on suppose proche de ce que va dire l'utilisateur) et le mot attendu par la reconnaissance vocale. De plus, afin de maximiser les chances et le naturel de l'interaction, pour chaque choix, on peut définir plusieurs expressions. Ainsi, pour demander au robot d'envoyer un mail, le développeur pourra mettre à disposition de l'utilisateur plusieurs phrases telles que "envoyer un mail", "envoyer un message" ou "envoyer un email". L'utilisateur aura ensuite le choix entre ces différentes expressions pour finalement dire la même chose. La solution de l'invention permet également de résoudre le problème d'une reconnaissance vocale qui ne gère pas la présence de plusieurs utilisateurs. Les humains se rendent compte qu'en parlant à plusieurs, la communication est difficile, donc ils s'adaptent en parlant un par un. Cette situation est facilitée par l'existence de codes d'interaction clairement mono-utilisateur, comme l'utilisation du tutoiement par le robot. Une reconnaissance vocale déficiente impose que l'interface Homme-robot gère notamment au mieux les situations d'échecs, fasse parler l'utilisateur au bon moment (cela va passer par des codes d'interaction) et mette à disposition des solutions alternatives au dialogue qui soient plus efficaces. Dans le cadre de la présente invention, une fonction de diagnostic audio permet de résoudre ce type de problèmes. Cette fonction s'exécute en faisant prononcer le mot à tester par le logiciel de synthèse vocale, text-to- speech. Ce mot est alors analysé par la reconnaissance vocale. Plus précisément, le même mot est prononcé, par exemple trois fois, à chaque fois en changeant la vitesse de la voix et son pitch, de façon à avoir un échantillon représentatif des manières de prononcer le mot. Les trois taux de reconnaissance renvoyés par la reconnaissance vocale sont alors moyennés, et c'est cette valeur qui est le pourcentage estimé de reconnaissance du mot. Il y a deux modes de diagnostic audio possibles Le mode "Together" fonctionne comme suit : tous les mots inscrits dans la boîte choix sont écoutés par la reconnaissance vocale, puis NAO calcule le taux estimé de reconnaissance comme décrit par ailleurs.
Le mode "One by One" fonctionne comme suit : pour une ligne donnée, le mot à analyser est écouté par la reconnaissance vocale, ainsi que les autres choix possibles sur les autres lignes, mais pas ses alternatives situées sur la même ligne que lui. L'intérêt de ce diagnostic est que si deux "synonymes" se ressemblent, par exemple "coucou!" et "coucou toi!", le taux estimé de reconnaissance ne sera pas aussi bas qu'il le serait en mode "Together" (les taux seraient très mauvais car ils seraient souvent confondus par la reconnaissance vocale.) En effet, il n'est pas grave que deux synonymes sont confondus par le robot.
Une fois le diagnostic effectué sur chaque ligne, les synonymes sont rangés par ordre décroissant de taux estimé de reconnaissance, et le taux de reconnaissance du meilleur synonyme est inscrit à la fin de la ligne.
Ainsi, la Boîte Choix est programmée pour demander à un utilisateur de confirmer sa réponse lorsque le robot n'est pas certain de l'avoir correctement reconnue ou interprétée. Ce mécanisme est identique à celui utilisé par un humain qui aurait une audition déficiente ou qui serait plongé dans un environnement rendant sa compréhension difficile. Le robot aura des réactions différentes selon le niveau de compréhension de la réponse de l'utilisateur. Plusieurs seuils (par exemple les seuils S1 et S2 définis en commentaire à la figure 5) sont alors fixés en fonction de la confiance de reconnaissance calculée par le logiciel de reconnaissance : par exemple, lorsque le premier seuil de reconnaissance S1 n'est pas atteint, le robot demande au joueur de répéter sa réponse ; lorsque le premier seuil S1 est atteint mais qu'un deuxième seuil S2 de reconnaissance plus élevé ne l'est pas, le robot va poser une question dont la réponse permettra de lever le doute. Le robot peut également fournir une aide pour que l'utilisateur réponde correctement au robot : il peut donner la liste des choix possibles, indiquer les moyens d'interaction avec lui, répéter la question posée s'il y en avait une. Les codes d'interaction sont également très utiles pour pallier les déficiences de la reconnaissance vocale. En effet, la reconnaissance vocale ne permet pas de parler au robot pendant qu'il parle, et le délai entre le lancement de la reconnaissance vocale et le moment où elle est réellement active est assez long. Un code sonore est ainsi joué au lancement de la reconnaissance vocale, indiquant à l'utilisateur qu'il peut parler. Ensuite, un code visuel assez intuitif, les LED des oreilles qui tournent, permet à l'utilisateur de savoir que le robot est en écoute. Les UlElements utilisant la reconnaissance vocale proposent également un moyen alternatif à cette reconnaissance vocale, pour permettre à l'utilisateur de réussir la communication même en cas de problèmes répétés de compréhension (cela peut être dû à un environnement extrêmement bruyant par exemple). Ces moyens alternatifs peuvent être tactiles, sonores, visuels, etc. Par exemple, la Boîte Choix permet à l'utilisateur de choisir une réponse en utilisant le capteur tactile : appuyer sur le capteur de devant permet d'avancer dans la liste de choix (le robot énonce alors chaque choix), celui de derrière permet de reculer dans cette liste, celui du milieu permet de valider son choix. On peut imaginer également que le robot énonce les différents choix, et que l'utilisateur dise "OK" quand il entend le choix qu'il veut valider. Ou encore, pour une confirmation, au lieu de dire "oui" ou "non" l'utilisateur peut appuyer sur un des bras du robot. Le module de contrôle des entrées/sorties des canaux de communication des différents types 1 , 2, 3 définis en commentaire à la figure 5 permet de générer de manière simple et conviviale les fonctions de gestion de ces combinaisons par des liaisons entre les différentes entrées/sorties des Boîtes Choix. De façon générale, la solution de l'invention propose une humanisation de l'interface, une simulation de l'interface Homme-Homme. Nous savons que trois principaux facteurs entrent en jeu lors d'une communication directe entre deux humains : bien sûr la parole c'est-à-dire les mots dits, mais aussi le ton de la voix et les éléments visuels. Pour preuve, en observant tout au long de leur évolution les moyens de communication indirecte, telle que l'écriture ou les messages instantanés, on peut voir très clairement de quelle façon le manque d'informations du dialogue peut en règle générale être pallié par l'ajout de substituts à la communication directe, substituts tels que la ponctuation ou plus récemment les smileys. Dans tous les cas, malgré les grandes avancées technologiques d'aujourd'hui, ces éléments fondamentaux sont encore difficilement transposables dans leur entier pour la communication homme-robot. Il est cependant possible de trouver des substituts artificiels qui améliorent le rendu du dialogue. La synthèse et la reconnaissance vocales du robot permettent une équivalence à la parole. Elles sont ainsi les piliers de sa communication avec un humain. Un robot humanoïde a a fortiori l'avantage de pouvoir rendre une grande partie des éléments visuels du dialogue que sont les gestes et les expressions faciales. En effet, bien qu'avec son corps anthropomorphe, ses déplacements ne soient pas aussi aisés qu'un robot sur roues, ses gestes peuvent être plus facilement basés sur le comportement humain et donc aussi facilement décryptés que les mouvements humains. La communication se fait alors plus naturellement.
Le ton de la voix et les expressions faciales manquent néanmoins sur un robot à visage et tonalité figés. Cependant, ces deux éléments sont compensés par d'autres fonctions, des codes qui traduiront ces éléments. Ils nécessitent un apprentissage plus ou moins long de l'utilisateur. L'objectif est alors de faire que cet apprentissage soit le plus court possible et donc que les codes soient les plus cohérents et les plus proches possible de ce que l'utilisateur connaît déjà.
En adaptant les lois basiques de l'ergonomie de Ben Shneiderman énoncées dans son livre Designing the User Interface: Stratégies for Effective Human-Computer Interaction (publié en 1997 : http://www. es, u d. edu/heil/pubs/books/dtui. shtml) et appliquées normalement aux interfaces graphiques, on arrive à des codes cohérents, simples et donc à une interaction naturelle et fluide. Ces lois énoncent les principes suivants : la cohérence des codes et des éléments d'interface, la présence de raccourcis pour les utilisateurs avancés, la présence de retours immédiats sur les actions effectuées, la fin explicite des dialogues, une gestion simple des erreurs, la possibilité de retours en arrière, l'utilisateur doit se sentir maître durant l'interaction et enfin, une stimulation moindre de la mémoire à court-terme de l'utilisateur.
La reconnaissance et la synthèse vocale sont limitatives, notamment par l'absence de langage naturel et une reconnaissance uniquement mono- utilisateur et ne permettant de reconnaître qu'un nombre limité de mots. La solution de l'invention résout le problème de la non-utilisation de langage naturel par les robots afin de proposer une interaction Homme-robot suffisamment naturelle. Déjà, la synthèse vocale du robot est utilisée au mieux. Notamment, la plupart des UlElements du robot utilisant la synthèse et/ou la reconnaissance vocale sont régionalisés. Un utilisateur francophone (respectivement anglophone) pourra ainsi converser avec son robot en français (respectivement en anglais), maximisant ainsi la réussite de l'interaction. Ensuite, des timings et des codes d'interaction sont utilisés au mieux afin d'améliorer la réactivité du robot et de faciliter le succès de la communication Homme-robot. Ainsi, la Boîte Choix propose plusieurs paramètres comme le délai d'attente d'une réponse de l'utilisateur. On s'assure ainsi que le robot n'attend pas trop longtemps avant de considérer que l'utilisateur n'a rien répondu, mais aussi qu'il attend suffisamment longtemps pour que la reconnaissance vocale puisse être activée au bon moment. Les codes d'interaction peuvent être gestuels, sonores et/ou visuels. Ainsi un bip sonore de fin de reconnaissance vocale permet à l'utilisateur de savoir que le robot ne l'écoute plus.
De plus, dans la solution de l'invention, la communication est rendue plus naturelle par une l'utilisation de plusieurs canaux de communication de modalités différentes, et des comportements particuliers de la part du robot. Ainsi, l'utilisation de la localisation sonore et de la détection de visage (notamment sa position) permet au robot de tourner sa tête vers son interlocuteur humain, ce qui semble un fait acquis lorsqu'il s'adresse à un autre humain. Le robot peut également mettre en œuvre une identification du locuteur (reconnaissance faciale, timbre de la voix, empreinte vocale...) afin de s'adresser à un humain en particulier en utilisant son nom, des caractéristiques qui lui sont propres comme, par exemple, l'historique des conversations et comportements joués par le robot. Le robot peut également savoir ce que l'utilisateur a pensé d'un comportement selon qu'il ait caressé son capteur tactile (l'Homme a aimé le comportement), et proposer alors de le jouer lors d'une communication orale par exemple. Le robot va tenter d'agir de façon adaptée à la situation. Ainsi, il peut jouer des animations, utiliser ses LED et diffuser du son, ce qui lui permet alors de simuler les gestes instinctifs qu'un humain fait quand il parle (parler avec les mains, ...). Le robot peut également produire des acquiescements de la tête (nommés head nods ). Plusieurs études, notamment celle de Justine Cassell faite dans son article Social Dialogue With Embodied Conversational Agents (publié en 2005:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10. 1. 1. 124.9853&rep=rep 1&tvpe=pdfh ont permis de prouver que l'homme considère qu'une machine ou un avatar semble plus intéressé par la conversation quand cette machine ou cet avatar produit des head nods, même quand ils sont produits au hasard. Tous ces signaux gestuels (comme acquiescer ou nier avec la tête, les bras ou les mains), sonores, la chronologie de l'interaction, la localisation de l'interlocuteur, ou encore la détection des intentions de l'utilisateur (est-ce qu'il avance ou recule) permettent de rendre plus naturelle et efficace l'interaction Homme-robot en la rendant plus proche des codes humains habituels. Ils résolvent donc également une partie des problèmes liés à la reconnaissance vocale restrictive. Ils sont un des avantages de l'invention. Les copies d'écrans des figures 8 à 13 décrivent la manière dont peuvent être programmés plusieurs cas de dialogue entre un robot NAO et un interlocuteur.
Pour utiliser la boîte choix dans le comportement, il faut la drag-and-dropper (glisser-déposer) depuis la librairie par défaut de Chorégraphe dans le diagramme (figure 8a). On ajoute une boîte LocalizedText, qui va permettre d'éditer la question en français et en anglais. On écrit la question en anglais "What is your favorite animal?" dans le plugin texte de la Boîte LocalizedText (figure 8b). On veut aussi éditer la question en français. Pour ce faire, on utilise la Combo Box du plugin de la boîte, et on choisit French. (figure 8c). On écrit alors le texte de la question en français dans le plugin texte qui est vide quand il n'est pas édité : "Quel est ton animal préféré ?" (figure 8d). La question doit être en entrée de la Boîte Choix, pour être bien gérée par le robot. On relie la sortie de la boîte LocalizedText à l'entrée onStart de la Boîte Choix (figure 8e).
On va maintenant éditer les choix, en anglais, comme l'indique la Combo Box de la Boîte Choix. On enlève les choix par défaut de la Boîte. Sur la première ligne du tableau, on écrit le premier choix "pangolin" (figure 9a). Sur la deuxième ligne, on propose un autre animal : "spider", mais on ajoute un synonyme "tarantula", séparé de spider par un slash '/'. Cela signifie que le robot considère spider et tarantula comme étant synonymes (figure 9b). On finit d'éditer les choix, en ajoutant par exemple "rabbit" et "pony". On remarque que le nombre de lignes s'adapte automatiquement quand on ajoute des choix (figure 9c). On utilise la Combo Box pour passer la langue d'édition de la Boîte Choix au français (figure 9d). Comme pour l'anglais, on écrit la liste de choix, ainsi on obtient : "pangolin", "araignée/tarentule", "lapin" et "poney". (figure 9d).
Mais on ne sait pas si le robot va bien reconnaître ces choix ou pas. On veut alors lancer la fonction de diagnostic audio. On clique sur le "plus" (figure 10a). On clique alors sur l'icône d'évaluation (figure 10b). Pour chaque ligne, les mots sont évalués (figure 10c). En cas de synonymes, le meilleur est placé au début, et le pourcentage indiqué est alors le résultat du meilleur synonyme. Le diagnostic audio se finit, on voit alors que "poney"' risque d'être très mal reconnu (figure 10d).
On décide alors de changer de mot et de mettre "cheval" à la place (figure 1 1 a). On relance le diagnostic. "Cheval" obtient un excellent score de 82%, on le conserve (figure 1 1 b).
On repasse en anglais et on lance le diagnostic sur les mots en anglais (figures 12a, 12 b). On rajoute ensuite à "poney" le synonyme "horse", en tant que traduction de "cheval" (figure 12c). On relance le diagnostic, et on remarque que "horse", ayant un meilleur score que "poney", a été placé en première position automatiquement (figure 12d).
On va maintenant éditer les paramètres qui peuvent être réglés. On clique sur la clé à molette en bas à gauche de la Boîte Choix (figure 13a). La fenêtre de paramétrage s'ouvre (figure 13b) ; on coche le paramètre booléen "activate arms" (figure 13c). Ainsi, le robot bougera les bras pendant qu'il parlera. On clique sur OK pour valider ce nouveau paramétrage.
On relie l'entrée générale du comportement à l'entrée de la boîte LocalizedText, et les sorties de la boîte Choix à la sortie générale du comportement (figure 13d).
On décrit maintenant un exemple de fonctionnement du logiciel programmé comme dans l'exemple décrit ci-dessus.
On asservit le robot grâce à l'icône Chorégraphe "enslave ail motors on/off", puis on le met debout grâce à la position "init pose" de la pose library. On met la langue du robot à français grâce au paramètre présent sur sa page web. On lance le comportement sur le robot grâce à l'icône Play de Chorégraphe.
En bougeant les bras, le robot demande "Quel est ton animal préféré ?", puis lance un signal sonore d'écoute. Pendant qu'il est en écoute, ses yeux tournent en bleu, ainsi que ses oreillles, et les capteurs tactiles de sa tête clignotent en bleu.
L'utilisateur répond alors "dauphin". Les yeux de NAO deviennent jaunes pendant qu'il analyse ce qui vient d'être dit. Il ne comprend pas la réponse : ses yeux flashent deux fois en rouge, et ses oreilles en bleu. Il dit "Je n'ai pas compris. Tu peux répondre : pangolin, araignée, lapin ou cheval. Quel est ton animal préféré ?", tout en bougeant les bras et il revient en phase d'écoute.
L'utilisateur répond alors "lapin". Le robot n'est pas sûr mais croit comprendre pangolin. Ses yeux flashent une fois en vert. Il dit alors, tout en lançant une animation des bras, "J'ai compris pangolin, est-ce correct ?". L'utilisateur répond "non". Le robot flashe une fois les yeux en rouge et lance une aide tout en bougeant les bras : "pangolin, araignée, lapin, ou cheval ? Tu peux aussi choisir une réponse à l'aide de mon capteur tactile. Quel est ton animal préféré ?" et il revient en mode écoute. L'utilisateur appuie alors sur le capteur tactile de devant, le robot flashe ses yeux une fois en bleu et dit "pangolin". Puis l'utilisateur appuie à nouveau, le robot répond "araignée" tout en flashant ses yeux une fois en bleu. La troisième fois le robot dit "lapin" avec un flash bleu des yeux. L'utilisateur appuie alors sur le capteur tactile du milieu pour valider son choix. Le robot flashe une fois ses yeux en vert, répète alors "lapin" et sort de la boîte et du comportement. D'autres interactions entre canaux de communication du robot sont possibles, telles que celles décrites ci-dessous.
La Boîte Choix utilise de manière privilégiée la reconnaissance vocale en combinaison avec le capteur tactile afin de reconnaître le choix de l'utilisateur. Une autre possibilité est d'utiliser la vision du robot, notamment la reconnaissance d'image. C'est une reconnaissance d'objet et non pas de concept : si on lui montre une canette, il reconnaîtra cette même canette et pas celle d'une autre marque. Une des possibilités du logiciel de développement dans sa version permettant de mettre en œuvre l'invetion est d'avoir dans ce logiciel le retour caméra du robot. L'utilisateur peut montrer des objets au robot, voir l'image obtenue dans Chorégraphe, et identifier à la main l'objet intéressant dans l'image. L'utilisateur le nomme. Le robot analyse alors l'objet et le stocke dans sa base de données d'images.
L'utilisateur peut alors utiliser ces images comme des choix possibles pour une boîte choix.
Par exemple, si l'utilisateur veut remplir une Boîte Choix avec des noms d'objets, comme "canette", "tasse", "magazine". Il remplit la Boîte Choix avec ces mots, puis prend une canette, sa tasse préférée et la couverture d'un magazine et les montre au robot pour qu'il les analyse comme expliqué précédemment. La Boîte Choix fait alors une recherche dans la base de données d'images du robot : si un objet noté "tasse" est présent, NAO le recherche alors en même temps qu'il écoute l'utilisateur, et ainsi de suite pour les autres mots. Ainsi, l'utilisateur lance cette Boîte sur NAO, qui écoute ses choix. L'utilisateur dit "canette" mais le robot ne comprend pas. Au bout de deux fois, le robot explique qu'il peut lui montrer "canette", "tasse" et "magazine" parce qu'ils sont dans sa base de données. L'utilisateur peut pendant l'écoute montrer la canette qui a servi à l'enregistrement (ou de la même marque). Le robot agit alors comme s'il avait reconnu le mot "canette".
Dans le cadre de la présente invention, il est également possible de programmer le robot pour qu'il serve d'agent de réception/lecture, écriture/envoi et administration d'un compte de messagerie d'un utilisateur du robot. Cette application est décrite ci-dessous.
Avec l'application Mail, NAO peut notamment lire des emails, répondre à un email ou envoyer des emails à un contact, mais aussi ajouter l'auteur d'un mail reçu aux contacts, supprimer un message, le marquer comme non lu, le relire, lire le message suivant ou le précédent.
Trois Boîtes Choix sont utilisées dans cette application, en faisant ainsi un élément indispensable. Les mots ont été choisis grâce au diagnostic audio. Quand l'application est lancée, le robot commence par regarder si l'utilisateur a reçu de nouveaux messages. Si oui, il lit le premier nouveau message puis lance une Boîte Choix sans question. Si non, il lance cette même Boîte Choix mais avec une question : "Que veux-tu que je fasse?". Le fait de pouvoir lancer une Boîte Choix avec ou sans question est donc utilisé dans l'application mail. Cette Boîte Choix permet à l'utilisateur de faire son choix parmi les actions possibles de NAO. Ces actions sont écrites dans le tableau du plugin de la boîte. La sortie de Boîte Choix "timeout" est utile, car en cas de timeout, NAO lit le message suivant. Un paramètre "maximum number of répétition when no reply" est alors mis à 1 : le robot quitte cette boîte choix au premier timeout. De plus, le paramètre "repeat validated choice" est désactivé, car après un choix de l'utilisateur le robot lance une animation ou action spécifique qui montre clairement ce qu'il a compris. Grâce aux paramètres booléens "activate head", "activate arms" et "activate legs", le robot va être animer avec des animations dédiées au discours.
Par exemple, les choix possibles de cette boîte, en français sont:
Enregistrer une réponse / Répondre à ce mail / Répondre au mail / Répondre ;
Lire à nouveau / Relire ce mail / Relire le mail / Relire ;
Suivant / Lire le suivant / Lire le mail suivant ;
- Précédent / Lire le mail précédent / Lire le message précédent ;
Marquer comme non lu / Conserver / Relire plus tard ;
Supprimer / Supprimer le mail / Supprimer le message ;
Écrire un mail / Envoyer un mail / Envoyer ;
Ajouter aux contacts;
- Sortir/Quitter/Passer/Arrête/Arrêter/Annuler/Tais toi : "Sortir" est un des choix par défaut de la boîte choix, qui permet ici de sortir de l'application mail.
Si l'utilisateur choisit l'option "Écrire un mail", il doit d'abord choisir un contact dans son carnet d'adresses. Pour réaliser cette fonction de choix, une Boîte Choix avec en entrée la question "A qui veux-tu écrire ?" est utilisée. La liste de choix est variable. Par conséquent, le tableau de la Boîte Choix n'a pas été rempli, la liste de contact est récupérée depuis le fichier qui la sauvegarde et envoyée à l'entrée "choicesList" de la boîte Choix, de type dynamic. Cette fois-ci, le paramètre "repeat validated choice" est activé, pour indiquer à l'utilisateur que Nao a bien compris à qui envoyer le message. Le paramètre "maximum number of répétition when no reply" est par exemple à 3, sa valeur par défaut pour, en cas de timeout, ne pas envoyer un mail à n'importe qui, mais bien pouvoir annuler l'envoi du mail et de revenir au menu principal. De même, dire "Sortir", choix par défaut de l'application, permet de revenir au menu principal. Une fonction d'aide est pour le cas où l'utilisateur ne se rappelle plus de ses contacts. Dans ce cas, avec le capteur tactile par exemple, NAO énonce la liste des contacts.
Que ce soit dans ce cas d'envoi direct d'un mail, ou bien dans le cas de réponse à un message reçu, le robot va enregistrer le message de l'utilisateur.
Une fois le message fini, le robot relit le message enregistré puis lance une Boîte Choix qui propose par exemple les différentes interactions suivantes:
Rejoue-le / Rejoue le message / Rejoue mon message : NAO relit le message.
- Réenregistre le message / Réenregistre mon message /
Réenregistre-le : le message peut être réenregistré, si le premier ne convient pas ;
Ne l'envoie pas / Ne pas envoyer / N'envoie pas le message : NAO n'enverra pas le message, puis reviendra au niveau précédent de l'application ;
Envoie-le / Envoie le message / Envoie mon message : NAO enverra le message ;
En cas de timeout, le message est envoyé ;
En cas de sortie "other" de la Boîte qui ne soit pas un timeout, comme une demande de sortie ou des échecs à répétition, l'application revient au niveau précédent.
Les paramètres sont sensiblement les mêmes que pour la Boîte Choix du menu principal, avec le paramètre "Maximum number of répétition when no reply" mis à 1 . Les paramètres "speech récognition timeout", qui indiquent au bout de combien de temps sans réponse le robot considère qu'il y a timeout, et "speech récognition timeout when confirmation" peuvent par exemple être mis à 4 secondes au lieu de 6 par défaut, pour que l'utilisateur puisse facilement ne rien dire et laisser le message être envoyé. La Boîte Choix peut également être configurée de manière statique avec des paramètres constants sur toute la durée d'utilisation de la Boîte. Mais dans le cadre de l'utilisation d'un système de génération automatique de questions, les paramètres peuvent être réglés automatiquement. Par exemple, dans le cadre d'utilisation d'un agent conversationnel tel que celui développé par la société As An Angel, ledit agent peut configurer la Boîte Choix en fonction des questions-réponses qu'il aura automatiquement générés.
D'autres améliorations ont été apportées au logiciel Chorégraphe de développement des comportements, notamment pour faciliter la mise en œuvre de la présente invention. Une description en est donnée ci-dessous.
Les Boites Chorégraphe sont implémentées au moyen d'un script dans un des langages de programmation supportés. Si cette Boîte a certains aspects paramétrables, comme le nombre de répétitions, la langue utilisée par le robot, le texte que le robot doit prononcer, ces informations sont intégrées directement dans le script de la boite. Lorsqu'on veut modifier les paramètres de la boite, par exemple après l'avoir dupliquée pour l'utiliser différemment, il faut modifier le script de la boite pour changer son comportement.
Comme c'est une opération courante, qu'un utilisateur sans connaissance approfondie du langage de script utilisé pourrait vouloir réaliser, ainsi que pour améliorer la productivité des utilisateurs de Chorégraphe, une interface spéciale a été développée pour pouvoir configurer des scripts de Boîte. Il y a deux aspects à cette fonctionnalité.
Dans l'interface de Chorégraphe, l'utilisateur a la possibilité de créer des "paramètres de Boîte" dans la fenêtre d'édition des attributs de la boite, de la même manière qu'il peut créer des entrées et des sorties pour la boite. Chaque "paramètre de boite" a un nom, une description, un type (parmi booléen, entier, flottant et chaîne), et en fonction du type peut avoir des attributs supplémentaires, comme une valeur par défaut. Enfin un "paramètre de boite" peut être défini comme héritant de la boite parente, ce qui affectera la manière dont la valeur sera déterminée. Une fois des "paramètres de boite" définis, la Boîte est affichée dans son diagramme avec un indicateur visuel supplémentaire dans son coin inférieur gauche. Quand l'utilisateur clique sur cette icône, un dialogue d'édition de "paramètres de Boîte" s'ouvre, et l'utilisateur peut définir la valeur associée à chaque "paramètre de Boîte", dans le cadre d'éventuelles contraintes définies dans les attributs du "paramètre de Boîte".
Dans le script de la boite, l'auteur de la Boîte peut désormais accéder aux "paramètres de Boîte" à l'aide de plusieurs fonctions prennant en argument le nom du "paramètre de Boîte". Il peut consulter la valeur courante d'un "paramètre de Boîte" et la changer. Il peut aussi créer des "paramètres de Boîte" dynamiques, qui n'apparaîtront pas dans Chorégraphe, mais qui pourront servir de stockage temporaire dans les scripts de la Boite. La valeur courante d'un paramètre dépend du fait qu'il soit marqué comme héritant de la Boîte parente ou non. S'il ne l'est pas (le cas par défaut), le "paramètre de Boîte" est spécifique à la Boîte, et quand le script de la Boîte le consulte sa valeur courante est simplement retournée. S'il est marqué comme héritant, lors de la lecture de la valeur, la hiérarchie de diagrammes de Boîtes va être remontée jusqu'à trouver une Boîte parente contenant un "paramètre de Boîte" du même nom. Si aucun n'est trouvé la valeur courante pour la Boîte courante est utilisée.
Le robot dispose par ailleurs d'un module logiciel lui permettant de reconnaître des objets qui passent dans le champ de vision de sa caméra. Cependant les objets à reconnaître doivent d'abord être appris dans une phase d'apprentissage. Cet apprentissage est réalisé à l'aide d'une interface spécifique dans Chorégraphe.
Cette interface affiche en temps réel la vidéo envoyée par la caméra du robot. L'image n'est disponible que lorsque Chorégraphe est connecté à un robot disposant d'une caméra et d'un module de capture vidéo correctement configuré. Quand l'affichage vidéo est activé, l'utilisateur peut déclencher un apprentissage. Un compte à rebours apparaît alors sur l'image, et l'utilisateur dispose alors par exemple de 4 secondes pour présenter un objet devant la caméra. A la fin du compte à rebours des images sont capturées et enregistrées. L'utilisateur doit alors détourer l'objet d'intérêt dans l'image en dessinant un polygone sur l'image figée. Une fois le polygone fermé, un dialogue s'ouvre demandant à l'utilisateur d'entrer des mots-clés définissant l'objet.
Chaque apprentissage génère une entrée dans une base de données qui est sauvegardée par Chorégraphe sur l'ordinateur de l'utilisateur. Une fois l'apprentissage terminé, un bouton permet d'envoyer une version allégée de la base de données sur le robot. Le module de reconnaissance d'objets utilisera alors cette base de données, et quand un objet sera reconnu, un événement contenant les mots-clés associés sera déclenché sur le robot.
Chorégraphe est par ailleurs un éditeur de comportements pour le robot. Comme décrit précédemment en commentaire à la figure 4, un comportement est un objet similaire à un programme informatique, qui peut être exécuté par le robot. Afin d'installer et d'exécuter ces comportements sur le robot, il a été développé une interface de gestion des comportements sur le robot. Quand Chorégraphe est connecté à un robot, une entrée des menus de l'application permet d'afficher le gestionnaire de comportements. C'est une fenêtre modale affichant une liste des comportements installés sur le robot, ainsi qu'un ensemble de boutons pour les manipuler.
Pour chaque comportement installé est affiché son nom, son état (en cours d'exécution ou non) et un attribut définissant si le comportement doit être exécuté au démarrage du robot. Pour démarrer ou arrêter un comportement, il suffit de cliquer sur l'icône affichant son état courant, ce qui a pour effet de basculer l'état. Une fois le comportement terminé l'état repasse automatiquement à "arrêté". L'attribut "lancer au démarrage" est une Boîte à cocher. Elle indique la valeur courante de l'attribut, et l'utilisateur peut simplement cliquer dessus pour changer cette valeur.
Les boutons affichés à côté de la liste de comportements permettent d'en ajouter, d'en supprimer, et d'en transférer vers l'ordinateur de l'utilisateur. L'utilisateur peut ainsi très facilement manipuler les comportements installés sur le robot, comme si c'était des fichiers sur son ordinateur. En particulier, un utilisateur peut télécharger un comportement, le modifier, et le réinstaller sur le robot, sans avoir à l'enregistrer sur son ordinateur. Les comportements installés par l'utilisateur peuvent alors s'exécuter en parallèle, sous les contraintes de cohérence temporelle et entre comportements définies par les différentes Boîtes de comportement, les Trames de comportement et la Timeline.
Les exemples décrits ci-dessus sont donnés à titre d'illustration de modes de 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.