INTERFAZ AVANZADA DE UN SISTEMA DE TELECIRUGÍA

José M. Peñafiel, Antonio Gil, José M. Azorín, José M. Sabater, Carlos Pérez, Ricardo Morales Virtual Reality & Robotics Lab

Universidad Miguel Hernández de Elche Avda. de la Universidad s/n, Edif. Torreblanca, 03202 Elche (Alicante)

jm.azorin@umh.es

Resumen Este artículo describe los componentes y herramientas, tanto hardware como software, que componen la interfaz gráfica empleada por el cirujano operador principal dentro del sistema global de telecirugía, así como sus posibles utilidades y facilidades que le dan a éste. También se describe las herramientas desarrolladas para la teleoperación del robot LR Mate 200iB de FANUC. Palabras Clave: Telecirugía, interfaz gráfica, cliente-servidor. 1 INTRODUCCIÓN La cirugía mínimamente invasiva (MIS) ha supuesto una revolución en el campo de la cirugía ya que es menos dolorosa y requiere menor tiempo de convalecencia del paciente que con la cirugía abierta tradicional. Se diferencia de esta última debido a que las operaciones se realizan introduciendo a través de pequeñas incisiones en el cuerpo del paciente cámaras y el instrumental quirúrgico necesario. Sin embargo esta técnica tiene algunos inconvenientes para el cirujano como la reducida visión de la zona de intervención, la pérdida de realimentación háptica y la pérdida de la coordinación manos-ojos [1]. Algunos de estos inconvenientes pueden ser paliados mediante el uso de la telecirugía. La telecirugía se ha convertido en uno de los campos de mayor investigación por la comunidad robótica en los últimos años. La telecirugía permite a los cirujanos llevar a cabo intervenciones a través de una interfaz de teleoperación controlando así robots mediante el uso de maestros hápticos. Permite proveer imágenes de la intervención, la conexión con expertos para situaciones especiales mediante el uso de internet, realizar operaciones tediosas o complicadas eliminando temblores o movimientos no deseados. También permite el control del procedimiento desde un lugar remoto. Además de todo ello, también permite el controlar robots virtuales mediante el uso

de simuladores que mediante procesos matemáticos recrean partes del cuerpo humano a intervenir. Esto es posible gracias a la teleoperación. Un sistema teleoperado se compone básicamente de un par maestro-esclavo. Mientras que el maestro se encuentra en la zona local donde se encuentra el operador, el esclavo se ubica en la zona remota inaccesible o peligrosa para éste en la que debe ejecutarse la tarea. El operador comanda el maestro para que el esclavo reproduzca sus órdenes en la zona remota. Dado que en ocasiones el operador no tiene acceso ni siquiera visual a la zona remota donde trabaja el esclavo, se hace necesaria la existencia en el sistema de una interfaz visual que permita una ejecución eficaz de la tarea. Esta interfaz visual se puede lograr con cámaras colocadas en el entorno remoto que envíen su señal a monitores ubicados en la zona local. En ocasiones se mejora la interfaz visual incorporando gráficos generados por computador, creándose lo que se denomina realidad aumentada [5]. Para mejorar el sistema teleoperado se pueden incorporar sensores de diversa naturaleza con el fin de obtener información exhaustiva de la zona remota. La elección del tipo de sensores y dispositivos maestro-esclavo dependerá de las tareas concretas y necesidades que el sistema tenga que satisfacer. A pesar de esto, el sistema de teleoperación se conforma de unos elementos comunes; los principales elementos que intervienen en un sistema teleoperado son: operador, dispositivo maestro, dispositivo esclavo, interfaz, canal de comunicación y sensores. Estos elementos pueden identificarse en la Figura 1.

Figura 1. Elementos de un sistema teleoperado Actualmente existen diversos grupos desarrollando interfaces de telecirugía. El Dto. Ingeniería de Sistemas y Automática de la Universidad de Málaga

