Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
CONTROL-COMMAND ARCHITECTURE FOR A MOBILE ROBOT USING ARTICULATED LIMBS
Document Type and Number:
WIPO Patent Application WO/2009/124951
Kind Code:
A1
Abstract:
The present invention relates to a mobile robot which can have a human appearance and elaborate functions enabling it to execute its missions. To allow optimization of the internal robot communications and versatility which is both physical (possible substitution of parts of the robot) and software (replacement of programs so as to adapt it to new missions), an architecture with three levels of computers is provided. The highest level comprises the intelligence of the robot which formulates commands which are transmitted by an intermediate computer to low-level cards which control the sensors and actuators. The communication between the intermediate computer and the low-level cards is managed by at least one specific secure communication protocol.

Inventors:
SERRE, Julien (1 rue Gustave Caillebotte, Carrieres Sur Seine, Carrieres Sur Seine, F-78420, FR)
MARNIER, Brice (57 rue Claude Decaen, Paris, Paris, F-75012, FR)
MATARD, Jérôme (110 Quai de Jemmapes, Paris, Paris, F-75010, FR)
Application Number:
EP2009/054177
Publication Date:
October 15, 2009
Filing Date:
April 08, 2009
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ALDEBARAN ROBOTICS (168 bis - 170 rue Raymond Losserand, Paris, F-75014, FR)
SERRE, Julien (1 rue Gustave Caillebotte, Carrieres Sur Seine, Carrieres Sur Seine, F-78420, FR)
MARNIER, Brice (57 rue Claude Decaen, Paris, Paris, F-75012, FR)
MATARD, Jérôme (110 Quai de Jemmapes, Paris, Paris, F-75010, FR)
International Classes:
B25J9/16; B62D57/02
Foreign References:
EP1486298A12004-12-15
EP1825966A12007-08-29
US20040015598A12004-01-22
US20070257910A12007-11-08
Attorney, Agent or Firm:
NGUYEN VAN YEN, Christian (Immeuble "Visium", 22 avenue Aristide Briand, Arcueil Cedex, F-94117, FR)
Download PDF:
Claims:

REVENDICATIONS

1. Robot mobile sur des membres articulés comprenant une pluralité de sous-ensembles de capteurs et d'actionneurs, chaque sous-ensemble étant commandé par une carte électronique (10), caractérisé en ce que les fonctions de contrôle d'au moins une partie des cartes électroniques sont réparties entre au moins un premier calculateur (20) et un deuxième calculateur (30), ledit premier calculateur (20) assurant notamment la transmission aux dites cartes électroniques (10) de messages de commande d'exécution de fonctions définies par le deuxième calculateur (30).

2. Robot mobile selon la revendication 1 caractérisé en ce que certaines fonctions du robot mobile sont programmées dans le premier calculateur, les dites fonctions gérant les réflexes du robot en déterminant des commandes des actionneurs en fonction de valeurs de certaines variables d'état des capteurs.

3. Robot mobile selon la revendication 1 caractérisé en ce que certaines données de configuration du robot mobile sont stockées dans une mémoire gérée par le premier calculateur, les dites données de configuration comprenant notamment la liste des cartes électroniques contrôlées, les capteurs et actionneurs commandés par les dites cartes et des paramètres de fonctionnement des dits capteurs et actionneurs.

4. Robot mobile selon la revendication 1 caractérisé en ce que le premier calculateur gère la procédure d'initialisation d'au moins une partie des cartes électroniques du robot.

5. Robot mobile selon la revendication 1 caractérisé en ce que des cartes électroniques du robot peuvent être remplacées par des cartes équivalentes sans modification ni de la programmation du premier calculateur ni de la programmation du deuxième calculateur.

6. Robot mobile selon la revendication 1 caractérisé en ce que le deuxième calculateur peut être remplacé par un autre calculateur équivalent sans modification de la programmation du premier calculateur. 7. Robot mobile selon la revendication 1 caractérisé en ce que les communications entre le premier calculateur et les cartes électroniques

sont gérées par un protocole sécurisé sur au moins un bus spécifique, ledit protocole sécurisé comportant des trames comprenant avant les octets du message un octet contenant au moins l'adresse de destination et un bit de poids fort à une valeur choisie, et après les octets du message, au moins un octet contenant la taille du message et un octet contenant un CRC.

8. Robot mobile selon la revendication 7 caractérisé en ce que tous les octets de la trame selon ledit protocole sécurisé ont un premier bit à la valeur complémentaire du bit de poids fort de l'octet d'adresse et que le premier octet tous les sept octets contient les sept bits des poids fort des sept octets suivants.

9. Robot mobile selon la revendication 7 caractérisé en ce que ledit protocole sécurisé comporte un mode de communication simulcast.

10. Robot mobile selon la revendication 7 caractérisé en ce que le premier calculateur et les cartes électroniques qu'il contrôle sont en outre connectés par au moins deux lignes de communication dont l'une permet la détection de fonctionnement et l'autre l'attribution d'adresses aux dites cartes électroniques.

11. Procédé de contrôle d'un robot mobile sur des membres articulés comprenant une pluralité de d'étapes de commandes de sous- ensembles de capteurs et d'actionneurs, chaque sous-ensemble étant commandé par une carte électronique (10), caractérisé en ce que les étapes de contrôle d'au moins une partie des cartes électroniques sont réparties entre au moins un premier calculateur (20) et un deuxième calculateur (30), ledit premier calculateur (20) assurant notamment l'étape de transmission aux dites cartes électroniques (10) de messages de commande d'exécution de fonctions dont l'étape de définition est réalisée par le deuxième calculateur (30).

