Logiciel de commande du robot chirurgical Minerva

par Yves Piguet*, Institut de Microtechnique, EPFL

En septembre dernier, les deux premières opérations du robot Minerva sur des patients couronnaient cinq ans de recherche, de développements, d'essais et de collaboration entre l'Institut de microtechnique de l'EPFL et le Service de neurochirurgie du CHUV. De nouveaux horizons s'ouvraient ainsi pour la robotique à l'IMT. Mais au niveau du développement, quels problèmes nouveaux a-t-il fallu résoudre par rapport aux robots industriels? Cet article tente d'y répondre en ce qui concerne la partie informatique de la commande. Deux aspects importants du logiciel ne seront pas abordés ici: l'imagerie (c'est-à-dire la récupération des images du scanner, leur traitement pour l'extraction des repères qui permettent leur localisation dans l'espace et leur affichage) et les changements de coordonnées (le passage des coordonnées cartésiennes du point du cerveau à atteindre aux consignes à donner aux axes du robot).

Un robot dédié à la stéréotaxie

Les opérations stéréotaxiques du cerveau consistent à introduire une sonde de faible diamètre (2 à 3 mm) dans le cerveau à travers un trou percé dans le crâne. Le point cible est repéré sur des images scanner. Un cadre de référence fixé sur le crâne permet de passer du référentiel image, défini par les traces de ce cadre sur les images scanner, au référentiel à trois dimensions dans lequel la position des instruments est fixée. Les opérations que l'on réalise actuellement avec cette technique comprennent les biopsies (prélèvements de tissus pour des analyses), l'évacuation des abcès et des hématomes, la mesure électrique de l'activité neuronale, la thalamotomie (destruction de cellules) et l'implantation de sources radioactives pour l'irradiation de tumeurs. L'opération manuelle se fait en plusieurs étapes. Tout d'abord, un système de fixation sur le crâne est mis en place et sera gardé jusqu'à la fin de l'opération; il permet de conserver une référence de positionnement par rapport au crâne et au cerveau. Le cadre de référence est fixé sur ce système. Un certain nombre d'images scanner sont prises, puis le patient est transporté en salle d'opération. Le cadre de référence est remplacé par un tube guide-sonde qui peut être réglé dans n'importe quelle position à l'aide de règles graduées. Les coordonnées du point cible et des éléments du cadre qui apparaissent sur l'image sont introduites dans un ordinateur portatif qui permet de calculer les angles à reporter sur le système de positionnement. On procède ensuite à la découpe de la peau, au perçage du crâne, puis à celui de la dure-mère. Enfin, l'intervention proprement dite a lieu. Au total, l'opération dure de deux à quatre heures.

Le but de Minerva est d'automatiser le plus possible l'opération en travaillant à l'intérieur du scanner (cf. figure 1). Le transfert de l'information entre le scanner et le système de positionnement est remplacé par une connexion informatique. Ceci a pour avantages d'éviter le déplacement du patient, de réduire les risques d'erreurs et de permettre la prise d'images de contrôle au cours de l'opération. Le robot effectue toutes les manipulations. Le chirurgien peut ainsi se concentrer sur l'intervention elle-même et donner ses ordres au robot.

Figure 1: schéma de principe du système Minerva

Répartition des tâches entre Sun et PC

Le logiciel de commande du robot Minerva est réparti sur une station de travail Sun et un compatible PC. Le logiciel sur Sun comprend deux parties: la gestion des images scanner (communication avec le scanner, traitement, détection des barres et changements de coordonnées référentiel image - référentiel cadre BRW, et affichage), et la commande du robot proprement dite. Les commandes données au robot sont envoyées par ligne série au PC qui est chargé des points suivants:

réception des commandes, décodage
vérification de la possibilité de lancer la commande (est-ce que les sondes sont retirées si l'on veut bouger le robot?)
changements de coordonnées entre celles du cadre de référence et les articulations du robot
vérification des risques de collisions entre le robot, le cadre, le support du cadre et le scanner
commande du robot proprement dite (par l'intermédiaire d'un système ARIA de la société Demaurex)
mesures de forces entre le robot et le patient
écriture dans un fichier de toutes les commandes reçues de la Sun et des messages qui lui sont retournés (boîte noire).

Contrôle des opérations

Une préoccupation constante a été de choisir un compromis acceptable entre la liberté accordée à l'utilisateur pour le laisser exécuter ce qu'il juge opportun d'une part, et les restrictions qu'impose le programme pour éviter un acte dangereux d'autre part.

Tout d'abord, une remarque sur le dialogue homme-machine s'impose. La commande du robot située sur PC sert d'intermédiaire entre la couche interface-utilisateur, située sur la station de travail, et les cartes d'axes. Il a fallu concevoir un protocole de communication entre la station de travail et le PC qui soit fiable, rapide et ‹ si possible ‹ simple. On a choisi d'avoir un système maître-esclave où l'esclave (le PC) reçoit des commandes et les exécute en renvoyant un ou plusieurs messages de confirmation, d'information ou d'erreur. Par conséquent, il n'y a pas de dialogue à l'initiative du PC: le PC ne peut pas poser de questions à l'utilisateur, telles que le mouvement que vous demandez peut être dangereux; êtes-vous sûr que vous voulez quand même l'exécuter?. Le PC (et en premier lieu le développeur) doit savoir dans quels cas il faut accepter ou refuser une commande.

La station Sun présente à l'utilisateur une liste des étapes de l'opération dans l'ordre logique d'exécution. Elle indique ce qui devrait être fait, ce qui pourrait l'être (par exemple recommencer le choix de la position-cible et de la trajectoire d'entrée) et ce qui est interdit (par exemple bouger le robot lorsque une sonde est introduite dans le cerveau) (cf. figure 2).

Figure 2: tableau de commande de l'opération (sur Sun)

Pour clarifier les choses, répertorions les différents risques et examinons quelles solutions on peut y apporter.

Endommagement du robot: certaines restrictions de mouvement sont évidentes (fins de course des axes); d'autres nécessitent des calculs plus importants (risques de collisions entre le robot et le scanner).
Valeurs par défaut: dans les premières versions du programme, un certain nombre de paramètres pouvaient être spécifiés par des commandes qui ne déclenchent aucun mouvement par elles-mêmes. Il a été décidé de les supprimer et de ne pas avoir de valeur par défaut, dans le but d'éviter que le concepteur et l'utilisateur n'aient une idée différente sur le fonctionnement normal du système. Le PC ne retient pratiquement plus aucune information en dehors de la position du point-cible, des angles d'approche et de la position du crâne. Lorsqu'il a besoin de connaître l'état du robot, il lit directement l'état des capteurs.
Erreur dans l'énoncé d'une commande: est-ce qu'une commande non reconnue ou un nombre erroné d'arguments doit simplement être signalé à l'utilisateur ou arrêter le robot? La seconde solution s'est imposée.
- Mouvements mettant en jeu la sécurité du patient: on touche ici aux décisions les plus difficiles à prendre. Certains choix ne peuvent être faits que par le chirurgien; mais d'autres semblent plus évidents, tels que:
- déplacement de la cible ou des angles d'approche lorsque le couteau est avancé. Même si quelques millimètres de marge sont suffisants pour permettre des mouvements sans risque, il a paru plus sûr et peu contraignant d'exiger que le bras soit complètement reculé. Dans cette position, un capteur inductif est activé. De même, le bras ne peut être reculé que si aucune sonde ne se trouve dans le cerveau.
Le perçage de la dure-mère, qui doit être fait après le perçage de l'os. Est-ce que le système doit mémoriser les étapes précédentes pour savoir ce qu'il est possible de faire? Dans le cas où l'on doit faire redémarrer la commande en pleine opération, il faudrait alors soit court-circuiter ces sécurités, soit informer le système de ce qui a déjà été fait. Comme l'utilisateur donne ses ordres par l'intermédiaire de la station de travail qui sert de tableau de commande général, il a semblé plus simple de déplacer en amont ce genre de sécurité.
Arrêt d'urgence: n'importe quel mouvement peut être interrompu soit par le bouton d'arrêt d'urgence électrique, soit par logiciel, soit encore par une erreur quelconque. Cela cause deux problèmes à résoudre impérativement:
l'opération interrompue doit pouvoir être reprise, si possible avec la même commande. C'est souvent facile à réaliser: si on a besoin d'un certain instrument pour exécuter une commande, par exemple, on ne le charge que s'il est encore sur le magasin d'instruments. Le perçage de l'os pose cependant un problème dans la mesure où la détection de l'extérieur du crâne est utilisée comme référence pour la suite. Quelques millimètres déjà percés mais oubliés signifieraient qu'on risque de surestimer l'épaisseur restante. Dans ce cas, on est obligé de mémoriser la position de l'extérieur du crâne une fois pour toutes. Si l'on veut percer ailleurs, il faudra l'indiquer spécifiquement.
Le système ‹ et l'utilisateur ‹ ne doivent pas partir du principe que chaque commande est exécutée jusqu'au bout. Ce serait désastreux lors du choix de la cible par exemple. Dans ce cas, les étapes suivantes sont interdites s'il est interrompu.

Protocole de communication

