CARTE ELECTRONIQUE ET SYSTEME COMPORTANT UNE PLURALITE

DE TELLES CARTES

L'invention porte sur une carte électronique destinée en particulier à l'automatique, la robotique et l'informatique industrielle. L'invention porte également sur un système comportant une pluralité de telles cartes reliées par un bus de communication et utilisées pour piloter des actionneurs, des capteurs ou d'autres dispositifs externes. Un tel système peut être utilisé comme système de commande embarqué d'un robot.

Jusqu'à présent, les besoins industriels en matière d'automatisation sont satisfaits essentiellement par des dispositifs classiques de type contrôleur d'axe ou servo-contrôleur.

Les contrôleurs d'axe se présentent typiquement sous forme de cartes d'extension pour ordinateur personnel ou pour bus industriel. Les servo-contrôleurs se distinguent des contrôleurs d'axe en ce qu'ils intègrent un circuit de puissance permettant une connexion directe avec un actionneur de type moteur électrique.

Les solutions développées sur la base de ces dispositifs sont volumineuses, ce qui limite la possibilité de développer des systèmes embarqués, par exemple sur des robots autonomes de petites dimensions. De plus, les logiciels intégrés aux contrôleurs d'axe du marché sont généralement orientés vers des applications industrielles de type machines outils. De ce fait, les types de commandes pouvant être mises en œuvre sont limitées et ne conviennent pas aux applications robotiques.

Les quelques solutions disponibles, basées sur des systèmes d'exploitation multitâche temps réel, qui conviennent pour des applications robotiques avancées, sont très onéreuses.

Le développement des microcontrôleurs, intégrant des microprocesseurs dédiés aux applications de commande, des mémoires vives et mortes, des interfaces de communication et, souvent, des convertisseurs analogique/numérique et numérique/analogique, est en train de faire évoluer le secteur de l'informatique industrielle.

Par exemple, la société Jeffrey Kerr LLC a développé une carte de commande basée sur un microcontrôleur PIC18F2331 et qui présente des dimensions limitées et une certaine flexibilité d'utilisation. Un document décrivant cette carte est accessible sur Internet à l'URL www.jrkerr.com/picsrvsc.pdf.

Néanmoins, cette carte ne convient pas à la réalisation d'un système de commande modulaire et décentré, notamment en raison de ses capacités de communication relativement limitées.

L'invention vise à surmonter au moins certains des inconvénients précités de l'art antérieur. Plus précisément, elle vise à permettre la réalisation d'un système de commande modulaire constitué par une pluralité de cartes du même type, ou de types similaires, susceptibles de communiquer et coopérer entre elles sous la supervision d'un ordinateur extérieur. Conformément à l'invention, ce but est atteint par une carte électronique comportant : un microcontrôleur ; des premiers moyens d'interface avec un bus de communication ; et des deuxièmes moyens d'interface avec un ordinateur de supervision ; ledit microcontrôleur étant programmé pour : (a) recevoir, à travers lesdits deuxièmes moyens d'interface, des premières commandes provenant dudit ordinateur de supervision ;

(b) extraire desdites commandes une information d'adressage et, en fonction de ladite information d'adressage, exécuter lesdites premières commandes ou bien les transmettre sur ledit bus de communication par l'intermédiaire desdits premiers moyens ; et

(c) recevoir dudit bus communication, par l'intermédiaire desdits premiers moyens d'interface, des deuxièmes commandes et les exécuter.

Selon des modes de réalisation avantageux de l'invention : - Ledit microcontrôleur peut également être programmé pour :

(d) transmettre ou recevoir, en fonction d'un paramètre de configuration, un signal de synchronisation sur ledit bus de communication par l'intermédiaire desdits premiers moyens d'interface ; et (e) exécuter au moins certaines desdites premières ou deuxièmes commandes seulement lors de la réception ou de la transmission dudit signal de synchronisation.

La carte peut comporter également des troisièmes moyens d'interface pour permettre audit microcontrôleur de communiquer avec un dispositif extérieur.

Au moins certaines desdites premières ou deuxièmes commandes peuvent comporter des consignes de pilotage d'un actionneur relié à la carte par l'intermédiaire desdits troisièmes moyens d'interface, l'exécution de ces commandes comportant la génération par ledit microcontrôleur d'un signal de pilotage dudit actionneur.

Un mécanisme d'interruption peut être prévu pour permettre l'exécution en temps réel desdites commandes comportant des consignes de pilotage.

Ledit microcontrôleur peut également être programmé pour, en fonction d'un paramètre de configuration :