está desarrollando el Sistema Experimental de Tele-Cirugía [4]. En este artículo se expone la interfaz para telecirugía que está siendo desarrollada en la Universidad Miguel Hernández de Elche basada en el uso de dispositivos maestros hápticos y robots esclavos. El objetivo de este sistema es el permitir realizar intervenciones remotas de cirugía mínimamente invasiva y proporcionar mayores ventajas que el procedimiento manual. El artículo está organizado del siguiente modo. En el apartado 2 se describe la arquitectura que compone la interfaz de telecirugía, así como sus componentes hardware y software. En el apartado 3 se expone las herramientas desarrolladas para poder controlar y manejar los robots esclavos. Por último en el apartado 4 figuran las principales conclusiones de este artículo. 2 ARQUITECTURA DEL SISTEMA Uno de los objetivos principales de la telecirugía es la posibilidad de realizar intervenciones remotas en hospitales pequeños o en los que no disponen del personal con suficiente experiencia para llevar a cabo la intervención sin la necesidad de la ayuda de otros cirujanos más expertos. La telecirugía nos permite disponer de esta ayuda sin la necesidad de que esté físicamente en el mismo lugar que se lleve a cabo la operación. Otra de las razones para emplear la telecirugía es la minimización de errores debidos a factores humanos. La telecirugía nos permite reducir errores y la fatiga del cirujano operador, delimitar mediante un ordenador de áreas de movimiento restringido impidiendo la posibilidad de dañar tejidos cercanos a la zona de intervención. El sistema de telecirugía nos permite estar en constante contacto con otro cirujano experto, situado físicamente en otra localización, en la intervención que se esté llevando a cabo mediante teleconferencia, además nos permite ser guiados mediante la visión de la operación en un simulador. El empleo del simulador permite planificar y entrenar la operación a realizar previamente, posibilitando a los cirujanos adquirir experiencia en la intervención a realizar. Este simulador también puede ser empleado por estudiantes de cirugía para realizar prácticas de diferentes intervenciones. La interfaz que se va a describir en la siguiente sección corresponde la interfaz utilizada por el cirujano principal (OR Main Surgeon) dentro del sistema de telecirugía mostrado en la figura 2 [1].

Figura 2. Arquitectura del sistema de telecirugía 2.1 ARQUITECTURA HARDWARE La figura 3 muestra la arquitectura hardware que compone el sistema que controla el cirujano principal en quirófano. En este esquema podemos describir los siguientes componentes del que consta:

Figura 3. Componentes del sistema MAC Ordenador de plataforma MAC. Todo el

sistema controlado por el cirujano operador gira alrededor de este ordenador ya que desde él, el cirujano principal realizará la operación. En la aplicación que correrá en este ordenador el cirujano dispondrá de la visión de las diferentes cámaras (figura 4) que componen el sistema, podrá manejar el robot operante mediante el uso de maestros hápticos. Actualmente se utilizan los maestros Omni de SensAble [8]. Otra de las opciones que permite la aplicación es el poder estar, mediante videoconferencia, conectado con otro cirujano experto que vaya guiando al cirujano principal. El guiado puede realizarse simultáneamente viendo en pantalla mediante VNC cómo el cirujano experto realiza la operación en un simulador. También es posible la conexión mediante VNC al simulador para poder practicar la operación a realizar. Utilizamos un ordenador MAC ya que son muy eficientes con el tratamiento y procesado de imágenes médicas para su utilización como ayuda y planificación en las intervenciones.

Figura 4. Vistas de la interfaz

Cámaras. El sistema está compuesto de diferentes

cámaras, desde cámaras endoscópicas hasta cámaras globales del quirófano mediante las cuales, el cirujano operador podrá ir guiándose para realizar la operación. El sistema soporta cámaras DV, IIDC (Firewire) y USB.

Phantom Omni. Son los maestros hápticos de

SensAble (Figura 5) encargados de comandar al robot operador así como también de reflejar la fuerza del extremo de la herramienta. Estos maestros están conectados a un ordenador PC que se comunica con el ordenador del operador (MAC) mediante el protocolo RPC enviando los movimientos del robot y recibiendo la fuerza de realimentación. También se emplean estos dispositivos para manejar poder manejar el simulador.

Figura 5. Dispositivo maestro.

Robot. El dispositivo esclavo que se va a teleoperar

es el robot LR Mate 200iB de la casa FANUC. Este robot es un brazo mecánico industrial de seis grados de libertad, en el que todas sus articulaciones son de rotación. En la Figura 5 se muestra la apariencia del mismo.

Las seis articulaciones que posee, numeradas del 1 al 6 desde la base hasta el extremo del robot (ver Figura 6), determinan la posición del robot y su espacio de trabajo. Estas

articulaciones se pueden dividir en dos grupos, siendo J1, J2 y J3 las articulaciones que determinan la posición y J4, J5 y J6 las articulaciones que determinan la orientación de la muñeca.

Figura 6. Brazo mecánico LR Mate 200iB Un aspecto muy importante, y necesario para el desarrollo de este trabajo es la disposición de un subsistema de entrada/salida remoto en el que se encuentra un conector Ethernet [3]. Esta interfaz, situada en la controladora del robot, nos proporciona la posibilidad de integrarlo a la red de área local y establecer comunicación con un PC.

