EP2596493A1 - Humanoid robot equipped with a natural dialogue interface,method for controlling the robot and corresponding program - Google Patents

Abstract

The invention relates to a humanoid robot equipped with an interface for natural dialogue with an interlocutor. In the prior art, the methods of dialogue between humanoid robots equipped, moreover, with developed movement functionalities and human beings are limited particularly by the capabilities of voice and visual recognition processing with which said robots can be fitted. The present invention equips said robots with capabilities for removing doubt from several methods of communication for the messages which they receive and for combining these different methods, which allow a great improvement in the quality and the natural character of the dialogues with those with whom the robots are speaking. The invention likewise provides simple and user-friendly means for implementing the programming of the functions which allow the free flow of these dialogues using multiple methods to be ensured.

Description

 HUMANOID ROBOT HAVING A NATURAL DIALOGUE INTERFACE, ROBOT CONTROL METHOD, AND CORRESPONDING PROGRAM

The present invention belongs to the field of humanoid robots. More specifically, it applies to the methods of programming and the use of dialogue interfaces with a robot of this type to enable the said robot to perform actions on the order of a user, the provision of adequate responses by said robot and, more generally, restoration of "humanoid relations" between said robot and his or her interlocutors.

 A robot can be called a humanoid from the moment it has certain attributes of the appearance and functionality of the man: a head, a trunk, two arms, possibly two hands, two legs, two feet ... Beyond appearance, the functions that a humanoid robot is able to fulfill will depend on its ability to perform movements, talk and reason. Humanoid robots are able to walk, to make gestures, with the limbs or with the head. The complexity of the gestures they are able to perform increases constantly.

 Some robots can talk in response to environmental stimuli. The development of speech recognition and synthesis tools has also made it possible to develop dialogue functions of certain robots with humans that significantly enrich the possibilities of interactions. Such human-robot interfaces using speech are disclosed in particular by US Pat. No. 7,741,569 and by the application published under number US2009 / 287678.

In these documents of the prior art, the imperfections inherent in voice recognition are mitigated by the use of semantic and / or contextual aids which require access to a database, learning and the use of computing resources. important to be able to remove the doubts of recognition - confidence interval low recognition, false positives, false negatives .... The use of these means is not appropriate in the case of a A multifunctional humanoid robot that must be economical with its computing resources to manage critical processes such as locomotion.

It would be advantageous to be able to have a humanoid robot capable of raising the suspicion of the recognition made by sensors and software that will remain imperfect in a simple and effective manner using the onboard computing resources on said robot.

The present invention solves this problem by providing a dialog interface with a humanoid robot that uses a natural mode of confirming responses.

For this purpose, the present invention discloses a humanoid robot comprising at least two message communication channels with at least one interlocutor according to different modalities, said at least two channels being each chosen from the reception, transmission, and a control module group. input / output of said channels, said robot being characterized in that said control module is able to improve the understanding of the messages received by said robot by executing at least one function selected in the group combination of messages received / transmitted on a first channel and on a second channel, sending a second message generated from a first message received on a channel.

Advantageously, said communication channels are chosen from the group of communication channels transmitting and / or receiving sound, visual, tactile messages, displacements and / or positions of at least part of the robot, and digital.

Advantageously, a first communication channel is a sound transmission channel and a second communication channel is a reception channel for displacements and / or positions of at least a part of the robot by said at least one interlocutor, said displacements and / or or positions being representative of inputs communicated by the interlocutor to the robot, the specifications of said inputs being defined by the robot to the interlocutor by the message transmitted on the first channel. Advantageously, the robot of the invention further comprises a third touch communication channel by which the interlocutor validates the inputs made on the second channel.

Advantageously, a first communication channel is a sound message reception channel and a second communication channel is a sound message transmission channel and in that said control module is able to evaluate the level of confidence of the understanding by said robot of a first message received on said first channel and generating at least a second message on said second channel whose content depends on said confidence level.

Advantageously, the first channel comprises a voice recognition filter messages received by a list of expressions each of which is associated with an expected recognition rate and that the content of said second message is chosen by a heuristic in the group comprising repetition of said first message on the first channel, confirmation request by a third message to be sent by the interlocutor on the first channel of a subset of the expressions of the filter, transmission request by the interlocutor of at least one another message on at least one third channel.

Advantageously, the robot of the invention is able to transmit on the second channel a start of listening signal on the first channel to ensure the half-duplex mode sequencing messages on the first and second channel.

Advantageously, said choice heuristic is a function of the position of the real recognition rates with respect to thresholds determined from the expected recognition rates.

Advantageously, said third channel is a touch reception channel or displacements of a part of the robot. Advantageously, the robot of the invention further comprises an interface module with an electronic mail, said interface module allowing an account holder on said messaging to use said robot as an agent for receiving / reading messages. electronic on the second channel, write / forward on the first channel and administer said account by dialogue using said first and second channel.

Advantageously, said third channel is a visual reception channel for images of objects corresponding to the list of expressions of the filter of the first channel, said images being compared to an image database of said objects previously recorded with said accessible expressions. by said input / output control module of said communication channels. Advantageously, a first communication channel is a visual message reception channel and a second communication channel is a sound message transmission channel and in that said control module is able to evaluate the level of confidence of the understanding by said robot of a first message received on said first channel and generating at least a second message on said second channel whose content depends on said confidence level.

Advantageously, the first channel comprises an image recognition filter of the messages received by a list of expressions to each of which is associated an expected recognition rate and in that the content of said second message is chosen by a heuristic in the group comprising request for repetition of said first message on the first channel, request for confirmation by a third message to be sent by the party on a third channel for receiving sound messages of a subset of the expressions of the filter, transmission request by the interlocutor of at least one other message on at least one fourth channel. Advantageously, at least one of the channels is a hybrid channel receiving as inputs the outputs of two channels merged by said input and output control module. The invention also discloses a method for controlling the communications of a humanoid robot with at least one interlocutor comprising at least two message transmission steps by communication channels using different modalities, said two steps being each chosen in the reception group , transmission, and a control step of the inputs / outputs of said channels, said robot being characterized in that said control step is able to improve the understanding of the messages received by said robot by performing at least one function selected in the combination group of messages received / transmitted on a first channel and a second channel, sending a second message generated from a first message received on a channel.

The invention also discloses a computer program comprising program code instructions for executing the above method when the program is run on a computer, said program being adapted to allow a humanoid robot comprising at least two channels communicating messages with at least one interlocutor according to different modalities, said at least two channels being each chosen from the reception group, transmission, and a sub-program for controlling the inputs / outputs of said channels, said computer program being characterized in that said control routine is able to improve the understanding of the messages received by said robot by executing at least one function selected in the group combination of messages received / transmitted on a first channel and on a second channel, transmission of a second message generated from a first message received on a channel.

The invention also discloses a method of developing a communication interface between at least one humanoid robot and at least one interlocutor, said at least one humanoid robot comprising at least two message communication channels with the at least one interlocutor according to different modalities, said at least two channels being each chosen in the reception group, transmission, and an input / output control module of said channels, said control module being able to improve the understanding of the messages received by said robot in performing at least one function selected from the combination group of received / transmitted messages on a first channel and a second channel, transmitting a second message generated from a first message received on a channel, said method being characterized in that it comprises a programming step of said chosen function.

Advantageously, said step of programming said chosen function comprises at least one substep of defining a first communication channel as a sound transmission channel and a second communication channel as a travel receiving channel. at least one robot member by said at least one interlocutor, a sub-step of defining a correspondence between said movements and inputs communicated by the interlocutor to the robot, and a substep of defining the specifications of said inputs by generating at least one message to be transmitted by the robot to the interlocutor on the first channel.

Advantageously, the development method of the invention further comprises a substep of defining a third touch communication channel by which the interlocutor validates the inputs made on the second channel.

Advantageously, the steps of the development method of the invention are carried out via at least one control box in which a main action frame to be performed by said robot is connected to at least one event selected from the group. antecedent events and successor events to the action to be programmed and programmed to take place according to a temporal constraint predefined by a Timeline.

Advantageously, said programming step of said selected function comprises at least one sub-step of defining a first channel of communication as a sound message receiving channel and a second communication channel as a sound message transmission channel, a sub-step of defining a confidence level evaluation function of the understanding by said robot of a first message received on said first channel and a substep of defining the generation of at least a second message on said second channel whose content depends on said confidence level.

Advantageously, the development method of the invention further comprises a substep of defining a voice recognition filter of the messages received on the first channel by a list of expressions each of which is associated with an expected recognition rate and a sub-step of defining the content of said second message by a heuristic chosen in the request group of repetition of said first message on the first channel, confirmation request by a third message to be sent by the interlocutor on the first channel of a sub all the expressions of the filter, request for transmission by the interlocutor of at least one other message on at least one third channel. Advantageously, the steps of the development method of the invention are carried out via at least one control box in which a main action frame to be performed by said robot is connected to at least one event selected from the group. antecedent events and successor events to the action to be programmed and programmed to take place according to a temporal constraint predefined by a timeline, said command box being a choice type box.

The invention also discloses a computer program comprising program code instructions for executing the above development method when the program is run on a computer, said program being adapted to allow a user to program a robot. humanoid device comprising at least two message communication channels with at least one interlocutor according to different modalities, said at least two channels being each selected from the reception, transmission group, and a control subprogram of input / output of said channels, said computer program being characterized in that it comprises a programming module in the control routine of at least one function to be executed by the selected robot in the group of received messages / transmitted on a first channel and a second channel, sending a second message generated from a first message received on a channel.

Advantageously, the computer program of the invention further comprises a module for programming the passage of at least one parameter to a control box.

Advantageously, the computer program of the invention further comprises a module for programming the return of the inputs of a visual communication channel of the robot in the interface of said program.

Advantageously, the computer program of the invention further comprises a module for programming behaviors of the robot running in parallel. The interface of the invention also has the advantage of offering multimodal confirmation modes that can easily be adapted to the environment in which the dialogue is executed, for example if the ambient noise is too high for the voice recognition may have some effectiveness. The user can be asked to replace / confirm ambiguous answers with a touch, a gesture or the display of a particular numerical symbol, color or shape. Thus, the user has at his disposal means enabling him to intuitively replace or emulate the traditional interfaces that he is used to using when he is facing his computer or using a smart phone or a touch pad.

