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:

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.

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