SISTEMA DE INFORMACIÓN PARA LA CAPTURA DE LAS EJECUCIONES PRESUPUESTALES SICEP
SISTEMA ROBÓTICOTELEOPERADO POR CAPTURA DE …
67
SISTEMA ROBÓTICOTELEOPERADO POR CAPTURA DE MOVIMIENTO AUTORES: JUAN SEBASTIÁN MÉNDEZ RUBIANO LUIS EDUARDO SALAZAR BADEL UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C JUNIO 2010
Transcript of SISTEMA ROBÓTICOTELEOPERADO POR CAPTURA DE …
SISTEMA ROBÓTICOTELEOPERADO POR CAPTURA DE MOVIMIENTO
AUTORES:
JUAN SEBASTIÁN MÉNDEZ RUBIANO
LUIS EDUARDO SALAZAR BADEL
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ D.C
JUNIO 2010
SISTEMA ROBÓTICO TELEOPERADO POR CAPTURA DE MOVIMIENTO
AUTORES:
JUAN SEBASTIÁN MÉNDEZ RUBIANO
LUIS EDUARDO SALAZAR BADEL
Proyecto de grado para optar por el título de
Ingeniero de Sistemas y Computación
PROFESOR ASESOR
Fernando De la Rosa, Ph.D.
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTE DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTA D.C
JUNIO 2010
3
TABLA DE CONTENIDOS
TABLA DE ILUSTRACIONES ........................................................................................................ 5
0. RESUMEN ......................................................................................................................... 7
1. INTRODUCCIÓN ................................................................................................................. 8
2. DESCRIPCIÓN GENERAL ..................................................................................................... 9
2.1 Objetivos ....................................................................................................................... 9
2.1.1 Objetivos generales ................................................................................................ 9
2.1.2 Objetivos específicos .............................................................................................. 9
2.2 Antecedentes (Estado del arte) .................................................................................. 10
2.3 Identificación del problema y de su Importancia ....................................................... 13
3. DISEÑO Y ESPECIFICACIONES ........................................................................................... 15
3.1 Definición del problema.............................................................................................. 15
3.2 Especificaciones .......................................................................................................... 16
3.2.1 Requerimientos funcionales ................................................................................ 16
3.2.2 Requerimiento no funcionales ............................................................................. 17
4. DESARROLLO DEL DISEÑO ................................................................................................ 18
4.1 Subsistema de Detección/Identificación Gestual ....................................................... 21
4.1.1 PhaseSpace Impulse Motion Capture System ..................................................... 22
4.1.2 Configuración del sistema Impulse de PhaseSpace ............................................. 25
4.1.3 Software de apoyo del subsistema de captura de movimiento .......................... 25
4.1.4 VRPN ..................................................................................................................... 27
4.2Subsistema de captura de video .................................................................................. 31
4.2.1 Cámara de video Logitech Quickcam Pro 9000.................................................... 32
4.3 Subsistema de Robot .................................................................................................. 32
4.3.1 Robot Pioneer P3DX ............................................................................................. 33
4.3.2 Sensor Láser Hokuyo URG-04LX ........................................................................... 34
4.4 Sistema central ........................................................................................................... 35
4.5 Alternativas de diseño ................................................................................................ 36
5. IMPLEMENTACIÓN .......................................................................................................... 37
5.1 Subsistema Detección/Identificación Gestual ............................................................ 39
4
5.2 Subsistema de Captura de Video ................................................................................ 40
5.3 Subsistema de Robot .................................................................................................. 43
5.4 Resultados esperados ................................................................................................. 45
6. VALIDACIÓN .................................................................................................................... 46
6.1 Método ....................................................................................................................... 46
6.2 Encuesta proyecto de grado ....................................................................................... 47
6.3 Validación de resultados ............................................................................................. 48
7. CONCLUSIONES ............................................................................................................... 52
7.1 Discusión ..................................................................................................................... 52
7.2 Trabajo futuro ............................................................................................................. 53
8. REFERENCIAS .................................................................................................................. 54
9. APÉNDICES ...................................................................................................................... 56
A. Código fuente ............................................................................................................ 56
B. Configuración inicial del sistema de captura de movimiento ................................. 57
1. Energía del sistema ............................................................................................... 57
2. Configuración inicial – Crear perfil ....................................................................... 58
3. Configuración inicial - Codificar ............................................................................ 62
C. Calibración del sistema de captura de movimiento ................................................ 64
5
TABLA DE ILUSTRACIONES
Figura 1. Estructura de solución final. División funcional……………………..……………………..18
Figura 2. Estructura básica de la solución final. Diagrama de despliegue……………………..19
Figura 3. Usuario probando el sistema………………………………………………………………………...20
Figura 4. Usuario en ambiente de interacción final………………………………………………………21
Figura 5. Diagrama de caja negra de subsistema de captura de movimiento………………..22
Figura 6. Dispositivos del sistema PhaseSpace IMPULSE………………………………………………24
Figura 7. Topología del sistema de captura de movimiento…........................................25
Figura 8. Software de apoyo del sistema PhaseSpace IMPULSE……................................27
Figura 9. Diagrama de caja negra de subsistema de captura de video………………………..31
Figura 10. Diagrama de caja negra de subsistema de robot………………………………………..32
Figura 11. Robot P3DX……………………….………………………………………………………..................33
Figura 12. Sensor Láser Range Finder HOKUYO URG-04LX………………………………………34
Figura 13. Diagrama de caja negra del sistema central……………………………………………….35
Figura 14. Diagrama de secuencia del sistema central………………………………………………….38
Figura 15. Usuario usando el sistema…………………………………………………………………………..39
Figura 16. Grafo base de directShow utilizado para la captura de video……………………….41
Figura 17. Comparación vista externa y vista del robot………………………………………………..43
Figura 18. Implementación móvil seleccionada……………………………………………………………44
Figura 19. Aceptación general de la solución………………………………………………………………..48
Figura 20. Gráfico de apreciación de la aceptación. Mejora, del tipo de interacción…….48
Figura 21. Gráfico de apreciación del punto fuerte del proyecto………………………………….49
Figura 22. Gráfico de apreciación del punto a mejorar del proyecto…………………………….49
6
Figura 23. Tiempo empleado por los usuarios de prueba……………………………………………..50
Figura 24. LED Driver conectado a la estación base…….………………………………………………..57
Figura 25. Pantalla principal del sistema de configuración. Pestaña LED devices………….58
Figura 26. Creación del perfil. Pantalla inicial……………………………………………………………….59
Figura 27. Creación del perfil. Elección del dispositivo………………………………………………….60
Figura 28. Crear perfil. Pantalla de configuración de la cadena de marcadores…………….61
Figura 29. Pantalla de codificación. Escogencia del perfil……………………………………………..62
Figura 30. Pantalla de codificación. Se escoge el dispositivo, la potencia, y se codifica…63
Figura 31. Pantalla de calibración. Vista principal…………………………………………………………64
Figura 32. Pantalla de calibración inicial…………………………………………………………………….65
Figura 33. Pantalla de calibración final…………………………………..…………………………………….66
7
0. RESUMEN
Los sistemas robóticos teleoperados se están convirtiendo en sistemas muy usados en la
actualidad. Se usan cuando ocurre un desastre, en busca de supervivientes, en vigilancia, o
en el caso de lugares de difícil acceso para el ser humano, como el espacio exterior. Por lo
general, se usan estos sistemas para mejorar la seguridad de las personas que participan
en una tarea, muchas veces riesgosa.
Este documento trata sobre la implementación en el manejo de este tipo de sistemas,
enfocándose en un punto particular: la interacción entre humano y robot. Se explica el
proceso de diseño, implementación, y pruebas que llevo a hacer un sistema capaz de
reconocer movimientos gestuales del usuario para controlar el movimiento del robot
teleoperado. La motivación fue la de implementar un tipo de interacción que permitirá
sentir al operario control directo con la máquina de manera más inmersiva y natural. Es
decir, sintiéndose el robot. O que al menos, fuera una forma de control más divertida de
usar que la convencional basada en palancas y botones. Se explica de manera detallada
los elementos utilizados, así como las ideas planteadas para llevar a buen término el
proyecto. Al final, igualmente, se hace un análisis de los resultados obtenidos a partir de
pruebas de campo con usuarios ajenos al proyecto, se justifica el uso de este tipo de
interacción y se dan pautas para ampliar y mejorar estos resultados mediante trabajos
posteriores.
8
1. INTRODUCCIÓN
Un sistema robótico teleoperado es un sistema que tiene como objetivo rastrear,
investigar e indagar en un lugar específico, por lo general poco accesible al ser humano,
con el fin de encontrar alguna cosa particular, o simplemente obtener información de un
sitio remoto para conocer sus condiciones. Así, por ejemplo, se tienen robots de
exploración espacial que no son más que sistemas que buscan recolectar material físico,
analizar cierta zona, o reconocer un lugar particular.
Por otro lado, la captura de movimiento es una técnica que permite almacenar
movimientos físicos de manera digital. Esto permite capturar gestos corporales, o sucesos
mecánicos en un computador para luego ser procesados e integrados en una aplicación de
computador. Por ejemplo, para hacer que una representación digital de una persona se
mueva de la misma forma que lo haría su par real.
La idea del proyecto es juntar estos dos conceptos y tecnologías de tal forma que se
pueda manipular un robot de exploración mediante la interacción con un sistema de
captura de movimiento. Es decir, que se pueda manejar un robot, de una forma más
intuitiva a la convencional, utilizando figuras gestuales hechas con los brazos y las piernas
de un operario. Esto, en teoría, permitiría un control más inmersivo y natural que el que
se utiliza actualmente mediante el uso de controladores a distancia, usando palancas y
botones.
El documento se divide en varios capítulos. Primero se plantean los objetivos del proyecto
y luego se explican antecedentes o proyectos relacionados, implementados por terceros.
Continúa con la identificación del problema y se analiza su importancia. Posteriormente se
define la problemática para luego especificarla según requerimientos funcionales y no
funcionales. Luego se muestra el desarrollo de diseño con una recolección de información
hardware y software y se describen las diferentes alternativas de diseño. A continuación
se muestra la implementación, mediante una descripción y un análisis previo de
resultados esperados. Y por último se presenta el método de validación, con los
resultados de una encuesta, y se discute ésta a modo de conclusión.
9
2. DESCRIPCIÓN GENERAL
2.1 Objetivos
2.1.1 Objetivos generales
Estudiar la viabilidad de manejar un robot de exploración utilizando captura de
movimiento para el reconocimiento de posturas gestuales. Así, se exploran nuevos
ambientes de interacción. El usuario cuenta con retroalimentación visual (video) e
información sensorial (radar laser) del ambiente local del robot para poder tomar las
decisiones de movimiento que se transmiten al robot.
2.1.2 Objetivos específicos
• Desarrollar un sistema de reconocimiento gestual que permita identificar los
comandos del usuario. Esta aplicación computacional es un cliente que se conecta
al servidor del sistema de captura de movimiento (IMPULSE), toma los datos, y los
procesa para ser identificados. El resultado de la identificación genera una
discriminación de posibles movimientos a realizar por el robot.
• Desarrollar un sistema de retroalimentación al usuario. Este sistema va a mostrar
dos tipos de datos al usuario: Imagen capturada de una cámara web, y distancias
obtenidas por el sensorláser del robot.
• Desarrollar un cliente que sea capaz de dar comandos sencillos de movimiento al
robot.Dos tipos de comandos se utilizan en el sistema: comandos proporcionados
por el usuario, y comandos de seguridad del robot. El primero será el menos
prioritario, aunque se espera sea el más utilizado, mientras que el segundo es el
más prioritario y se utiliza como comportamientosde recuperación del robot. Es
decir, en cuanto el robot se vea vulnerado, ya sea con un objeto cercano, o con sus
llantas trabadas se ejecutara un conjunto de movimientos que hacen que el robot
se mantenga a salvo.
10
• Estudiar la experiencia de usuario y la viabilidad a la hora de manejar este tipo de
sistemas con una interacción no convencional de captura de movimiento.
2.2 Antecedentes (Estado del arte)
En la actualidad la robótica se encuentra cada vez más inmersa en la sociedad. Esto brinda
nuevas oportunidades para aquellos que desarrollan estas tecnologías y supone nuevas
formas de interacción entre los humanos y los robots. Esto se debe a que cada día existen
nuevas formas de robots con diversas funcionalidades que obligan a los humanos a
interactuar asimismo de distintas formas.
Lo anterior no significa que toda la interacción entre humanos y robots sea directa,
existen varios tipos de interacción que se basan en el control remoto (control a distancia)
de los robots por parte de los humanos. Gran parte de la diversidad de los controles
utilizados varían de acuerdo a la tarea que se pretende realizar con el robot, lo cual
describe Song et al. [4]. En este trabajo se realiza un estudio sobre diferentes tipos de
interacción mediante varios controles convencionales para realizar algunas tareas,
intentando determinar qué tipo de control resulta más conveniente para el humano
dependiendo de la tarea a realizar. Concluyen, por ejemplo, que para una gran cantidad
de tareas, y utilizando los controles convencionales, lo más cómodo y aparentemente
adecuado es el comúnmente utilizado Joystick. Entiéndase por controles convencionales
al tipo de dispositivos de interacción entre humanos y robots que pueden ser fácilmente
utilizados con la ayuda de un computador personal, tales como el teclado, dispositivos con
comandos de botones, timón y pedales diseñados para juegos de carreras, Joystick o un
control de Wii, entre otros.
El último control mencionado, el control de Wii, ha causado un gran interés para la
robótica, ya que su flexibilidad ofrece varias oportunidades de control. Tal es el caso de lo
realizado por Guo y Sharlin [1], quienes utilizaron un control de Wii para interactuar con
un robot AIBO de Sony. Esto les permitió un control gestual del robot. Incluso si los gestos
de control eran limitados a, por decirlo de alguna forma, la “orientación” que tomaran los
11
controles, la idea básica de utilizar posturas o gestos para controlar a un robot es algo que
está presente en la actualidad.
Aunque la manera como se le imponen órdenes a un robot es de vital importancia en la
interacción entre humanos y robots, los controles mencionados se diseñan teniendo en
mente una perspectiva total del panorama en el cual el robot se encuentra y realiza sus
tareas. Sin embargo, al diseñar un sistema de control para un robot teleoperado se debe
tener en cuenta la manera como el usuario percibe el entorno en el que se encuentre el
robot, ya que no siempre el usuario podrá ver al robot. Es por eso que a este tipo de
robots se les equipa con una variedad de sensores y cámaras.
Este tipo de operación lleva una nueva problemática y es la navegación efectiva del robot
que se está controlando. Nielsen y Goodrich [3] evalúan la conveniencia de navegar
mediante video y mapas en dos y tres dimensiones, concluyendo que una plataforma
híbrida en la cual se presente simultáneamente video y un mapa en tres dimensiones
resulta más conveniente para la navegación de un robot teleoperado. Esto se debe a que
muchas veces la transmisión de video puede tener retardos significativso mientras que un
mapa puede ser generado mediante el uso único de la información recibida por los
sensores, lo cual es más liviano para transmitir.
Todo lo anterior lleva a pensar que las nuevas formas de interactuar con los robots serán
formas de interacción no convencionales con respecto a lo conocido hoy en día.
Existe un proyecto el cual consiste en la identificación de posturas labiales para manipular
un robot con cuatro grados de libertad [5]. El sistema se creó pensando en una forma no
convencional, fácil de usar, e intuitiva (según los autores) de manipular un robot que
pudiera realizar la cirugía tradicional en laparoscopia. Normalmente, esta técnica de
operación se hace de manera manual con un endoscopio. Sin embargo, se dice que es
peligrosa ( y no óptima ) pues los instrumentos se mueven demasiado por los temblores
en la mano del cirujano. Esto hace que el procedimiento sea, finalmente, mal ejecutado
en muchas ocasiones.
12
Para resolver este problema se ha pensado en la implementación de un Sistema de
Posicionamiento del Laparoscopio por un brazo robotizado (SPRL) con diferentes tipo de
interacción: Voz, movimientos de la cabeza, etc. En este caso, se centran en la interacción
con el robot mediante la identificación de cinco posturas labiales: boca relajada, boca
abierta, boca cerrada, y apretada, y la inclinación hacia la izquierda y hacia la derecha.
Esto se logra utilizando técnicas de adquisición de imágenes (video) y procesamiento de
diferentes tipos que logran aislar e interpretar los movimientos de esta región del rostro,
mandando órdenes específicas de movimiento al robot.
Personalmente se considera que este procedimiento es un intento interesante para el
manejo de un robot, pero tal vez no logra cumplir su objetivo. Es decir, se cree que puede
ser un buen sistema para otro tipo de aplicaciones que no sean procedimientos de
precisión, como lo es, en este caso, una cirugía. Además, no se ve tan intuitivo como
afirman los autores ya que se necesita de muchas horas de entrenamiento para lograr
acostumbrar al cirujano a utilizar y controlar una zona del cuerpo tan poco convencional.
Aun así, se considera que para robótica móvil, algo como lo implementado en este
documento podría ser interesante y útil.
Otro proyecto de interacción no convencional trata sobre la identificación y la
interpretación de gestos táctiles para el movimiento de robots [6]. El sistema se hizo
pensando en la necesidad de crear un nuevo paradigma a la hora de interactuar en el
mundo real con tareas de programación complejas sobres robots basados en un sistema
de expresión no verbal. Los autores de este proyecto argumentan que esta es una forma
intuitiva de manejar tareas sobre máquinas que requieran de transiciones, o secuencias
de operación. Por ejemplo, resulta sencillo trazar una ruta mediante gestos de tal forma
que el robot la interprete y la siga.
Esto no es fácil porque las expresiones gestuales no son exactas. Es evidente que la forma
en la que se hace un movimiento no puede ser repetida exactamente entre personas, e
incluso es difícil hacerlo con un solo usuario. Es en este punto donde este proyecto cobra
importancia y relevancia pues exponen ciertas técnicas y consideraciones que hay que
13
tener en cuenta a la hora de realizar un trabajo de similares características. Por ejemplo,
muestran cómo es posible identificar figuras geométricas definidas (triángulos,
rectángulos, etc.) mediante el enfoque de unos puntos particulares: los vértices. Se
muestra que, para este tipo de figuras, se torna esencial el reconocimiento de éstos pues
con ellos se sabe que figura es la que se trata de representar. Así, si acaso son
identificados, por ejemplo, tres vértices, se está tratando inequívocamente con un
triángulo y no con un rectángulo. De igual forma se muestra que, una vez reconocida la
figura, lo que caracteriza el gesto no son los vértices, como en el caso anterior, sino la
longitud de las aristas.
En el trabajo no se emplea el sistema completo: La unión entre la interacción y el robot.
Pero aun así es una muy buena referencia a la hora de tener en cuenta puntos clave en la
comunicación mediante detección de gestos. Cabe aclarar que no se implementó el
sistema completo, por lo que no es posible estimar, con este trabajo, la viabilidad de este
tipo de comunicación.
2.3 Identificación del problema y de su Importancia
Los sistemas robóticos de exploración se están volviendo cada vez más comunes. Se han
ido convirtiendo en una gran herramienta y complemento a la hora de resolver tareas en
lugares de difícil acceso, o en circunstancias que conllevan peligro al ser humano. Por
ejemplo, no es extraño oír que para desactivar una bomba sea enviado un robot de
exploración, o que para explorar un terreno, luego de un desastre natural, sea enviado un
sistema de este tipo para la posible localización de sobrevivientes.
A pesar del gran auge que están teniendo estos sistemas, se considera aún pobre las
investigaciones referentes a la interacción con los mismos. Normalmente, se hace a partir
de un control a distancia con un video de retroalimentación, o utilizando caminos y
movimientos predeterminados diseñados por algún operario.
En este punto es donde el proyecto cobra importancia porque, si bien es cierto, el control
actual, basado en una palanca y botones, es relativamente cómodo, sigue siendo un tipo
14
de interacción utilizado de hace muchos años, y probablemente obsoleto y poco natural.
Fue desarrollado, sin muchos cambios, desde el inicio de los proyectos de este tipo, como
concepto, y no se ha modificado significativamente desde entonces. Se piensa importante
probar la viabilidad de un tipo de interacción más natural al ser humano: Los gestos
corporales. Se utilizan las extremidades del cuerpo para dar diferentes comandos al robot
de exploración, olvidándose por completo de botones y palancas.
Es probable que el sistema de control actual esté tan arraigado que resulte difícil
introducir este tipo de interacción no tan convencional. Aun así, se considera apropiado y
pertinente probar otra alternativa al manejo de éstos.
15
3. DISEÑO Y ESPECIFICACIONES
3.1 Definición del problema
El problema a resolver se puede definir como la falta de comodidad y naturalidad con la
que se manejan los sistemas teleoperados hoy día, además de la poca exploración de
alternativas implementadas exitosas para este fin. El proyecto se enfoca en dar una
aproximación de solución a este problema mediante la inserción de un nuevo tipo de
interacción, sin precedentes en este campo. Lo más parecido, y que se aproxima al
concepto utilizado en este desarrollo, es el de reconocer movimientos corporales
humanos para copiarlos en robots de forma humanoide. Por ejemplo, mover un brazo
robótico con la captura del movimiento de un brazo humano. El concepto, en este caso, es
diferente pues se desea mover un robot móvil (teleoperado) mediante la interpretación
de gestos y posiciones corporales, pero sin imitar. Es decir, se quiere interpretar poses
humanas normalmente utilizadas como comandos atómicos de un robot móvil. Todos
hemos visto como, por ejemplo, al ir conduciendo, algunos conductores que van a girar a
la izquierda extienden su brazo para indicar su intención. Este gesto es entendido por todo
el mundo pues de una u otra forma es natural. Y es justamente esto lo que se quiere
aprovechar en el desarrollo del concepto de este prototipo. El robot móvil, en condiciones
normales, no estará a la vista del usuario. Es por esto que se requiere tener información
local actualizada del ambiente del robot, para poder tele-operarlo. Adicionalmente, el
robot puede enfrentarse a situaciones de riesgo, como pasar cerca de objetos en el
ambiente, para lo que el robot debe reaccionar de forma autónoma y evitar riegos.
16
3.2 Especificaciones
3.2.1 Requerimientos funcionales
Nombre Dar comando de movimiento al robot. Resumen Dado un gesto corporal del usuario el
sistema debe reconocerlo y diferenciarlo para mandarlo al robot teleoperado.
Entradas • Gesto corporal: movimiento de brazo derecho en alguna dirección cartesiana.
• Usuario en posición de uso del sistema, mirando hacia la pantalla.
Resultados Luego del procesamiento el robot debe moverse en la dirección que el operario le indica.
Nombre Mostrar video al usuario Resumen Para que la experiencia sea lo más
inmersiva posible, el usuario ha de ver lo que el robot tiene al frente. Esto se hace por medio de un servidor de video que captura y envía a un cliente las imágenes tomadas de una cámara web embarcada en el robot.
Entradas -- Resultados Se muestra en la pantalla del cliente,
proyectada en una pantalla, el video que captura la cámara web posicionada al frente del robot
Nombre Mostrar información sensorial local del robot.
Resumen Para dar más información al usuario de lo que sucede en el entorno local del robot, se muestra en pantalla un radar 2D con una representación de lo ubicado al frente del robot. Igualmente se muestran marcas que indican la distancia a los que se encuentran estos objetos.
17
Entradas -- Resultados En la pantalla del cliente, en la parte
superior derecha, se muestra un pequeño recuadro en donde se ubica un radar. Éste muestra una representación e indica distancias de los objetos que están frente al robot. Las distancias abarcadas van desde los 20 cms hasta los 4 metros, aproximadamente.
Nombre Evitar peligro para el robot. Resumen Mantener la integridad del robot
teleoperado es una prioridad, por lo que evitar que éste sufra daños es primordial. El robot debe darse cuenta automáticamente que está en peligro, ya sea por objetos cercanos o por bloqueo de llantas, y debe actuar, obviando los comandos del operario, de acuerdo a la situación de tal manera que evite el peligro. Una vez finalizada la tarea se vuelve a dar control al usuario.
Entradas • Objeto cercano (<50cms). • Bloqueo de llantas.
Resultados El robot se mueve evitando el obstáculo. En el momento de esta tarea, el operario no tiene el control del robot. Una vez finalizada vuelve a él.
3.2.2 Requerimiento no funcionales
Tipo Compatibilidad Descripción La cámara utilizada en el robot debe ser
compatible con DirectShow.
Tipo Disponibilidad Descripción El robot puede moverse libremente por el
entorno de exploración siempre y cuando esté conectado a una red en la que se puede comunicar con el sistema central.
18
4. DESARROLLO DEL DISEÑO
El proyecto se ha diseñado para ser una integración de varios subsistemas. Cada uno de
éstos con responsabilidades específicas. Funcionalmente, se tienen tres subsistemas: un
subsistema de captura de movimiento (con su respectiva detección gestual), un
subsistema de captura de video, y otro subsistema de robot. Para unir éstos, se ha
diseñado un sistema central que se encarga de gestionar estos tres subsistemas.
Figura 1. Estructura de solución final. División funcional.
Los cuatro componentes corresponden específicamente a cada una de las funciones que
hacen que el proyecto sea aplicable: la detección gestual, como sistema de interacción. La
captura de video para retroalimentar al usuario (junto con las detecciones láser) y el
sistema robot, como elemento a teleoperar.
Cada componente del diseño es un sistema distribuido entre una componente específica y
el sistema central, mediante varias arquitecturas básicas de cliente-servidor. La idea del
Captura video Sistema central
Robot Detección gestual
Información de los marcadores del traje
Recibir comando
Ejecutar comando
Identificación del gesto
Enviar comando
Recibir imagen Construir interfaz
Enviar datos láser
Obtener imagen
Enviar imagen
Recibir datos
19
diseño es desacoplar tecnologías de tal manera que se pueda cambiar de implementación
fácilmente, por si se quiere mejorar las prestaciones de alguno de éstos.
El despliegue de las tareas de los subsistemas se hace sobre cuatro máquinas diferentes.
En total son 2 computadoras (una de ellas obligatoriamente un laptop), un servidor y un
robot. El servidor es el que tiene las herramientas necesarias para obtener información de
movimiento del usuario, La laptop contiene lo necesario para la implementación de un
servidor de video, que a su vez está montado sobre un robot (que envía información
sensorial láser). Y un computador, que está conectado a un proyector y muestra la
retroalimentación al usuario (construir interfaz), además de acoplar los sistemas.
Un diagrama de despliegue donde se muestra ésta información se ve en el siguiente
diagrama.
Figura 2. Estructura básica de la solución final. Diagrama de despliegue.
En las figuras 3 y 4 se muestran varios usuarios en el ambiente de trabajo normal. Se ve el
área de uso delimitado por las cámaras infrarrojas, del sistema de captura de movimiento,
así como la proyección (en la pared haciendo pruebas o en la pantalla del escenario final)
Sistema central Robot/Laptop
Captura de movimiento
Información de los marcadores del traje
Recibir comando
Ejecutar comando
Identificación del gesto
Enviar comando
Recibir datos
Recibir imagen Construir interfaz
Enviar datos Obtener
imagen
Enviar imagen
20
de la retroalimentación provenientes del sistema central. El usuario se posiciona, dentro
del área de interacción, donde más cómodo se siente, mirando hacia la proyección
utilizando un traje especial de licra que tiene unos marcadores LED.
Figura 3. Usuario probando el sistema, usando el traje de captura de movimiento en el espacio delimitado por éste sistema. En este caso, el frente se encuentra mirando a la pared, donde se está proyectando la imagen de retroalimentación proveniente del robot.
21
Para mayor detalle, a continuación se presenta un desglose de cada uno de los
subsistemas funcionales, así como de las partes que los componen y de los
usuario/elementos que intervienen en ellos.
4.1 Subsistema de Detección/Identificación Gestual
Este subsistema es el encargado de interpretar los movimientos hechos por el usuario. Si
el gesto hecho por éste hace parte del abanico de movimientos aceptados, el subsistema
se encarga de traducirlos a comandos que entienda el robot. En caso contrario,
simplemente los omite. Para entender el funcionamiento del mismo, se muestra en la
Figura 4. Usuario en ambiente de interacción final. En este caso, se usa una pantalla en donde se muestra la retroalimentación del robot. El área de trabajo es la misma pero con una
orientación diferente.
22
figura 5 una representación de caja negra en donde se ven las entradas y salidas básicas
del subsistema.
Figura 5. Diagrama de caja negra de subsistema de detección/identificación gestual.
Los actores y elementos que intervienen en el manejo de este subsistema son los siguientes:
• Usuario • Sistema Impulse Motion Capture de PhaseSpace • Sistema central.
4.1.1 PhaseSpace Impulse Motion Capture System
El IMPULSE, es un sistema de captura de movimiento de la empresa PhaseSpace [7]que
provee las herramientas (hardware y software) necesarias para capturar datos de
movimiento a un bajo costo. Es el finalmente escogido y se basa en la lectura de unos
marcadores infrarrojos LED por medio cámaras infrarrojas. El sistema entrega la posición
3D de cada uno de los marcadores a 480 cuadros por segundo.
ESPECIFICACIONES
Dimensiones cámara 108 mm x 83 mm x 57 mm
Peso cámara 227 gr
Resolución de pixel 3600 x 3600
Megapixeles cámara 12.4
Subsistema de captura de movimiento
Movimiento gestual (usuario)
Comando de movimiento (al robot)
23
Campo de visión 60 grados
Número de marcadores 256 independientes
Dimensiones marcador 20 mm x 14 mm x 3.2 mm
Peso marcador 4.5 gr
Frecuencia de captura 480 Hz (frames/sec)
Latencia 10 ms
Según el fabricante, los datos obtenidos por el sistema son tan confiables que no es
necesario agregar ninguna etapa de filtrado de datos. Esto hace que, a pesar de ser
relativamente económico, se acerque, en prestaciones, a sus homólogos más costosos.
El sistema completo del laboratorio consta de los siguientes elementos (Figura 6):
• Cámaras Infrarojas (8 unidades): El conjunto de cámaras identifican las posiciones
de los leds que usa el usuario.
• Marcadores infrarojos LED (6 unidades): Son los marcadores que se colocan en el
traje del usuario a nivel del brazo para identificar sus gestos.
• Traje de marcadores (1 unidad): Traje de licra en donde se posicionan y sostienen
los marcadores LED. En el proyecto, solo era necesario que el usuario se pusiera el
brazo derecho.
• Barra de calibración (1 unidad): Elemento rígido con marcadores LED que utiliza el
sistema para su calibración. Su uso se describe con más detalle en el apéndice C.
• LED Base Station: Este dispositivo es el encargado de sincronizar los “LED
controllers” con el servidor, además de transmitir nuevas configuraciones.
• LED Controller: transceptor RF que utiliza un microprocesador para controlar los
LEDs (hasta 72 en cada uno). Es el encargado de almacenar las configuraciones de
los marcadores, y de darle energía a los mismos.
• Servidor: Contiene todos los programas necesarios para el manejo del sistema.
Viene de fábrica con el sistema operativo SlackWare, una distribución de Linux.
24
Figura 6. Dispositivos del sistema PhaseSpace IMPULSE (de arriba a abajo y de izquierda a
derecha): cámara infraroja, marcador infrarojo LED, traje de marcadores, barra de calibración, LED
Base Station, LED Controller, servidor.
25
4.1.2 Configuración del sistema Impulse de PhaseSpace
La configuración del sistema es relativamente sencilla pues está diseñado para que el
servidor sea el que maneje absolutamente todo. A éste se conectan las cámaras en serie a
un puerto de red de los muchos que tiene el servidor. Igualmente, se conecta la estación
base. Los LED Controllers, por otro lado, son cargados por el usuario a la hora de hacer la
captura de movimiento. Solo es necesario conectarlo al servidor, por medio de la estación
base, a la hora de configurarlo (proceso que se describe en el anexo B).
4.1.3 Software de apoyo del subsistema de captura de movimiento
El sistema de captura de movimiento consta de tres tipos de aplicación: uno gráfico al
usuario, un servidor OWL, y un sistema de configuración. El primero es el encargado de
calibrar (con la aplicación de calibración) y mostrar los datos de manera visual (master). El
segundo es el que extrae los datos y los deja a disposición de las aplicaciones cliente. Y el
tercero es el que configura el sistema en su totalidad.
El software utilizado como apoyo al subsistema consta de los siguientes elementos (Figura
8):
Figura 7. Topología del sistema de captura de movimiento. Imagen tomada de [7].
26
• Sistema de calibración: es el encargado de sincronizar, calibrar y ajustar los
diferentes componentes utilizados. Es el que detecta el número de cámaras
utilizadas y el que termina identificando la orientación de éstas. La manera como
se calibra el sistema es descrita en detalle en el apéndice C.
• Master:Actúa como el cliente “primario” del sistema IMPULSE. Se conecta al
servidor OWL y tiene como propósito grabar una secuencia de movimientos,
guardándolos en tipos de archivos .RPD o .C3D. Al ser el cliente primario, tiene la
posibilidad de que otros clientes se conecten a él para adquirir información. Sin
embargo, por simplicidad, en este proyecto no se utilizan estas posibilidades, sino
que el cliente creado se comunica directamente con el servidor OWL. Sin embargo,
ha sido empleado para verificar que el funcionamiento del sistema sea el correcto.
• Servidor OWL: es una aplicación que corre desde el arranque del sistema. Éste
toma los datos obtenidos por las cámaras infrarrojas y los procesa para hacerlos
disponibles a aplicaciones cliente por medio de una conexión TCP.Es posible
conectarse directamente a este servidor haciendo un programa en C, utilizando el
API que provee el fabricante. Sin embargo, se considera más práctico utilizar una
solución estándar como el VRPN.
• Sistema de configuración: es la interface principal para manipular y adaptar el
dispositivo a una disposición específica. Está escrito en PHP, y puede ser accesado
por medio de cualquier navegador web, tanto local como remotamente. En él se
configuran diferentes aspectos como la cantidad de “LED drivers” a utilizar,
además de la cantidad y disposición de los marcadores LED. La manera de
configurar el sistema IMPULSE se explica detalladamente en el anexo B.
27
Figura 8. Software de apoyo del sistema PhaseSpace IMPULSE (de arriba a abajo y de izquierda a
derecha): Sistema de calibración, Master, Sistema de configuración.
4.1.4 VRPN
VRPN, como es descrito por sus creadores, “es un conjunto de clases dentro de una
librería y un conjunto de servidores diseñados para implementar interfaces de red
transparentes entre aplicaciones y dispositivos físicos (tracker, etc.) en sistemas de
realidad virtual. La idea es tener un PC u otro host en cada estación de realidad virtual que
controle los periféricos (tracker, dispositivos de botón, entradas análogas, sonido, etc.).
VRPN provee conexiones entre aplicaciones y todos los dispositivos usando la clase de
servicio apropiada para cada tipo que use una conexión.”
28
Es decir, VRPN ofrece la posibilidad de manejar dispositivos de entrada remotamente
ofreciendo una capa de abstracción, transparente al usuario, que hace ver el conjunto de
dispositivos como si fueran uno solo.
El sistema IMPULSE de captura de movimiento está soportado como tracker en las
especificaciones del VRPN por lo que usarlo es relativamente sencillo. Es necesario instalar
el servidor VRPN en la máquina en la que está conectado el sistema de captura de
movimiento y crear un archivo de configuración. Éste último se pasa como parámetro a la
hora de ejecutarlo.
Para instalarlo, es necesario hacer una compilación del programa. El fabricante la
proporciona de esta forma pues es necesario utilizar librerías propias de los dispositivos
de entrada a los que se les va a dar soporte. En este caso, PhaseSpace proporciona en su
página web la librería con las cabeceras necesarias.
Una vez instalado, el sistema consta de dos partes: el servidor, y la aplicación cliente. El
primero es el que se encarga de enviar los datos, y el segundo el que adquiere los datos y
los procesa.
SERVIDOR
En el lado del servidor, es necesario crear un archivo de configuración que contenga la
información del dispositivo que se va a utilizar, así como algunos parámetros
característicos. El archivo es un texto plano con extensión .cfg que se ve de la siguiente
manera:
29
La primera línea tiene tres campos: el primero identifica el tipo de tracker que va a utilizar
VRPN. En este caso el sistema IMPULSE de PhaseSpace; El segundo es el nombre público
del tracker que se va a utilizar a la hora de la adquisición de datos por red en el cliente; El
tercer campo corresponde a la dirección IP del servidor OWL.
La segunda línea tiene igualmente tres campos: el primero corresponde al número de
adquisiciones por segundo (normalmente múltiplo de 30fps). El segundo es un
componente binario que indica si luego de leer los datos más recientes se descartan las
adquisiciones anteriores (1 para descartarlos, 0 para conservarlos). El tercer campo
también es un componente binario e indica si el sistema se va a comportar en modo
esclavo (1) o en modo maestro (0). La diferencia entre los modos es que el modo maestro
hace que el sistema se conecte al servidor OWL directamente, mientras que el modo
esclavo lo hace por medio de una aplicación cliente, como el Master.
Las líneas siguientes definen, y configuran, la lista de marcadores que se van a utilizar en
la aplicación. Éstas empiezan con la etiqueta <owl> y tienen la siguiente estructura:
Número de sensor : Tipo de marcador ID_LED
La manera de ejecutar el servidor con el archivo de configuración, en la máquina utilizada
es la siguiente:
cd vrpn_phasespace7.13/vrpn/server_src/pc_linux ./vrpn_server –fconfiguracionPhase.cfg
CLIENTE
30
El lado cliente es escrito en C++ y se encarga de pedir los datos, remotamente, para ser
procesados. Es relativamente sencillo el manejo del sistema pues solo es necesario utilizar
un objeto de tipo vrpn_tracker_remote que se encuentra en vrpn_tracker.h.
…
El objeto mencionado se configura pasándole al constructor una cadena de caracteres que
tiene la estructura: “nombre_publico@tcp://<dirección ip>”. Luego, simplemente se le da
el nombre a la función de callback que va a manejar los cambios en el tracker. Con esto, se
deja la aplicación en un loop que esté llamando constantemente al “mainloop” del
tracker.
Ahora, la función de callback se llama automáticamente cada vez que hay un cambio en
las componentes de los marcadores del tracker de VRPN. A ésta función le entra un objeto
de tipo vrpn_TRACKERCB que es la que finalmente contiene la información de la posición
de los marcadores.
31
El objeto vrpn_TRACKERCB tiene todos los atributos necesarios para el manejo de la
información. De éste, se puede sacar el número de sensor, la posición x, y, y z, entre otras
cosas útiles al usuario.
4.2 Subsistema de captura de video
Este subsistema es el encargado de dar retroalimentación visual al usuario. La idea es
tener una cámara que transmita, en primera persona, imágenes actualizadas provenientes
del frente del robot. Para entender el comportamiento funcional del mismo, se muestra
en la figura 9 una representación de caja negra en donde se ven las entradas y salidas
básicas de este subsistema.
Figura 9. Diagrama de caja negra de subsistema de captura de video.
Los elementos implicados en este subsistema son:
• Laptop. • Cámara de Video Logitech Quickcam Pro 9000. • Sistema central.
Subsistema de captura de video Imagen capturada remotamente
Imagen lista para ser mostrada en el cliente
32
4.2.1 Cámara de video Logitech Quickcam Pro 9000
La cámara de video utilizada es la Quickcam Pro 9000 fabricada por Logitech [12]. Esta es
una cámara web de altas prestaciones capaz de grabar video fluido en alta definición
(720p) así como tomar fotos de 8 megapixeles. Tiene auto focus de precisión y un
micrófono con cancelación de ruido. Además, esta cámara es compatible con directshow,
requisito indispensable para el manejo del video en la aplicación servidor del sistema
embarcado en el robot.
4.3 Subsistema de Robot
Este subsistema es el encargado de recibir y ejecutar los comandos de movimiento del
robot móvil, así como de transmitir a la aplicación cliente los datos obtenidos del sensor
láser. El funcionamiento básico del mismo se ve en la figura 9 donde se muestra una
representación de caja negra en donde se ven las entradas y salidas básicas de este
subsistema.
Figura 10. Diagrama de caja negra de subsistema de robot.
Los elementos involucrados en este subsistema son los siguientes:
• Robot Pioneer P3DX
• Sensor Láser hokuyo URG-04LX
Subsistema de robot Comandos de movimiento
Datos de posición de los sensores láser (en el cliente)
33
• Sistema central
4.3.1 Robot Pioneer P3DX
El P3DX es un robot diferencial fabricado por Mobile Robots Inc. [10]. Este robot se
caracteriza por su fácil manejo y puesta a punto. De fábrica, el robot viene equipado con
motores en cada rueda, llantas de 19 centímetros, cuerpo de aluminio, 8 sensores de
ultrasonidoybaterías. En cuanto a software, viene equipado con el kit de desarrollo
compuesto por los siguientes elementos:
LibreriasCore de Aria.
Simulador “MobileSim”.
MobileEyes.
Mapper 3 (Basic).
Figura 11. Robot P3DX. Tiene embarcado una tarjeta de red inalámbrica y un sensor laser ubicados en la parte superior del robot. Adicional a esto, se ha acondicionado un computador portátil con una cámara web Logitech para el manejo del video.
34
En el proyecto, se van a utilizar las funciones más básicas de movimiento: Girar izquierda,
girar derecha, moverse hacia adelante, y moverse hacia atrás. Por sí solo, el robot móvil
no cuenta con muchos sistemas de información sensorial. Tiene unos sensores de
ultrasonido que toman lecturas de proximidad, pero este sensor no suele ser muy
confiable. El robot utilizado en el laboratorio cuenta con dos sistemas adicionales
descritos en secciones más adelante (sección 4.1.4 y capítulos 4.1 y 5, para ser precisos)
que corresponden a un sensor láser, para medidas de proximidad más fiables, y un
sistema de captura de video que brinda información sensorial adicional.
4.3.2 Sensor Láser Hokuyo URG-04LX
El HOKUYO URG-04LX [11] es un sensor láser de altas prestaciones utilizado
principalmente en robótica. Este sensor ofrece interfaces de conexión serial (RS-232) y
USB para proveer los datos de la escaneada. El campo de visión es de 240 grados con una
resolución de 0.32 grados a un frecuencia de 10Hz. Es capaz de leer distancias desde los
20mm hasta los 4 metros. Por ser usado en robots autónomos, ha sido pensado para que
consuma muy poca potencia (2.5W). Las especificaciones completas se muestran en la
tabla a continuación.
En el proyecto, se utiliza este sensor para dar información sensorial del ambiente local del
robot. Las lecturas obtenidas se muestran al usuario en un radar,logrando que éste
Figura 12. Sensor Láser Range Finder HOKUYO URG-04LX.
35
identifique más fácil y eficazmente distancias de los objetos que tiene al frente. El campo
de visión usado es de 160 grados (aunque el láser permita más) para que la estructura de
montaje no interfiera con las lecturas.
4.4 Sistema central
Este sistema es diferente a los demás. Está relacionado con todos los subsistemas pues
tiene componentes de cada uno, como se ve en el diagrama de despliegue. Por el lado del
video, éste es el que tiene el cliente que pide (y procesa) la imagen enviada desde la
cámara. Por otro lado, pide los datos del láser como coordenadas rectangulares. Y por el
lado de la detección gestual, es en este sistema donde se encuentra el cliente que pide los
datos de los marcadores y hace la detección del gesto. Todos estos subprocesos son
considerados parte de los otros subsistemas, por su división funcional. Aun así vale aclarar
que es en este sistema donde se ejecutan. La responsabilidad del sistema central, que no
está ligada a los otros subsistemas, es el que se encarga de poner de manifiesto las
entradas de video y láser en una proyección para retroalimentar al usuario. Se muestra el
video, como retroalimentación principal, y se muestran los puntos del láser en un radar en
la esquina superior derecha. En la siguiente figura, se encuentra la representación de caja
negra donde se muestran las entradas y las salidas del sistema.
Figura 13. Diagrama de caja negra del sistema central.
Sistema central
Imagen de video Retroalimentación
(al usuario) Puntos/coordenadas del laser
36
4.5 Alternativas de diseño
Como alternativas de captura de movimiento se tenía otro sistema basado en esferas
reflectoras. El sistema seleccionado se utilizó ya que ofrece una mayor precisión y
facilidad de calibración. En cuanto al robot, otro modelo del robot seleccionado
proporcionaba la funcionalidad del servidor de video con una cámara integrada, el cual no
fue posible utilizar debido a fallas técnicas. Existían además otros modelos disponibles de
robots en el laboratorio, sin embargo no ofrecían una plataforma adecuada para
transportar una laptop.
37
5. IMPLEMENTACIÓN
La implementación del proyecto está basada en una arquitectura de Cliente-Servidor en la
cual el procesamiento se realiza en el cliente y el servidor simplemente ejecuta
instrucciones y proporciona información. Este modelo fue seleccionado ya que el robot en
sí únicamente puede realizar las tareas antes mencionadas y cualquier lógica debe ser
implementada en un cliente de control.
Debido a que el robot seleccionado no proporciona ninguna imagen de navegación por sí
mismo, se tomó la decisión de implementar un servidor de video que proporcione,
mediante el uso de una cámara web, la vista del robot. De modo que la implementación
consta de dos servidores en el robot y un cliente para ambos.
La secuencia que debe seguir el programa principal del sistema central debe tener en
cuenta una inicialización del sistema, conexión con los servidores correspondientes, un
ciclo principal y un cierre apropiado. En éste ciclo se debe tener en cuenta la interacción
con cada uno de los servidores del sistema, a saber: el servidor del sistema de captura de
movimiento, el servidor del robot y el servidor de video.
38
Como se puede observar en el diagrama anterior, la implementación propuesta se divide
en varios elementos que conforman la solución. Debe existir un proceso que determine la
posición del usuario, con el objeto de almacenar el comando a enviar al robot, debe existir
un proceso que reciba las imágenes del servidor de la cámara y las almacene para luego
ser utilizadas y debe existir un proceso que construya la ventana principal basado en la
imagen almacenada y las lecturas del láser.
Figura 14. Diagrama de secuencia del sistema central. Se observa la inicialización de componentes, conexión con servidores, el ciclo principal, y la condición de salida. La transición de estado se expresa verticalmente, mientras que subprocesos se expresan horizontalmente. Estos subprocesos son ejecuciones ligadas directamente a su estado e implican salidas del sistema, ya sean a la pantalla del usuario o al robot.
Fin
SI
NO Condición de salida
Leer teclado
Construir y pintar la ventana principal
Imagen actual
Solicitar la imagen de la cámara
Lecturas del láser
Solicitar las lecturas del láser
Comandos de movimiento
Detectar la posición del usuario
Solicitar la posición de los marcadores
Conexión con servidores
Inicio
39
La condición de salida la determina el usuario sobre la máquina cliente. Basta con
presionar [Esc] para dar la instrucción de detener la aplicación, la cual envía un comando
de salida al servidor de imágenes, cierra las conexiones con los servidores y finaliza su
ejecución.
5.1 Subsistema Detección/Identificación Gestual
Adicional al servidor del robot, el sistema de captura de movimiento tiene a su vez un
servidor que proporciona un medio de interacción con dicho sistema. La aplicación debe
proporcionar un mecanismo de comunicación con este sistema con el objeto de obtener
las lecturas del mismo y determinar la acción correspondiente. Éste mecanismo consiste
en enviar peticiones a través del protocolo TCP solicitando las posiciones de los
marcadores. Una vez se obtienen estas posiciones x, y, z, en milímetros, es posible
determinar el gesto que el usuario está realizando.
Figura 15. Usuario usando el sistema. Éste tiene el brazo extendido al frente, posición que indica movimiento del robot en esta misma dirección.
40
Lo primero es el proceso que determina la posición del usuario. Debido a la simplicidad de
las instrucciones a enviar, la solución más sencilla a éste problema es utilizar un vector de
dirección del brazo que permita determinar, respecto a unos ejes relativos, la intención
del usuario. Ya que no se puede esperar que todos los usuarios realicen la misma postura
exactamente igual cada vez, el sistema debe ser robusto ante variaciones en la postura del
usuario.
Dicho esto, el proceso a seguir es el siguiente: primero se determinan cuales lecturas de
los marcadores representan los extremos del brazo, lo cual es necesario ya que en ciertas
posiciones no se obtienen lecturas de todos los marcadores, una vez hecho esto se traza
un vector entre las posiciones de los marcadores extremos. Teniendo un vector, se puede
determinar la “dirección dominante”, siendo esto la dirección caracterizada por la
componente vectorial x, y o z que posea mayor magnitud. Una vez se obtiene la dirección
dominante, se puede establecer la intención del usuario dada la calibración del sistema. Es
decir, la ubicación del usuario supone los ejes X e Y alineados con la pantalla de
visualización y el eje Z en dirección saliente de la misma (hacia atrás).
Bajo esta convención, por ejemplo, si el usuario desea dar la orden de avanzar, debe
apuntar su brazo hacia adelante, lo que para el sistema sería el eje Z negativo, y esto se
traduce en una componente Z dominante en dirección negativa. Debido a esto, la posición
espacial del usuario se torna irrelevante siempre que éste se encuentre observando la
pantalla de visualización.
Una vez se conoce la intención del usuario se debe almacenar la información para que el
comportamiento de control del robot pueda enviar el comando correspondiente. Aunque
la ejecución del comando se realice asíncronamente, es posible inyectar información a
dicha ejecución para realizar la acción pertinente.
5.2 Subsistema de Captura de Video
El servidor de video se basa en la tecnología de directShow de Microsoft. La captura de
video se realiza mediante un grafo de filtros de esta tecnología. Cada filtro proporciona
41
una funcionalidad necesaria para capturar el video, haciendo la captura independiente de
la cámara web utilizada, siempre que ésta sea compatible con directShow, y dejando el
manejo de controladores al sistema operativo.
El grafo base consta de cuatro filtros. El primero proporciona acceso a la cámara web, la
cual puede ser cualquier cámara web conectada al sistema que sea compatible con
directShow. Mediante una directiva de la librería, es posible obtener un filtro vinculado
con la cámara web predeterminada. El segundo filtro obtiene las imágenes de la cámara
en un formato base de directShow, un AVI. Esto último conlleva al uso del tercer filtro, el
cual es necesario para tener acceso a los datos de la imagen. Finalmente se utiliza un filtro
de “rendering” o visualización, el cual pinta en pantalla la imagen obtenida. Este último
filtro fue reemplazado en la aplicación por un “null-renderer”, el cual no pinta en pantalla
la imagen sino que permite tener acceso al buffer de memoria que contiene la imagen a
pintar, de este modo es posible enviarla al cliente.
Una vez se obtiene la imagen, es necesario enviarla al cliente. Para esto se utilizaron
paquetes UDP, protocolo que permite transmitir audio y video a gran velocidad,
sacrificando calidad del video por velocidad de transmisión. Debido a una restricción del
protocolo, es imposible enviar paquetes de un tamaño superior a 64kB, por lo que se debe
segmentar la imagen en paquetes de igual tamaño para reconstruirla del lado del cliente.
Luego de una serie de pruebas, se determinó que el tamaño idóneo para la transmisión es
de 15360 bytes, lo que permite segmentar la imagen en exactamente 60 paquetes de este
tamaño.
Figura 16. Grafo base de directShow utilizado para la captura de video.
42
Sabiendo que el robot ejecutará la instrucción deseada, es necesario obtener la imagen
actual. Para ello el cliente se la solicita al servidor, quien envía la información cruda que
obtiene de la cámara. Ya que no se garantiza que todo paquete enviado llegue al destino,
la imagen anterior remplaza los paquetes perdidos en el caso que se obtenga una imagen
parcial.
Teniendo la imagen actual, tan sólo es necesario obtener las lecturas del láser para pintar
en pantalla la situación actual. El láser obtiene un vector de distancias, correspondientes a
las lecturas tomadas para distintos ángulos desde el centro del láser. Teniendo esta
información y la imagen, es posible pintar la ventana principal, la cual consta de la imagen
actual en el fondo y un “radar” en la esquina superior derecha, el cual muestra las lecturas
tomadas del láser respecto al robot.
A continuación se presenta una imagen con la retroalimentación proporcionada
43
5.3 Subsistema de Robot
El cliente del robot está en una arquitectura basada en comportamientos y el
procesamiento de la misma se realiza asíncronamente, requiriendo la definición de un
único comportamiento personalizado que ejecute el comando de dirección dependiente
Figura 17. Comparación vista externa y vista del robot.(Arriba) Interfaz gráfica de la aplicación. Se puede observar en la esquina superior derecha un radar con las detecciones del láser provenientes de objetos posicionados a menos de 4 metros del robot. Cada línea circular en el radar representa 1 metro de distancia al robot con un ángulo de visión de 160°. Arriba se muestra lo visto desde el robot. (Abajo) Se muestra una imagen de la misma escena tomada desde fuera del robot.
44
de las variables internas. Los demás comportamientos a utilizar son definidos por la
librería del fabricante y tienen mayor prioridad de ejecución, ya que estos
comportamientos tienen como propósito la seguridad del robot.
El comportamiento antes mencionado sencillamente enviará el comando de avanzar a
velocidad constante, rotar hacia la derecha, rotar hacia la izquierda o retroceder
dependiendo del gesto que haya sido detectado. Éste comportamiento sólo será
ejecutado si ninguno de los comportamientos del fabricante utilizados se encuentra en
ejecución.
Los comportamientos del fabricante utilizados son, en orden de prioridad: “Stallrecover” y
“Avoidobstacle”. El primero se encarga de “sacar de aprietos” al robot en caso de que los
comando enviados no puedan ser ejecutados. Básicamente intenta retroceder una
distancia aleatoria dentro de un rango y luego girar un ángulo aleatorio dentro de un
rango. El segundo impide una colisión del robot contra algún obstáculo mediante lecturas
de láser, teniendo en cuenta una distancia umbral de 50cm de evasión de un objeto.
Figura 18. Implementación móvil seleccionada. Se coloca una portátil sobre el robot para complementar visualmente la información proporcionada por el robot. Éste equipo cuenta con una cámara web, la cual proporciona las imágenes.
45
5.4 Resultados esperados
El fundamento principal de este proyecto es mejorar la interacción del usuario con el
robot, tornando al sistema de control en algo sencillo y divertido de usar. Dicho esto se
espera que la interacción con el sistema sea agradable para el usuario, que sea seguro
para tele-operar el robot, que tenga un buen tiempo de respuesta, que proporcione
información de calidad con un mínimo retardo para actuar rápidamente, y que presente
una gran estabilidad de comunicación con el robot.
Dicho esto se espera tener una retroalimentación positiva de los usuarios de prueba con
respecto a los aspectos antes mencionados. El sistema propuesto debe satisfacer esos
requerimientos para ser considerado exitoso.
En cuanto a la implementación, se espera que el robot tenga un buen rango de
movimiento. Aunque estamos sujetos al alcance que tenga la conexión inalámbrica a la
red. Y que la respuesta de la retroalimentación sea aceptable, teniendo en cuenta que se
están usando webcams.
46
6. VALIDACIÓN
6.1 Método
Para verificar la experiencia de usuario se van a realizar pruebas de campo con el sistema
total funcionando. La idea es que personas ajenas al proyecto, y de diferentes niveles de
conocimiento y familiaridad, se coloquen el traje de captura y utilicen el sistema de la
manera que consideren apropiada. Se les dará unas indicaciones previas, así como un
camino por el que el robot puede ser movido libremente. El robot debe recorrer una
trayectoria de aproximadamente40 metros por un camino pre-definido para luego
regresar al lugar de pruebas. Al final de la tarea, el usuario evaluaráel sistema por medio
de una encuesta corta, descrita más adelante.
La validacióntotal del sistema (tarea y encuesta), por usuario, se planea de
aproximadamente 15 minutos. Lo suficiente para darse una idea de las posibilidades de
interacción del proyecto, pero sin llegar a ser molesta al sujeto de pruebas.
Los puntos que se van a evaluar en la encuesta son: facilidad de manejo, comodidad a la
hora de usar el sistema, viabilidad, comparación con otras técnicas de interacción, puntos
fuertes, puntos débiles a mejorar, y apreciación general del proyecto.
Para comparar la eficacia de la solución, se tendrá en cuenta un recorrido realizado
mediante el control tradicional como referencia. El tiempo de éste recorrido fue de
aproximadamente 5 minutos con una velocidad media de 266 mm/s. Se tendrá en cuenta
que la velocidad programada en el robot es de 150 mm/s, lo que resultaría en un tiempo
estimado ideal del recorrido de 8 minutos con 53 segundos.
47
6.2 Encuesta proyecto de grado SISTEMA ROBÓTICO DE EXPLORACIÓN ASISTIDO POR CAPTURA DE MOVIMIENTO
Califique de uno (1) a cinco (5), donde 1 es muy negativo y 5 es muy positivo.
1 2 3 4 5 1. Facilidad para manejar el sistema 2. Comodidad para usar el sistema. 3. Satisfacción en la ejecución de la tarea de exploración 4. Fidelidad en comandos de movimiento. 5. Fidelidad en información sensorial (video + laser)
Marque con una “X” una de las opciones descritas inmediatamente después de la pregunta.
6. Considera que este tipo de sistema (por captura de movimiento) mejora la interacción convencional basada en un control remoto?Si_______ No________
7. Cuál de las siguientes opciones considera punto fuerte del proyecto.
Captura de Movimiento ________ Interacción ________ Información sensorial ________ Concepto general ________
8. Cuál de las siguientes opciones considera punto a mejorar del proyecto.
Captura de Movimiento ________ Interacción ________ Información sensorial ________ Concepto general ________
48
6.3 Validación de resultados
Figura 19. Aceptación general de la solución. Preguntas de la 1 a la 5 de la encuesta.
Figura 20. Gráfico de apreciación de la aceptación. Mejora, del tipo de interacción. Pregunta 6 de la encuesta.
0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%
100,00%93,33%
77,78%91,11% 91,11%
75,56%
Aceptación general de la solución
22,22%
77,78%
¿Considera que éste tipo de sistema mejora la interacción convencional?
No
Si
49
Figura 21. Gráfico de apreciación del punto fuerte del proyecto. Pregunta 7 de la encuesta.
Figura 22. Gráfico de apreciación del punto a mejorar del proyecto. Pregunta 8 de la encuesta.
8,33%
33,33%
25,00%
33,33%
¿Cuál considera el punto fuerte del proyecto?
Captura de movimiento
Interacción
Información sensorial
Concepto general
10,00%
40,00%50,00%
0,00%
¿Cual considera un punto a mejorar del proyecto?
Captura de movimiento
Interacción
Información sensorial
Concepto general
50
Figura 23. Tiempo empleado por los usuarios de prueba realizando el recorrido de evaluación. El
tiempo promedio es de 12 minutos 44 segundos.
De los resultados de las encuestas se puede deducir el alto grado de aceptación que tuvo
la idea como concepto general. Se ve reflejado en los resultados de la figura 26 en donde
la gran mayoría piensa que el prototipo mejora la interacción convencional. Esto implica, a
su vez, que los usuarios de una u otra forma se sintieron manejando el sistema de manera
más natural que la convencional.
El proyecto, según resultados de la figura 24, tiene varios puntos a favor. A considerar,
principalmente, el concepto general y la interacción, aunque los resultados están bastante
bien repartidos (con solo un 8% de diferencia entre primero y segundo). Se considera que
los usuarios opinaron favorablemente de todos los ámbitos de evaluación exceptuando la
muestra de información. Esto se ve claramente reflejado en los resultados de la figura 25
en donde la mitad de los encuestados votaron negativamente este ítem. No deja de ser
curioso el hecho de que un 25% opinan que la información es punto fuerte del proyecto al
mismo tiempo que es el ítem menos valorado. Esto, al parecer, tiene que ver con los
distintos tipos de información mostrados. Mientras que a los usuarios, en general, se les
hizo incomodo el video mostrado de la cámara del robot, quedaron gratamente
0:00:00
0:02:53
0:05:46
0:08:38
0:11:31
0:14:24
0:17:17
0:20:10
Tiem
po
Tiempo del recorrido
51
sorprendidos con la implementación del radar laser. Se piensa que los que votaron
favorablemente a este ítem lo hicieron pensando justamente en este último aspecto.
Finalmente, los tiempos de desempeño de las pruebas de campo reflejan una demora
adicional a la solución ideal descrita en el método de validación. Esto se esperaba pues se
utilizó el caso ideal como punto de comparación. Aun así, se considera que los tiempos
obtenidos son bastante aceptables teniendo en cuenta la poca preparación previa de los
usuarios y las fallas de video. En promedio, los tiempos se ubican en los 12 minutos
alejándose por 4 minutos, aproximadamente, del tiempo ideal. Los últimos dos casos
tienen tiempos menores pues coincidieron con un breve periodo de tiempo en el que el
video funcionó más fluidamente.
En cuanto a las expectativas, se puede decir que se cumplieron en su mayoría. Los
usuarios consideraron un paso adelante esta nueva interacción como método viable de
teleoperación, y se tuvo una gran autonomía de funcionamiento del robot, que nunca se
salió del rango de cubrimiento de la red inalámbrica. Lo único achacable, es el hecho de
no haber mostrado con suficiente calidad el video arrojado por el servidor embarcado en
el robot. En ciertos puntos de la prueba no se sabía con exactitud que se tenía en frente,
además que durante el total del recorrido, la latencia del video era de aproximadamente 2
segundos. Esto impedía interactuar de la mejor manera con el robot, pues la interacción
tiene una latencia diferente considerablemente menor (500ms).
52
7. CONCLUSIONES
7.1 Discusión
Este trabajo presenta una propuesta de un sistema de tele-operación de un robot móvil
dirigido por gestos de movimiento del usuario. El sistema fue validado experimentalmente
con pruebas de usuario en nuestro laboratorio de robótica. De acuerdo a los resultados
obtenidos, el tener un sistema de control no convencional es una idea implementable y
con una aceptación favorable por parte de un diverso grupo de usuarios finales. La
tendencia del público en general es la de aceptar nuevos sistemas de control que
involucren ambientes inmersivos.
En este tipo de sistema se puede lograr una amplia aceptación si se logra diseñar una
interacción sencilla, divertida y que no requiera de una gran capacitación. Como se pudo
observar en los resultados, la interacción obtenida fue aceptada debido en gran parte a la
facilidad de manejo del sistema. Bastaron unas simples instrucciones de uso para que los
usuarios utilizaran satisfactoriamente el sistema.
A pesar de la gran aceptación, un sistema de este estilo debe proporcionar una interacción
fluida para que el concepto general resulte interesante. En este caso particular hay lugar a
una gran mejora al componente de transmisión de video, el talón de Aquiles del proyecto.
Los resultados obtenidos muestran un descontento principal en lo referente al video y la
retroalimentación sensorial, lo cual resalta una gran incomodidad al momento de utilizar
el sistema. Esta debilidad aumenta la latencia del sistema, crítica en un sistema de tele-
operación, que repercute en mayores tiempos en la toma de decisiones por parte del
usuario para realizar una tele-operación fluida.
53
7.2 Trabajo futuro
Este proyecto se presta para hacer mucho trabajo futuro. Actualmente, se ha estado
trabajando arduamente para encontrar un tipo de control más intuitivo y divertido de
usar. Hasta ahora se han hecho varios intentos, unos más afortunados que otros.
El proyecto se divide en tres grandes áreas en las que se podría hacer un trabajo posterior.
La primera área es la de la retroalimentación del usuario. Se considera que el proyecto
podría mejorar en este aspecto pues se implementó utilizando una cámara web, que
aunque proporciona resultados aceptables, podría ser mejorado. El subsistema
implementado resulta lento al momento de transmitir el video y presenta una gran
pérdida de paquetes, por lo que hay lugar a una gran mejora de este subsistema. Éste tipo
de cámaras suelen tener una respuesta lenta además de tener que hacer tratamientos en
la imagen antes de poder ser mostradas (que implica esfuerzo de máquina). Mejorando el
dispositivo de captura de imagen se podría mejorar la experiencia de usuario. Así lo
indican las encuestas en los puntos a mejorar del proyecto (figura 25) y así lo
manifestaron los usuarios que utilizaron el sistema.
Otra área en la que se podría trabajar a futuro es en el de la interacción. Depende de si es
viable el sistema propuesto se podría pensar en utilizar otro tipo de movimientos para
representar movimiento en el robot, o simplemente utilizar los que ya se tienen pero
agregando otros comandos. Por ejemplo, si se tiene una cámara con movimiento se
podría pensar en que un brazo controle el movimiento propio del robot mientras que el
otro controle el movimiento de la cámara.
Por último, se considera que se podría trabajar en la portabilidad del subsistema de la
captura de movimiento para hacerla útil a otro tipo de aplicaciones. Se podría hacer el
sistema más portable y compatible para ser usada con dispositivos de entrada diferentes.
Es decir, cambiar el servidor de captura de movimiento por un nuevo dispositivo que
proporcione las lecturas necesarias para detectar el gesto del usuario de una manera más
portable.
54
8. REFERENCIAS
[1] C. Guo and E. Sharlin, “Exploring the use of tangible user interfaces for human-robot interaction: a comparative study,” 2008.[en línea] Disponible en http://portal.acm.org/citation.cfm?id=1357076 [2] A. Steinfeld, T. Fong, D. Kaber, M. Lewis, J. Scholtz, A. Schultz, and M. Goodrich, “Common metrics for human-robot interaction,” Proceeding of the 1st ACM SIGCHI/SIGART conference on human-robot interaction - HRI '06, 2006, p. 33. [3] C.W. Nielsen and M.a. Goodrich, “Comparing the usefulness of video and map information in navigation tasks,” Proceeding of the 1st ACM SIGCHI/SIGART conference on Human-robot interaction - HRI '06, 2006, p. 95. [4] T.H. Song, J.H. Park, S.M. Chung, S.H. Hong, K.H. Kwon, S. Lee, and J.W. Jeon, \A study on usability of human-robot interaction using a mobile computer and a human interface device," Proceedings of the 9th international conference on Human computer interaction with mobile devices and services - MobileHCI '07, 2007, pp. 462-466. [5]F. Prieto, J.E. Hernández, and J.B. Gómez, "Manipulación de robots con base en posturas labiales"Dyna, 2008, pp. 187-198.Disponible en http://redalyc.uaemex.mx/pdf/496/49615419.pdf [6] R.M. Voyles and P.K. Khoslaf, “Tactile Gestures for Human/Robot Interaction,” International Conference on Intelligent Robots and Systemas-Volume 3 – Pittsburgh, Pennsylvania, USA.Disponible en http://www.computer.org/portal/web/csdl/abs/proceedings/iros/1995/7108/03/71083007abs.htm [7]PhaseSpaceMotion Capture | Products, PhaseSpace, http://www.phasespace.com/productsMain.html, Fecha de último acceso: 20 de Julio de 2010. [8] Padilla Andrés“ JUEGO DE REALIDAD ALTERNA MISIÓN S.E.N.E.C.A: Ambiente de interacción: HMD más Tracker,” Universidad de los Andes, 2008. [9]Microsoft Corporation “MSDN Library”, 2010. [en línea] disponible en http://msdn.microsoft.com/en-us/library [10] Intelligent Mobile Robotic platforms for applications, research and rapid prototyping, Mobile Robots Inc., http://www.mobilerobots.com/Mobile_Robots.aspx, Fecha de últimoacceso: 20 de Julio de 2010.
55
[11] Scanningrangefinder URG-04LX, HOKUYO, http://www.hokuyo-aut.jp/02sensor/07scanner/urg_04lx.html , Fecha de último acceso: 20 de Julio de 2010. [12]QuickCam Pro 9000, Logitech, http://www.logitech.com/repository/1403/pdf/25618.1.0.pdf , Fecha de último acceso: 20 de Julio de 2010
56
9. APÉNDICES
A. Código fuente
El código fuente del sistema ha sido entregado en formato digital junto con las
dependencias correspondientes. El disco entregado tiene la siguiente estructura:
Software/mainClient
Software/videoCaptureServer
Software/Dependencias
Documentación/Documento.pdf
57
B. Configuración inicial del sistema de captura de movimiento
El sistema IMPULSE de captura de movimiento de PhaseSpace es relativamente fácil de
usar. Sin embargo, es necesario conocer el funcionamiento del mismo para lograr una
configuración y utilización adecuadas. A continuación se muestran los diferentes aspectos
que consideramos podrían ser de interés a la hora de familiarizarse con el sistema.
1. Energía del sistema
El sistema, al ser inalámbrico, necesita de baterías para funcionar. Esta, precisamente, es
una de las funciones del driver. Normalmente, el sistema tiene una autonomía de entre
dos a cuatro horas de uso continuo (u ocho horas en uso normal). Para cargar el driver se
puede usar la estación base, como se muestra en la imagen, o un tipo de cargador especial
que tiene terminaciones RJ11.
Figura 24. LED Driver conectado a la estación base. Permite esto cargar el driver además de codificar la información.
58
2. Configuración inicial – Crear perfil
Para cada aplicación que se vaya a crear, que use el sistema, es necesario crear un perfil.
Éste es el que guarda información importante como el número de leds a utilizar, el
número de puerto al que está conectado, etc.
1. El programa de configuración principal del sistema está hecho en php y se ingresa
por medio de cualquier browser, tanto local como remotamente. Simplemente hay
que digitar la dirección ip del servidor (o localhost si es en la misma máquina) y
aceptar. Aparecerá en pantalla una petición de usuario y contraseña. Ésta es
proporcionada a los clientes por phasespace que, por defecto, es “admin” como
usuario y “phasespace” como contraseña. Aparecera una pantalla como la que se
muestra a continuación.
Se escoge la pestaña “LED Devices” que es donde se encuentra la información que se va a manipular. En la parte superior de la pantalla están los pasos necesarios para codificar el “driver” mientras que la parte inferior muestra los diferentes perfiles.
Figura 25. Pantalla principal del sistema de configuración. Pestaña LED devices.
59
úSi no se ha creado un perfil se debe presionar el botón “create new profile”. Aparece una pantalla en la que se ingresa el nombre del perfil, el número de slots que se van a utilizar, y una pequeña descripción. Se ingresan estos datos y se dáclick a “createthisprofile”.
2. En la siguiente pantalla es donde se ingresa la información de qué tipo de dispositivo es el que va a ser utilizado. En este caso, se elige la opción de “Driver” agregando un nombre a éste, si se quiere. Luego se da click en “AddthisDevice”.
Figura 26. Creación del perfil. Pantalla inicial.
60
3. En la pantalla que aparece se escribe el nombre de la cadena de leds que se va a
utilizar. Esto hace que se puedan tratar cadenas de manera independiente para
abstraer un poco la información. Así, por ejemplo, se puede tener una cadena que
sea la del brazo izquierdo, y otra que sea la del brazo derecho. También es
necesario agregar el número de puerto físico al que va a ser conectada la cadena,
la cantidad de LEDS que va a tener la cadena, así como su orden. Es importante
anotar que el orden que se da en este paso será el orden definitivo que va a tener
la cadena, por lo que es necesario aprendérsela para reproducirla exactamente en
la conexión de los LEDS del traje (que también tienen números de la A a la Z); Una
vez definida la secuencia se guarda todo presionando “Savethis Driver”.
Figura 27. Creación del perfil. Elección del dispositivo.
61
Figura 28. Crear perfil. Pantalla de configuración de la cadena de marcadores.
62
3. Configuración inicial - Codificar
Cada vez que se va a usar el sistema se debe cargar la configuración adaptada a cada
aplicación. A esto lo llaman codificar “encode” y es lo que, finalmente, sube la información
al “LED Driver”. Para hacer esto hay dos pasos simples.
1. En la página principal se ingresa a la sección de “LED Devices” y ahí se da click en
“profileselection” ubicado en la parte superior. Esto hace que aparezca un menú
en el que se debe ingresar hasta un máximo de 4 perfiles. Se verifica que el driver
utilizado, el puerto, y la cadena sean correctas y se presiona “Save”.
Figura 29. Pantalla de codificación. Escogencia del perfil.
63
2. Una vez más, en el menú principal (sección “LED Devices”) se presiona, esta vez, el botón “Encode”. Esto hace que aparezca un pequeño menú en el que se escoge el driver que se va a configurar (si es que se configuraron varios) así como la potencia a la que se va a transmitir. Una mayor potencia hace que el sistema tenga un mayor alcance. Sin embargo, esto hace que la batería dure menos. Por defecto viene un una potencia de 0.6 que da un buen balance. Se da click en “Encode”. Vale aclarar, que el “LED Driver” a configurar debe estar conectado al servidor por medio de la “Base Station”. Aparecerá un mensaje diciendo que se ha codificado correctamente. Para asegurarse de eso, es aconsejable mirar el “LED Driver”. Si los indicadores luminosos empiezan a girar indican que ha quedado correctamente configurado. Se retira el driver de la estación base y se conecta al traje siguiendo los parámetros con el que fue configurado. Ya no es necesario hacer nada más en el sistema de configuración.
Figura 30. Pantalla de codificación. Se escoge el dispositivo, la potencia, y se codifica.
64
C. Calibración del sistema de captura de movimiento
Una de las partes críticas del manejo del sistema de captura de movimiento es la
calibración. Esta le permite al sistema hacer mediciones que hacen ajustes de precisión en
los datos. Igualmente, es en esta etapa en donde se definen los ejes y el origen.
Hay dos maneras de calibrar el sistema: el modo básico, y el modo avanzado. El primero,
es un “wizard” que va guiando al usuario mediante pasos sencillos. Sin embargo, se
considera más rápida y práctica la configuración avanzada. Se abre la aplicación,
escogiendo el modo avanzado, apareciendo la siguiente ventana.
Primero se da click en el botón “connect”. El sistema reconoce automáticamente la
cantidad de cámaras conectadas. Como se ve en la imagen, se tienen disponibles, a la hora
de realizar este documento, seis cámaras. Y se enciende la barra de calibración.
Figura 31. Pantalla de calibración. Vista principal.
65
Luego de la conexión, se elige la opción de “Calibration” en el menú desplegable y la vista
2D, y se presiona el botón “calíbrate”. De esta manera, se empiezan a adquirir los datos
que van a hacer los ajustes. En este paso se utiliza la barra apuntando a cada una de las
cámaras de tal manera que se cubran todos los ángulos de visión de ésta. Los ángulos de
visión se discretizan en el software en cuadros, como se puede ver en la imagen. Cada vez
que una sección de la cámara identifica 4 o más LEDS (identificados como puntos blancos
en el software) se ilumina de verde. La idea de esta parte de la calibración es rellenar la
mayor cantidad de cuadros posibles. Mientras más mejor, sin embargo, es aconsejable
rellenarlos todos para evitar repetir este paso.
Inicialmente, este paso puede llegar a ser tedioso (y lo es!), pero con un poco de práctica
se puede terminar rellenando los cuadros en uno o dos minutos. Como consejo, es bueno
Figura 32. Pantalla de calibración inicial. Etapa en la que se pasa la barra de calibración por cada una de las cámaras. Se han de llenar los cuadros de verde lo más posible.
66
saber que la parte derecha del rombo son los datos adquiridos a la derecha de la cámara,
la izquierda lo mismo, pero que la parte de arriba y abajo del rombo están invertidos: la
parte de arriba representa los valores adquiridos de la parte de debajo de la cámara y la
parte de abajo lo contrario.
Normalmente, al estar enfocados en una cámara, se toman datos igualmente en las otras.
Por lo que es aconsejable empezar con las cámaras de la mitad. Esto hace que los datos a
tomar en las cámaras de los extremos sean mucho menos, pues ya muchos se han
adquirido.
Una vez iluminados los rombos se da click en el botón “calíbrate”. Con esto, el sistema
empieza la calibración automática de cuatro pasos. A la derecha de la aplicación, se indica
si cada uno de los pasos ha pasado con éxito: debe salir un OK en cada una de ellas.
En el cuadro principal, aparece una representación espacial del sistema en el que se puede
ver la barra en una representación de tres dimensiones.
Figura 33. Pantalla de calibración final. Cuando todo ha salido bien.
67
Por último, hay que indicar los ejes que va a usar el sistema. Dependiendo de éstos, y del
origen, es que los datos van a ser representados. Para hacer esto se elige la opción de
“alignment” en el menú desplegable y se presiona el botón de align. Luego, se debe
colocar la vara de calibración en el punto que se quiere sea el origen. Es importante notar
cual es el marcador de la vara identificada con el número cero, pues es éste punto el que
va a adquirir. Una vez colocada la vara en posición, se da click en “snapshot”. Aparece en
pantalla un punto (donde se encontraba el marcador cero al dar click) con la etiqueta
“origin”. Ahora, es necesario desplazar el cero de la vara hacia la dirección que se desea
sea el eje X. Nuevamente se da click en snapshot. Aparece en pantalla un vector, desde el
origen, con la etiqueta “X”. Finalmente, se desplaza nuevamente la vara en la dirección
que se quiere sea el eje “Z”, nuevamente presionando “Snapshot”. El eje faltante (Y) lo
calcula el software automáticamente haciendo un producto cruz de los vectores unitarios
calculados anteriormente. Se puede comprobar que las direcciones son correctas
comparando las direcciones con la representación cartesiana ubicada abajo a la izquierda.
Se dáclick en “Save” y se cierra el programa.
Con esto, el sistema ha quedado correctamente calibrado y ya puede ser usado
normalmente. El proceso total dura aproximadamente dos o tres minutos y solo es
necesario hacerlo la primera vez que se va a utilizar el sistema (siempre y cuando no se
muevan las cámaras de posición).