In addition, the modes of expression of the robot can themselves be multimodal, combining inter alia intonation, gaze, gesture to hold the attention of his interlocutor and communicate emotions or clues to answers to provide. Moreover, by approaching the natural modes of communication between humans, the interface of the invention contributes to to improve the results of the recognition system and to enhance the quality of the experience of the user immersed in a "real virtuality", that is to say that of a dialogue with a physically embodied avatar.

The invention also provides an environment for developing these interfaces, ergonomic and versatile, which makes it very easy to create, in a very short time, new interaction scenarios specially adapted for uses of the robot not imagined by its designer.

The invention will be better understood and its various features and advantages will emerge from the following description of several exemplary embodiments and its appended figures including:

 FIG. 1 is a diagram of the physical architecture of a humanoid robot in several embodiments of the invention;

 FIG. 2 illustrates the head of a humanoid robot comprising sensors that are useful for implementing the invention in several of its embodiments;

 FIG. 3 is a schematic diagram of the architecture of high level software for controlling the functions of the robot in several embodiments of the invention;

 FIG. 4 is a diagram of the functional architecture for editing and programming the behaviors / interactions of a robot in several embodiments of the invention;

 FIG. 5 is a functional flowchart of the treatments generally applied to improve the interpretation given by a humanoid robot of the responses / stimuli it receives in several embodiments of the invention;

 FIG. 6 is a logic diagram for programming the behaviors / interactions of a robot in several embodiments of the invention;

 FIGS. 7a, 7b and 7c represent timing diagrams illustrating the logical and temporal combination of the interactions of a multimodal interface in several embodiments of the invention;

FIGS. 8a, 8b, 8c, 8d and 8e show a series of screens making it possible to program a dialogue with a robot humanoid with binary choice and option of changing the interaction language in one embodiment of the invention;

 FIGS. 9a, 9b, 9c, 9d and 9e show a series of screens making it possible to program a dialogue with a humanoid robot with choice choices in a list and option of changing the language of interaction in one embodiment of the invention. 'invention;

FIGS. 10a, 10b, 10c and 10d show a series of screens making it possible to perform a comparative speech recognition test between several options of a list of choices in one embodiment of the invention;

 FIGS. 11a and 11b show a series of screens making it possible to replace or supplement options of a list of choices and to perform a new comparative speech recognition test between several options in one embodiment of the invention. 'invention;

 FIGS. 12a, 12b, 12c and 12d show a series of screens making it possible to perform a comparative voice recognition test between several options of a list of choices in a language different from that of the question in one embodiment of the invention. the invention;

 FIGS. 13a, 13b, 13c and 13d show a series of screens making it possible to check / modify the thresholds of the comparative speech recognition tests between several options of a list of choices in one embodiment of the invention.

Figure 1 illustrates the physical architecture of a humanoid robot in one embodiment of the invention. Such a robot has been disclosed in particular in the patent application WO2009 / 124951 published on 15/10/2009. This platform served as a basis for the improvements that led to the present invention. In the remainder of the description, this humanoid robot can be indifferently referred to under this generic name or under its trademark NAO ™, without the generality of the reference being modified. This robot comprises about two dozen electronic cards type 1 10 control sensors and actuators that control the joints. The card 1 10 shown in the figure is the one that controls the left foot. A The virtues of architecture are that the cards controlling the joints are for the most part interchangeable. A joint normally has at least two degrees of freedom and therefore two motors. Each motor is driven at an angle. The joint also includes several position sensors, including MRE (Magnetic Rotary Encoder). The electronic control card includes a commercial microcontroller. It can be for example a DSPIC ™ of the company Microchip. It is a 16-bit MCU coupled to a DSP. This MCU has a servo loop cycle of one ms. The robot can also include other types of actuators, including LEDs (electroluminescent diodes) whose color and intensity can reflect the emotions of the robot. It may also include other types of position sensors, including an inertial unit, FSR (ground pressure sensors), etc ....

The head 160 includes the intelligence of the robot, including the card 130 which performs the high-level functions that allow the robot to perform the tasks assigned to it, including, in the context of the present invention, participation in games. The card 130 could however be located elsewhere in the robot, for example in the trunk. However, we will see that this location, when the head is removable, can replace these high-level functions and thus in particular to completely change the intelligence of the robot and therefore its missions very quickly. Or conversely to change a body by another (for example a defective body by a non defective) keeping the same artificial intelligence. The head may also include specialized cards, especially in the speech or vision processing or also in the processing of service inputs / outputs, such as the encoding necessary to open a port to establish a communication remotely over Wide Area Network (WAN). The processor of the card 130 may be a commercial x86 processor. A low-power processor such as the Géode ™ from AMD (32-bit, 500 MHz) will be favorably selected. The card also includes a set of RAM and flash memories. This card also manages the communication of the robot with the outside (behavior server, other robots ...), normally on a WiFi transmission layer, WiMax, possibly on a public network of mobile data communications with standard protocols possibly encapsulated in a VPN. The processor is normally controlled by a standard OS which allows to use the usual high-level languages (C, C ++, Python, ...) or the specific languages of artificial intelligence like URBI (programming language specialized in robotics) for programming high-level functions.

A card 120 is housed in the trunk of the robot. This is where the computer that provides the transmission to cards 1 10 orders calculated by the card 130. This card could be housed elsewhere in the robot. But the location in the trunk is advantageous because it is located near the head and at the crossroads of the four members, which allows to minimize the connectivity connecting the card 130 to the card 120 and cards 1 10. The calculator of this card 120 is also a commercial processor. This may advantageously be a 32-bit processor of the ARM 9 ™ type clocked at 100 MHz. The type of processor, its central position, close to the on / off button, its connection to the control of the power supply make it a tool well adapted for the management of the power supply of the robot (standby mode, emergency stop,. ..). The card also includes a set of RAM and flash memories.

 This three-level architecture is particularly advantageous for the implementation of the present invention in which the robot must be able to execute coordinated movements and other actions such as sensor readings and simultaneously interpret words or signals emitted in its environment. and react or respond to them. Figures 2a and 2b respectively show a front view and a side view of the head of a humanoid robot having sensors useful for the implementation of the invention in several of its embodiments. The head 160 of Figure 1 is improved to a head 200a, 200b, so as to provide the robot with sensory capabilities and expressions that are useful in the practice of the present invention.

NAO has 4 omnidirectional microphones 21a, 212a, 213a, 214a, for example KEEG1540PBL-A provided by Kingstate Electronics Corp., 21a at the front, 214a at the back and 212a and 213a. on each side of the head (see also Figure 2b), of which only the access holes to the outside are visible in the figures because they are distributed to the inside of the head. From the sound captures made by the microphones, a voice recognition and analysis system, for example a BabEAR ™ system provided by the company Acapela ™, recognizes a corpus of predefined words that a user having the appropriate interfaces, presented more far in the description, can enrich with its own terms. These words trigger the behavior of his choice, including answers to questions interpreted by the robot. The software environment supports multiple languages, as indicated later in the description. NAO is also able to detect the origin of a sound, which allows it to remove ambiguities between several speakers.

NAO sees through two 640x480 CMOS cameras, 220a, capable of capturing 30 frames per second, for example of brand cameras Omnivision ™ reference 0V760 (CMOS sensor 1/6 ^th inch: 3.6 μιτι pixels). The first camera placed at the forehead, is pointed towards its horizon, while the second placed at the level of the mouth, scrutinizes its immediate environment. The software can retrieve photos of what NAO sees and the video stream. To perceive and interpret its environment, NAO embeds a set of face detection and recognition algorithms, shapes, which allow it to recognize its interlocutor, to locate a ball as well as more complex objects.

Placed at the top of its skull, NAO is equipped with a capacitive sensor, 230a, for example divided into three sections and developed specifically by the plaintiff for this application. More than three sections could be planned for particular applications. It is thus possible to give information to NAO by touch, for example by pressing a series of buttons allowing the triggering of actions defined by the application, which may be, in the context of the present invention, different responses associated with each button, a scroll in a list of choices, access to a help menu, etc. The system is accompanied by LEDs that indicate whether there is contact. NAO can express itself by reading aloud any text file residing locally in its storage space, for example programmed according to the modes explained later in the description or retrieved from a website or an RSS feed. With 2 loudspeakers, 210b, arranged on each side of the head, its voice synthesis system Acapela Acapela Acapela for example, is configurable, which allows changes in particular the speed and / or tone of the voice .

It is possible to send a music file to NAO and play it. NAO accepts, for example, the formats _.wav and _.mp3, which makes it possible, in the context of the present invention, to provide musical responses or personalized sounds for accompanying or replacing voice responses. Other music file formats may also be accepted. Figure 3 is a diagram of the architecture of high level software for controlling the functions of the robot in one embodiment of the invention.

 A software architecture of this type has been disclosed in particular in the patent application WO2009 / 124955 published on 15/10/2009. It comprises the basic functions of communication management between a robot and a PC or a remote site and exchange of software that provide the software infrastructure necessary for the implementation of the present invention. This architecture is described below generically, without specific mention of the software functions used in a specific application, it being understood that these functions are treated like any other behavior management software function of the robot of the present invention. FIG. 3 is very schematically represented a first humanoid robot RH1 communicating with a first remote terminal TD1, for example by wireless link for reasons of mobility. Remote terminal means a remote terminal of the server platform PFS, providing, via a communication network, access to a web service SW, dedicated to this type of humanoid robot RH1.

Of course, the communication links between elements of the system may be wired, and the mobile terminals may be, alternatively, mobile phones or laptops. A second humanoid robot RH2 communicates with a second remote terminal TD2, for example also by wireless link so as not to hinder the mobility of the humanoid robot RH2.