Le PC et la Sun communiquent par interface série RS-232. Dans le sens Sun PC, il faut assurer, si ce n'est une transmission fiable à 100%, du moins une détection des erreurs pour éviter des mouvements incontrôlés. De plus, il ne faut pas que, suite à une interruption de la liaison, on ne puisse plus transmettre d'arrêt d'urgence. Les commandes sont constituées d'un mot-clef et de paramètres numériques compréhensibles directement par l'utilisateur. Chaque ligne de commande est terminée par un octet de checksum et un saut de ligne. Le PC possède un watchdog qui arrête le robot si aucun caractère n'est reçu pendant plus de 0,2 s. Entre les commandes, des espaces sont envoyés par la Sun.

Pour faciliter les essais effectués en laboratoire en l'absence de la station de travail, on peut taper les commandes directement au clavier. Des fonctions d'éditions minimales (gestion du backspace, rappel des commandes précédentes) sont disponibles. Dans ce cas, il n'y a évidemment plus ni timeout ni checksum, mais un message rappelle continuellement que ce mode de fonctionnement ne doit pas être utilisé pour les opérations réelles.

Dans le sens PC Sun, les contraintes sont moins sévères: une erreur n'aurait pas de conséquences graves, car les messages servent essentiellement à renseigner l'utilisateur de manière qualitative sur le déroulement de chaque étape (il y a donc une grande redondance). Les messages s'inspirent de ce que l'on trouve dans les protocoles FTP ou NNTP: ils sont identifiés par un code numérique qui indique aussi l'état du robot (mouvement en cours d'exécution ou robot prêt pour une nouvelle commande). En plus, ils contiennent une description textuelle et d'éventuels paramètres qui sont exploités par la Sun pour afficher, par exemple, l'avance d'une sonde sous forme graphique.

Tous les messages transmis sont enregistrés dans un fichier qui sert de boîte noire (cf. figure 3). Cela permettrait, en cas de problème, de savoir exactement ce qui s'est passé et d'en déterminer plus facilement la cause. C'est également très utile pour garder une trace des essais. Pour les étapes nécessitant une analyse plus fine, telles que le perçage ou l'insertion d'une sonde, les forces mesurées sur l'instrument (qui servent en premier lieu à contrôler l'opération) sont enregistrées dans des fichiers séparés.

1123 10:18:52.43 C  outil+ 5
1124 10:18:52.43  R  100(Begin "outil+ 5")
1125 10:18:52.48    S.U. moved from 3 to 4
1126 10:19:41.04  R  135(Tool biopsy configured)
1127 10:19:41.09  R  135(Tool biopsy initialized)
1128 10:19:41.26  R  010(Ok)
1129 10:21:06.72 C  biopsie -50 10 4
1130 10:21:06.78  R  100(Begin "biopsie -50 10 4")
1131 10:21:06.83  R  135(Tool biopsy configured)
1132 10:21:06.89  R  135(Tool biopsy initialized)
1133 10:21:06.89  R  135(Calibrating)
1134 10:21:26.50  R  138(Logging measures in "04102126.ICR")
1135 10:22:48.01  R  135(Calibration done)
1136 10:23:08.82  R  135(Waiting for the probe)
1137 10:23:08.82  R  139(Pause)
1138 10:27:55.20 C  finpause
1139 10:27:55.42  R  110(Ok)
1140 10:27:55.75  R  138(Logging measures in "04102755.BIO")
1141 10:27:55.81  R  135(Going close to the knife)
1142 10:28:25.96  R  135(Beginning Inserting Probe)
1143 10:28:37.83  R  010(Ok)

Figure 3: extrait de la boîte noire du PC

Conclusion

La commande logicielle de Minerva a demandé de résoudre des problèmes de natures très diverses. L'aspect robotique et système temps-réel est basé sur une librairie fournie par le constructeur de la commande électronique et ressemble évidemment à d'autres commandes de robots. La sécurité a une place primordiale. On peut arrêter le système en cas de problème (bouton d'arrêt d'urgence que l'on retrouve sur toutes les machines), mais il faut être capable de poursuivre l'opération rapidement et sans aucun risque. Et enfin, il faut trouver un juste milieu entre le contrôle total du robot par le chirurgien et les ingénieurs et la supervision des mouvements par l'ordinateur. Du point de vue de l'ingénieur, le développement de Minerva a été particulièrement intéressant parce qu'il intègre des domaines techniques très différents (mécanique, électronique, capteurs, informatique, mathématiques) et qu'il demande une collaboration étroite avec le monde médical, qui a souvent une façon très différente d'aborder les problèmes. Je tiens à remercier les autres membres de l'équipe Minerva: Dominique Glauser, Pierre Flury et Marc Epitaux.

article paru dans le Flash informatique spécial été 1994 du 6 septembre 1994