En esta sección se explicará detalladamente el enfoque que tiene la investigación de sistemas teleoperados en la actualidad, profundizando en temas como los componentes que conforman un sistema de este tipo y las variables que resultan clave mediar para describir su desempeño. Fue importante dirigir esta investigación a estos temas para tomar decisiones en la programación y arquitectura que se siguió en el LASM y también para tener un punto de comparación con otras investigaciones.
Mucha de la literatura revisada aseguraba que la correcta funcionalidad de un sistema teleoperado generalmente contiene en su arquitectura los siguientes componentes presentados en
forma secuencial (Figura 2.9):
Usuario.
Interface humano-máquina (IHM) orientada a conexión a internet. Medio de acceso remoto.
Computadora servidor.
Método de acceso a controlador de robot. Controlador de robot.
Robot.
Sensores de retroalimentación.
Figura 2.9. Componentes de sistemas robóticos teleoperados. (adaptado de (Ho & Zhang, 1999), (Nuño, 2004))
30
2.7.1
IHM orientada a conexión a internet para sistemas teleoperados.
Una descripción para el componente usuario no es indispensable para el entendimiento de los
componentes de teleoperación, nos basta con decir que es la persona a interactuar con el sistema con ubicación remota a él. Por lo tanto la IHM, como es un componente basado en internet, se convierte en el cliente dentro de esta cadena, el cual tiene dos maneras de llegar a interactuar con la computadora servidor, a través de un navegador de red (web browser como: Internet Explorer,
Netscape Navigator, etc.) o a través de lo que común mente en la literatura se conoce como stand-
alone (aplicación independiente) con capacidades de conexión a internet.
Un software web browser se basa en Hyper Text Transport Protocol (HTTP) para desplegar texto e información gráfica al usuario. La IHM que se apegue a esta manera de presentar la información por internet se programa en Hyper Text Markup Language (HTML). En cambio una
aplicación stand-alone puede ser programada en cualquier lenguaje de programación con las
características de ser dependiente de la plataforma en que se programó y manejar protocolos de red para que pueda conectarse a la computadora servidor.
Independientemente de la manera en que se haya construido la IHM, ésta contendrá el conjunto de botones, uso de imágenes interactivas o representaciones virtuales del robot, espacios para introducir información alfanumérica, comandos por reconocimiento de voz, etcétera para ejecutar una acción sobre el robot. Como ejemplos a estas afirmaciones se pueden mencionar: el robot de
cuatro patas SILO4 (Galvez, Estremera, & González de Santos, 2000) utilizado en el laboratorio
de visión y robótica en ENSI Bourges (Benali, Idasiak, & Fontaine, 2001) cuya IHM utiliza una
serie de botones que permite seleccionar qué pierna va a moverse y cuánto desplazamiento tendrá.
También el robot móvil con representación virtual de la Universidad de Essex en Inglaterra (The
Eyebot Project, 1996) cuyo módulo de representación virtual con la ayuda de un sonar crea un mapa en video de los posibles obstáculos que el robot puede tener y permite al usuario hacer modificaciones de trayectorias a partir de esas imágenes. Una manera diferente de controlar un
robot es expuesta en (Talyor & Trevelyan, 1995) ya que el usuario tiene que proporcionar un
número para las diferentes coordenadas x, y, z. Por otra parte el proyecto Tele-Garden (Goldberg
& Santarromana, 1997) cuya representación gráfica en dos dimensiones le permite al usuario seleccionar el área de una imagen en donde el robot se posicionará. Asimismo la investigación llevada a cabo por el Dr. Manuel Macías en el ramo de teleingeniería en el ITESM campus
Monterrey donde expone el concepto Telelab (Macías, 2008) que cuenta con un brazo robótico de
31
Santos, 2000), en modo semiautomático como en (Goldberg & Santarromana, 1997), o bien en modo totalmente automático.
2.7.2
Medio de acceso remoto.
Existen muchas formas en las que se puede teleoperar un sistema, por radio frecuencia (Ogai,
Wada, Hirai, Abe, & Sato, 2007), conexiones físicas a larga distancia tipo maestro esclavo
(Clement, Vertut, Fournier, Espiau, & Andre, 1985), por decir algunas. Para el caso en el que el medio por el cual el usuario envía comandos al robot y recibe la retroalimentación de éste sea a
través de internet si es por una conexión dedicada como las que usan las aplicaciones stand-alone,
en ésta debe extremar seguridad en los datos que se están enviando además de desarrollar un método de control en el envío. Aunado a esto es necesario establecer diferentes niveles de conexión
para discernir usuarios administradores de usuarios comunes. En (De Pasquale, 1998) se muestra
un ejemplo que usa una aplicación stand-alone cuya conexión es directa para transmitir la
información de control del cliente al servidor y viceversa. Esta información debe ser
“excesivamente validada”, lo cual agrega tiempo de procesamiento preliminar al comando a ejecutar en este tipo de sistemas. En cambio cuando se usan aplicaciones web toda esta seguridad se lleva a cabo por el servidor web ajeno a la programación de la aplicación y así se evita el programador tener que validar las peticiones de conexión. Aunque sistemas como los del Dr.
Manuel Macías (Telelab) (Macías, 2008) permiten tener un grado de seguridad alto al pedir la
identificación de cada usuario en un horario previamente solicitado y además combinar las bondades de utilizar una conexión web que ya se mencionaron.
2.7.3
Computadora servidor.
La computadora servidor es la que procesa gran parte del código que tiene que ver con las acciones programadas del robot. Esta computadora está en constante comunicación con el controlador del robot y por sus características de servidor es muy indispensable que esté todo el tiempo corriendo la aplicación y en conexión a internet. La conexión con el controlador del robot provee a la computadora cliente las necesidades de retroalimentación de los sensores que interpreta el usuario, quien puede enviar y recibir información al servidor ya sea por medio de un servidor web o una conexión directa a la red como lo hemos estado viendo. Varios ejemplos como en
32
proyecto Mercury (Goldberg & Mascha, 1994) o el laboratorio remoto Telelab (Macías, 2008) en
donde se sigue esta metodología de tener un servidor que atiende las peticiones de usuarios. Es común encontrar en la literatura, en el caso de tener un servidor web, variaciones como
NCSA HTTP Demon (Goldberg & Mascha, 1994) o Microsoft Personal Web Server (Saucy &
Mondada, 1997), pero en sí, la inclinación por algún servidor web se define dependiendo de la plataforma en la que se ha realizado la aplicación, de sus propósitos de investigación, seguridad
entre otras cosas relacionadas con el desempeño del servidor. Ejemplo de esto es el proyecto “The
Web Interface for Telescience (WITS)”(Paul, Gregory, Tharp, & Kam, 1997), cuyos creadores se basaron en un servidor web robusto que pudiera manejar arriba de mil peticiones de conexión a la vez.
2.7.4
Modo de acceso al controlador de robot.
La interface de comunicación entre el servidor y el controlador puede darse de diferentes maneras. Algunas de estas maneras son más eficientes, rápidas, prácticas o sencillas de usar que otras. La decisión de escoger una u otra depende de la velocidad de respuesta que la aplicación requiera, por ejemplo no sería lo mismo la velocidad de respuesta del actuador cuando se controla temperatura que la que se necesita para controlar un péndulo invertido. Dentro de estos modos destacan: Wireless Local Area Networks (WLAN), IEEE 802.11 como WiFi e HiperLAN, Ethernet y sus variantes, RS-232, etc. Algunos desarrollos de esto se pueden ver en proyectos como el
cuadrúpedo SILO4 (Galvez, Estremera, & González de Santos, 2000), el péndulo invertido
(Salzmann, Latchman, Gillet, & Crisalle, 1999) o el proyecto de los tanques acoplados
(Ramakrishnan, y otros, 2001) que utilizan una conexión RS-232, el proyecto de los robots
agentes (Huosheng, Lixiang, Pui, & Zhou) que además de controlar a los robots se manipulan
cámaras ambos controles utilizando como medio de conexión WLAN o el revolucionario sistema
del Dr. Manuel Macías (Macías, 2008) que utiliza una Simatic Station (PLC Siemens) en cuyo
gabinete reside un módulo de comunicaciones que va más allá de una simple interface Ethernet puesto que incluye un servidor web, un servidor de correo electrónico y funciones FTP (CP 343-1 IT).
33
2.7.5
Controlador de robot.
El controlador del robot es quien tiene los algoritmos de control para llevar al cumplimiento correcto de tareas que el robot tiene que realizar además que es el encargado de hacer la interface de comunicación entre el servidor con el actuador en sí. El controlador recibe comandos de control de alto nivel del servidor y los transforma en instrucciones de bajo nivel para posteriormente mandarlas al robot, una vez que éste haya terminado la tarea, envía la retroalimentación correspondiente al controlador y se hace el mismo proceso de manera inversa para que el usuario interprete el estatus del robot.
Por su naturaleza, no es común encontrar en la literatura la manera en que se implementaron
estos algoritmos, si a caso se encuentra la técnica utilizada como en (Benali, Idasiak, & Fontaine,
2001) que utilizan lógica difusa para que un administrador de modos de control tome decisiones
sobre cuál sería el correcto control para desempeñar una trayectoria, en (Huosheng, Lixiang, Pui,
& Zhou) con programación en C++ se realizaron algunos algoritmos con el propósito de proveer
autonomía y enfrentar el retraso arbitrario que presenta la Internet, en (Salzmann, Latchman,
Gillet, & Crisalle, 1999) donde se programó un cotrolador/optimizador que estima los nuevos parámetros de los paquetes que hay que enviar basándose en la referencia dada y un ancho de banda
que también estima, todo esto en la plataforma de LabView. También en (Ramakrishnan, y otros,
2001) donde se compara el desempeño de tres controladores programados por técnicas de PID, espacio de estados y lógica difusa para mantener bajo control el proyecto de los tanques acoplados.
Asimismo el sistema del Dr. Manuel Macías en el ITESM campus Monterrey (Macías, 2008) que
utiliza una unidad de control de procesos (CPU) del tipo CPU 314C-2 DP donde se encuentra toda la programación en lenguaje escalera para controlar al robot de tres ejes.
2.7.6
Robot.
El robot es el subsistema final dentro de esta cadena de teleoperación, en él se encuentran todos los servomotores a controlar para lograr una tarea específica y dependiendo de esta tarea estos robots se categorizan como por ejemplo: robots manipuladores con gripper (especie de mano con dos dedos), brazos robóticos, móviles, submarinos, humanoides, etc. Las tareas típicas que realizan los robots suelen ser de: ambiente militar, industrial, para la educación, la medicina, experimentación, espacial, submarina o de riesgo. Cada robot tiene su propio controlador que como mencionamos en los párrafos anteriores sirve para hacer la interface entre el servidor y el robot en
sí. En la literatura revisada se encontraron robots como el del concepto Telelab (Macías, 2008)
34
Idasiak, & Fontaine, 2001) que tiene una orientación para la educación en dónde el estudiante
puede manipular este cuadrúpedo y experimentar la teleoperación. En (Huosheng, Lixiang, Pui, &
Zhou) se coordinan varios robots para realizar tareas complejas que uno sólo no podría llevar a
cabo con propósitos comerciales como “tele-manufactura, tele-capacitación o tele-servicio”. En
(Alencastre-Miranda, Muñoz-Gómez, & Rudomín, 2003) con fines de experimentación se manipula un robot PUMA del tipo gripper pero en colaboración de varios usuarios a la vez en un medio virtual.
2.7.7
Sensores de retroalimentación.
Esta parte se refiere a la manera en la que el usuario remoto se percata del estatus del robot. Aplicaciones avanzadas proveen retroalimentación de video, sonido o del tipo háptica (fuerza de retroalimentación). Otras aplicaciones no tan avanzadas pero no menos importantes con el encendido o apagado de algún indicador en la IHM es suficiente para encadenar secuencias que el robot ejecute. Cuando la aplicación utiliza el video como retroalimentación el número de cámaras varía dependiendo de las perspectivas necesarias para completar las tareas por ejemplo en
(Tanenbaum, 2003) sólo fue necesario tener una cámara ya que el objetivo del proyecto es que el usuario tenga una perspectiva panorámica y controle ésta a diferencia de las cámaras que se utilizan en (Huosheng, Lixiang, Pui, & Zhou) una en cada robot agente y otra que proporciona la vista general de ambiente. Otro caso es cuando se trata de controlar la transmisión del video como en
(Salzmann, Latchman, Gillet, & Crisalle, 1999) que de dos formas que graba la cámara, cuadro por cuadro y en modo continuo, se ha escogido la primera por la posibilidad que presenta para que el usuario pueda definir la compresión del video. También cuando se trata de controlar el zoom o el
panorama de la cámara como en (Ramakrishnan, y otros, 2001) que se utiliza una unidad
motorizada tipo “pan tilt” para que el usuario por medio de comandos que interpreta un controlador
especializado para la cámara pueda cambiar la orientación horizontal y vertical de ésta, método que
también se utiliza en Telelab (Macías, 2008) donde se tienen 2 cámaras de video para tener
diferentes perspectivas, cada una de ellas con control pan, tilt, zoom e iluminación para dar más libertad al usuario y hacer la experiencia de teleoperación más real. Esto sin contar la interacción que proporciona la interface humano máquina con sus indicadores en pantalla.
35