The TD1 and TD2 remote terminals and the PFS server platform are networked via the RC communication network. For the web service of the PFS server platform as well as for the TD1 and TD2 remote terminals, and for the humanoid robots RH1 and RH2, only one respective connection module B5, B2, B4, B1 and B3 dedicated to at least a module comprising at least one series of instructions implementing a software function by execution by a processor. The respective modules M51, M52, M21, M22, M41, M42, M1 1, M12, M31, M32 of the linking modules B5, B2, B4, B1 and B3 are in this example represented in number of two per module. linking, but this number may be different and any for each linking module.

 We will now illustrate a non-limiting example of operation of the system devised by a user of the first remote terminal TD1 having the first humanoid robot RH1. It may, for example, have his robot perform a certain number of functions by means of a software application embedded on the first remote terminal TD1, or accessible on the server platform PFS from the first remote terminal TD1.

 For example, he simply realizes, by means of graphic tools of the software application, an application for his robot, in which the robot will walk for 10 seconds then say "Hello everyone". This application is for example downloaded into the first humanoid robot RH1 in the form of a module, for example the module M1 1, then triggered by the user via the first remote terminal TD1.

The first humanoid robot RH1 triggers the module M1 1 which must first use a function "On". The module M1 1 then uses a connection interface module and function call or proxy P1 which makes a request to the connection module B1 to which the module M1 1 is linked. The linking module B1 makes requests to its own modules and modules for connecting the network to which it is directly connected (child contact modules) which repeat this operation iteratively until a network matching module responds to the request with the location of the called function it has in a module. The response to the request is also transmitted iteratively by the parent linking modules (in the opposite direction) to the connection module B1 directly linked to the proxy P1 needing to connect and call this function. For example, the function requested for the step is located in the module M41 of the second remote terminal TD2. In return, the connection module B4 returned the call parameters of the "on" function, which, for example, contain an integer duration parameter in seconds representing the duration during which the robot is going to walk, and a parameter Exclusive, of Boolean type, representing the exclusive or not running of the robot, ie if the robot is allowed to do another action or not while walking. In this example, we call the walk function with the parameter Duration equal to 10 and the Exclusive parameter equal to 1, because we want it to speak after having walked for 10 seconds in this example.

The connection and call interface module P1 can thus make the connection and the call of the "on" function with the desired parameters, remotely, as if it were located locally. The connection interface and function call modules use intercom software capable of calling a function of a module located on a different terminal or server, the function being able to be written by a series of instructions in a computer language different from that of the calling module. Proxies use, for example, the SOAP intercommunication software. We therefore have an inter-platform and inter-language communication architecture. Once this function delocalized "on" carried out, the module M1 1 must call a function "speaks". Another connection interface and function call or P2 proxy module makes a request to the connection module B1 to which the module M1 1 is linked. The connection module B1 makes a request to its own modules M1 1 and M12 in a first step, through a function performed in the form of a sequence of stored instructions, which goes, by example, return the presence of this function "speaks" in the module M12. The connection module B1 informs the connection interface module and function call P2 which can then call directly, by a call-type call local the "speak" function of the module M12, with as parameter, for example, the text to say "hello", this parameter having been transmitted to the P2 proxy by the linking module B1.

 In addition, the system comprises an STM storage and management module (short for "Short Term Memory" in English) of parameters representative of the state of the mobile terminal, in this case the humanoid robot RH1, adapted to set day the values of said parameters on receipt of an external event, and to inform a module, upon prior request, of an update of one of said stored parameter. Also the module prevented will be able to initiate an action according to the modifications of parameters of which it was informed.

 In connection with the previously described example, for example, the STM storage and management module can memorize the state of a parameter representative of the appearance of someone detected by a motion detector of the robot RH1. When this parameter passes from a representative state of person in the immediate environment of the robot to a representative state of someone present in the immediate environment of the robot, on request previously carried out by the module M1 1, the memory module and STM prevents, by an event or signal, this change in value. The module M1 1 can then, for example, automatically trigger the successive triggering described above (the functions "on" and "speaks").

 In the example of FIG. 3, the storage and management module STM is part of the remote terminal TD1, but, as a variant, it can be part of the other remote terminal TD2, of the server platform PFS, or a humanoid robot RH1 or RH2.

 The STM storage and management module is also capable of storing in memory a temporal evolution of certain parameters over respective reference time intervals. Thus, a module of the system can, in addition, have access to the evolution of the values of these parameters for a certain duration, and take into account these changes in the actions to be carried out.

As a variant, the modules of the called functions can be located on the server platform PGS, on a humanoid robot RH1, RH2 or on a remote terminal TD1, TD2 of the communication network RC. Thus, the present invention makes it possible to have a program distributed over the network, and an identical operation of the mobile terminal, whether it makes a local or remote call to a function.

 In addition, the present architecture also makes it possible to have a set of stored parameters representative of the state of the mobile terminal, and to be able to take account of changes in this state to trigger certain actions automatically.

 In addition, the storage and management module can also record an evolution of parameter values during a predetermined time interval, which allows a module to have access to a history of the evolution of these parameters.

 These communication and storage functions, which constitute a system for operating and managing robot interfaces, called NAOQI, are particularly useful for the implementation of the present invention.

FIG. 4 is a diagram of the functional architecture for editing and programming the behaviors of a robot in one embodiment of the invention.

Such an architecture has been described by patent application PCT / EP2010 / 057111 filed on 25/05/2010. The software for editing and programming the behaviors of a humanoid robot for implementing said architecture is commercially known as Choregraph ™, and may be denoted by its generic name or by its commercial name, without altering the generality of the references.

 The robot controlled by this architecture may be a humanoid robot having a head, a trunk and four members, each of the parts being articulated, each articulation being controlled by one or more motors. This architecture allows a user of the system to control such a robot by creating simulated behaviors on a virtual robot and executed on the real robot connected to the system by a wired or wireless link.

It involves visualizing, simulating and executing behaviors (such as walking - straight, right or left of n not, a hello - movements of one of the arms above the head speech, etc.) and movements (of the head, part of a member, a given angle) on the screen of a computer programmed to do this.

 Figure 4 is a process flow diagram that illustrates the articulation of the commands triggered by events with their temporal dimension. Commands triggered by events are represented in the semantics of the invention by Boxes or "Boxes" or "Control Boxes" 410. A Box is a tree-based programming structure that may include one or more of the following elements that are defined next:

 - A "timeline" or time axis of 420 frames;

 - A "Diagram" or Flow Diagram 470

 - A Script 490.

 Control boxes are normally interconnected by connections that most often transmit event information from one Box to another, as detailed later in the description. Any Box is connected directly or indirectly to a "Root Box" or Root that initializes the behavior / motion scenario of the robot.

A time axis of Frames 420 represents the temporal constraint to which the behaviors and movements of the robot defined in the box in which the said time axis of frames is inserted. In the rest of the description and the claims, we will use the Anglo-Saxon name of Timeline, commonly accepted with the same meaning in the world of programming. The Timeline thus synchronizes the behaviors and movements of the Box. It is divided into frames which are associated with a run rate defined in number of frames per second or Frames Per Second (FPS). The FPS of each Timeline is customizable by the user. By default, the FPS can be set to a given value, for example 15 FPS. A Timeline can include:

One or more Behavior Layers or "Behavior Layers" 430, each comprising one or more Behavior Key Frames or "Behavior Principal Frames" 450, which may themselves include one or more Diagrams or "flow diagrams" 470, which are actually sets of boxes that can also be directly attached to a higher level mailbox, without going through a Behavior Layer or a Timeline;

 One or more Motion Layers or "Motion Layers" 440, each comprising one or more Motion Key Frames or "Main Motion Frames" 460 which may include one or more Motion Screens or "Motion Screens" 480.

 A behavior layer defines a set of behaviors of the robot or main behavior patterns. Several behavior layers can be defined within the same box. They will then be programmed to run synchronously by the Timeline of the Box.

 A behavior layer may include one or more main patterns of behavior. A main behavior matrix defines a behavior of the robot, such as walking ("Walk"), speech ("Say"), the music game ("Music") ... A certain number of behaviors are pre-programmed in the system of the invention to be directly inserted by the user in a simple "drag and drop" from a library as detailed later in the description. Each Primary Behavior Frame is defined by a trigger event that is the start of the frame to which it is inserted into the Timeline. The end of the Main Behavior Frame is defined only to the extent that another Main Behavior Frame is inserted after it, or if an end event is defined.

A Movement Layer defines a set of robot motions that are programmed by one or more successive main Motion Frames that group movements of the robot's joint motors. These movements to be executed are defined by the angular positions of arrival of said engines that can be programmed by action on motion screens, said actions being detailed further in the description. All the main Motion Frames of the same Box are synchronized by the Timeline of the Box. A Main Motion Frame is defined by an Arrival Frame. The starting frame is the ending frame of the previous main movement frame or the start event of the box. The Main Behavior Frames and the Main Motion Frames are commonly referred to as Main Action Frame.

 It is possible to run in parallel several main action frames (behavior or movement), provided that they are attached to the same Timeline.

 A flow diagram is a set of connected boxes, as detailed below. Each of the Boxes may in turn include other timelines to which new patterns of behavior or movement are attached.

 A script is a program directly executable by the robot. In the context of the present invention, the scripts are privilegedly written in C ++ language. A Box that includes a script does not include any other element.

The software can be installed on a PC or other personal computer platform using a Windows ™, Mac ™ or Linux ™ operating system.

 The humanoid robot of the present invention will generally be programmed to interact with a human being using the Choregraph ™ software. The combination of temporal and behavioral logics made possible by this development architecture is particularly advantageous for the implementation of the present invention. A number of tools, discussed later in the following description, have been particularly developed for the implementation of a humanoid robot with a natural dialogue interface in the context of the present invention.

FIG. 5 is a functional flowchart of the treatments generally applied to improve the interpretation given by a humanoid robot of the response / stimuli it receives in several embodiments of the invention.

Over time, humans have developed a wide variety of ways to interact with machines. These means follow the evolution of technologies, so they are more and more efficient. In any case, for to be effective, the interaction whatever it is, must be adapted to the platform and the needs of the user.

 The graphical interfaces and windowed environments thus make available to a user a certain number of interface elements, also called GUI components (in English: GUI Elements or Graphical User Interface Elements), for example: text box (Text Box in English), OK / Cancel buttons, checkboxes, radio buttons, or Combo Boxes. These elements, adapted to a graphical interface, can not be used as such on a humanoid robot that does not provide in principle visual feedback of traditional screen type. But the exchanges with the robot should be at least as rich as those with the graphical interface of a computer. We then want to be able to choose an option, spell a word, launch or quit an application in the same way that we tick a box, we enter a text on the keyboard, we double-click on an icon or we would click on the cross in the application window. We do not want to simply copy these existing elements just because we want a humanized interface and natural for the user. It is therefore necessary to find user interface elements that are adapted to an autonomous humanoid robot.

 These elements must also be easily customizable for creators of humanoid robot behaviors and allow easy adaptation to the user's language. The existing autonomous robots can set up simple human-robot interfaces, such as voice recognition, but in the prior art, no multimodal, regionalized (allowing multilingualism) and fail-managing user interface elements provided to users and developers.