(f) générer un signal d'acquittement de l'exécution d'une commande comportant une consigne de pilotage, et le transmettre sur ledit bus de communication par l'intermédiaire desdits premiers moyens d'interface ; ou (g) recevoir des signaux d'acquittement transmis par d'autres cartes sur ledit bus de communication.

Ledit microcontrôleur peut également être programmé pour :

(h) transmettre ou recevoir par l'intermédiaire desdits premiers moyens d'interface une requête de services dirigée ou provenant d'une autre carte ;

(i) exécuter la ou les requêtes de services reçues par l'intermédiaire desdits premiers moyens d'interface ; et

(j) transmettre ou recevoir par l'intermédiaire desdits premiers moyens d'interface un message de réponse indiquant qu'un service requis a été exécuté.

Ledit microcontrôleur peut être programmé pour exécuter les services correspondant auxdites requêtes en temps non-réel.

Les premiers moyens d'interface peuvent être adaptés pour permettre audit microcontrôleur de communiquer avec d'autres cartes du même type à travers un bus de type CAN.

Les deuxièmes moyens d'interface peuvent être de type sériai.

L'invention porte également sur un système comportant : un bus de communication et une pluralité de cartes électroniques telles que décrites ci-dessus reliées audit bus de communication per l'intermédiaire des premiers moyens d'interface respectifs ; au moins une desdites cartes étant également reliée à un ordinateur de supervision respectif par l'intermédiaire de ses deuxièmes moyens d'interface.

En particulier, lesdites cartes peuvent être identiques entre elles, du point de vue aussi bien matériel que logiciel, à l'exception d'un ou plusieurs paramètres de configuration.

Avantageusement, dans un tel système, une et une seule desdites cartes peut être configurée pour transmettre un signal de synchronisation sur ledit bus de communication par l'intermédiaire de ses premiers moyens d'interface ; et au moins une autre desdites cartes peut être configurée pour recevoir ledit signal de synchronisation par l'intermédiaire de ses premiers moyens d'interface ; lesdites cartes pouvant être programmées pour exécuter au moins certaines desdites premières ou deuxièmes commandes seulement lors de la réception ou de la transmission dudit signal de synchronisation.

L'invention porte également sur un système robotique comportant un tel système de commande embarqué. Avantageusement, au

moins une première carte électronique peut être reliée à un actionneur tandis qu'au moins une deuxième carte électronique peut être reliée à un capteur.

D'autres caractéristiques, détails et avantages de l'invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d'exemple et qui représentent, respectivement :

La figure 1 , l'architecture d'un système de commande selon l'art antérieur.

La figure 2, l'architecture d'un système de commande selon l'invention ; et La figure 3, l'architecture fonctionnelle d'une carte électronique selon un mode de réalisation de l'invention ;

La figure 1 représente un système de commande qui est décrit plus en détail dans le document précité émanant de la société Jeffrey Kerr LLC. Ce système comporte un superviseur SUP et une pluralité de cartes de commande C'1 , C'2..., chacune pilotant un actionneur A1 , A2 ou un autre dispositif externe. Le superviseur et les cartes sont reliés par un bus de communication BUS'. Le système fonctionne sur la base d'un protocole de type maître-esclave : le superviseur transmet aux cartes de commande des paquets d'instructions ; les cartes retournent au superviseur des informations d'état sur une ligne de communication séparée, et gèrent les collisions de données sur cette ligne. Aucune communication entre cartes n'est prévue si ce n'est, au démarrage, pour l'attribution d'une adresse unique à chaque carte.

La figure 2 illustre l'architecture d'un système de commande selon l'invention. Ce système est construit autour d'un bus de communication

BUS auquel sont reliées, de manière bidirectionnelle, des cartes électroniques C1 , C2, C3, etc. Le bus BUS peut être un bus de terrain, par exemple un bus CAN. Une des cartes (C1) est également reliée à un ordinateur de supervision SUP par l'intermédiaire d'un moyen de communication séparé, tel qu'une liaison série. En outre, chaque carte (ou, parfois, seulement certaines d'entre elles) est connecté à un dispositif externe, qu'elle pilote. Par exemple, les cartes C1 et C2 sont reliées à un