12. Procédé de contrôle d'un robot mobile selon la revendication 11 caractérisé en ce que les communications entre le premier calculateur et les cartes électroniques sont gérées par un protocole sécurisé sur au moins un bus spécifique, ledit protocole sécurisé comportant des trames comprenant avant les octets du message un octet contenant au moins l'adresse de destination et un bit de poids fort à une valeur choisie, et après les octets du message, au moins un octet contenant

la taille du message et un octet contenant un CRC et en ce que tous les octets de la trame selon ledit protocole sécurisé ont un premier bit à la valeur complémentaire du bit de poids fort de l'octet d'adresse et que le premier octet tous les sept octets contient les sept bit des poids fort des sept octets suivants.

13. Procédé de contrôle d'un robot mobile selon la revendication 11 caractérisé en ce que les messages de commande sont transmis aux cartes électroniques avec une période sensiblement fixe dont l'ordre de grandeur est la dizaine de millisecondes. 14. Procédé de contrôle d'un robot mobile selon la revendication 11 caractérisé en ce que les messages de commande élaborés par le deuxième calculateur comportent au moins une date d'exécution par commande.

15. Procédé de contrôle d'un robot mobile selon la revendication 14 caractérisé en ce que les valeurs des commandes datées sont calculées par interpolation aux dates d'envoi périodiques entre les valeurs juste avant et les valeurs juste après.

16. Procédé de contrôle d'un robot mobile selon la revendication 13 caractérisé en ce que les consignes d'asservissement exécutées par une carte électronique entre une première commande et une deuxième commande sont extrapolées des commandes précédentes en prolongeant la vitesse de variation de commande entre la commande précédent la première commande et ladite première commande.

17. Procédé de contrôle d'un robot mobile selon la revendication 13 caractérisé en ce que les consignes d'asservissement exécutées par une carte électronique entre une première commande et une deuxième commande sont extrapolées des commandes précédentes en translatant la vitesse de variation de commande entre la commande précédent la première commande et ladite première commande sur la consigne d'asservissement appliquée entre Ia première et la deuxième commandes.

Description:

ARCHITECTURE DE CONTROLE - COMMANDE D'UN ROBOT MOBILE UTILISANT DES MEMBRES ARTICULES

La présente invention appartient au domaine des systèmes de contrôle et de commande embarqués sur des robots. Plus précisément, elle s'applique à l'architecture de robots qui se déplacent sur ou utilisent des membres articulés, notamment de forme humaine ou animale. Un robot peut être qualifié d'humanoïde à partir du moment où il possède certains attributs de l'apparence humaine : une tête, un tronc, deux bras, deux mains, deux jambes, deux pieds... Un robot humanoïde peut cependant être plus ou moins évolué. Ses membres peuvent avoir un nombre plus ou moins importants d'articulations. Il peut gérer lui-même son équilibre en statique et en dynamique et marcher sur deux membres, éventuellement en trois dimensions. Il peut capter des signaux de l'environnement (« entendre », « voir », « toucher », « sentir »...) et réagir selon des comportements plus ou moins sophistiqués, ainsi qu'interagir avec d'autres robots ou des humains, soit par la parole soit par le geste. Plus on souhaitera donner au robot une apparence et un comportement humains, plus il sera nécessaire de donner de degrés de liberté sous contrainte aux articulations des membres (donc de multiplier les moteurs pilotant ces articulations), de multiplier les capteurs, et les traitements et de générer des réactions réflexes. Plus on souhaitera l'adapter à des missions définies par des utilisateurs (humains, eux), plus il sera nécessaire de prévoir la possibilité de personnaliser la structure physique du robot (en remplaçant par exemple une tête par une autre) et son intelligence (en mettant à jour les programmes qui la constituent, ce qui peut nécessiter des interactions avec un serveur d'où il pourra télécharger les applications nouvelles faisant évoluer ses missions ou ses comportements). Cette complexification et cette versatilité des structures physiques et logicielles de robots mobiles sur des membres articulés ne peut pas être réalisée dans les architectures de l'art antérieur. En effet, une architecture de contrôle-commande comportant une seule unité centrale de calcul qui pilote tous les moteurs de commande des articulations atteint rapidement ses limites, notamment en raison de la lourdeur de la connectique associée. Une alternative est de prévoir une architecture décentralisée, classique dans des systèmes de robotique industrielle, avec

une carte mère et une carte contrôleur par unité moteur ou capteur. Dans le cas d'un robot humanoïde ayant les fonctions indiquées, la gestion des communications en entrée/sortie de la carte mère devient alors très lourde pour le processeur de celle-ci, jusqu'à la saturer. La présente invention résout ce problème en prévoyant une architecture de contrôle-commande à au moins trois niveaux, un niveau de commande des capteurs/actionneurs par une carte électronique dotée d'au moins un microcontrôleur, un niveau de traduction et transmission de commandes aux dites cartes et de pilotage direct de fonctions de base, et un niveau de génération de fonctions de plus haut niveau comportant l'intelligence artificielle du robot.