Indeed, today, the type of voice recognition that can be implemented on a humanoid robot of reasonable size and price, with multi-sensor acquisition and processing capabilities, locomotion capabilities and 'a large number of degrees of freedom of its four members, is necessarily limited by the computing resources and electrical energy that it is possible to embark on the robot. These resources are in fact necessarily assigned priority treatment to ensure the safety and reliability of catches of signals and commands necessary for the execution of movements. It is therefore necessary to provide human-robot interface elements making it possible to better correct the inevitable imperfections, in this context, of voice recognition and to offer the user a successful interaction thanks in particular to mechanisms for doubt about the robot's interpretation of the messages it receives from the user and questions returned by the robot that fall within the context of a converging dialogue sequence.

 It should also be noted that the human does not speak naturally to a robot because he does not find his human references, that is to say, the gestures and the behaviors that a human would have in the same situation. The interaction will not be particularly natural if the robot does not look in the direction of the human, usual interaction in the Man-Man interaction. Moreover, unlike human communication, the type of voice recognition compatible with the computer resources embedded on a multi-function humanoid robot does not effectively manage interactions with multiple users. In addition, most robots use little or no natural language, speech synthesis is usually programmed with pre-written sentences by humans, whether a story invented for the robot or an email written by a human and that the robot will read. There is therefore a lack of elements to bring the Man-robot interaction closer to a Man-Man interaction. The human-robot interfaces of the prior art do not have enough multi-modality or interaction codes to simulate a natural human-human interaction and contribute to the success of the interaction. In addition, if the interface uses knowledge already acquired by the user and even those he uses daily, the experience will be much easier and will require little learning from the user . Thus, sweeping a room in a virtual world will be all the more instinctively with a virtual reality headset by moving your head than by pressing the arrows on a computer keyboard.

The solution of the invention proposes user interface elements, combining software and hardware, adapted to an autonomous humanoid robot. By transposing the name GUI Elements used above to the behaviors of a robot, we then define BUI Elements (Behavior User Interface Elements), which we can call here more generally and simply UlElements. Such UlElements can for example be defined to simply code actions such as:

 leave an application at any time by simultaneously tapping the three touch sensors on the robot's head; challenge the robot using voice recognition; move to the next step of an application by tapping one of the robot's touch sensors.

 These simple elements are thus real interaction codes that can be implemented in generic libraries to be available in all the behaviors and applications of a robot or created as specific resources of a given project.

The UlElements of the invention are elements that can be used and parameterized easily by a behavior developer. These are mainly choreographic boxes that become GUIs Basic elements for programming behaviors. Notably, some of these boxes include Choreographer plugins, encoded in C ++ using a Widget library produced by the Qt ™ environment for developing GUI components.

There is shown in Figure 5 a simplified view of a functional architecture for the implementation of the invention.

Arranged within or in connection with the central unit 120 of Figure 1 an input / output control module 510 of the communication channels by which the robot will exchange his messages with his interlocutors. This module comprises, physically or logically, the transmission / reception preprocessing means of the specialized communication channels of which the robot is equipped.

 Without this being limiting, three types of message communication channels are shown in the figure, each type having a reception channel and a transmission channel.

A type 1 receiver channel 521 corresponds to human hearing and enables a robot to acquire sound signals, preferably messages voice with semantic content. To do this, the robot can be equipped with microphones 210a shown in Figure 2a. The outputs of this channel are normally preprocessed by a dedicated signal processing processor that executes speech recognition algorithms. These algorithms can be more or less complex and variable in effectiveness depending on the environment in which they are used (ambient noise, multi speakers ...) and the achievement of specific learning more or less complete. In all configurations, however, recognition errors are unavoidable.

A type 1 transmitter channel 531 corresponds to human speech and enables a robot to speak, that is to say to pronounce semantic content voice messages, for example via speakers 210b represented on the device. Figure 2b. The language, timbre, rhythm and tone of the voice can be varied depending on the context and to express a feeling. But these sounds can also be beeps, prerecorded music, it being understood that the beep, in Morse sequence for example, and the music, according to pre-established codes, can also have a semantic content.

 A type 2 receiver channel 522 corresponds to human vision and allows a robot to locate its environment and acquire images that it can then recognize if they are stored in a memory accessible to it. To do this, the robot can be equipped for example CMOS cameras 220a shown in Figure 2a. One of the cameras is preferably dedicated to distant vision, the other to near vision. Advantageously, the image recognition algorithms are adapted to allow detection or recognition of the faces of the interlocutors of the robot. Again, whatever the performance of recognition, uncertainties or errors are inevitable. Image recognition can also be applied to simple shapes such as figures presented to the robot on visuals or marks, the meaning of which can be defined by coding.

A transmitter channel 532 of type 2 is an artificial channel without direct human equivalent. This channel allows the emission of light signals produced by LEDs implanted on the body of the robot. Many LEDs can be provided, especially on the eyes, ears, torso, feet. They may have different colors and may have variable frequency flashing capability. This channel provides the robot with simple and powerful means of sending messages. In particular, a particular code can be defined and programmed by a user.

A 523 type 3 receiver channel is a channel equivalent to human touch. This channel is however limited in its tactile areas. These may for example be concentrated in a touch sensor such as the sensor 230a shown in Figure 2a. The interlocutor of the robot will activate the touch sensor to communicate a message to the robot, binary type (validation of an action) or more complex. The information received by this channel can indeed correspond to a code defined by the user, either unitary (tape, caress respectively having a meaning of punishment and reward), or sequential Morse type. A specific touch sensor is not necessarily necessary to define a communication channel of this type. A channel of the same type, to the extent that it receives a contact action from a speaker, can be defined in which the message sensor is a continuous analog sensor represented by the positions of the arms and / or forearms of the robot, said positions being representative of digital values communicated by the interlocutor to the robot, as will be explained later in the following description. Indeed, the robot knows at any moment the angular positions of its joints and therefore knows how to interpret as a message variations thereof caused by a displacement under the action of the interlocutor, if the meaning of said displacement has been defined to advance. A simple touch of a limb (the forearm for example) can also be detected by the angular position sensors of the joints of the robot. Sudden movements, such as jolts or uplift, can be detected by the robot's inertial unit and its foot-sole sensors (FSR), respectively.

A type 533 transmitter channel of type 3 is equivalent to the human gesture. The head can be endowed with two degrees of freedom: displacement in azimuth, measured by a yaw angle (or yaw in English) and displacement in elevation, measured by a pitch angle (or pitch in English). These two movements traditionally define approval (pitch) or denial (yaw) messages. They also allow the robot to lead his gaze towards the interlocutor with whom he is in conversation. The shoulders, elbows, wrists can be respectively given the following degrees of freedom: pitch and roll (roll or twist right / left); yaw; yaw. The hand can have opening and closing capabilities. Combinations of the movements of these joints make it possible to define the content of messages to be communicated to the interlocutors of the robot by this channel.

 Other message communication channels, not shown in the figure, exist or can also be defined. In particular, the robot can receive and transmit signals via infrared, Bluetooth or Wifi connection. It is therefore possible for an interlocutor to transmit messages to the robot via this channel, in particular by using a remote control programmed for this purpose, for example an Apple ™ iPhone ™ or another phone with motion capture and / or positioning.

Similarly a robot can send messages to another robot via these communication ports.

 According to the invention, a message communication channel can be defined by merging different type channels into a hybrid type channel. Thus, the outputs of a sound channel with speech recognition and a visual channel with image recognition can be combined to create a new channel whose outputs will be enhanced by a data fusion process. , the output output of this channel is a priori a higher level of confidence than those of the two outputs taken separately.

Also shown in FIG. 5 are two interlocutors 541 and 542 of the robot. Naturally, only one or more interlocutors are possible in the implementation scenarios of the invention. In addition the interlocutors can be located at a distance from the robot, provided they are connected to the room where it is located by the data links for transmitting the audio and / or visual signals necessary for the exchange of messages. . Naturally, in this case, the use of type 3 communication channels that require physical contact will not be possible.

The relative position of the robot with respect to its interlocutors and with respect to its environment can also be measured by particular sensors (speech recognition associated with a location of the speaker, image recognition, ultrasonic sensor, etc.) and be interpreted, for example, crossed with an analysis of volume, tone or expression to characterize the nature of the human dialogue / robot and possibly modify its progress. Thus, an interlocutor who approaches and speaks loudly can be seen by the robot as a threat and trigger different protective behaviors, with associated gestures, or even a modification or interruption of interactions.

The logic control of the inputs / outputs of these different communication channels is performed by module 510.

 This allows both, as explained later in the description, to raise doubts on the inputs of a receiver channel of a first type (for example sound), by messages transmitted on an emitter channel of the same first type, said actions to remove doubt that can be performed in response by the interlocutor on a channel of the same first type or on a receiver channel of a second type (for example tactile). The request messages to remove doubt about a message received on a channel of a first type (for example sound) can also be transmitted on a channel of a second type (for example visual, by emission of LED), the action to remove doubt of the interlocutor to be performed on a receiver channel of a third type (eg touch). These combinations are given for purely illustrative and non-limiting purposes, a wide variety of combinations being possible.

 The input / output control module of the communication channels 510 can also be used more simply to combine message entries, this combination to virtually eliminate any possibility of doubt in the "mind" of the robot.

 The programming of the combination function of the inputs received by a receiver channel and the outputs transmitted by a receiver channel can be achieved in a simple way using BUIEIements.

We will describe later a type of BUIEIements constituted by a command box of type Choice or Box Choice. This represents a way of making a choice in a closed list. It is especially adapted to the recognition of a limited number of words and sentences, within the framework a dialogue, the robot can ask a question before listening to the choice of the user.

 We describe below a BUIlement type distinct from a different type of a Choice Box.