actionneur (moteurs électriques A1 , A2 respectivement) par l'intermédiaire d'une carte de puissance CP1 , CP2, tandis que la carte C3 est reliée directement à un capteur (caméra numérique CA3). Il est préférable que les cartes C1 , C2 n'intègrent pas le circuit de puissance CP1 , CP2 : cela permet de limiter leur encombrement et leur coût et de rendre leur utilisation plus flexible. En effet, selon un mode préféré de réalisation de l'invention, toutes les cartes du système sont identiques, aussi bien du point de vue matériel que logiciel, à l'exception d'un certain nombre de paramètres de configuration. L'ordinateur de supervision SUP transmet à la carte C1 des commandes de haut niveau par l'intermédiaire de la liaison série SER. Ces commandes de haut niveau peuvent être, par exemple, des consignes de pilotage des actionneurs A1 , A2, ou des requêtes d'envoi de données adressées à la caméra CA3. La carte C1 , en plus de piloter l'un des actionneurs du système, accomplit un rôle de routage : elle décode les commandes reçues et décide si elles lui sont destinées ou pas. Dans le premier cas, elle les exécute ; par exemple, elle génère un signal de pilotage de l'actionneur A1 lui permettant d'atteindre la consigne. Dans le deuxième cas, elle les transmet (avec l'information d'adressage correspondante) sur le bus BUS. Par exemple, lorsque le superviseur SUP envoie une consigne de position pour l'actionneur A2, la carte C1 reconnaît que cette commande ne lui est pas destinée et la transmet sur le bus ; toutes les cartes du système lisent la commande transmise, mais seule la carte C2 se reconnaît comme destinataire, décode la commande et l'exécute. La conversion d'une commande de consigne en un signal de pilotage peut s'effectuer, par exemple, au moyen d'un contrôleur de type PID (proportionnelle - intégrale - dérivée).