A cet effet, la présente invention divulgue un robot mobile sur des membres articulés comprenant une pluralité de sous-ensembles de capteurs et d'actionneurs, chaque sous-ensemble étant commandé par une carte électronique, caractérisé en ce que les fonctions de contrôle d'au moins une partie des cartes électroniques sont réparties entre au moins un premier calculateur et un deuxième calculateur, ledit premier calculateur assurant notamment la transmission aux dites cartes électroniques de messages de commande d'exécution de fonctions définies par le deuxième calculateur. Avantageusement, certaines fonctions du robot mobile sont programmées dans le premier calculateur, les dites fonctions gérant les réflexes du robot en déterminant des commandes des actionneurs en fonction de valeurs de certaines variables d'état des capteurs. Avantageusement, certaines données de configuration du robot mobile sont stockées dans une mémoire gérée par le premier calculateur, les dites données de configuration comprenant notamment la liste des cartes électroniques contrôlées, les capteurs et actionneurs commandés par les dites cartes et des paramètres de fonctionnement des dits capteurs et actionneurs. Avantageusement, le premier calculateur gère la procédure d'initialisation d'au moins une partie des cartes électroniques du robot. Avantageusement, des cartes électroniques du robot peuvent être remplacées par des cartes équivalentes sans modification ni de la programmation du premier calculateur ni de la programmation du deuxième calculateur.

Avantageusement, le deuxième calculateur peut être remplacé par un autre calculateur équivalent sans modification de la programmation du premier calculateur.

Avantageusement, les communications entre le premier calculateur et les cartes électroniques sont gérées par un protocole sécurisé sur au moins un bus spécifique, ledit protocole sécurisé comportant des trames comprenant avant les octets du message un octet contenant au moins l'adresse de destination et un bit de poids fort à une valeur choisie, et après les octets du message, au moins un octet contenant la taille du message et un octet contenant un CRC.

Avantageusement, tous les octets de la trame selon ledit protocole sécurisé ont un premier bit à la valeur complémentaire du bit de poids fort de l'octet d'adresse et que le premier octet tous les sept octets contient les sept bit des poids fort des sept octets suivants. Avantageusement, ledit protocole sécurisé comporte un mode de communication simulcast.

Avantageusement, le premier calculateur et les cartes électroniques qu'il contrôle sont en outre connectés par au moins deux lignes de communication dont l'une permet la détection de fonctionnement et l'autre l'attribution d'adresses aux dites cartes électroniques.

La présente invention divulgue également un procédé de contrôle d'un robot mobile sur des membres articulés comprenant une pluralité de d'étapes de commandes de sous-ensembles de capteurs et d'actionneurs, chaque sous- ensemble étant commandé par une carte électronique, caractérisé en ce que les étapes de contrôle d'au moins une partie des cartes électroniques sont réparties entre au moins un premier calculateur et un deuxième calculateur, ledit premier calculateur assurant notamment l'étape de transmission aux dites cartes électroniques de messages de commande d'exécution de fonctions dont l'étape de définition est réalisée par le deuxième calculateur. Avantageusement, les communications entre le premier calculateur et les cartes électroniques sont gérées par un protocole sécurisé sur au moins un bus spécifique, ledit protocole sécurisé comportant des trames comprenant avant les octets du message un octet contenant au moins l'adresse de destination et un bit de poids fort à une valeur choisie, et après les octets du message, au moins un octet contenant la taille du message et un octet

contenant un CRC et, en en outre, tous les octets de la trame selon ledit protocole sécurisé ont un premier bit à la valeur complémentaire du bit de poids fort de l'octet d'adresse et le premier octet tous les sept octets contient les sept bit des poids fort des sept octets suivants. Avantageusement, les messages de commande sont transmis aux cartes électroniques avec une période sensiblement fixe dont l'ordre de grandeur est Ia dizaine de millisecondes.

Avantageusement, les messages de commande élaborés par le deuxième calculateur comportent au moins une date d'exécution par commande. Avantageusement, les valeurs des commandes datées sont calculées par interpolation aux dates d'envoi périodiques entre les valeurs juste avant et les valeurs juste après.

Avantageusement, les consignes d'asservissement exécutées par une carte électronique entre une première commande et une deuxième commande sont extrapolées des commandes précédentes en prolongeant la vitesse de variation de commande entre la commande précédent la première commande et ladite première commande.

Avantageusement, les consignes d'asservissement exécutées par une carte électronique entre une première commande et une deuxième commande sont extrapolées des commandes précédentes en translatant la vitesse de variation de commande entre la commande précédent la première commande et ladite première commande sur la consigne d'asservissement appliquée entre la première et Ia deuxième commandes.

Cette architecture présente l'avantage de libérer l'essentiel de la puissance ce calcul de l'unité de plus haut niveau pour les tâches d'intelligence artificielle qui assurent la génération de comportements du robot en adéquation avec des profils d'utilisation dudit robot. Elle permet également de gérer les communications entre les différents calculateurs sur des bus différents, optimisés par niveau, et de prévoir des protocoles de communication également optimisés. En outre, cette architecture présente l'avantage supplémentaire que des parties du robot peuvent être changées sans reconfiguratîon du cœur du robot. Elle est également optimale pour l'utilisation de commandes datées qui sont nécessaires pour synchroniser l'exécution des ordres transmis aux nombreuses articulations d'un robot

humanoïde, éventuellement en provenance d'une machine distante ou d'un autre robot en communication avec le premier robot via une liaison asynchrone.

L'invention sera mieux comprise et ses différentes caractéristiques et avantages ressortiront de la description qui suit de plusieurs exemples de réalisation et de ses figures annexées dont :

- La figure 1 est un schéma de l'architecture physique d'un robot humanoïde dans un mode de réalisation de l'invention ;

- La figure 2 est un schéma de l'architecture fonctionnelle d'un robot humanoïde dans un mode de réalisation de l'invention ;

- La figure 3 est un schéma de principe de l'architecture logique d'un robot humanoïde dans un mode de réalisation de l'invention ;

- La figure 4 est un schéma illustrant la transmission par le premier calculateur de commandes générées par le deuxième calculateur aux cartes électroniques dans un robot humanoïde dans un mode de réalisation de l'invention ;

