Brevet FR2910650A1 — publié le 20080627

PROCEDE DE COMMANDE D'UN ÉQUIPEMENT MATERIEL L'invention se rapporte à un procédé de commande pour des équipements matériels. Dans les domaines de l'industrie, scientifique, domestique et des loisirs, des équipements matériels tels que des automates sont utilisés pour la réalisation de missions précises en vue de remplacer des êtres vivants dans l'accomplissement de tâches ou de les imiter physiquement dans leurs démarches ou dans le formalisme d'expressions du visage, comme c'est le cas pour des humanoïdes ou des animaux robots. Ces équipements matériels sont contrôlés, commandés ou pilotés à partir de procédés complexes, qui sont dédiés à des équipements matériels bien définis. Ces procédés génèrent des commandes prédéfinies en fonction d'informations recueillies de différents capteurs et de paramètres internes. Dans l'art antérieur, on connaît la demande de brevet US 6,330,494 dans laquelle un système comprenant un processeur et des mémoires détecte sur la base d'un capteur d'accélération une posture anormale du corps d'un robot et la corrige par l'adoption d'une posture normale à partir d'un procédé de commande proposant des postures déterminées. Ce changement de posture correspond à des cycles d'actions déjà définis et qui tiennent compte de paramètres acquis par différents capteurs et de paramètres internes au robot. L'inconvénient d'un tel procédé est de ne pas être paramétrable ou modifiable afin de permettre au robot de réaliser des commandes autres que celles qui ont été prédéfinies et qui sont stockées dans une partie de sa mémoire. Ce procédé ne permet pas la réalisation de 2910650 2 mouvements complexes. On connaît aussi d'autres procédés reposant sur des architectures logicielles complexes comme les projets Tekkotsu (http:///www.tekkotsu.org) et Player Stage 5 (http: //plaverstage.sou_r.cefoAge.net) qui proposent des procédés de commande implémentés dans un environnement client/serveur et dédiés pour le premier exclusivement à un robot déterminé, 1' Aibo (nom commercial) , qui est un chien robot de compagnie et pour le second à une catégorie 10 de robots équipés de roues. Ces procédés permettent de contrôler des robots à partir de commandes parallèles, pour l'exécution de mouvements simultanés, ou de commandes séries sur la base d'outils logiciel informatique reposant sur des processus complexes de programmation. 15 L'inconvénient de ces procédés est de reposer sur une architecture logicielle qui, dans le cadre d'exécution de commandes, fait appel à des processus complexes de programmation multi-processus, dépendant des systèmes 20 d'exploitations appartenant aux équipements matériels sur lesquels ils s'exécutent, qui ne permettent pas l'exécution de mouvements complexes sur tous types d'équipements matériels. 25 On connaît aussi dans l'art antérieur la publication : URBI: Towards a Universal Robotic Low-Level Programming Language lors des débats de la conférence IEEE/RSJ 2005 (International Conference on Intelligent Robots and Systems), avec pour auteur Baillie-J.C. 30 Ce document enseigne un procédé de commande permettant de contrôler un robot comprenant un système d'exploitation comportant des étapes de perception consistant en l'acquisition de paramètres et des étapes d'exécution de fonctions en fonction desdits paramètres lors d'un cycle 2910650 3 d'action. Cette publication ne décrit pas de caractéristiques permettant de solutionner le problème résolu par l'invention qui se rapporte notamment à l'exécution de 5 plusieurs commandes simultanément. La présente invention vise à pallier ces inconvénients. Un des buts de l'invention est de permettre 10 l'exécution de mouvements complexes sur tous les types d'équipements matériels. Pour ce faire, la présente invention concerne un procédé de commande d'un équipement matériel comprenant un 15 système d'exploitation comportant : -des étapes de perception consistant en l'acquisition de paramètres; - des étapes d'exécution de fonctions en fonction desdits paramètres lors d'un cycle d'action ; 20 caractérisé en ce qu'au moins une desdites étapes d'exécution comprend : - une segmentation automatique en microcycles MiIj d'une pluralité d'instructions Ij se rapportant auxdites 25 fonctions avec : • i étant un nombre entier désignant le numéro du cycle, • j étant un nombre entier compris entre 1 et N, • N étant le nombre de commandes élémentaires à 30 exécuter en parallèle à l'instant i, par un ordonnanceur appartenant à un noyau informatique distinct du noyau du système d'exploitation, et 2910650 4 - une exécution de N micro-cycles MiIj de chacune desdites instructions Ij, puis des N micro-cycles Mi+ili de chacune desdites instructions Ij non achevées lors d'un 5 cycle d'action précédent, par ledit noyau informatique dudit équipement matériel. Avantageusement l'ordonnanceur permet l'exécution en simultanée de plusieurs commandes, destinées à contrôler 10 des servomoteurs constituants un équipement matériel, permettant ainsi la réalisation de mouvements complexes. D'autre part la présence d'un ordonnanceur, appartenant à un noyau, qui soit indépendant d'un système d'exploitation d'un équipement matériel permet à ce procédé 15 d'être portable et donc compatible avec tous les types d'équipements matériels. Dans un mode de réalisation, une distribution des micro-cycles à exécuter est réalisée sur un ensemble de 20 noyaux disponibles exécutés en parallèle et initialisés au démarrage d'un noyau principal. Également dans un autre mode de réalisation, une distribution des micro-cycles à exécuter est réalisée sur un unique noyau disponible et initialisé au démarrage d'un 25 noyau principal. Également dans un autre mode de réalisation lesdits noyaux exécutés en parallèle sont répartis sur plusieurs processeurs, l'exécution entre lesdits processeurs étant ordonnancé par le système d'exploitation. 30 Dans une variante de l'invention certains des micro-cycles correspondent à l'intégralité de l'instruction lorsque celle-ci a un temps d'exécution nul. Dans un autre variante de l'invention, l'instruction peut être découpée en T/dt microcycles pour dt étant le 2910650 5 temps d'exécution d'un microcycles et T le temps d'exécution de la commande. Dans une variante le microcycle à l'instant t pour une instruction I est défini par l'ensemble des opérations 5 nécessaires pour faire évoluer les variables internes ou externes liées à l'instruction I entre l'instant t et t+dt. Dans un autre variante toute commande est préfixée d'au moins un marqueur. Dans un mode de réalisation toute commande préfixée 10 par un marqueur M peut être stoppée par un signal spécifique portant sur le marqueur M ce signal pouvant être émis par une commande. Dans un autre mode de réalisation toute commande préfixée par un marqueur M peut être suspendue 15 temporairement par un signal spécifique portant sur le marqueur M ce signal pouvant être émis par une commande. Dans un autre mode de réalisation, toute commande préfixée par un marqueur M peut être réactivée après une suspension temporaire par un signal spécifique portant sur 20 le marqueur M ce signal pouvant être émis par une commande. Dans une variante de l'invention, toute commande préfixée par un marqueur M peut être stoppée par un signal spécifique pouvant être émis par une commande portant sur le marqueur M, ce signal inhibant l'exécution de toute 25 commande ultérieure associée au marqueur M. Dans une autre variante de l'invention, l'inhibition d'un marqueur M peut être levée par l'émission d'un signal spécifique, ledit signal spécifique pouvant être émis par une commande portant sur le marqueur M. 30 Dans un mode de réalisation, les marqueurs peuvent être organisés dans une hiérarchie d'héritage. Dans un mode de réalisation, l'utilisation d'un marqueur M s'étend à tout marqueur M' héritier. Dans un mode de réalisation, des instructions sont 2910650 6 susceptibles de déclencher une ou plusieurs commandes lorsqu'un test devient vrai, test portant sur des conditions sur des variables et/ou des évènements. Dans un mode de réalisation, des instructions sont 5 susceptibles de déclencher une ou plusieurs commandes aussi longtemps qu'un test est vrai, test portant sur des conditions sur des variables et/ou des évènements. Dans un mode de réalisation, des instructions sont susceptibles de se terminer lorsqu'un test devient vrai, 10 test portant sur des conditions sur des variables et/ou des évènements. Dans un mode de réalisation, des instructions sont susceptibles de se suspendre pendant qu'un test est vrai, test portant sur des conditions sur des variables et/ou des 15 évènements. Dans un mode de réalisation, les dites instructions s'enregistrent auprès des variables et évènements composant le test qui leur est associé de telle sorte que toutes modifications des dites variables et évènements provoquent 20 au moins une réévaluation du test à la fin du cycle. Dans un autre mode de réalisation, les données utilisées par les instructions peuvent être regroupées dans des structures hiérarchiques appelées objet et regroupant des variables et/ou des fonctions et/ou des procédures 25 portant sur ces variables. Dans un autre mode de réalisation, lesdits objets peuvent être regroupés dans des ensembles appelés groupe. Dans un mode de réalisation, les groupes peuvent être hiérarchisés dans une hiérarchie distincte de celle des 30 objets qu'ils contiennent. Dans un mode de réalisation, des fonctions ou procédures exécutées au niveau d'un groupe peuvent être parallèlement exécutées sur tout objet du groupe ou récursivement sur tout sous groupe. 2910650 7 Dans un mode de réalisation, des actions sur des variables au niveau d'un groupe peuvent être parallèlement exécutées sur tout objet du groupe ou récursivement sur tout sous groupe. 5 Dans un mode de réalisation, des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être exécutées l'une après l'autre. Dans un mode de réalisation, des affectations concurrentes d'une variable effectuées au cours d'un même 10 cycle peuvent être exécutées en additionnant les valeurs des affectations correspondantes. Dans un mode de réalisation, des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être exécutées en faisant la moyenne des 15 valeurs des affectations correspondantes. Dans un mode de réalisation, des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être exécutées en ne retenant que la dernière des affectations reçues au cours du cycle et en stoppant 20 les autres affectations. Dans un mode de réalisation, des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être exécutées en ne retenant que la première des affectations reçues au cours du cycle et en stoppant 25 les autres affectations. Dans un mode de réalisation, des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être exécutées en ne retenant que la dernière D des affectations reçues au cours du cycle et en 30 maintenant les autres affectations dormantes, la plus ancienne d'entre elles prenant la place de D quand D se termine. Dans un mode de réalisation, les variables peuvent être modifiées par des commandes de durée non nulle 2910650 8 associant l'évaluation d'une fonction du temps à la valeur de la variable. On définit maintenant un mode de réalisation de 5 l'invention, en référence aux figures annexées : - la figure 1 illustre une vue schématique d'un mode de réalisation de l'invention ; - la figure 2 illustre un mode de fonctionnement de l'invention. 10 Dans un mode de réalisation, l'invention s'inscrit dans une architecture réseau fonctionnant sous protocole TCP/IP dans un environnement client/serveur. Ce dispositif se compose d'un terminal associé à un robot, capable de 15 communiquer en s'échangeant des données numériques par des moyens reposant sur une technologie de réseau informatique sans fil. Ce terminal est un ordinateur comprenant un processeur associé à des mémoires volatiles et non volatiles et à une interface réseau WIFI répondant à la 20 norme IEEE 802.11 (ISO/CEI 8802-11) pour la gestion et l'échange de données. Dans un autre mode de réalisation on peut avoir un PDA, un ordinateur portable, ou encore un téléphone mobile. Le robot comprend un microprocesseur 64 bits RISC 25 cadencé à 600Mhz couplé à trois composants mémoire différents : une mémoire non volatile d'une capacité de 64Mbits, - une mémoire de donnée d'une capacité de 32Mbits 30 sous la forme d'une petite carte, une mémoire volatile d'une capacité de 32Mbits. D'autre part le processeur de ce robot est associé à une interface réseau WIFI basée sur la norme IEEE 802.11. Ce robot est pourvu de servomoteurs répartis dans 2910650 9 différentes parties de son corps avec : - un au niveau de la bouche, référencé dans le procédé sous l'objet motorl, - trois pour les mouvements associés à la tête, 5 référencé dans le procédé sous les objets motor2, motor3, motor4, et d'autres servomoteurs pour des mouvements liés à la queue et à chacune des quatre pattes. 10 Par ailleurs ce robot comprend un certain nombre de capteurs tels que : - une caméra CCD couleur pour la vision référencé dans le procédé sous l'objet capteurl, 15 - un capteur infrarouge de distance au niveau de la tête référencé dans le procédé sous l'objet capteur2, et d'autres capteurs et/ou détecteurs de pression, tactiles, d'accélérations linéaires. 20 Un utilisateur à partir de l'ordinateur client peut contrôler et commander ce robot afin que celuici puisse effectuer tout type de mouvement pouvant se rapporter par exemple à un déplacement, à un changement de posture à partir de différentes étapes de commande. Ces différentes 25 étapes intègrent la gestion des servomoteurs et la lecture et/ou l'interprétation de signaux provenant de différents capteurs et détecteurs. Comme illustré à la figure 1, dans cet environnement 30 client/serveur, le robot traite, dans son rôle de serveur, les différentes requêtes de commande emanant de l'ordinateur client 1. Le rôle de serveur 2 est dévolu au robot afin de permettre à plusieurs clients de se connecter au robot simultanément. Une approche centralisée au niveau 2910650 10 du robot est nécessaire pour intégrer les ordres de ces différents clients. La communication entre les acteurs de cet environnement se faisant par une liaison sans fil. 5 Dans un autre mode de réalisation, la communication entre le serveur et le client peut être une communication directe inter-processus (IPC) ou une mémoire partagée si tous deux correspondent à des processus exécutés sur le robot, dans le même espace mémoire. 10 Dans notre mode de réalisation, l'invention se rapporte à un procédé de commande qui à partir d'une interface logicielle qu'on appellera ici le noyau URBI (nom commercial), compris sur le serveur 2, permet de gérer les 15 ressources matérielles et logicielles du robot et offre la possibilité aux différents composants de communiquer entre eux. De cette façon, il est capable d'interpréter et de traiter les différentes commandes émanant de l'ordinateur 20 client 1 afin que le robot puisse exécuter les mouvements ordonnés. Ces commandes peuvent comprendre des interactions complexes entre des capteurs 4. Dans la suite nous engloberons sous le terme capteur les notions de détecteur et/ou capteur. 25 Les différents mouvements effectués par le robot sont accomplis à partir des servomoteurs 3 dont la gestion et la coordination relève du traitement apporté, par le processeur associé à l'interface logicielle, aux données 30 recueillies de capteurs 4 et/ou de l'interface réseau WIFI avec des instructions de commande provenant de l'ordinateur client. 2910650 11 Chaque donnée émanant de capteurs 4 est enregistrée dans une variable appartenant à un objet intégré au noyau URBI hébergé sur le serveur 2. Un ensemble de commandes fournies par le serveur 2 au travers du noyau URBI 5 constituent les moyens de contrôle et de commande des servomoteurs, qui sont capables d'initier des mouvements divers et variés au robot, mais aussi des capteurs. Les données relatives à un capteur 4 peuvent être 10 récupérées par l'utilisateur à partir de l'ordinateur client 1 qui comprend un terminal de commande , fonctionnant par exemple sous protocole telnet , et dans lequel la commande suivante peut être saisie : 15 > capteur2.val ; avec capteur2 correspondant à l'objet lié au composant de mesure de distance par infrarouge, . sépare l'objet de ses attributs, val correspond à l'attribut contenant la valeur et ; correspond à un séparateur de 20 commande séquentiel indiquant ici que la commande doit être exécutée immédiatement. On peut préciser que d'autres attributs que val peuvent contenir la valeur effective de capteur 2, l'usage de val est une convention. Une fois saisie et validée par l'utilisateur, cette 25 commande est transmise à la mémoire volatile de l'ordinateur client 1 pour y être enregistrée. Le processeur de l'ordinateur va par la suite récupérer cette commande capteur2.val pour l'inclure dans une trame de données afin d'être transmise 5 au robot au travers de 30 composants d'entrée/sortie par l'interface réseau WIFI. À réception par le serveur 2, cette instruction de commande est extraite de la trame de données et ensuite traitée et interprétée par le noyau URBI. Le capteur 4 est interrogé 8, et ensuite il envoie une réponse 7 au serveur. Une fois 2910650 12 reçue le noyau URBI traite cette réponse et celle-ci est transmise 9 par la suite via le même processus à l'ordinateur client et apparaîtra dans le terminal de commande de la façon suivante : 5 [036901543:notag] 15.103026 Ceci signifie que pour le capteur infrarouge de distance capteur2 la position mesurée à l'instant 036901543 10 ms (milliseconde) depuis l'allumage du robot est de 15.103026.10-3m (mètre). Le robot peut à partir des différents servomoteurs 3 qu'il comporte, réaliser un ensemble de mouvements sur la 15 base de commandes saisies à partir du terminal de commande telnet présent sur l'ordinateur client 1. Le noyau URBI, que comprend le serveur 2, offre la possibilité de contrôler en parallèle l'exécution de 20 commandes 6 pour différents servomoteurs 3 du robot. Ce contrôle en parallèle est réalisé sans avoir nécessairement recours à l'utilisation de processus complexes de programmation multi-processus liés au système d'exploitation. 25 Le robot peut réaliser des mouvements linéaires parallèles à partir des moyens de commande et de contrôle saisis par l'utilisateur dans le terminal de commande de l'ordinateur client 1 sous la forme d'une instruction, incluant un contrôle parallèle, apte à piloter les 30 servomoteurs dont les objets sont motorl et motor2 et qui correspond a : > tagl : motorl.val = 120 time: 45s & (lière commande) 2910650 13 tag2 : motor2.val = 0 speed:11 , (2ième commande) at (motorl.val =-= 12) stop tag2 (3ième commande) avec : - tagl , tag2 correspondant à des marqueurs permettant d'identifier les commandes qui les suivent, - at correspondant à un détecteur d'évènements, 10 associé à une condition, - notag qui est un marqueur implicite associé à la troisième commande puisqu'aucun marqueur n'est présent avant at . Toute commande a donc un marqueur, soit explicite, soit implicite notag , 15 - : qui correspond à un séparateur entre le marqueur et sa commande, - motorl.val et motor2.val correspondant à deux variables de position de servomoteurs que l'on souhaite commander en parallèle, 20 - speed correspondant à un modificateur d'affectation précisant la vitesse à laquelle la valeur cible spécifiée après = doit être atteinte, - stop correspondant à une commande permettant de provoquer l'interruption d'une commande, 25 - stop tag2 qui sera déclenchée au moment où la condition associée à at sera vérifiée, - & qui permet d'associer deux commandes afin qu'elles puissent être exécutées simultanément et en démarrant au même instant, 30 - , signifiant que la troisième commande doit commencer en même temps ou après la seconde, - =-= correspondant à un comparateur flou prenant en compte les imprécisions liées à la mesure de la position du moteur. 5 2910650 14 On peut préciser que si on avait eu le caractère suivant I entre la première et la seconde commande cette dernière débuterait dès que la première serait terminée. 5 Cette première commande une fois reçue par le serveur 1 est enregistrée dans sa mémoire volatile et est ensuite traitée par le processeur associé au noyau URBI ce dernier étant stocké dans la mémoire non-volatile de ce serveur. Cette première commande engendre l'exécution par le robot 10 d'un mouvement sur la base d'un servomoteur 3 associé à la variable motorl.val en indiquant que cette variable doit atteindre la valeur 120 en 45s, en partant de la valeur actuelle qui n'est pas spécifiée. Simultanément, l'exécution de la deuxième commande initie un mouvement sur 15 le moteur associé à la variable motor2.val , de telle sorte que la valeur 0 est atteinte avec une vitesse de 11 deg/s. Les deux premières commandes démarrent rigoureusement au même instant, conformément à la sémantique du séparateur & et ont une durée dans le 20 temps de 45s pour la première, et le temps nécessaire pour atteindre la valeur 0 à la vitesse de 11 deg/s pour la seconde. La troisième commande démarrant en même temps ou après la seconde, induit que les deux exécutions peuvent se superposer temporellement ou pas. Les marqueurs permettent 25 de référencer les commandes associées c'est-à-dire les commandes indiquées après le : , et, éventuellement, de les interrompre à partir de la commande stop, de les geler à partir de la commande freeze ou de les bloquer à partir de la commande block de façon non limitative 30 ultérieurement. On peut remarquer que la virgule dans une commande est une version plus souple du séparateur & . On peut déduire que : 2910650 15 A,B implique que début (B) >= début(A) . Ceci signifie que B peut démarrer en même temps que A, cas d'égalité, ou bien à un quelconque moment après le début de A. En pratique, A est donc détaché du flot 5 d'exécution, puisque B peut démarrer à tout moment, indépendamment de l'état d'exécution de A. En comparaison avec & , où l'on a : A&B qui implique que début(B) début(A) , 10 c'est-à-dire que A et B doivent démarrer exactement au même moment. La première et la deuxième commande sont exécutées en parallèle en étant découpées en unités élémentaires 15 d'actions exécutées au cours de cycles. Le noyau URBI fonctionne par cycle d'exécution de durée ou période fixe, définie à l'avance. En prenant 32ms comme période, durant chaque cycle, les instructions en cours et non encore terminées sont avancées dans leur exécution d'un pas de 20 temps égal à cette période du cycle. Pour une variable placée sous le contrôle d'une évolution linéaire avec le modificateur speed valant 10 (deg/s), chaque cycle modifiera cette variable de 10 fois 32ms (milliseconde). Cette approche du parallélisme est différente de celle que 25 l'on retrouve au niveau d'un système d'exploitation, basé sur des processus, car le noyau URBI agit directement au niveau des instructions, et non pas au niveau du code binaire. L'avantage est un contrôle plus fin du flot d'exécution, au niveau de la commande et non pas au niveau 30 du programme. La progression d'une variable d'un cycle à l'autre est, dans les commandes précédentes, linéaire, c'est-à-dire que chaque cycle modifie la variable d'une quantité fixe, en particulier dans le cas de la première et deuxième commande. Dans le cas général, cette progression 2910650 16 peut être quelconque, en particulier lorsque des commandes sinusoïdales sont utilisées, comme dans la commande suivante : 5 > motor3.val = 12 sin:15s ampli:24, avec sin qui correspond à un modificateur sinusoïdal indiquant la période de la variation sinusoïdale centrée autour de la valeur 12, et ampli qui correspond à un modificateur d'amplitude précisant l'amplitude de la 10 variation sinusoïdale autour de cette valeur 12. Cette commande génère une oscillation sinusoïdale centrée en 12, d'amplitude 24 et de période 15s (seconde). Elle a une durée infinie et ne se termine jamais, la valeur de motor3.val sera perpétuellement mise à jour à chaque 15 cycle. Ce type de variation sinusoïdale est particulièrement utile pour réaliser des cycles de marche pour des robots bipèdes ou quadrupèdes, en appliquant une ou plusieurs de ces commandes à chaque moteur des pattes afin de réaliser très simplement le mouvement périodique 20 correspondant à la marche souhaitée, en utilisant les capacités de superposition de commandes décrites précédemment (pages 6 à 7). Concernant la troisième commande, celle-ci met en place un mécanisme de déclenchement de commande 25 conditionnée par un test. C'est-à-dire que lorsque le test motorl.val=-=12 devient vrai, la commande stop tag2 est exécutée. Dans cette commande le comparateur =-= indique un test approximatif tel que a=-=b est équivalent à abs(b-a) delta + b->delta avec 30 abs désignant la valeur absolue au sens mathématique et -> delta une propriété de la variable, contenant une valeur d'écart type admissible pour cette variable. La commande stop tag2 a pour effet d'arrêter la deuxième commande portant sur la variable motor2.val , Si elle 2910650 17 est encore en cours d'exécution, de cette façon elle n'atteindra pas sa valeur finale. Le test décrit dans la troisième commande n'est pas nécessairement réévalué à chaque cycle mais uniquement lorsque les variables ou 5 évènements le constituant changent. La variable motorl.val impliquée dans le test change à chaque cycle car elle est liée à la valeur du servomoteur qui évolue constamment. En revanche, pour une commande du type at (ma variable-1)". celle-ci ne sera réévaluée que lorsque 10 la valeur de ma variable est modifiée, soit par un programme soit par l'utilisateur de l'ordinateur client 1. Les variables constituant le test contiennent donc une série de pointeurs vers les commandes du type de at (comme whenever ou waituntil ) de telle sorte 15 qu'elles puissent commander la réévaluation du test lorsqu'elles sont modifiées. Cette réévaluation n'aura lieu au plus qu'une fois par cycle, les demandes de réévaluations intervenant au cours d'un même cycle étant accumulées et exécutées uniquement à la fin du cycle. Lors 20 de l'évaluation d'un test portant sur des variables impliquant plusieurs moteurs, celle-ci sera en principe requise plusieurs fois par cycle, une fois par moteur, mais ne sera en pratique évaluée qu'une seule fois. De manière générale lorsque des commandes exécutées en 25 parallèle agissent simultanément sur une même variable var , celle-ci dispose de six modes de superposition pour gérer ces affectations concurrentes. On dira que des affectations sont concurrentes lorsqu'elles surviennent au cours d'un même cycle. Cette capacité à gérer les 30 affectations concurrentes est essentielle dans un robot où les servomoteurs peuvent recevoir en permanence plusieurs ordres contradictoires en parallèle, ou pour réaliser des mouvements complexes par superposition, à la manière d'une série de calques. Les six modes de superposition sont : 2910650 18 - add pour lequel les affectations concurrentes sont additionnées, - mix pour lequel les affectations concurrentes sont moyennées, 5 - queue pour lequel les affectations concurrentes sont traitées dans l'ordre d'arrivée, l'une après l'autre, - discard pour lequel les affectations concurrentes sont ignorées si une affectation est déjà en 10 cours, - cancel pour lequel toute nouvelle affectation concurrente prend la place de celles préexistantes, - normal pour lequel toute nouvelle affectation concurrente prend la priorité sur celles préexistantes, 15 celles-ci pouvant continuer à s'exécuter en tâche de fond, jusqu'à ce que cette nouvelle affectation se termine. Ces modes de superposition spécifient la façon dont les affectations concurrentes sont agrégées. Le noyau URBI compris sur le serveur, comporte un 20 moyen permettant de gérer ces affectations pour une variable donnée. Ce moyen correspond à la propriété blend . Dans ce contexte on a la commande suivante saisie par l'utilisateur : > x->blend = add; 25 > x=1 & x=5; // x vaut 6 avec x correspondant à une variable quelconque. Si x est une variable associée à la valeur d'un servomoteur, on peut superposer la commande servomoteur ordonnant au moteur d'atteindre la valeur 1 à celle 30 ordonnant d'atteindre la valeur 5, et permet de gérer le conflit potentiel en additionnant ces deux valeurs. 2910650 19 Pour l'exécution d'un mouvement nécessitant des poses par le robot, l'utilisateur saisit dans le terminal de commande : > motorl.val = 1 ; wait (12s) ; motor2.val = 4 ; 5 avec : wait qui correspond à une commande de pose, 12s qui correspond au temps d'attente désiré et motorl.val , motor2.val qui correspondent aux variables associées aux moteurs 1 et 2 situés au niveau de la tête. 10 La valeur ou variable spécifiée entre parenthèses après wait sera évaluée à chaque cycle pour comparer le temps actuel avec l'instant d'arrêt, paramétré à 12s après le démarrage de la commande. De manière générale, toute commande à durée non nulle est segmentée en unités 15 élémentaires d'une durée égale à celle d'un cycle et elle est exécutée pas à pas, cycle après cycle. Elle peut avoir une durée finie ou infinie. La tâche consistant à exécuter un cycle sur une commande donnée peut être répartie sur plusieurs processeurs, par un mécanisme logiciel de 20 répartition de la charge de travail dans des pools . On entend par pool une entité logicielle regroupant plusieurs processus logiques qui ne sont pas exécutés en parallèle au sein du pool mais en série les uns par rapport aux autres. Les pools dans l'invention sont en revanche 25 exécutés en parallèle les uns par rapport aux autres. L'avantage d'un pool est d'avoir une granularité plus importante que les processus qu'il héberge. Il serait coûteux dans l'état actuel des techniques d'exécuter en parallèle plusieurs millions de micro-cycles d'instruction, 30 mais il est aisé d'exécuter un millier de pools contenant chacun plusieurs milliers de processus logiques, tout en ne sacrifiant pas les avantages du parallélisme. 2910650 20 A la figure 2 est illustrée par une étape de démarrage 10 du robot, ainsi que des étapes de perception, d'exécution 14 et de commande 24 d'un équipement matériel. Dans l'étape de perception 11 le robot est dans un état 12 5 d'attente de commande. Cet état correspond au temps tO de référence initial de telle sorte que t=tO. Cette étape de perception 11 consiste en une acquisition de paramètres de fonction à exécuter se rapportant à un ensemble de commande 13 comme par exemple les commandes suivantes que nous avons 10 vues précédemment : > tagl : motorl.val = 120 time: 45s & (lière commande) tag2 : motor2.val = 0 speed:11 , (2ième commande) 15 at (motorl.val =-= 12) stop tag2 (3ième commande) Elle consiste aussi en une acquisition de paramètres interne provenant de données précédemment traitées et de 20 capteurs 4. L'étape d'exécution 14 se rapporte au lancement 15, 16, 17 simultané de la première, deuxième et troisième commande et aux exécutions en parallèles de fonctions de cycles d'action. Ces exécutions sont réalisées par un 25 ordonnanceur qui effectue une segmentation automatique en microcycles MiIj des commandes ou instructions Ij à exécuter en parallèle émulé avec i un nombre entier désignant le numéro du cycle, j un nombre entier compris entre 1 et N, 30 N le nombre de commandes élémentaires à exécuter en parallèle à l'instant i. Un noyau informatique exécute successivement les N micro-cycles MiIj de chacune des instructions I 2910650 21 Ainsi l'exécution 18 d'un microcycle MoI3 débute par la mise à jour d'une valeur d'une variable de position motorl.val à partir du capteur motorl afin de vérifier l'opération de comparaison présent dans la troisième 5 commande. Si cette opération est vérifiée cette troisième commande est exécutée et consiste ici à terminer la deuxième commande 19 et ensuite à passer à l'exécution du micro cycle suivant. A l'inverse si cette opération n'est pas vérifiée on passe directement à l'exécution du 10 microcycle suivant. L'exécution du microcycle MoI2 suivant débute par la mise à jour d'une valeur se rapportant à une variable motor2.val contenue dans la deuxième commande afin de vérifier l'opération motor2.val=0. Si l'opération est vérifiée la deuxième commande est exécutée en terminant la 15 deuxième commande 19 et ensuite on passe à l'exécution du micro cycle suivant. Si cette opération n'est pas vérifiée on passe directement à l'exécution du microcycle suivant. L'exécution du dernier microcycle MoI1 débute par la mise à jour de la valeur de la variable de position 20 motorl.val comprise dans la première commande et par la vérification de l'opération t>t0+45s se rapportant à cette première commande.Si cette opération est vérifiée la première commande est terminée et une mise à jour des capteurs motorl et motor2 est effectuée et un nouveau cycle 25 d'action est débuté afin d'exécuter les micro-cycles des instructions non achevées lors de l'étape précédente. L'étape de commande d'un équipement matériel consiste à terminer la première et la deuxième commande. 30 Le système d'exploitation sur la base duquel fonctionne le procédé n'intervient pas directement pour réaliser ce parallélisme des différentes commandes du noyau URBI, reposant sur le mécanisme de cycles décrit précédemment, mais il peut éventuellement intervenir pour 2910650 22 répartir l'activité des différents pools en alternant leur fenêtre d'exécution au niveau du code binaire les constituant, ce qui est un procédé technique connu. REVENDICATIONS 1. Procédé de commande d'un équipement matériel comprenant un système d'exploitation comportant : - des étapes de perception (11) consistant en l'acquisition de paramètres; - des étapes d'exécution (14) de fonctions en fonction desdits paramètres lors d'un cycle d'action ; caractérisé en ce qu'au moins une desdites étapes d'exécution (14) comprend : - une segmentation automatique en microcycles MiIj (21,20,18) d'une pluralité d'instructions Ij (13) se rapportant auxdites fonctions avec : • i étant un nombre entier désignant le numéro du cycle, • j étant un nombre entier compris entre 1 et N, • N étant le nombre de commandes élémentaires à exécuter en parallèle à l'instant i, par un ordonnanceur appartenant à un noyau informatique distinct du noyau du système d'exploitation, et - une exécution de N micro-cycles MiIj (21,20,18) de chacune desdites instructions Ij (13), puis des N micro-cycles Mi+1Ii de chacune desdites instructions Ij non achevées lors d'un cycle d'action précédent, par ledit noyau informatique dudit équipement matériel. 2. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce qu'une distribution des micro-cycles (21,20,18) à exécuter est réalisée sur un ensemble de noyaux disponibles exécutés en 2910650 24 parallèles et initialisés au démarrage d'un noyau principal. 3. Procédé de commande d'un équipement matériel 5 selon les revendications 1 ou 2 précédente caractérisé en ce que lesdits noyaux exécutés en parallèles sont répartis sur plusieurs processeurs, l'exécution entre lesdits processeurs étant ordonnancée par le système d'exploitation. 10 4. Procédé de commande d'un équipement matériel selon les revendications 1 ou 2 caractérisé en ce que certains des micro-cycles (21,20,18) correspondent à l'intégralité de l'instruction lorsque celle- ci a un temps 15 d'exécution nul. 5. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que l'instruction peut être découpée en T/dt micro-cycles 20 (21,20,18) pour dt étant le temps d'exécution d'un micro-cycles (21,20,18) et T le temps d'exécution de la commande. 6. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que le 25 microcycle (21,20,18) à l'instant t pour une instruction I (13) soit défini par l'ensemble des opérations nécessaires pour faire évoluer des variables internes ou externes liées à l'instruction I entre l'instant t et t+dt. 30 7. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que toute commande est préfixée d'au moins un marqueur. 2910650 25 8. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que toute commande préfixée par un marqueur M peut être stoppée par un signal spécifique portant sur le marqueur M, ce 5 signal pouvant être émis par une instruction. 9. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que toute commande préfixée par un marqueur M peut être 10 suspendue temporairement par un signal spécifique portant sur le marqueur M, ce signal pouvant être émis par une instruction. 10. Procédé de commande d'un équipement matériel 15 selon la revendication précédente caractérisé en ce que toute commande préfixée par un marqueur M peut être réactivée après une suspension temporaire par un signal spécifique portant sur le marqueur M, ce signal pouvant être émis par une instruction. 20 11. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que toute classe commande préfixée par un marqueur M peut être stoppée par un signal spécifique pouvant être émis par une 25 instruction portant sur le marqueur M, ce signal inhibant l'exécution de toute commande ultérieure associée au marqueur M. 12. Procédé de commande d'un équipement matériel 30 selon la revendication précédente caractérisé en ce que l'inhibition d'un marqueur M peut être levée par l'émission d'un signal spécifique, ledit signal spécifique pouvant être émis par une instruction portant sur le marqueur M. 2910650 26 13. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que les marqueurs peuvent être organisés dans une hiérarchie d'héritage. 14. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que l'utilisation d'un marqueur M s'étend à tout marqueur M' héritier. 10 15. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que des instructions sont susceptibles de déclencher une ou plusieurs commandes lorsqu'un test devient vrai, test 15 portant sur des conditions sur des variables et/ou des évènements. 16. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que des 20 instructions sont susceptibles de déclencher une ou plusieurs commandes lorsqu'un test est vrai, test portant sur des conditions sur des variables et/ou des évènements. 17. Procédé de commande d'un équipement matériel 25 selon la revendication précédente caractérisé en ce que des instructions sont susceptibles de se terminer lorsqu'un test devient vrai, test portant sur des conditions sur des variables et/ou des évènements. 30 18. Procédé de commande d'un équipement matériel selon la revendication précédente caractérisé en ce que des instructions sont susceptibles de se suspendre pendant qu'un test est vrai, test portant sur des conditions sur des variables et/ou des évènements. 5 2910650 27 19. Procédé de commande d'un équipement matériel selon l'une des revendications 15 à 18 caractérisé en ce que les dites instructions s'enregistrent auprès des 5 variables et évènements composant le test qui leur est associé de telle sorte que toutes modifications des dites variables et évènements provoquent au moins une réévaluation du test à la fin du cycle. 10 20. Procédé de commande d'un équipement matériel selon l'une quelconque des revendications précédentes caractérisé en ce que les données utilisées par les instructions peuvent être regroupés dans des structures hiérarchiques appelées objet et regroupant des variables 15 et/ou des fonctions et/ou des procédures et/ou des évènements portant sur ces variables. 21. Procédé de commande d'un équipement matériel selon l'une quelconque des revendications précédentes 20 caractérisé en ce que lesdits objets peuvent être regroupés dans des ensembles appelés groupe. 22. Procédé de commande d'un équipement matériel selon l'une quelconque des revendications précédentes 25 caractérisé en ce que les groupes peuvent être hiérarchisés dans une hiérarchie distincte de celle des objets qu'ils contiennent. 23. Procédé de commande d'un équipement matériel 30 selon l'une quelconque des revendications précédentes caractérisé en ce que des fonctions ou procédures exécutées au niveau d'un groupe peuvent être parallèlement exécutées sur tout objet du groupe ou récursivement sur tout sous groupe. 2910650 28 24. Procédé de commande d'un équipement matériel selon l'une quelconque des revendications précédentes caractérisé en ce que des actions sur des variables au 5 niveau d'un groupe peuvent être parallèlement exécutées sur tout objet du groupe ou récursivement sur tout sous groupe. 25. Procédé de commande d'un équipement matériel selon l'une quelconque des revendications précédentes 10 caractérisé en ce que des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être exécutées l'une après l'autre. 26. Procédé de commande d'un équipement matériel 15 selon l'une quelconque des revendications précédentes caractérisé en ce que des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être exécutées en additionnant les valeurs des affectations correspondantes. 20 27. Procédé de commande d'un équipement matériel selon l'une quelconque des revendications précédentes caractérisé en ce que des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être 25 exécutées en faisant la moyenne des valeurs des affectations correspondantes. 28. Procédé de commande d'un équipement matériel selon l'une quelconque des revendications précédentes 30 caractérisé en ce que des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être exécutées en ne retenant que la dernière des affectations reçues au cours du cycle et en stoppant les autres affectations. 2910650 29 29. Procédé de commande d'un équipement matériel selon l'une quelconque des revendications précédentes caractérisé en ce que des affectations concurrentes d'une 5 variable effectuées au cours d'un même cycle peuvent être exécutées en ne retenant que la première des affectations reçues au cours du cycle et en stoppant les autres affectations. 10 30. Procédé de commande d'un équipement matériel selon l'une quelconque des revendications précédentes caractérisé en ce que des affectations concurrentes d'une variable effectuées au cours d'un même cycle peuvent être exécutées en ne retenant que la dernière D des affectations 15 reçues au cours du cycle et en maintenant les autres affectations dormantes, la plus ancienne d'entre elles prenant la place de D quand D se termine. 31. Procédé de commande d'un équipement matériel 20 selon l'une quelconque des revendications précédentes caractérisé en ce que les variables peuvent être modifiées par des commandes de durée non nulle associant l'évaluation d'une fonction du temps à la valeur de la variable. 25