We illustrate this modality by the example of the choice of an integer. For this element, the robot, for example, states on its type 1 transmitter channel 531, the minimum number and the maximum number available to the user, and tends to its interlocutor one of his arms, the latter being in weak servo. This arm will constitute the receiver channel 523 of type 3 of Figure 5. The low position of the arm is associated with the minimum figure, the high position to the maximum figure. The user thus uses the robot arm as a cursor to choose its number. The robot knows the position of his arm thanks to the sensors available on the ShoulderPitch. To enhance this interaction, the robot looks at his hand while the user moves his arm. At each change of position, the robot can state the number chosen. The user can validate his choice by touching the middle touch sensor on the head of the robot, using another type 523 receiver channel 3. It is also possible, especially in case of too many numbers in relation to the accuracy of the sensors, one arm allows to make a rough adjustment, and the second to choose more precisely. Lists of ordered expressions can be represented by numbers. The procedure above then becomes a modality of choice in a drop-down menu announced by the robot.

An alternative for selecting a digit is to use only the touch sensor. For example :

 Typing on the front sensor will move down one notch in the list of digits;

 Typing on the back one makes it possible to advance in the list of digits;

 - Leave the front or back sensor pressed to speed up scrolling in the list of numbers;

 The choice would be by touching the middle sensor.

We see that it is possible to vary significantly the possible combinations according to the use scenarios of the invention. FIG. 6 is a logic diagram for programming the behaviors / interactions of a robot in several embodiments of the invention.

 The example illustrated by the figure is a scenario where a robot dialogues with an interlocutor who offers him a choice in a list of words, for example in the case of a guessing game. In this scenario, a type 1 receive channel, a type 3 receive channel, and a type 1 transmit channel are used.

 The actions represented by the code 610 in the figure are actions of a robot interlocutor: a choice made by the user on a list, for example, previously stated by the robot; timeout (or lack of choice); answer "yes / no" to a request for confirmation of understanding of one or more words on this list.

 The actions represented by the code 620 in the figure are actions of the robot that will be activated according to the state of the internal variables represented by the code 630. The significance of these internal variables is as follows:

 r: probability rate of recognition by the robot of the word spoken by the user among those of the list of choices; - f: cumulative number of recognition failures;

 t: number of timeouts (or no choice by the interlocutor after a predefined time);

 51: threshold 1 of probability of recognition rate;

52: threshold 2 of probability of recognition rate; - tmax: maximum number of possible timeouts;

 fmax: maximum number of possible failures.

The general way in which timeout is treated corresponds to the application to the problem posed of a simple principle of everyday human life: "Who does not say a word consents ..."

The general logic of the treatments shown in this figure is described below.

NAO listens to the user / interlocutor and the variables f and t are initialized to zero. If the interlocutor passes the predetermined timeout time, the timeout counter is incremented and if the maximum number of timeouts is reached, the interaction loop is interrupted. This application can be initialized either in a behavior in a deterministic context where a specific action made by the user will trigger it such as an interpellation of the robot, in a game to know the number of players when it is started or by the support on one of the tactile sensors of the head, either in the context of an artificial intelligence which will trigger it according to parameters such as the detected presence of a human being, the time of day or more generally, the history of events of the day stored by the robot. For example, if it detects that the user is calling it, it triggers an application to know what the user wants from him and why he called him. In another context, it can trigger itself an application to propose a game if it detects the presence of a human, he has a strong desire to play and it's been a long time since he played . If the interlocutor states a choice before the expiry of the timeout, the probability rate of measured recognition r is compared with thresholds S1 and S2 (S1 <S2), expected recognition probability rates, which will be described later. of which they are determined.

 If r <S1, this recognition of the word is considered a failure. The chess counter is incremented. If fmax is reached, the word is declared permanently unrecognized and the interaction is interrupted. If fmax is not reached, we can predict, as illustrated in the figure, three cases:

 at the first failure (f = 1), the robot indicates to its interlocutor "I did not understand" and activates the function "activateHelpWhenFailure" consisting of repeating the list of choices;

at the second failure, (f = 2), the robot also indicates "I did not understand" and activates another "activateHelpWhenFailure" function consisting in providing the listener with the list of choices and asking the other person to use its tactile sensor, telling him how to use it; beyond (3 <f <fmax), the robot can pronounce sentences telling the other person that the conditions for an efficient conversation are not fulfilled, such as "there is too much "noise", which will normally prompt the caller to stop the conversation.

If S1 <r <S2, the robot has a doubt about what he actually heard; according to the procedure shown in the figure, he can then proceed to an action of raising doubt, by pronouncing the word or expression that he thinks he has recognized and asking his interlocutor "Is this correct? " if the person answers "yes" or does not answer after the timeout, the robot considers that the answer is correct. If the interlocutor answers "no", the failure counter is incremented; if fmax is reached, the robot definitively indicates that it has not understood and the interaction stops; if fmax is not reached:

 at the first failure (f = 1), the robot can activate that of the functions "activateHelpWhenFailure" consisting of repeating the list of choices;

at the second failure (f = 2), activates another "activateHelpWhenFailure" function consisting in providing the listener with the listener and asking the other party to use his tactile sensor, indicating how to use it; - from the ^3rd and failure to f max, the caller has to repeat the selection until the probability of recognition rate improves.

In this way, it is thus possible to greatly overcome the imperfections of voice recognition and to create an improved fluidity in the conversation between the robot and its interlocutor.

FIGS. 7a, 7b and 7c represent timing diagrams illustrating the logical and temporal combination of the interactions of a multimodal interface in several embodiments of the invention.

These figures are views of the Choice Boxes making it possible to program the interactions of the type shown in the diagram of FIG. 6. The Choice Boxes are Boxes such as those illustrated under item 410 in FIG. 4, but they are a particular type allowing the particularly effective programming of specialized behaviors for a natural dialogue.

 The meanings of the symbols in these figures are as follows:

 in Figure 7a,

 - 710a denotes the actions / words of the robot or its interlocutor;

 720a denotes the touch sensor;

 740a denotes a recognition beep;

 750a designates the LEDs of the face of the robot in a rotating animated position;

 751 a designates the LEDs of the face of the robot in the fixed position;

 760a designates the LED flash of the robot's face (which may be of different colors depending on the robot's understanding of the message received);

 770a designates the timeout function;

 780a denotes the output of the Choice Box;

 790a designates the function "Go to the touch sensor menu" (Figure 7b);

 7A0 denotes the function "Go to sorting choices" (FIG. 7c);

 - 7B0 designates the function "Go to the voice recognition menu";

 R1, R2 and R3 respectively denote a case where the robot unambiguously understands, a case where the robot understands but doubt and a case where the robot does not understand at all; - In Figure 7c, 710c designates the function "Return to the previous menu".

The general logic of the treatments programmed in the Choice Box is identical to that already described. The additional elements described here are:

 - The use of LEDs 750a of the face of the robot, possibly the LED flash to punctuate the exchange of questions and answers: the LEDs are in fixed position 751 a to indicate that the robot detects speech and analysis;

The use of an acoustic "beep" emitted by the robot to indicate when it is ready to recognize; because of the limitations of processing capacity and power supply, and also to avoid recognition noise, it is not active at the same time as speech synthesis; it is therefore not necessary for the interlocutor to answer too early the questions posed to him by the robot; the "beep" gives the top to start responding;

 The ability to use several levels of help that depend on the history of the robot and its experience this user during this exchange and previous exchanges;

 - The ability to navigate between several menus to facilitate programming.

The figures which are now described are screenshots on which a Chorégraphe software's Choice Box component described in commentary in FIG. 4 above is used to program simple or complex interactions between an NAO robot and an interlocutor by using the illustrated examples of the reception and transmission channels of type 1 (voice exchanges).

 FIGS. 8a, 8b, 8c, 8d and 8e show a series of screens making it possible to program a dialogue with a humanoid robot with a binary choice and an option to change the language of interaction in one embodiment of the invention;

 FIGS. 9a, 9b, 9c, 9d and 9e show a series of screens making it possible to program a dialogue with a humanoid robot with choice choices in a list and option of changing the interaction language in one embodiment of the invention. invention;

 FIGS. 10a, 10b, 10c and 10d show a series of screens making it possible to perform a comparative voice recognition test between several options of a list of choices in one embodiment of the invention;

FIGS. 11a and 11b show a series of screens making it possible to replace or supplement options of a list of choices and to perform a new comparative speech recognition test between several options in one embodiment of the invention. invention; Figures 12a, 12b, 12c and 12d show a sequence of screens for performing a comparative speech recognition test between several options of a choice list in a language different from that of the question in an embodiment of the invention. 'invention;

FIGS. 13a, 13b, 13c and 13d show a series of screens making it possible to check / modify the thresholds of the comparative speech recognition tests between several options of a list of choices in one embodiment of the invention. In general, a Choice Box allows a user to choose a response from a predefined set of choices. It uses an array-like component that allows a developer to write an intuitive and readable set of possible choices. The list of choices can also be put in the box, if the developer does not know it in advance. Thus, for example, in the case of an application handling the email of the user, the robot can make him choose a contact in his address book stored in a separate file. These Ul Elements are very configurable tools. UlElements using recognition and / or speech synthesis are regionalized. For example, the Choice Box is editable in French and English. At the GUI level for programming, the Widget Qt ™ used to change the edit language of the box can be a ComboBox.

 The inputs (and outputs) of the choreographer boxes can be of several types:

 1. "bang": a signal is sent

 2. number: the entry retrieves a number, integer or floating

 3. string: the input retrieves a string

 4. dynamic.

 An input (respectively output) of dynamic type retrieves (respectively sort) an ALValue.

The ALValue are a union of common types, described in an NAOQI library, including: integers, floats, array, boolean, string, but also "bang", which is an uninitialized ALValue. Dynamic type entries allow you to manage the changes of an application in a very flexible way. In particular, the choice of inter-modal and / or intra- modalities, the presentation of aids are provided to the interlocutors of the robot to activate them may depend on the number of possible choices.

Thus, we can send a python array (array type) to the input of a choreographer box provided that this entry is of type dynamic.