- Les figures 5A et 5B sont des chronogrammes illustrant la génération de commandes datées par l'un des calculateurs de premier ou de deuxième niveau pour transmission aux cartes électroniques de plus bas niveau dans un robot humanoïde dans un mode de réalisation de l'invention ;

- Les figures 6A, 6B, 6C et 6D sont des chronogrammes illustrant différents scénarios de fusion des commandes datées dans un mode de réalisation de l'invention ; - La figure 7 illustre la répartition des éléments de configuration entre les différents niveaux de l'architecture d'un robot humanoïde dans un mode de réalisation de l'invention.

Dans la suite de la description, les abréviations et acronymes ont les significations indiquées dans le tableau ci-dessous, à moins qu'une signification différente ne leur soit explicitement donnée dans un contexte particulier :

La figure 1 illustre l'architecture physique d'un robot humanoïde dans un mode de réalisation de l'invention. Ce robot comprend environ deux douzaines de cartes électroniques du type 10 de commande de capteurs 120 et d'actionneurs 130 qui pilotent les articulations. La carte 10 montrée sur la

figure est celle qui contrôle le pied gauche. Une des vertus de l'architecture est que les cartes contrôlant les articulations sont pour la plupart interchangeables. Une articulation a normalement au moins deux degrés de liberté et donc deux moteurs. Chaque moteur est piloté en angle. L'articulation comporte également plusieurs capteurs de position, notamment des MRE (Magnetic Rotary Encoder). La carte électronique de contrôle comporte un microcontrôleur du commerce 110. Ce peut être par exemple un DSPIC™ de la société Microchip. C'est un MCU 16 bits couplé à un DSP. Ce MCU a un cycle d'asservissement en boucle d'une ms. Le robot peut également comporter d'autres types d'actionneurs, notamment des LED 140 (Diodes électroluminescentes) dont la couleur et l'intensité peuvent traduire les émotions du robot. Celui-ci peut également comporter d'autres types de capteurs de position, notamment une centrale inertielle, des FSR (Capteurs de pression au sol), etc.... La tête comporte l'intelligence du robot, notamment la carte 30 qui exécute les fonctions de haut niveau qui permettent au robot d'accomplir les missions qui lui sont assignées. La carte 30 pourrait cependant être située ailleurs dans le robot, par exemple dans le tronc. On verra cependant que cette localisation, lorsque la tête est amovible, permet de remplacer ces fonctions de haut niveau et donc notamment de changer complètement l'intelligence du robot et donc ses missions très rapidement. Ou à l'inverse de changer un corps par un autre (par exemple un corps défectueux par un non défectueux) en gardant la même intelligence artificielle. La tête peut comporter également des cartes spécialisées, notamment dans le traitement de la parole ou de la vision. Le processeur 310 de la carte 30 peut être un processeur x86 du commerce. On choisira de manière privilégiée un processeur à basse consommation tel que le Géode™ de la société AMD (32 bits, 500 MHz). La carte comporte également un ensemble de mémoires RAM et flash. Cette carte gère également les communications du robot avec l'extérieur (serveur de comportements, autres robots...), normalement sur une couche de transmission WiFi, WiMax » éventuellement sur une réseau public de communications mobiles de données avec des protocoles standards éventuellement encapsulés dans un VPN. Le processeur 310 est normalement piloté par un OS standard ce qui permet d'utiliser les langages de haut niveau usuels (C, C++, Python, Ruby,...) ou les langages spécifiques

de l'intelligence articifîelle comme URBI (language de programation spécialisé dans la robotique) pour la programmation des fonctions de haut niveau.