Après avoir exécuté (ou avoir essayé d'exécuter) la commande de pilotage, la carte émet un message d'acquittement, qui remonte au superviseur par l'intermédiaire de la carte C1. Par exemple, une carte peut communiquer, au moyen de son message d'acquittement, que la commande n'a pas pu être exécutée à cause d'une défaillance ; le

superviseur peut réagir en arrêtant le système ou en le ramenant dans une position de sécurité, et en déclenchant une alarme.

Toutes les commandes transmises aux cartes ne sont pas nécessairement orientées au pilotage du dispositif externe : les cartes peuvent également exécuter des opérations de pur traitement des données

(par exemple, des calculs). En particulier, une carte quelconque peut demander à une autre carte d'accomplir un « service » : pour ce faire, elle envoie une requête sur le bus. La réponse lui parviendra également par. l'intermédiaire du bus. En règle générale, les commandes de pilotage doivent être accomplies en temps réel, à la différence des requêtes de services. Cela est assuré, d'une manière connue en soi, par un mécanisme d'interruption.

Dans certaines applications, plusieurs actionneurs doivent être pilotés de manière synchronisée. C'est le cas, par exemple, d'un robot marcheur, qui doit actionner de manière coordonnée plusieurs articulations.

Pour cela, un signal de synchronisation généré par l'une des cartes du système (typiquement, mais pas nécessairement, la carte C1 reliée au superviseur) est transmis par l'intermédiaire du bus BUS. Dans ce mode de réalisation de l'invention, les cartes sont programmées pour ne démarrer l'exécution d'une instruction de consigne que lors de la réception d'un signal de synchronisation (lors de son émission, dans le cas de la carte de synchronisation).

Il est intéressant de noter que dans un système il est possible de prévoir plusieurs superviseurs, reliés à des cartes différentes (à condition de veiller à éviter des instructions contradictoires ou à prévoir un mécanisme de priorité). En revanche, en général, une et une seule carte pourra être habilitée à transmettre le signal de synchronisation.

Avantageusement, toutes les cartes sont identiques, et en particulier elles sont programmées aussi bien pour envoyer que pour recevoir un signal de synchronisation. Cependant, un paramètre de configuration peut être prévu pour activer ou désactiver la fonction de génération (ou de réception, respectivement) de ce signal.

II est intéressant de noter que le protocole de communication mis en œuvre n'est pas de type maître-esclave : toutes les cartes sont à la fois maîtres et esclaves.

De préférence, les cartes du système sont adaptées pour interpréter des commandes de haut niveau transmises par le superviseur, et les convertir en séquences d'instructions de plus bas niveau, directement exécutables. De cette manière, la « programmation » du système par l'utilisateur (qui a accès direct seulement au superviseur) est grandement facilitée. Le système de la figure 2 trouve application, par exemple, dans le cas d'un robot autonome. Dans ce cas : la liaison série SER peut être sans fil ; certaines des cartes peuvent piloter des actionneurs pour permettre le déplacement du robot, au moyen de roues ou jambes, ou des manipulations au moyens de bras ou autres outils ; d'autres cartes peuvent piloter des capteurs tels que des caméras ou des sonars pour détecter des obstacles ; le superviseur peut se limiter à transmettre des consignes de directions de très haut niveau (par exemple : avancer d'une certaine distance dans une certaine direction à une certaine vitesse), déterminées sur la base des signaux reçus des capteurs ; la carte de synchronisation peut convertir ces consignes de très haut niveau en consignes de plus bas niveau et les répartir entre les cartes associées aux différents actionneurs ; - si la charge de computation requise est trop importante, la carte de synchronisation peut la partager avec les autres cartes au moyen de requêtes de services.

L'architecture de commande de la figure 1 , beaucoup plus rigide, ne permettrait pas la mise en œuvre de ce procédé de pilotage. Pour réaliser des robots autonomes il est nécessaire de piloter un grand nombre de degrés de liberté par des cartes embarquées. Ces cartes doivent donc être de petites dimensions et économiques. Pour cette

raison, une carte selon l'invention aura de préférence une structure extrêmement simple. Elle sera constituée essentiellement par un microcontrôleur (par exemple, le microcontrôleur dsPIC30f4011 fabriqué par la société Microchip), par des premiers moyens d'interface avec le bus de communication BUS, de deuxièmes moyens d'interface avec l'ordinateur de supervision SUP, des troisièmes moyens d'interface pour permettre audit microcontrôleur de communiquer avec un dispositif extérieur (actionneur, capteur, etc.) et éventuellement les fonctionnalités électroniques « secondaires » usuelles (alimentation, diagnostic, protection...). Le microcontrôleur exécute un programme, enregistré sur une mémoire non-volatile interne ou externe, mettant en œuvre l'architecture fonctionnelle illustré sur la figure 3.

La figure 3 montre les premier moyens d'interface 11 , reliant la carte C à un bus de terrain BUS de type CAN, les deuxièmes moyens d'interface 12, la reliant à un port série de type RS232 et les troisièmes moyens d'interface 13, la reliant à une carte de puissance CP pour le pilotage d'un actionneur A. Les moyens d'interface 11 , 12 et 13 sont à la fois matériels et logiciels.

Lorsqu'un signal entrant est présent à l'interface 12, une routine de capture s'active (bloc 1) et, le cas échéant, une interruption est déclenchée. Le signal capturé est ensuite décodé (bloc 2) pour en extraire une instruction, ou une partie d'une instruction complexe, qui est passée à un assembleur - ordonnanceur de commandes 6.

De même, la présence d'un signal entrant à l'interface 11 active une routine de capture de message et génération d'interruption (bloc 3), ainsi que de capture d'un signal de synchronisation. En effet, le signal de synchronisation ne doit pas subir le même traitement que les messages de commande, mais être immédiatement envoyé au générateur de consignes GC, dont le fonctionnement sera décrit plus loin. Le traitement en temps réel du signal de synchronisation est rendu possible par la routine d'interruption du bloc 3.

Les instructions reçues des premiers moyens d'interface 11 sont décodées (bloc 4) et reconnues. Il peut s'agir en particulier : de messages de commande de services ou d'opérateurs

(5) ; - de messages d'acquittement de consigne (7) ; de messages de consigne (8) ; ou de messages dits « banalisés » (9).

D'une manière connue en soi, les commandes de services sont constituées par des codes de commande et par des opérateurs. Ces différents éléments sont reçus par paquets, pas nécessairement de manière ordonnée. En outre, différentes commandes peuvent être reçues simultanément. D'où la nécessité d'un assembleur-ordonnanceur pour reconstituer les commandes complètes et déterminer leur ordre d'exécution.

Les commandes reconstituées, qu'elles aient été reçues par les premiers ou les deuxièmes moyens d'interface, sont communiquées à un programme serveur qui exécute les services requis (généralement, en temps non réel).

Les messages d'acquittement de consigne (bloc 7) reçus par la carte directement interfacée avec le superviseur sont transmis directement à un bloc 13 d'attente d'acquittement prévu dans un distributeur de consignes DC, actif uniquement dans cette carte.

Les messages de consigne (bloc 8) reçus par la carte sont transmis directement à un bloc 10 d'un générateur de consigne GC, où ils sont stockés. Ce bloc 10, passe la valeur de la prochaine consigne à exécuter à un bloc de pilotage 22 (contrôleur PID, par exemple) qui pilote un actionneur A par l'intermédiaire des troisièmes moyens d'interface 13 et éventuellement d'un circuit de puissance CP. A son tour, l'actionneur A entraîne un axe AX par l'intermédiaire d'une liaison mécanique, généralement de type élastique. Le pilotage de l'axe se fait en boucle fermée : pour cela le bloc de pilotage 22 reçoit en entrée des signaux de retour SR1 , SR2 indicatifs de la position et/ou de la vitesse de l'axe (SR1), du courant de commande de l'actionneur A (SR2), etc.

II est intéressant de noter que la carte reliée directement au superviseur peut elle-même piloter un axe : elle reçoit donc du superviseur

SUP des consignes qui lui sont directement destinées et que ne doivent pas être distribuées par l'intermédiaire du bus BUS. Sur la figure 3, cela est représenté par la liaison en trait pointillé entre les blocs 2 et 8.

Les messages « banalisés » 9 sont les réponses aux requêtes de services. Ils peuvent contenir, par exemple, le résultat d'un calcul. La carte qui est directement reliée au superviseur reçoit les messages banalisés générés par les autres cartes et les transmet audit superviseur par l'intermédiaire de la liaison série, après les avoir stockés temporairement dans une messagerie 20. Les deux octogones marqués « 1 » matérialisent la liaison fonctionnelle entre la messagerie 20 et le contrôleur RS232 (12), pour ne pas alourdir la figure.

La messagerie 20 reçoit également les messages banalisés engendrés par le programme serveur (bloc ES) de ladite carte.

Dans le cas des autres cartes, les messages banalisés sont transmis sur le bus par l'intermédiaire des premiers moyens d'interface 11 (voir bloc 18)

Le générateur de consigne GC, actif dans toutes les cartes, est essentiellement un générateur de rampe qui interpole la position de l'actionneur entre deux échantillons de consigne de position résultants des calculs de planification de la trajectoire. La génération de la rampe peut être lancée grâce au signal de synchronisation (voir la liaison fonctionnelle entre les blocs 3 et GC). En outre, le générateur de consigne GC comporte un bloc 11 d'émission et envoi d'un signal d'acquittement, indiquant si la consigne a été exécutée correctement. Les messages d'acquittement (bloc 17) sont à leur tour envoyés sur le bus par l'intermédiaire des moyens d'interface 11.

Un mécanisme d'interruption permet l'exécution des commandes de consigne en temps réel, en leur donnant la priorité sur l'exécution des requêtes de services.

Comme expliqué plus haut, le distributeur de consignes DC est actif seulement dans le cas d'une carte directement reliée au superviseur. Ce composant accomplit plusieurs fonctions : via le bus et l'interface 12, il distribue aux autres cartes les consignes reçues du superviseur et qui leur sont destinées (blocs 12 et 17) ; il attend les signaux d'acquittement de consigne qui lui parviennent, toujours via le bus et l'interface 12, desdites autres cartes ; en cas de défaut de réception d'un acquittement attendu, il en informe le superviseur et provoque l'arrêt des générateurs de consigne de toutes les autres cartes (via le bus CAN); et il génère (bloc 14) et transmet (bloc 15) sur le bus le signal de synchronisation.

En ce qui concerne cette dernière fonction, il est opportun de souligner qu'elle n'est pas nécessairement liée à la distribution de consignes. On peut, en effet, envisager que la carte de synchronisation ne soit pas la même carte qui reçoit les consignes du superviseur et les distribue au reste du système.

Enfin, un « programme client » 21 reçoit en entrée des commandes provenant de l'assembleur/ordonnanceur et génère des requêtes de services qui sont transmises aux autres cartes par l'intermédiaire du bus et de l'interface 11 (voir bloc 19).

Le schéma fonctionnel de la figure 3 est tout à fait général et peut convenir à différentes applications. La carte peut être fournie pourvue d'un set d'instructions prédéterminé, destiné à une application spécifique. Par exemple, ces instructions peuvent comprendre le pilotage d'actionneur et de capteur, des temporisations, des fonctions de gestion de situations d'erreurs, des commandes d'entrées et sorties, des opérations mathématiques. D'autres instructions peuvent être ajoutées au besoin. En effet, une « instruction » n'est qu'un code mnémonique qui déclenche une routine enregistrée dans une mémoire non volatile (interne ou externe au microcontrôleur). Plusieurs algorithmes de pilotage des actionneurs peuvent également être prévus.

On obtient ainsi un système qui est à la fois modulaire, flexible et facilement personnalisable.