Simulador. En un ordenador PC se encuentra el

simulador dinámico de telecirugía [1]. Este simulador sirve para practicar la operación a realizar así como también para que el cirujano experto pueda guiar visualmente al cirujano operador. Para obtener la visualización de este simulador, en el ordenador del simulador correrá un servidor VNC que permita conectarse con la aplicación del ordenador del cirujano operador (MAC).

2.2 ARQUITECTURA SOFTWARE Para el desarrollo de la aplicación en Mac se ha utilizado el entorno de desarrollo Xcode [11]. Esta aplicación es el entorno de desarrollo integrado (IDE) que Apple Computer suministra gratuitamente. Xcode trabaja conjuntamente con InterfaceBuilder, una herramienta que nos permite realizar interfaces gráficos de usuario. Con esta herramienta podemos emplear los lenguajes de programación C/C++, Objetive C, Java y AppleScript. También nos permite crear binarios universales para ordenadores PowerPC y para Intel (x86).

El framework empleado ha sido Carbon [2] ya que nos permite readaptar fácilmente código desarrollado para cualquier plataforma UNIX. Carbon permite el uso de lenguajes de programación C y C++, además contiene herramientas para la gestión de eventos (Event Handling).

Figura 7. Interfaz gráfica.

En la figura 7 se ve el aspecto de la interfaz que verá el cirujano donde se tiene una visión de todas las cámaras conectadas y del servidor VNC en el lado derecho de la aplicación. En la zona de la izquierda podemos ver con más detalle en un mayor tamaño la cámara seleccionada o el servidor VNC. Las funciones fundamentales del programa son: Cámaras. La aplicación permite la conexión de

cámaras DV, IIDC (Firewire) y USB. Se pueden ver simultáneamente 3 cámaras que se podrán configurar entre todas las conectadas al ordenador. Su previsualización será en unas pequeñas pantallas en la zona derecha de la aplicación. Para la captura del video de las cámaras se ha usado el API Quicktime [2] que contiene herramientas para la captura de audio/video, su manipulación, compresión, etc. Uno de estos grupos de herramientas son los Sequence Grabber Components que contienen herramientas como los Sequence Grabber Channels que nos permiten la previsualización y captura tanto de audio como de video. Es necesario el crear un SGChannel por cada dispositivo que queramos usar (en este caso 3) y en cada uno configurar un canal de vídeo. Al configurarlos, él sólo busca los dispositivos conectados, también permitiendo la asignación del dispositivo que queramos emplear.

VNC Virtual Network Computing [10]. Es un

protocolo originalmete desarrollado en los laboratorios AT&T, basado en la arquitectura

cliente-servidor que permite la visualización de otra máquina y su control. El protocolo VNC usa el protocolo RFB (“remote framebuffer”) que permite el acceso a interfaces gráficas de usuario. La versión usada ha sido la 3.3 [9]. Mediante este protocolo se puede visualizar la aplicación del simulador y controlarla desde el lugar del cirujano operador.

Videoconferencia. Mediante el programa se puede

lanzar los programas de videoconferencia más usados como el Skype y el iChat (incluido en MacOS X) compatible AOL Instant Messenger para PC.

RPC. El RPC es un protocolo que permite a un

programa ejecutar código en otra máquina remota. El programador no tiene que estar pendiente de las comunicaciones. Basado en la estructura cliente-servidor donde el cliente inicia el proceso solicitando al servidor que ejecute cierta función retornando éste el resultado de la operación [7]. La interfaz dispone de un cliente RPC para enviar las órdenes de control del robot así como también tiene un servidor que se encarga de tramitar las órdenes provenientes del ordenador controlado por los maestros hápticos.

3 COMUNICACIONES CON EL

ROBOT La empresa FANUC, además de fabricar componentes industriales desarrolla el software necesario para su control y desarrollo de tareas. De entre todo el software disponible para este robot, PC Developer´s Kit (PCDK) nos proporciona la comunicación con el robot desde un PC. Al instalar esta herramienta disponemos de dos librerías, FRRobot y FRRobotManager accesibles desde el compilador Microsoft Visual Basic. Estas dos librerías, orientadas a objetos ofrecen la posibilidad de acceder a muchos parámetros del robot, tales como variables del sistema, registros de posición, alarmas, programas almacenados, etc. Aunque con estas librerías se está en disposición de crear aplicaciones desarrolladas en Visual Basic, en las que un PC se comunique con el robot, va a ser necesaria la incorporación de nuevos recursos software para superar algunas limitaciones inherentes al uso de estas librerías. Las limitaciones son:

• Únicamente es posible desarrollar aplicaciones en el lenguaje de programación Visual Basic. Este hecho es una importante restricción a la hora de incorporar algunos dispositivos a la aplicación, ya que algunas

cámaras, sensores, dispositivos maestros, etc., sólo disponen bibliotecas en C/C++ para su control.

• Otra restricción inherente a estas librerías es

la necesidad de disponer un PC bajo la plataforma Windows para poder desarrollar aplicaciones que se comuniquen con el robot, ya que el software PCDK sólo se puede instalar en esta plataforma, y el lenguaje Visual Basic es propietario de Microsoft.

Por estos motivos se han incorporado dos elementos para salvar estas limitaciones, con el fin de desarrollar una herramienta que controle al robot mucho más abierta y con posibilidad de incorporación de otros elementos hardware y software. 3.1 DLL ACTIVE-X. RPC Para solucionar las limitaciones de las librerías proporcionadas por el software PC Developer´s Kit citadas anteriormente, se han incorporado dos elementos al esquema de comunicación, una DLL Active-X para poder desarrollar aplicaciones en C++ y la implementación del protocolo RPC, mediante el cual crearemos aplicaciones distribuidas basadas en el modelo cliente-servidor, en el que podremos desarrollar clientes bajo diversas plataformas como Windows, Linux o MacOS. Una DLL Active-X es un archivo que contiene funciones que se pueden llamar desde aplicaciones u otras DLLs. Los programadores utilizan las DLL para poder reciclar el código y aislar las diferentes tareas. Las DLL no pueden ejecutarse directamente, es necesario llamarlas desde un código externo. Por tanto, mediante el compilador Visual Basic podremos crear una serie de funciones en las que encapsulemos código de las librerías FRRobot y FRRobotManager, estas funciones estarán integradas en el componente DLL Active-X y mediante una aplicación programada en C++ llamaremos a estas funciones. La incorporación de este elemento nos posibilita a desarrollar aplicaciones en C++ que llamen a las funciones del componente DLL Active-X. El código que integra la función de la DLL pertenece a las librerías FRRobot y FRRobotManager, y al ejecutarse se encargan de la comunicación entre el PC y el robot. Para poder desarrollar aplicaciones que controlen el robot bajo otras plataformas diferentes a Windows utilizaremos el protocolo RPC. Este protocolo, cuyas siglas significan llamada a procedimiento remoto (del inglés “remote procedure call”), es una interfaz de programación que permite el desarrollo de

aplicaciones distribuidas. Mediante un conjunto de funciones, este protocolo permite que los programas llamen a subrutinas que se ejecutan en un sistema remoto, incluyendo códigos de retorno y variables predefinidas para soportar el procesamiento distribuido [9]. El modelo de comunicación RPC se basa en el modelo cliente-servidor. El servidor es una aplicación que se está ejecutando indefinidamente a la espera de recibir alguna petición del cliente. El servidor, por tanto, es el que tiene el código de las funciones y el que las ejecuta en el momento en que recibe una petición. El cliente es una aplicación que envía peticiones de ejecución de alguna función al servidor; cuando el cliente llama a una función, ésta se ejecuta en el servidor y el cliente detiene su ejecución hasta que el servidor termina [6]. En la Figura 8 se muestra el esquema de comunicación incorporando todos los elementos explicados. Se ha creado un servidor de peticiones RPC bajo la plataforma Windows enlazado con la DLL Active-X. El cliente se desarrollará en la plataforma que se desee, Windows, Linux, MacOS, y realizará llamadas al servidor; éste al recibir la llamada procedente del cliente, llamará la función de la DLL correspondiente, la cual se encargará de comunicarse con el robot. Todas las comunicaciones se efectúan a través de la red de área local.

Figura 8. Esquema de comunicación.

3.2 APLICACIONES DESARROLLADAS Se han desarrollado dos aplicaciones, un servidor y un cliente, programadas en C++. Para el entorno gráfico se ha utilizado la librería Qt v4.0.1 desarrollada por Trolltech; la principal ventaja de esta librería es que se trata de una librería multiplataforma, siendo compatibles las aplicaciones desarrolladas tanto en Windows como Linux y MacOS. Trolltech proporciona también versiones en OpenSource de estas librerías que se encuentran en constante evolución. La aplicación servidor es la encargada de atender todas las peticiones RPC que le pueda hacer el cliente. Cuando atiende la petición, llama a la función correspondiente de la DLL Active-X la cual se comunica con el robot. Además de la atención de peticiones, el servidor lleva a cabo otras tareas como la monitorización de la comunicación RPC con el cliente, la monitorización de la conexión con el robot,