Une carte 20 est logée dans le tronc du robot. C'est là que se situe le calculateur qui, selon l'invention, assure la transmission aux cartes 10 des ordres calculés par la carte 30. Cette carte pourrait être logée ailleurs dans le robot. Mais la localisation dans le tronc est avantageuses car elle se situe près de la tête et au carrefour des quatre membres, ce qui permet donc de minimiser la connectique reliant cette carte 30 à la carte 20 et aux cartes 10. Le calculateur 210 de cette carte 20 est également un processeur du commerce. Ce peut avantageusement être un processeur 32 bits du type ARM 7™ cadencé à 60 MHz. Le type du processeur, sa position centrale, proche du bouton de marche/arrêt, sa liaison au contrôle de l'alimentation en font un outil bien adapté pour la gestion de l'alimentation du robot (mode veille, arrêt d'urgence, ...). La carte comporte également un ensemble de mémoires RAM et flash.

Dans cette architecture à trois niveaux selon l'invention, une fonction de reprogrammation des microcontrôleurs 110 et 210 est prévue dans la carte- mère. La figure 2 illustre la fonction principale du calculateur 210 qui est d'assurer la transmission des ordres élaborés par le calculateur 310 aux cartes 10 comprenant notamment des capteurs 120, des actionneurs (par exemple des moteurs 130 et éventuellement des LED 140). Certains ordres peuvent être transmis directement à certaines cartes sans passer par la carte 20. C'est notamment le cas pour les cartes situées dans la tête qui ne comportent pas de moteur (cartes assurant le contrôle des LEDs du visage, de la détection du toucher et des LED des oreilles). La liaison entre ces cartes et la carte 30 est assurée avantageusement par un bus I2C, efficace pour les trames de signaux qui l'empruntent. La carte 20 est reliée à la carte 30 par un bus USB qui a une fiabilité et une vitesse suffisantes pour cette fonction, et qui utilise très peu de puissance sur le processeur 30. En outre, cette liaison USB permet, lorsqu'on enlève la tête contenant Ia carte 30 dans un mode de réalisation, de connecter directement les autres éléments de l'architecture de calcul à un ordinateur externe pour réaliser les développements et le test..

Un protocole USB adapté pour cette application est décrit sommairement ci- après. La structure du message est classique : un en-tête comprenant un premier octet fixe, un deuxième octet de type, un octet d'adresse, un octet de longueur de message, les octets du message (jusqu'à 128 octets) et deux octets fixes de fin de message dont le premier est identique au premier octet d'en-tête. Les octets du message qui sont égaux au premier octet d'en- tête sont systématiquement doublés pour détromper le récepteur. Une spécificité du protocole utilisé est la gestion des accusés de réception positifs et négatifs (ACK et NACK) à la lecture et à l'écriture. Dans les deux cas, si l'opération est réussie (ACK), le message comprend dans le champ « Données » celles qui ont été lues ou écrites. Si l'opération échoue (NACK), le champ « Données » comporte une séquence spécifique. La carte 20 communique avec les cartes 10 situées dans les membres supérieurs et les membres inférieurs par deux liaisons par exemple du type RS485. Chaque liaison RS485 est complétée par une ligne de débogage à laquelle sont reliées toutes les cartes 10 et la carte 20 et une ligne de chaînage par membre qui passe de la première carte 10 d'un membre à la suivante en partant de la carte 20. La fonction de ces lignes est expliquée plus loin dans la description. Les liaisons RS485 sont très utilisées en environnement industriel et sont adaptées à une utilisation pour la commande et le contrôle d'un robot humanoïde en raison de leur très faible sensibilité aux parasites. En outre elles offrent un débit supérieur à 46.600 octets par seconde qui est nécessaire pour échanger des informations nombreuses dans les deux directions. Elles présentent cependant l'inconvénient que les trames de messages sont envoyées en continu sur la liaison ce qui rend plus difficile le décodage des messages. Il est donc nécessaire d'utiliser un protocole de communication sécurisé permettant de retrouver les différents messages dans les trames. Un des protocoles possibles est décrit ci-après. Il consiste à titre principal à mettre à zéro le premier bit de chaque octet et à insérer avant sept octets un octet comprenant les bits de poids fort des sept octets suivants. Par ailleurs, l'en-tête de message est constitué par un octet comprenant l'adresse de destination sur six bits, un bit qui indique si on fait une lecture ou une écriture, et un bit de poids fort systématiquement à 1. Le début du message comprend deux octets en plus de l'adresse, le premier

codant Ia taille du message, le second le type du message et le dernier octet du message est constitué par un CRC portant sur l'intégralité du message. Les messages peuvent être du type : angle d'une articulation, viscosité d'une articulation, réinitialisation, LEDs, configuration d'un Device, diverses commandes de reprogrammation, etc. Pour qu'un message soit valide, il faut donc respecter les critères suivants : 1 er MSB à 1 , les autres à 0, adresse, type de message, taille et CRC corrects. La charge de gestion du protocole est assez légère à la fois à l'émission et à la réception. Le message est de taille fixe, ce qui facilite grandement la gestion temporelle de la communication.

Pour alléger la charge liée aux codes de contrôle, il est fait un usage assez large d'une fonction de broadcast, en réalité le plus souvent de simulcast ou émission simultanée à des adresses différentes. Dans ce cas, la 1 ere adresse de destination est mise à zéro. Les cartes de destination d'une partie du message sont identifiées par un BID ou Broadcast ID qui permet à chaque carte de retrouver la partie du message qui lui est destiné. Ce mode permet en particulier l'envoi de commandes aux actionneurs, telles que les positions des articulations à atteindre. Pour la lecture des cartes moteurs, le protocole est légèrement différent : le maître envoie le 1 er octet (toujours avec le MSB à 1 ) suivi du nombre d'octets à demander sur 7 bits et d'un CRC sur 7 bits de ces deux octets. La carte désignée par l'adresse ne répond que si le CRC est bon. Elle répond alors le nombre d'octets demandé avec le MSB toujours à 0. Les données lues sur les cartes moteurs dépendent de la longueur demandée, le point de départ étant toujours le même. Les données les plus utiles et les plus fréquemment lues sont placées au début de la zone à lire. Il s'agit des positions des capteurs des articulations, du courant, des erreurs et de la température. Au niveau de la carte torse 20 il n'y a pas de comptage des octets. Il y seulement un time-out correspondant au temps d'envoi des octets de réponse avec une marge. A l'issue du time-out, la carte a reçu ou non les octets, ce qui permet de ne pas perturber le fonctionnement du reste du robot en cas de défaillance d'une carte.

Les liaisons de débogage et de chaînage sont utilisées essentiellement au moment de l'initialisation du robot, dont la gestion est également assurée par la carte 20, ce qui est une autre de ses fonctions importantes. La carte 20 est

commandée par Ie bouton d'allumage et s'initialise en premier. Les cartes 10 et la carte 30 démarrent ensuite ; tes cartes 10 envoient sur la ligne de débogage un bit à 0 ; la carte 20 leur envoie en retour une commande sur la ligne de chaînage qui fait passer ce bit d'état à 1. Les adresses sont ensuite attribuées par incrément d'une unité de proche en proche pour chacune des cartes sur chaque ligne de chaînage, jusqu'à la dernière carte du membre. C'est donc la position des cartes 10 dans la chaîne qui crée une différentiation « physique » entre celles-ci alors qu'elles sont identiques, En cas de reset, la totalité du chaînage est rejouée. Les lignes de débogage et de chaînage sont par exemple des lignes utilisant le protocole One Wire sur lesquelles circulent des trains d'impulsions carrées qui codent des bits 0 (durée de l'impulsion à l'état bas de l'ordre de 50 μs) et 1 (durée de l'impulsion à l'état bas de l'ordre de 250 μs).

