Bei der Entwicklung und Forschung im Bereich der robotergestützten Chirurgie muss viel Zeit aufgewendet werden um die Software, Sensorik und Aktorik zu einem funktionierendem Demonstrator zu kombinieren. Hierbei wird oft Zeit in Basistechniken investiert, die zwar im Prinzip bekannt und vorhanden, aber nicht im konkreten Kontext verfügbar sind. Auch bei verfügbaren Softwarepaketen wie Slicer ist eine Integration in die bestehende Infrastruktur nicht trivial. Wünschenswert wäre eine Entwicklungsumgebung, die möglichst hohe Echtzeitanforderungen erfüllt, eine einfache modellbasierte Entwicklung ermöglicht sowie geringe Anforderungen an die verwendeten Betriebssysteme stellt. Weitere erstrebenswerte Eigenschaften sind die Möglichkeit, einfache Versuche oder Auswertungen zu scripten, das Vorhandensein von einfach zu implementierenden Schnittstellen, einer integrierten Simulationsumgebung für das Robotersystem und einer direkten Formulierungsmöglichkeit für mathematische Probleme. Ein Lösungsentwurf, der diese Anforderungen bereits zu weiten Teilen erfüllt, wird hier vorgestellt. Die beschriebene Umgebung wurde und wird im Rahmen der Arbeit an vier verschiedenen EU-Forschungsprojekten des sechsten und siebten Rahmenprogrammes entwickelt und wurde bereits mit verschiedenen Partnern genutzt. Ziel ist die Etablierung eines OpenSource Projektes speziell für die robotergestützte Chirurgie.
Simulationsumgebung Regelungsmodelle für Roboter
2
Bei dem hier vorgestellten Ansatz wurden Abstriche hinsichtlich der Anforderung an harte Echtzeit gemacht. Harte Echtzeit ist unter Standardbetriebssystemen wie Windows oder Linux ohne Modifikation des Systemkerns nicht möglich. Ein anderer Nachteil ist die Abgrenzung von Echtzeit- und Nicht-Echtzeit-Komponenten, womit IPC (Inter Process Communication) Mechanismen wie Shared Memory nicht mehr genutzt werden können. Ebenso liegen nicht alle Bibliotheken passend vor und eine Modifikation der Software bedeutet oft hohen Aufwand bei geringem Nutzen. Das hier vorgestellte Framework nutzt die Realtime CORBA Spezifikation und die passende Implementierung ACE TAO, die eine sehr effiziente Implementierung des Standards bietet. Schnittstellen werden in der IDL (Interface Definition Language) definiert und vom TAO Compiler direkt in C++ Code umgesetzt. Der CORBA Naming_Service wird als zentraler Dienst genutzt, der Auskunft gibt, auf welchem Rechner ein spezifischer Dienst aktiviert ist.
Um eine weiche Echtzeitumgebung zu realisieren laufen sämtliche Prozesse und Threads mit erhöhter Priorität, unter
Windows kommt z.B. die höchste Stufe “REALTIME_PRIORITY_CLASS“ zum Einsatz [
Für die in den Schnittstellen definierten Funktionen wurden passende Gegenstellen für Matlab/Simulink implementiert.
Im Falle von skriptingfähigen Kommandos geschieht dies als MEX-Funktion, hierzu gehört z.B. ein PTP Kommando,
das somit von der Matlab Kommandozeile genutzt werden kann und für Matlab Skripte verfügbar ist. Im Falle von
Funktionen für die Regelung werden diese mittels S-Functions für Simulink aufgerufen. Da Simulink aus dem Model ein
C Programm erstellt und kompiliert, ist durch „hand geschriebenen“ Code kaum eine Verbesserung der
Leistungsfähigkeit zu erreichen. Als Simulationsumgebung wird Openrave genutzt. Openrave stellt bereits eine komplette Umgebung
bereit um CAD Daten zu laden und über Matlab die Umgebung kommandieren zu können [
Abb. 2: Robotersystem für die haptische minimalinvasive Chirurgie, bestehend aus 2 LBR Robotern und einem RX90 Roboter (Endoskop). Die beiden LBR Roboter sind mit haptischen Eingabegeräten von Force Dimension gekoppelt. Das vorgestellte Framework OP:Sense wird im Labor am IPR auf einem verteilten System genutzt, bei dem jeweils ein PC die folgenden Programme ausführt: • Implementierung der Schnittstelle für das Trackinggerät, den Namensdienst und der Robotersteuerung • Roboterregelung und Haptik • Simulationsumgebung • PMD Kamerasystem • Testsetup mit Kinect Kameras Die Roboter werden momentan mit einem Takt zwischen 5 ms und 20 ms über die FRI Schnittstelle angesteuert. Da die LBR Roboter im Gelenkraum mit einem höheren Takt selber interpolieren, ist durch eine höhere externe Taktrate nur eine marginale Steigerung der Dynamik der Roboter zu erwarten, was den Aufwand kaum rechtfertigt. In weiteren Projekten wird OP:Sense bereits von Studenten und Mitarbeitern genutzt. Dass das System auf jedem Rechner mit Windows sehr schnell installiert und ohne Modifikationen am System betrieben werden kann, erlaubt es auch Studenten Erfahrungen im praktischen Umgang im Bereich der Robotik zu sammeln. Weiterhin wird mit OP:Sense ein Ansatz zur automatischen Repositionierung des Endoskops realisiert. Derzeit wird das Framework in zwei EU Projekten des siebten Rahmenprogramms genutzt: in „SAFROS – Patient Safety in Robotic Surgery“ und „ACTIVE – Active Constraints Technologies for Ill-defined or Volatile Environments“. Darüber hinaus wird das System momentan für eine Veröffentlichung als OpenSource Projekt im Jahr 2011 vorbereitet. Desweiteren werden erste Anwendungen am IPR vorbereitet, in denen OP:Sense für reale Anwendungen unter anderem im Bereich der Orthopädie evaluiert werden kann. Abb. 3: Zwei Erweiterungen des Setups, die momentan mit dem Framework entwickelt werden. Links: das Resultat des Voxel-Carving Algorithmus, der die Daten von sechs PMD S3 Kameras verwendet und zur Kollisionsvermeidung genutzt werden soll. Rechts: die Einbindung der Microsoft Kinect Kamera in die Simulationsumgebung, um Chirurgen und Patienten markerlos tracken zu können. 4
Die vorgestellte Umgebung zielt auf die schnelle Entwicklung von Beispielanwendungen ab. Dabei wurden harte
Echtzeitanforderungen absichtlich nicht berücksichtigt und das Framework stellt nur sicher, dass die Komponenten über eine
nicht erreichte Deadline informiert werden. Ein Ansatz um harte Echtzeit in eine RADE Umgebung einfließen zu lassen
wurde von Jörg et al. Vorgestellt [