y el estado y posición del robot. En la Figura 9 se muestra la apariencia gráfica del mismo.

Figura 9. Aplicación servidor.

La aplicación cliente es la que interactúa con el usuario. Esta aplicación envía las peticiones RPC al cliente. Las tareas que el usuario podrá realizar serán las de visualizar y editar los registros de posición del robot, llevar un seguimiento de las alarmas y errores producidos, monitorizar tanto la comunicación RPC con el servidor como la conexión con el robot, monitorizar la posición actual del robot y realizar dos tipos de teleoperación, mediante “sliders” y mediante un dispositivo maestro. Mediante la opción de control “sliders”, el usuario podrá teleoperar el robot en cada una de sus seis dimensiones (X,Y,Z,W,P,R) de manera unidimensional. Para ello bastará con mover los “sliders” que aparecen en la interfaz del cliente, cada “slider” controla una dimensión. Mediante el dispositivo maestro, el usuario teleoperará el robot a través del dispositivo Omni Phantom de SensAble. Este dispositivo es un robot maestro de seis grados de libertad, en el que teleoperaremos el robot en posición. En la Figura 10 se muestra una imagen del mismo. A continuación se muestra la apariencia gráfica de la aplicación cliente.

Figura 10. Aplicación cliente. Estas dos herramientas son las que se han creado con el fin de controlar el brazo mecánico FANUC LR

Mate 200iB a través de la red de área local. El servidor se ejecutará en un PC bajo la plataforma Windows, en el que esté instalado el software PCDK y se encuentre la DLL Active-X que se ha creado con las funciones que encapsulan el código de las librerías FRRobot y FRRobotManager. El cliente se podrá desarrollar en la plataforma que más convenga, ya sea Windows, Linux o MacOS. Una vez esté ejecutándose el servidor, el cliente podrá comunicarse con él enviando peticiones RPC, el servidor al atenderlas llamará a la función de la DLL Active-X correspondiente y ésta se comunicará con el robot, el cual ejecutará la tarea deseada. Cuando esta termine, devolverá el control al servidor, el cual devolverá un código de retorno al cliente devolviéndole el control. 4 CONCLUSIONES En este artículo se ha presentado los componentes de la interfaz de un sistema de telecirugía así como también las herramientas necesarias para manejar un robot esclavo. El objetivo del interfaz de telecirugía es el facilitar las herramientas necesarias al cirujano operador que le permitan teleoperar al robot, comunicarse con otros expertos situados en otra localización que permita guiarle durante la intervención, así como la posibilidad de planificar y practicar la operación a realizar. Agradecimientos Este trabajo ha sido financiado por la Generaliat Valenciana dentro del marco Ajudes per a projectes d'investigació científica i desenvolupament tecnologic mediante el proyecto GV06/034 y por la Comisión Interministerial de Ciencia y Tecnología (CICyT) mediante el proyecto DPI2005-08203-C02-02. Referencias [1] Azorín, J.M., Sabater, J.M., García, N., Pérez,

C., Morales, R., Compañ, A. (2006) “Requerimientos de un sistema de telecirugía mínimamente invasiva”, Actas de las XXVII Jornadas de Automática, pp. 3-7.

[2] Carbon (2007) http://developer.apple.com/ carbon/index.html [3] Fanucrobotics http://www.fanucrobotics.es [4] Gómez de Gabriel, J.M., Muñoz Martínez,

V.F., Dominguez Fernández, F.J., Serón Barba, J., (2005) “Sistema Experimental de Tele-Cirugía”, Revista eSalud.

[5] Ibáñez, M. (2005) Desarrollo de un visualizador predictivo de teleoperación, Proyecto Final de Carrera Ingeniería Industrial, Universidad Miguel Hernández de Elche.

[6] Kay A. Robbins, Steven Robbins (1997). “UNIX Programación Práctica. Guía para la concurrencia la comunicación y los multihilos”, Prentice Hall.

[7] RPC (2007) Remote Procedure Call http://es.wikipedia.org

[8] SensAble (2006) http://www.sensable.com [9] Trista, R., Wood, K.R., (1998) “The RFB

Protocol”, ORL Cambridge. [10] VNC (2006) Virtual Network Computing

http://www.realvnc.com [11] Xcode (2007) http://developer.apple.com/tools/ xcode/