La figure 3 illustre l'architecture logique d'un robot humanoïde selon l'invention.

Le robot comprend un module de gestion des cartes (DCM) qui peut être implanté pour l'essentiel sur la carte 30 mais également au moins partiellement sur la carte 20. Le programme DCM commence par lire un buffer de configuration interne à chaque carte 10 (par exemple une carte moteur). Ce buffer ne comporte à ce stade que des indications internes à la carte (versions du bootloader - chargeur automatique du fichier de démarrage, du programme, de la carte ; adresse de la carte obtenue par le chaînage). Le buffer est complété dans le DCM par toutes les valeurs de configuration : BID, nombre et position des MRE dans la chaîne, nombre et position des moteurs, coefficient d'asservissement des articulations, présence de LED, ou de FSR, etc. Le buffer est ensuite envoyé à nouveau à la carte 10, Cette mise à jour des paramètres de configuration des cartes 10 remplace avantageusement une mise à jour de la mémoire flash des cartes. Les données lues sur les cartes 10 sont stockées dans une base de données interne du robot (STM) conservée en RAM. L'architecture logique du robot se décompose en un type de périphériques maîtres dénommés Devices dans la suite de la description (essentiellement MCU 110 des cartes électroniques 10 du robot) puis en périphériques esclaves dénommés SubDevices (capteurs 120 ou actionneurs 130, 140) reliés au Device. Les Devices sont eux-

mêmes esclaves par rapport à l'ensemble cartes 20,30. Hs sont caractérisés par un type, un bus (I2C tête ou torse, RS485 haut ou bas) et une adresse sur ce bus. Les SubDevices sont caractérisés par un type (moteurs, LEDs FSR ...) qui définissent s'ils sont capteur ou actionneur, le Device de rattachement et le numéro de SubDevice.