Choregraphic software used to implement the invention includes box parameters of Boolean type (Check Box), string of characters (Text Box), multiple choice of strings (Combo Box) editable or not by the end user , integer or Floating floating (Slider), or other. For example, the programmer who uses the Choice Box in his behavior or application has the option to check or uncheck the boolean "Repeat validated choice" (in French, "Repeat the validated choice"). This will affect the behavior of NAO during the interaction as it defines whether NAO always repeats the user-validated choice or not.

To overcome the deficiency of speech recognition, a diagnostic tool can maximize the success of voice interaction. Thus, in the Choice Box, when the developer has finished writing his list of words in the table, he can launch this tool which will indicate a percentage of recognition of these words, 100% corresponding to a word that will certainly be recognized by the robot, 0% to a word that the robot will not recognize. This diagnosis is made by comparing the word said speech synthesis (which is assumed to be close to what the user will say) and the expected word by voice recognition. Moreover, to maximize the chances and the naturalness of the interaction, for each choice, we can define several expressions. Thus, to ask the robot to send an email, the developer can make available to the user several phrases such as "send an email", "send a message" or "send an email". The user will then have the choice between these different expressions to finally say the same thing. The solution of the invention also solves the problem of voice recognition that does not handle the presence of multiple users. Humans realize that when talking to others, communication is difficult, so they adapt by talking one by one. This situation is facilitated by the existence of clearly single-user interaction codes, such as the use of the tutelage by the robot. A deficient voice recognition requires that the Man-robot interface manages chess situations in the best possible way, to make the user talk at the right moment (it will go through interaction codes) and to make available alternative solutions to the dialogue. that are more effective. In the context of the present invention, an audio diagnostic function makes it possible to solve this type of problem. This function is executed by pronouncing the word to be tested by the speech-synthesis software, text-to-speech. This word is then analyzed by voice recognition. More precisely, the same word is pronounced, for example three times, each time by changing the speed of the voice and its pitch, so as to have a representative sample of the ways of pronouncing the word. The three recognition rates returned by the speech recognition are then averaged, and it is this value which is the estimated percentage of recognition of the word. There are two possible audio diagnostic modes "Together" mode works as follows: all words in the choice box are listened to by speech recognition, and NAO then calculates the estimated recognition rate as described elsewhere.

The "One by One" mode works as follows: for a given line, the word to be analyzed is listened to by voice recognition, as well as the other possible choices on the other lines, but not its alternatives located on the same line as him. The advantage of this diagnosis is that if two "synonyms" are similar, for example "hello!" and "hello!", the estimated rate of recognition will not be as low as it would be in "Together" mode (the rates would be very bad because they would often be confused by voice recognition). is not serious that two synonyms are confused by the robot.

 Once the diagnosis is made on each line, the synonyms are ranked in descending order of the estimated rate of recognition, and the recognition rate of the best synonym is written at the end of the line.

Thus, the Choice Box is programmed to ask a user to confirm his answer when the robot is not sure of having correctly recognized or interpreted it. This mechanism is identical to that used by a human who has poor hearing or is immersed in an environment that makes understanding difficult. The robot will have different reactions depending on the level of understanding of the response of the user. Several thresholds (for example the thresholds S1 and S2 defined in comment in FIG. 5) are then fixed as a function of the recognition confidence calculated by the recognition software: for example, when the first recognition threshold S1 is not reached. , the robot asks the player to repeat his answer; when the first threshold S1 is reached but a second threshold S2 of higher recognition is not, the robot will ask a question whose answer will remove the doubt. The robot can also provide help for the user to respond correctly to the robot: he can give the list of possible choices, indicate the means of interaction with him, repeat the question asked if there was one. Interaction codes are also very useful to overcome the deficiencies of speech recognition. Indeed, the speech recognition does not speak to the robot while he speaks, and the time between the launch of speech recognition and the moment when it is really active is quite long. A tone code is thus played at the launch of voice recognition, indicating to the user that he can speak. Then, a rather intuitive visual code, the LEDs of the ears that turn, allows the user to know that the robot is listening. UlElements using voice recognition also offer an alternative way to this voice recognition, to allow the user to succeed in communication even in case of repeated problems of understanding (this may be due to an extremely noisy environment for example). These alternative means can be tactile, sound, visual, etc. For example, the Choice Box allows the user to choose an answer by using the touch sensor: pressing on the front sensor makes it possible to advance in the list of choices (the robot then states each choice), the back one makes it possible to back in this list, the middle one to validate his choice. One can also imagine that the robot states the various choices, and that the user says "OK" when he hears the choice he wants to validate. Or, for a confirmation, instead of saying "yes" or "no" the user can press one of the arms of the robot. The input / output control module of the communication channels of the various types 1, 2, 3 defined in comment in FIG. 5 makes it possible to generate, in a simple and user-friendly manner, the management functions of these combinations by links between the different inputs / Outputs of Choice Boxes. In general, the solution of the invention proposes a humanization of the interface, a simulation of the Man-Man interface. We know that three main factors come into play when there is a direct communication between two humans: of course the word, that is to say the words, but also the tone of the voice and the visual elements. As proof, by observing throughout their evolution the means of indirect communication, such as writing or instant messages, we can see very clearly how the lack of information of the dialogue can in general be mitigated by the adding substitutes for direct communication, substitutes such as punctuation or more recently smileys. In any case, despite the great technological advances of today, these fundamental elements are still difficult to transpose in their entirety for human-robot communication. However, it is possible to find artificial substitutes that improve the rendering of the dialogue. The vocal synthesis and recognition of the robot allow an equivalence to speech. They are thus the pillars of his communication with a human. A humanoid robot has the advantage of being able to make a large part of the visual elements of the dialog that are gestures and facial expressions. Indeed, although with his anthropomorphic body, his movements are not as easy as a robot on wheels, his gestures can be more easily based on human behavior and thus easily decrypted as human movements. Communication is then more natural.

 The tone of the voice and the facial expressions are nevertheless missing on a robot with frozen face and tone. However, these two elements are offset by other functions, codes that translate these elements. They require a more or less long learning of the user. The goal is to make this learning as short as possible and therefore the codes are the most consistent and as close as possible to what the user already knows.

By adapting Ben Shneiderman's basic ergonomic laws set out in his book Designing the User Interface: Strategies for Effective Human-Computer Interaction (published in 1997: http: // www. Es, edu u / heil / pubs / books / dtui.shtml) and applied normally to graphic interfaces, we arrive at coherent codes, simple and therefore to a natural and fluid interaction. These laws set out the following principles: the consistency of codes and interface elements, the presence of shortcuts for advanced users, the presence of immediate feedback on the actions performed, the explicit end of dialogues, simple error handling, possibility of backtracking, the user must feel master during the interaction and finally, less stimulation of the short-term memory of the user.

 Recognition and speech synthesis are limiting, in particular by the absence of natural language and a recognition that is uniquely user-friendly and that allows only a limited number of words to be recognized. The solution of the invention solves the problem of the non-use of natural language by robots in order to propose a sufficiently natural human-robot interaction. Already, the voice synthesis of the robot is used at best. In particular, most of the UlElements of the robot using synthesis and / or voice recognition are regionalised. A French-speaking user (respectively English-speaking) will be able to converse with his robot in French (respectively in English), thus maximizing the success of the interaction. Then, timings and interaction codes are best used to improve the responsiveness of the robot and facilitate the success of human-robot communication. Thus, the Choice Box offers several parameters such as the waiting time for a user response. This ensures that the robot does not wait too long before considering that the user has not responded, but also that it waits long enough for the voice recognition can be activated at the right time. The interaction codes can be gestural, sound and / or visual. Thus a beep of end of voice recognition allows the user to know that the robot does not listen anymore.

In addition, in the solution of the invention, the communication is made more natural by the use of several communication channels of different modalities, and particular behavior on the part of the robot. Thus, the use of sound localization and face detection (including its position) allows the robot to turn its head towards its human interlocutor, which seems a fact when it is addressed to another human. The robot can also implement a speaker identification (facial recognition, voice stamp, voice print ...) so to speak to a particular human by using his name, his own characteristics such as, for example, the history of conversations and behaviors played by the robot. The robot can also know what the user has thought of a behavior as he has touched his touch sensor (Man liked the behavior), and then offer to play it during an oral communication for example. The robot will try to act appropriately to the situation. Thus, he can play animations, use his LEDs and broadcast sound, which allows him to simulate the instinctive gestures that a human does when he speaks (talking with the hands, ...). The robot can also produce head nods (called head nods). Several studies, including that of Justine Cassell made in her article Social Dialogue With Embodied Conversational Agents (published in 2005:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10. 1. 1. 124.9853 & rep = rep 1 & tvpe = pdfh have proved that the man considers that a machine or an avatar seems more interested in the conversation when this machine or this avatar produces head nods, even when they are produced at hazard. All these gestural signals (such as acquiesce or deny with the head, arms or hands), sound, the chronology of the interaction, the location of the interlocutor, or the detection of the intentions of the user (is this whether it is moving forward or backward) make Man-robot interaction more natural and effective by making it closer to the usual human codes. They also solve some of the problems related to restrictive speech recognition. They are one of the advantages of the invention. The screen shots in Figures 8 to 13 describe how you can program multiple dialogs between an NAO robot and a caller.

To use the choice box in the behavior, you need drag-and-drop (drag-and-drop) from the default choreographer library in the diagram (Figure 8a). We add a LocalizedText box, which will allow to edit the question in French and in English. The question is written in English "What is your favorite animal?" in the text plugin of the LocalizedText Box (Figure 8b). We also want to edit the question in French. To do this, we use the Combo Box plugin box, and we choose French. (Figure 8c). We then write the text of the question in French in the text plugin which is empty when it is not edited: "What is your favorite animal?" (Figure 8d). The question must be in the box of choice, to be well managed by the robot. The output of the LocalizedText box is connected to the OnStart entry of the Choice Box (Figure 8e).

We will now edit the choices, in English, as indicated by the Combo Box of the Choice Box. Remove the default choices from the Box. On the first line of the table, we write the first choice "pangolin" (Figure 9a). On the second line, we propose another animal: "spider", but we add a synonym "tarantula", separated from spider by a slash '/'. This means that the robot considers spider and tarantula to be synonymous (Figure 9b). We finish editing the choices, adding for example "rabbit" and "pony". Note that the number of lines adapts automatically when you add choices (Figure 9c). The Combo Box is used to pass the language of edition of the Choice Box to French (figure 9d). As for English, we write the list of choices, so we get: "pangolin", "spider / tarantula", "rabbit" and "pony". (Figure 9d).

 But we do not know if the robot will recognize these choices or not. We want to start the audio diagnostic function. We click on the "plus" (figure 10a). Then click on the evaluation icon (Figure 10b). For each line, the words are evaluated (Figure 10c). In case of synonyms, the best is placed at the beginning, and the percentage indicated is then the result of the best synonym. The audio diagnosis ends, we see that "pony" 'may be very poorly recognized (Figure 10d).

 It is then decided to change the word and put "horse" instead (Figure 1 1 a). We restart the diagnosis. "Horse" gets an excellent score of 82%, it is preserved (Figure 1 1 b).

 We go back to English and we start the diagnosis on words in English (Figures 12a, 12b). Then we add to "pony" the synonym "horse", as a translation of "horse" (Figure 12c). We restart the diagnosis, and we note that "horse", having a better score than "pony", was placed in first position automatically (Figure 12d).

We will now edit the parameters that can be set. Click on the adjustable wrench at the bottom left of the Choice Box (Figure 13a). The parameter window opens (Figure 13b); check the Boolean parameter "activate arms" (Figure 13c). Thus, the robot will move his arms while he speaks. Click on OK to validate this new setting.

We connect the general input of the behavior to the input of the LocalizedText box, and the outputs of the Choice box to the general output of the behavior (Figure 13d).

 An example of operation of the programmed software is now described as in the example described above.

 The robot is enslaved by the icon Chorégraphe "enslave garlic motors on / off", then it is put upright thanks to the "init pose" position of the pose library. We put the language of the robot to French thanks to the parameter present on its web page. We start the behavior on the robot with the Choreographer Play icon.

 By moving the arms, the robot asks "What is your favorite animal?", And then starts a listening sound. While he is listening, his eyes turn blue, as well as his ears, and the touch sensors of his head blink blue.

 The user then answers "dolphin". NAO's eyes turn yellow as he analyzes what has just been said. He does not understand the answer: his eyes flash red twice, and his ears blue. He said, "I did not understand, you can answer: pangolin, spider, rabbit or horse.What is your favorite animal?" While moving his arms and he returns to the listening phase.

The user then responds "rabbit". The robot is not sure but believes to understand pangolin. His eyes flash once in green. He then said, while throwing an animation of the arms, "I understood pangolin, is it correct?". The user answers "no". The robot flashes once the eyes red and throws a helper while moving his arms: "pangolin, spider, rabbit, or horse? You can also choose an answer using my touch sensor.What is your favorite animal? " and he comes back in listening mode. The user then presses on the front touch sensor, the robot flashes his eyes once in blue and says "pangolin". Then the user presses again, the robot responds "spider" while flaming his eyes once in blue. The third time the robot says "rabbit" with a blue flash of eyes. The user then presses on the middle touch sensor to validate his choice. The robot flashes once his eyes green, then repeat "rabbit" and out of the box and behavior. Other interactions between communication channels of the robot are possible, such as those described below.

 The Choice Box makes special use of voice recognition in combination with the touch sensor to recognize the user's choice. Another possibility is to use the robot's vision, especially image recognition. It is an object recognition and not a concept: if you show him a can, he will recognize this same can and not another brand. One of the possibilities of the development software in its version allowing to implement the invetion is to have in this software the camera feedback of the robot. The user can show objects to the robot, see the image obtained in Choreographer, and identify by hand the interesting object in the image. The user names it. The robot then analyzes the object and stores it in its image database.

The user can then use these images as possible choices for a choice box.

 For example, if the user wants to fill a Choice Box with object names, such as "can", "cup", "magazine". He fills the Choice Box with these words, then takes a can, his favorite mug and the cover of a magazine and shows them to the robot for analysis as explained above. The Choice Box then searches the robot's image database: if an object marked "cup" is present, NAO then searches for it while listening to the user, and so on for the others. words. Thus, the user launches this Box on NAO, which listens to his choices. The user says "bobbin" but the robot does not understand. After two times, the robot explains that he can show him "can", "cup" and "magazine" because they are in his database. The user can while listening listen to the bobbin that was used for recording (or the same brand). The robot then acts as if he recognized the word "bobbin".

In the context of the present invention, it is also possible to program the robot to act as an agent for receiving / reading, writing / sending and administering an email account of a user of the robot. This application is described below.

With the Mail application, NAO can read emails, reply to an email or send emails to a contact, but also add the author of a mail received to contacts, delete a message, mark it as unread, re-read it, read the next or previous message.

 Three Choice Boxes are used in this application, making it an indispensable element. The words were chosen thanks to the audio diagnosis. When the application is launched, the robot starts by looking if the user has received new messages. If so, it reads the first new message then launches a Choice Box without question. If not, he launches this same Choice Box but with a question: "What do you want me to do?" Being able to launch a Choice Box with or without question is therefore used in the mail application. This Choice Box allows the user to choose from the possible actions of NAO. These actions are written in the table of the plugin of the box. The output of Choice Box "timeout" is useful, because in case of timeout, NAO reads the following message. A parameter "maximum number of repetition when no reply" is then set to 1: the robot leaves this box choice at the first timeout. In addition, the parameter "repeat validated choice" is disabled, because after a choice of the user the robot launches a specific animation or action that clearly shows what he understood. Thanks to the boolean parameters "activate head", "activate arms" and "activate legs", the robot will be animated with animations dedicated to the speech.

For example, the possible choices of this box, in French are:

 Record an answer / Reply to this email / Reply to the email / Reply;

 Read Again / Read Again / Reread Mail / Reread;

Next / Read the next / Read the following email;

 - Previous / Read the previous mail / Read the previous message;

 Mark as unread / Keep / Replay later;

Delete / Delete the mail / Delete the message;

Write an e-mail / Send an e-mail / Send;

 Add to Contacts;

 - Exit / Exit / Skip / Stop / Stop / Cancel / Shut up: "Exit" is one of the default choices of the box choice, which allows here to exit the mail application.

If the user chooses the option "Write a mail", he must first choose a contact in his address book. To realize this function of choice, a Box Choice with in entry the question "To whom do you want to write?" is used. The list choice is variable. As a result, the Choice Box table has not been filled in. The contact list is retrieved from the file that saves it and sent to the "choices" entry in the Choice box, of type dynamic. This time, the "repeat validated choice" parameter is set to tell the user that Nao understood who to send the message to. The parameter "maximum number of repetition when no reply" is for example 3, its default value for, in case of timeout, not to send an email to anyone, but to be able to cancel the sending of the mail and return to the main menu. Similarly, saying "Exit", the default choice of the application, allows you to return to the main menu. A help function is for the case where the user does not remember his contacts. In this case, with the touch sensor for example, NAO states the list of contacts.

Whether in this case sending a direct mail, or in the case of response to a message received, the robot will record the message of the user.

 Once the message is finished, the robot re-reads the recorded message and then launches a Choice Box which proposes for example the following different interactions:

 Replay it / Replay the message / Replay my message: NAO re-read the message.

 - Resave the message / Resave my message /

Resave it: the message can be re-registered, if the first one is not suitable;

 Do not send / Do not send / Do not send the message: NAO will not send the message, then return to the previous level of the application;

 Sends it / Sends the message / Sends my message: NAO will send the message;

 In case of timeout, the message is sent;

 In case of "other" output of the Box that is not a timeout, such as an exit request or repeated failures, the application returns to the previous level.

The settings are essentially the same as for the Main Menu Choice Box, with the "Maximum number of repeat when no reply" setting set to 1. The parameters "speech recognition timeout", which indicate after how much time without response the robot considers that there is timeout, and "speech recognition timeout when confirmation" can for example be set to 4 seconds instead of 6 by default, so that the user can easily say nothing and let the message be sent. The Choice Box can also be statically configured with constant parameters over the entire life of the Box. But in the context of using an automatic question generation system, the parameters can be set automatically. For example, in the context of using a conversational agent such as that developed by the company As An Angel, said agent can configure the Choice Box based on the questions and answers that he automatically generated.

Other improvements have been made to the choreographic behavior development software, in particular to facilitate the implementation of the present invention. A description is given below.

Chorégraphe boxes are implemented by means of a script in one of the supported programming languages. If this box has some parametrizable aspects, such as the number of repetitions, the language used by the robot, the text that the robot must pronounce, this information is integrated directly into the script of the box. When one wants to modify the parameters of the box, for example after having duplicated it to use it differently, it is necessary to modify the script of the box to change its behavior.

As it is a common operation, a user without a deep knowledge of the scripting language used might want to achieve, as well as to improve the productivity of Choreographer users, a special interface has been developed to be able to configure Box scripts. There are two aspects to this feature.

In the Choreographer interface, the user can create "box parameters" in the box attributes edit window, in the same way that he can create inputs and outputs for the box. . Each "box parameter" has a name, a description, a type (among boolean, integer, float and string), and depending on the type can have additional attributes, such as a default value. Finally a "box parameter" can be defined as inheriting from the parent box, this which will affect how the value will be determined. Once "box parameters" have been defined, the box is displayed in its diagram with an additional visual indicator in its lower left corner. When the user clicks on this icon, a dialog for editing "Box parameters" opens, and the user can define the value associated with each "Box parameter", within the framework of any constraints defined in the attributes of the "Box parameter".

 In the box script, the author of the Box can now access the "Box parameters" using several functions that take the name of the "Box parameter" as an argument. It can view the current value of a "Box parameter" and change it. It can also create dynamic "Box parameters", which will not appear in Choregraph, but which can be used as temporary storage in the Box's scripts. The current value of a parameter depends on whether it is marked as inheriting from the Parent Box or not. If it is not (the default case), the "Box parameter" is box specific, and when the box script looks at its current value, it is simply returned. If marked as inheriting, when reading the value, the Boards diagrams hierarchy will be rolled up to find a Parent Box containing a "Box parameter" of the same name. If none is found the current value for the Current Box is used.

The robot also has a software module allowing it to recognize objects that pass in the field of vision of its camera. However, the objects to be recognized must first be learned in a learning phase. This learning is done using a specific interface in Choreographer.

This interface displays in real time the video sent by the robot's camera. The image is only available when Choreographer is connected to a robot with a camera and a properly configured video capture module. When video display is enabled, the user can initiate a learning. A countdown then appears on the image, and the user then has for example 4 seconds to present an object in front of the camera. At the end of the countdown the images are captured and recorded. The user must then crop the object of interest in the image by drawing a polygon on the frozen image. Once the polygon is closed, a dialog opens asking the user to enter keywords defining the object.

Each learning generates an entry in a database that is saved by choreographer on the user's computer. Once the learning is finished, a button makes it possible to send a light version of the database on the robot. The object recognition module will then use this database, and when an object is recognized, an event containing the associated keywords will be triggered on the robot.

Choreographer is also a behavior editor for the robot. As previously described in commentary to FIG. 4, a behavior is an object similar to a computer program, which can be executed by the robot. In order to install and execute these behaviors on the robot, it has been developed a behavior management interface on the robot. When Choreographer is connected to a robot, an entry in the application's menus is used to display the behavior manager. It is a modal window displaying a list of behaviors installed on the robot, as well as a set of buttons to manipulate them.

 For each installed behavior is displayed its name, its state (running or not) and an attribute defining if the behavior must be executed at the start of the robot. To start or stop a behavior, simply click on the icon displaying its current state, which has the effect of toggling the state. Once the behavior is complete, the status automatically returns to "stopped". The attribute "start at startup" is a checkbox. It indicates the current value of the attribute, and the user can simply click on it to change that value.

The buttons displayed next to the behavior list allow you to add, remove, and transfer to the user's computer. The user can very easily manipulate the behaviors installed on the robot, as if it were files on his computer. In particular, a user can download a behavior, modify it, and reinstall it on the robot, without having to save it on his computer. The behaviors installed by the user can then run in parallel, under the constraints of temporal coherence and between behaviors defined by the different Behavior Boxes, Behavior Frames and Timeline.

The examples described above are given by way of illustration of embodiments of the invention. They in no way limit the scope of the invention which is defined by the following claims.

Claims

1. A humanoid robot comprising at least two natural communication channels (521, 522, 523, 531, 532, 533) of messages with at least one interlocutor (541, 542) in different ways, said at least two channels being each selected from the reception group, transmission, and a control module (510) of the inputs / outputs of said channels, said robot being characterized in that said control module is able to improve the understanding of the messages received by said robot by performing at least one selected function in the combination group of messages received / transmitted on a first channel and a second channel, sending a second message generated from a first message received on a channel.

2. Humanoid robot according to claim 1, characterized in that said communication channels are chosen from the group of communication channels transmitting and / or receiving sound, visual, tactile, gestural, positional or symbolic messages.

3. Humanoid robot according to claim 2, characterized in that a first communication channel is a sound transmission channel and a second communication channel is a reception channel of gestures and / or positions of at least a part of the robot by said at least one interlocutor, said gestures and / or positions being representative of inputs communicated by the interlocutor to the robot, the specifications of said entries being defined by the robot to the interlocutor by the message transmitted on the first channel.

4. humanoid robot according to claim 3, characterized in that it further comprises a third touch communication channel by which the interlocutor validates the entries made on the second channel.

5. Humanoid robot according to claim 2, characterized in that a first communication channel is a sound message receiving channel and a second communication channel is a sound message transmission channel and in that said control module is able to evaluate the level of confidence of said robot in understanding a first message received on said first channel and generating at least a second message on said second channel whose content depends on said confidence level.

6. Humanoid robot according to claim 5, characterized in that the first channel comprises a voice recognition filter messages received by a list of expressions each of which is associated with an expected recognition rate and that the content of said second message is chosen by a heuristic in the group comprising request for repetition of said first message on the first channel, confirmation request by a third message to be sent by the interlocutor on the first channel of a subset of the expressions of the filter, request for transmission by the interlocutor of at least one other message on at least one third channel.

7. humanoid robot according to claim 6, characterized in that it is able to transmit on the second channel a start of listening signal on the first channel to ensure the half-duplex mode sequencing messages on the first and the second channel.

8. humanoid robot according to claim 6, characterized in that said heuristic of choice is a function of the position of the actual recognition rates with respect to thresholds determined from the expected recognition rates.

9. Humanoid robot according to claim 6, characterized in that said third channel is a touch reception channel or gestures of a part of the robot.

10. humanoid robot according to one of claims 5 to 9, characterized in that it further comprises an interface module with an electronic mail, said interface module allowing an account holder on said e-mail to use said robot as an agent for receiving / reading electronic messages on the second channel, writing / dispatching on the first channel and administering said count by dialogue using said first and second channel.

1 1. A humanoid robot according to claim 6, characterized in that said third channel is a visual image object receiving channel corresponding to the list of filter expressions of the first channel, said images being compared to a database of images of said previously recorded objects with said expressions accessible by said input / output control module of said communication channels.

12. Humanoid robot according to claim 2, characterized in that a first communication channel is a visual message receiving channel and a second communication channel is a sound message transmission channel and in that said control module is able to evaluate the level of confidence of said robot's understanding of a first message received on said first channel and to generate at least a second message on said second channel whose content depends on said confidence level.

13. Humanoid robot according to claim 12, characterized in that the first channel comprises an image recognition filter messages received by a list of expressions each of which is associated with an expected recognition rate and that the content of said second message is chosen by a heuristic in the group comprising request for repetition of said first message on the first channel, confirmation request by a third message to be sent by the interlocutor on a third channel for receiving sound messages of a subset expressions of the filter, transmission request by the interlocutor of at least one other message on at least one fourth channel.

14. Humanoid robot according to one of claims 1 to 13, characterized in that at least one of the channels is a hybrid channel receiving as inputs the outputs of two channels merged by said input and output control module.

15. A method of controlling the communications of a humanoid robot with at least one interlocutor comprising at least two message transmission steps by communication channels using different modalities, said two steps being each chosen in the reception, transmission, and reception group. a step of controlling the inputs / outputs of said channels, said robot being characterized in that said control step is able to improve the understanding of the messages received by said robot by performing at least one function selected in the group combination of received / transmitted messages on a first channel and a second channel, transmitting a second message generated from a first message received on a channel.

A computer program comprising program code instructions for executing the method of claim 15 when the program is run on a computer, said program being adapted to allow a humanoid robot comprising at least two communication channels to communicate with each other. messages with at least one interlocutor according to different modalities, said at least two channels being each chosen from the reception group, transmission, and a subroutine for controlling the inputs / outputs of said channels, said computer program being characterized in that said control routine is able to improve the understanding of the messages received by said robot by executing at least one function selected in the group combination of messages received / transmitted on a first channel and on a second channel, sending a second message generated from a first message received on a channel.

17. A method of editing and controlling a communication interface between at least one humanoid robot and at least one interlocutor, said at least one humanoid robot comprising at least two channels for natural communication of messages with the at least one interlocutor according to different modalities, said at least two channels being each chosen in the reception group, transmission, and an input / output control module of said channels, said control module being able to improve the understanding of the messages received by said robot in performing at least one function selected from the combination group of received / transmitted messages on a first channel and a second channel, transmitting a second message generated from a first message received on a channel, said method being characterized in that it comprises a programming step of said chosen function.

18. Editing and control method according to claim 17, characterized in that said step of programming said selected function comprises at least one sub-step of defining a first communication channel as a sound emission channel. and a second communication channel as a reception channel for at least one gesture printed to a robot member by said at least one interlocutor, a substep of defining a correspondence between said at least one gesture and an input communicated by the interlocutor to the robot, and a substep of defining the specifications of said inputs by generating at least one message to be transmitted by the robot to the interlocutor on the first channel.

19. A method of editing and control according to claim 18, characterized in that it further comprises a sub-step of defining a third touch communication channel by which the interlocutor validates the entries made on the second channel. .

20. A method of editing and control according to one of claims 18 to 19, characterized in that its steps are performed through at least one control box in which a main action frame to be performed by said robot is connected to at least one selected event in the group of antecedent events and successor events to the action to be programmed and programmed to take place according to a temporal constraint predefined by a Timeline.

21. An editing and control method according to claim 17, characterized in that said step of programming said selected function comprises at least one substep of defining a first communication channel as a sound message receiving channel and a a second communication channel as a transmission channel of sound messages, a sub-step of defining a function for evaluating a level of confidence of the understanding by said robot of a first message received on said first channel and a sub-step of defining the generation of at least one second message on said second channel whose content depends on said confidence level.

22. A method of editing and control according to claim 21, characterized in that it further comprises a substep of defining a voice recognition filter messages received on the first channel by a list of expressions to each of which is associated an expected recognition rate and a sub-step of defining the content of said second message by a heuristic chosen in the request group for repetition of said first message on the first channel, confirmation request by a third message to be sent by the first message; interlocutor on the first channel of a subset of the expressions of the filter, transmission request by the interlocutor of at least one other message on at least one third channel.

23. Development method according to one of claims 21 to 22, characterized in that its steps are performed via at least one control box in which a main frame of action to be performed by said robot is connected at least one event selected in the group of antecedent events and successor events to the action to be programmed and programmed to take place according to a temporal constraint predefined by a timeline, said command box being a choice type box.

A computer program comprising program code instructions for executing the method of claim 17 when the program is run on a computer, said program being adapted to allow a user to program a humanoid robot comprising at least two natural message communication channels with at least one interlocutor according to different modalities, said at least two channels being each selected from the reception group, transmission, and an input / output control subroutine of said channels, said computer program being characterized in that it comprises a programming module in the control routine of at least one function to be executed by the robot selected in the group combination of messages received / transmitted on a first channel and on a second channel, sending a second message generated from a first message received on a channel.

25. Computer program according to claim 24, characterized in that it further comprises a module for programming the passage of at least one parameter to a control box.

26. Computer program according to claim 24, characterized in that it further comprises a module for programming the return of the inputs of a visual communication channel of the robot in the interface of said program.

27. Computer program according to claim 24, characterized in that it further comprises a module for programming behaviors of the robot running in parallel.