Il est a noter que la position de l'articulation correspond à un SubDevice capteur (correspondant à l'information angulaire renvoyée par le capteur) et à un SubDevice actionneur séparé du premier, correspondant à la position à atteindre demandée. Par exemple une carte moteur comprend de manière privilégiée deux SubDevices moteur (actionneur), 2 SubDevices position du capteur (capteur), 2 SubDevices courant (capteur)... La carte visage peut comporter un grand nombre de SubDevices LED (actionneur) (48 dans une mode de réalisation). Un SubDevice est également caractérisé par la valeur en virgule flottante de sa variable d'état principale (la position angulaire de l'articulation pour un capteur de position, la mesure de courant pour le capteur de courant, la valeur de la LED pour l'actionneur LED, etc. ainsi que par les valeurs de variables dérivées de la variable principale (gain, offset, valeurs minimale et maximale, accusé de réception (ACK) ou accusé de non réception (NACK), ERREUR - différente de 0 en cas de problème). Les Devices n'ont pas de valeur de variable d'état principale, mais ils ont des valeurs de compteurs du type ACK/NACK/ERREUR. D'autres valeurs sont spécifiques aux types de Devices ou de SubDevices (par exemple les coefficients d'asservissement sur les actuateurs moteur). Toutes ces valeurs sont mises à jour automatiquement et visibles dans la STM depuis les applications du haut niveau.

Les compteurs ACK et NACK s'incrément respectivement à chaque communication réussie ou à chaque erreur de communication avec le Device/SubDevice. Ils permettent de détecter les problèmes d'accès à la carte et de calculer leur fréquence.

Cette architecture Device/SubDevice est décrite pour chaque robot dans un fichier de configuration présent par défaut (configuration standard) dans la carte 30 et facilement modifiable, mais certaines valeurs spécifiques sont aussi stockées dans une mémoire flash de la carte 20. Il s'agit d'une autre

fonction importante de cette carte 20 qui permet ainsi de préserver l'indépendance entre le haut niveau et le bas niveau du robot. Le DCM n'a pas lui-même d'information « en dur » sur l'architecture électronique du robot. L'accès aux capteurs et actionneurs se fait par une « clef » portant le nom du SubDevice/Value. Pour le niveau haut, il n'y a aucune différence entre les LEDs des pieds (gérées en RS485 sur une carte moteur via l'USB de la carte torse), les LEDs du torse (gérées par la carte torse via des requêtes USB) , les LEDs du visage (gérées par la carte visage via des requêtes I2C). Dans un mode de réalisation privilégié, le DCM fonctionne avec un cycle interne de 10 à 20ms. La plupart des capteurs et des actionneurs, sont mis à jour/ lus systématiquement à chaque cycle. Cela permet de fonctionner à charge constante, d'optimiser les communications, de rendre non critique une erreur de communication (elle ne « dure » que 20ms). En outre, en préférant une mise à jour systématique de la plupart des capteurs à une mise à jour par une requête, on assure une disponibilité immédiate de l'information à jour pour l'ensemble des modules haut niveau du robot. La carte 20 assure la conversion des commandes élaborées par le DCM et transmises dans un protocole USB en protocole RS485. Il est possible d'utiliser également une des mémoires de la carte 20 comme mémoire tampon de ces commandes, de manière à effectuer des calculs d'interpolation entre commandes comme indiqué plus bas.

A titre d'exemple du fonctionnement de l'architecture selon l'invention, la figure 4 illustre la génération et la transmission d'un ensemble de commandes pour que le robot avance d'une distance δ en suivant un cap θ à une vitesse δ'. Le processeur 30 élabore les commandes à appliquer aux moteurs des articulations Ai , A 2 , A 3 du robot pour exécuter l'ordre δ, δ', θ.

Pour chaque articulation, il y a une ou plusieurs commandes sous la forme d'angles à atteindre. Dans un mode privilégié de réalisation de l'invention, pour toutes les commandes à exécuter on calcule la date absolue de l'exécution. Dans cette architecture de processeurs et de bus non déterministes, ni les communications entre cartes du robot ni les communications en provenance de l'extérieur qui peuvent fournir des paramètres en entrée à la consigne à exécuter, ne peuvent avoir un temps

de parcours garanti vers le lieu de leur exécution et donc des dates d'arrivée et d'exécution certaines. La datation des commandes permet d'assurer leur synchronisation dans ce contexte de manière relativement simple. On peut par exemple utiliser la date système du processeur 30. En fonction des informations de configuration et de l'état du système connu, le DCM élabore une suite de valeurs de la variable α (commande en angle) de contrainte des actionneurs A, à une suite d'instants t dans l'avenir, {o^ t }. La durée T sur laquelle il est possible de calculer et transmettre les valeurs α est fonction notamment de la capacité mémoire de la RAM dédiée du DCM.. Dans la mesure où le DCM a son propre cycle (10 à 20 ms comme déjà indiqué), il est nécessaire de générer des commandes actuelles au moment où les trames sont transmises. Pour toutes les commandes appliquées à des actionneurs dont les variables d'état sont continues (telles que l'angle qui caractérise la rotation d'un moteur d'articulation ou la luminance d'une LED), cette génération s'opère à l'instant t en recherchant les commandes α,ti et α Jt 2 qui sont respectivement juste avant t et juste après t., et en réalisant une interpolation linéaire entre ces deux valeurs, pondérées par le temps écoulé entre t1 , t2 et t.

Pour l'envoi de nouvelles commandes, il est également possible de fusionner deux suites {α t } concernant un même actionneur, celle en RAM du DCM et une nouvelle envoyée par un module extérieur. Cette opération est réalisée avant l'interpolation. Le résultat de l'interpolation est encapsulé dans des trames USB puis transmise de la carte 30 à la carte 20. En variante, on peut également transmettre la suite { α )it } et réaliser les transformations dans la carte 20 . Dans les deux cas, le processeur 210 réalise ensuite l'élimination du protocole USB et l'encapsulation dans des trames RS485 selon le protocole sécurisé décrit plus haut. On utilise de manière privilégiée le mode simulcast, en codant les adresses des Devices contenant les SubDevices A, devant exécuter les commandes. Les trames sont ensuite transmises simultanément sur le bus RS485 aux Devices contrôlant les SubDevîces A, devant exécuter des commandes. La procédure de contrôle des trames permet de s'assurer de l'intégrité des messages transmis. Une interpolation est réalisée sur les Devices entre la 1 ere commande à exécuter et la dernière exécutée auparavant de manière à lisser les mouvements des articulations.

Des transformations par interpolation linéaire opérées à l'émission sont illustrées par les figures 5A et 5B. Dans le cas simple de la figure 5A, 7 commandes espacées de 10 ms se substituent au fur et à mesure à deux commandes espacées de 70 ms. Les valeurs des commandes évoluent sans difficulté de manière monotone. Dans le cas plus complexe de la figure 5B où il y a un changement de sens de variation de la variable d'état, la fonction d'interpolation en escalier permet de reconstituer ce changement de manière plus lissée.

Différents types de transformations par fusion de trames de commandes sont illustrées par les figures 6A, 6B, 6C et 6D. Dans le cas de la figure 6A, la fusion consiste à prendre en compte toutes les commandes. Dans le cas de la figure 6B, la commande la plus ancienne est effacée au-delà d'une date donnée. Dans le cas de la figure 6C, la commande la plus ancienne est effacée avant une date donnée. Dans le cas de la figure 6D, la commande la plus ancienne est complètement effacée.

Il est également avantageux de lisser l'exécution des commandes reçues par un actuateur de manière à éviter, dans la mesure du possible, les discontinuités. Pour ce faire, différents algorithmes d'extrapolation sont possibles. Deux d'entre eux sont illustrés par les figures 7A et 7B. Onrappelle tout d'abord que le cycle de réception des commandes des de l'ordre de la dizaine de ms (20 ms dans un mode de réalisation privilégié actuel) et qu'il est à peu près constant hors sauf contention de charge réseau ou processeur, alors que le cycle d'asservissement est de l'ordre de la ms. Dans le cas de la figure 7A, on considère que la vitesse d'évolution de la commande αt, telle que mesurée sur la période to, ti, (α't, = (an - ato)/( ti - to)) est constante sur l'intervalle de temps suivant ti, t 2 . L'asservissement sur une consigne extrapolée (Vθ ε [ti, t 2 ], αe = α ω + α' t , *( θ - tO) permet d'atteindre une commande β 2 en ti alors qu'à défaut la consigne d'asservissement passerait brutalement de CH à α 2 . On voit de manière graphique, si la consigne reste à vitesse constante, accélère ou décélère légèrement, l'asservissement à une consigne interpolée de cette manière est plus efficace que le maintien de la consigne précédente, puisque la différence β 2 - α 2 est plus petite que la différence α 2 - α-i.

On note que dans ce cas, l'asservissement effectivement réalisé va de β2 à β 3 , β 3 correspondant à la consigne extrapolée entre (CH , tι) et (02, î 2 ). Cette condition n'est pas remplie si la consigne décélère très rapidement : dans ce cas la différence β 2 - 0 2 est plus grande que la différence 0 2 - α-t. L'évolution de la consigne est figurée en traits pleins. Sur la figure 7B, on a illustré ce deuxième type de situation de décélération significative et on lui applique un autre mode de calcul de l'évolution de la consigne qui consiste à introduire un effet retard d'un cycle : γ 2 est le translaté de α 2 d'un cycle. On voit graphiquement qu'ainsi γ 2 est plus proche d' α 2 que qui résulterait du calcul précédent. En revanche, au cycle suivant, l'écart s'inverse, mais la somme des deux reste favorable. Il est en outre utile d'introduire un certain nombre de règles de comportement pour régler l'évolution des consignes dans des cas particuliers : si un algorithme d'extrapolation ne peut fonctionner, la consigne est laissée inchangée ; si aucune commande n'est reçue pendant un temps chosi, par exemple, pour un cycle de 20 ms, 50ms, on n'applique pas d'extrapolation en laissant la consigne à la valeur atteinte en dernier ; on bout d'un autre temps choisi, par exemple 10 fois le temps choisi dans le cas précédent, on arrête le robot ; on ne coupe cependant jamais l'actionneur en préférant appliquer une consigne de freinage électromagnétique pour éviter une chute brutale du robot ou d'une de ses articulations.

Les avantages d'un système de commandes datées tel que décrit ci-dessus sont multiples : - il évite par défaut les discontinuités brusques, même si celles-ci restent possibles en cas de besoin avec deux commandes avec des dates très proches;

- il permet en une seule commande de faire une interpolation linéaire entre deux valeurs qui est une interpolation simple mais toujours valable (on peut ramener les autres interpolations en une suite d'interpolations linéaires, et donc minimiser aussi les commandes dans des cas plus complexes) ;

- il permet d'éviter les problèmes de synchronisation entre le DCM (qui a son propre cycle) et les autres modules ; il suffit par exemple de donner les commandes au moins un cycle à l'avance au DCM pour

qu'il calcule une interpolation correspondant à la consigne, ce qui ne génère pas d'à-coup dans les mouvements ; il procure une précision dans les consignes, et donc les mouvements, qui est excellente ; - il est insensible aux éventuels retards, latences, ou délais variables de communications ; il permet de synchroniser très simplement plusieurs actuateurs, même s'ils sont commandés par des modules totalement différents, et situés ou non dans le robot. En outre, les modules externes peuvent récupérer l'horloge système de manière simple, et donc se synchroniser avec le générateur de commandes. Pour diminuer la charge de calcul du DCM, il est possible de regrouper les commandes à adresser à plusieurs actionneurs sur un alias.

On peut également envisager de générer ou modifier des commandes pour les actionneurs directement dans le calculateur 210. En particulier, un certain nombre d'événements ne nécessitent pas forcément l'intervention du calculateur de haut niveau. Certaines fonctions réflexes notamment peuvent être directement pilotées dans la carte 20, notamment la gestion de l'équilibre du robot ou l'évitement de collisions entre membres. Il suffit d'implanter l'algorithmie correspondante et une partie du DCM sur la carte 20.

Pour assurer une certaine versatilité du robot, il est par ailleurs nécessaire de prévoir des fichiers contenant les configurations matérielle et logicielle facilement accessibles et modifiables. La répartition de ces fichiers de configuration est illustrée par la figure 7.

Il y a un fichier de configuration (préférence) Device.xml et plusieurs sous- fïchiers liés à certaines parties du robot (Device_Head.xml, Device_Chest.xml et d'autres si c'est nécessaire). Certaines parties du robot sont interchangeables. La tête peut être facilement séparée du corps ou y être à nouveau implantée. Des bras ou d'autres parties du robot peuvent également être remplacés. Cette versatilité est à la fois utile pour la maintenance et, comme déjà indiqué, pour adapter un robot à de nouvelles missions ou lui donner une nouvelle personnalité ou une nouvelle apparence. Or il y a des valeurs de calibration associés à ces parties qui sont

indispensables pour tenir compte de manière fine de l'implantation spécifique (calibration des capteurs des articulations, des LEDs, modifications apportées pour ajuster certains paramètres après montage...) . La meilleure solution n'est donc pas de stocker ces valeurs de calibration dans des fichiers de la carte tête, sous peine d'avoir une mauvaise calibration du corps en cas d'échange de tête. Il est préférable de ne stocker dans un fichier commun à tous les robots (Device.xml) que les valeurs par défaut et sans calibration de la configuration de base complète sous une forme clef = valeur. Les valeurs des clefs de ce fichier sont écrasées par 2 autres fichiers. Le 1er est lié à la tête, et est enregistré comme un fichier séparé (Device_Head.xml). Il contient la calibration de l'ensemble des SubDevices de la tête (LEDs essentiellement). Dans la carte torse est stocké un fichier qui est associé à l'ensemble du corps du robot (Device_Chest.xml). Au lancement, le « chest config in flash » est lu dans la carte torse et copié dans la RAM du DCM ainsi que, sous forme de fichier temporaire, dans le système de fichier Préférences de la tête. Les valeurs du Device.xml dans la STM sont écrasées.

La seule référence est donc le contenu de la mémoire flash de la carte torse. Ainsi en cas d'échange de têtes, le fichier de la carte torse du nouveau corps sera donc lu, éliminant tout problème possible.

Les exemples décrits ci-dessus sont donnés à titre d'illustration de modes de réalisation de l'invention. Ils ne limitent en aucune manière le champ de l'invention qui est défini par les revendications qui suivent.