Detección y seguimiento de visitante con robot móvil

Texto completo

(1)DETECCIÓN Y SEGUIMIENTO DE VISITANTE CON ROBOT MÓVIL. ALFREDO MORALES PINZÓN. Universidad de los Andes Departamento de Ingeniería de Sistemas y Computación Bogotá, D.C. 2007 I.

(2) DETECCIÓN Y SEGUIMIENTO DE VISITANTE CON ROBOT MÓVIL. ALFREDO MORALES PINZÓN. Proyecto de grado para optar al título de Ingeniero de Sistemas y Computación. Profesor Asesor: Fernando De la Rosa, Ph.D.. Universidad de los Andes Departamento de Ingeniería de Sistemas y Computación Bogotá, D.C. 2007 II.

(3) A mi mamá,. por su amor incondicional.. III.

(4) ÍNDICE Pag. INTRODUCCIÓN. 1. 1. Marco Teórico. 2. 1.1. Robótica Móvil. 2. 1.1.1. Robot Diferencial. 4. 1.2. Procesamiento de Imágenes. 6. 1.2.1. Segmentación de Imágenes. 7. 1.3. Hardware del Robot. 8. 1.3.1. Sensores y Cámara. 11. 1.4. Software. 14. 1.4.1. ARCOS. 14. 1.4.2. ARIA. 15. 1.4.3. ArNetworking. 17. 1.4.4. ACTS. 17. 1.4.5. MOBILEEYES. 19. 1.5. Modelo Cliente Servidor. 19. 2. Propuesta de solución. 21. 2.1. Entrenamiento de ACTS. 21. 2.2. Arquitectura. 23. 2.2.1. Arquitectura de prueba. 24. 2.2.2. Arquitectura con cliente remoto. 24. 2.2.3. Arquitectura final. 26. 2.3. Ciclo de Ejecución. 26. 2.3.1. Método FIRE de ejecución. 27. 3. Pruebas y Análisis de Resultados. 30. 3.1. Iluminación. 30. 3.2. Velocidad del visitante. 30. 3.3. Comunicación Inalámbrica. 31. 3.4. Distancia y área mínima de detección. 31. I.

(5) 3.5. Arquitectura. 32. 4. Conclusiones y Trabajo futuro. 34. Referencias. 36. ANEXO 1. Manual de usuario de la aplicación. 38. ANEXO 2. Código de la aplicación. 40. II.

(6) ÍNDICE DE FIGURAS Pag. Figura 1. Ejemplo robot articular PUMA.……………………………………… 3. Figura 2. Localización por marcas...……............................................................. 4. Figura 3. Configuración robot holonómico…………………………................... 5. Figura 4. Configuración robot diferencial………………………………………. 6. Figura 5. Ejemplo de segmentación…………………………………………….. 9. Figura 6. Robot PIONNER P3-DX…………………………………………….. 10. Figura 7. Formas de comunicar el robot con un computador cliente…………… 11. Figura 8. Posición de los sonares en el cinturón frontal del robot……………… 13. Figura 9. Cámara PZT CANON CC50…………………………………………. 14. Figura 10. Relaciones entre el software que brinda el fabricante MobileRobots… 15. Figura 11. Ciclo de sincronización del robot…………………………………….. 16. Figura 12. Arquitectura básica de uso de ArNetworking………………………... 18. Figura 13. Ventanas de entrenamiento ACTS……………………………………. 19. Figura 14. Cambios en la segmentación de color debido al cambio de iluminación 23. Figura 15. Arquitectura básica de prueba..………………………………………... 24. Figura 16. Arquitectura con cliente remoto……………………………………….. 25. Figura 17. Arquitectura final de la aplicación…………………………………….. 26. Figura 18. Diagrama de Flujo del método fire de toma de decisiones……………. 28. Figura 19, 20 Aplicación MOBILEYES corriendo en un computador remoto………. 33. III.

(7) INTRODUCCIÓN Una de las principales funciones para las que fueron creados los robots fue el reemplazar al humano en tareas en donde su integridad se pudiera ver afectada o las tareas a realizar fueran repetitivas y desgastantes. Podemos encontrar por ejemplo robots exploradores en zonas o espacios en los que un humano no podría sobrevivir como el Sojourney, el cual fue el primer robot tele-operado que recorrió Marte, o robots ensambladores de partes mecánicas en las que las operaciones son muchas y precisas.. Como una de las aplicaciones para las que se puede usar un robot móvil y gracias a las herramientas que éstos nos ofrecen, se pensó en tener un robot que siguiera a un visitante durante su recorrido por una zona específica. Esta aplicación se puede ver como un soporte a las tareas de seguridad, ya que un humano está monitoreando desde un computador remoto el comportamiento del visitante, permitiendo tomar acciones en casos de acceso a zonas restringidas o situaciones inesperadas. En general se pueden usar el robot para otras tareas, sin embargo este ha sido el enfoque que se la ha dado.. En este documento se muestra tanto la teoría de base como la implementación, diseño, pruebas y los resultados de la aplicación la cual se ha denominado detección y seguimiento de visitante con robot móvil. Es importante señalar que el robot sobre el cual se trabajó contiene un computador embebido, así como una cámara de video en su parte superior y el hardware necesario para la adquisición de video. Además la aplicación hace uso de herramientas de segmentaciones de imágenes sobre video, el sistema operativo del robot y el API para la comunicación y uso de los servicios del robot.. En el primer capítulo del documento se presenta la teoría de las herramientas usadas en la aplicación, así como la descripción y uso del hardware y software usado. En el segundo capítulo se encuentra la propuesta de solución. En el tercero se exponen las pruebas experimentales y el análisis de los resultados y en el cuarto encontramos las conclusiones y el trabajo futuro. 1.

(8) 1. MARCO TEÓRICO En el proyecto se hace uso de varias técnicas y tecnologías en diferentes campos, como lo son robótica móvil y tratamiento de imágenes que se complementan. En este primer capítulo se busca dar una introducción a la teoría que se usó en el proyecto, así como el propósito específico para el que fueron usados.. 1.1 Robótica Móvil La robótica tiene dos grandes campos de estudio, la robótica articular y la robótica móvil. La primera se refiere a un manipulador multifuncional reprogramable con varios grados de libertad, capaz de manipular materias, piezas, herramientas o dispositivos especiales según trayectorias viables programadas para realizar tareas diversas [1], por lo general nos referimos a brazos articulados como los que se usan en el ensamblado de partes para carros o de ensamblado de circuitos integrados, en la Figura 1 se muestra un robot articulado conocido como PUMA. En cuanto a la segunda se refiere a robots cuya base es móvil, es decir que poseen un sistema de desplazamiento sobre la superficie en la que trabajan, ya sea el suelo, el agua o el aire. Un ejemplo de un robot móvil es la aspiradora robot o el perro AIBO. Estos dos campos de la robótica tienen problemas a resolver diferentes, sin embargo se pueden combinar en un mismo robot para resolver una mayor cantidad de tareas.. Uno de los principales problemas de estudio en robótica móvil es la planificación autónoma de movimientos, la cual busca encontrar un camino geométrico partiendo de una configuración inicial, es decir una posición y orientación inicial, a una configuración final teniendo en cuenta los obstáculos que puedan existir. Para resolver este problema se han planteado diferentes métodos los cuales difieren en ciertas características y se clasifican en diferentes familias. Entre las familias más importantes encontramos las esqueleto, descomposición en celdas [2], funciones de potencial y probabilísticos [3]. Es así la complejidad del problema que tiene muchas extensiones para usos reales, ya que no. 2.

(9) es suficiente el algoritmo que resuelve la rutina, además se necesitan sensores y equipos de apoyo los cuales puedan mejorar la correcta ejecución de la trayectoria.. Figura 1. Robot articular PUMA [10].. Dado el problema de planificación podemos encontrar dispositivos y sensores que ayudan a la correcta ejecución de la trayectoria. En simulación se podría decir que un robot ejecuta bien una trayectoria sin embargo esto no es suficiente para concluir que se va a ejecutar satisfactoriamente en la realidad, ya que el ambiente en el que se mueve el robot tiene variables que no se tomaron en cuenta, lo cual hace necesario un apoyo en la ejecución. Una de las técnicas que se usan para la ejecución de una trayectoria es Dead Reckoning [4] la cual usa como medidas de movimiento los sensores disponibles en las ruedas o motores los cuales por lo general son enconders, sin embargo por medio de esta técnica se obtiene un error incremental en el movimiento del robot, haciendo necesario el uso de técnicas de ubicación que disminuyan este error. Dentro de las técnicas de apoyo podemos encontrar la localización por marcas, la cual consiste en estimar la posición del robot a partir de una marca reconocida por alguno de sus sensores cuya posición es conocida [5], en la Figura 2 se muestra un tipo de marcas para localización de un robot.. 3.

(10) En el proyecto se hace uso de un robot móvil que cuenta con dos llantas, 8 sensores sonares y una cámara de video. Este robot tiene la particularidad de ser un robot diferencial el cual tiene la capacidad de rotar sobre su propio eje, además sus sensores sonares permiten tomar medidas de distancias y en especial de proximidad para no chocar contra obstáculos y en cuanto a la cámara de video nos permite tomar decisiones de acuerdo a la imagen adquirida en cierto instante. Con todo esto unido se pueden desarrollar varias tareas, en especial este proyecto.. Figura 2. Localización por marcas. Marcas visuales en forma de Z reconocidas por el robot para su localización [6].. 1.1.1 Robot Diferencial Dentro de la robótica móvil y en especial dentro de los robots equipados con ruedas se encuentran diferentes configuraciones de posición y de movimiento de las ruedas la cuales generan restricciones en cuanto a los movimientos del robot. En cuanto a la forma como se genera el movimiento se encuentran dos grupos, los robots holonómicos y los no holonómicos, su gran diferencia radica en que los robots holonómicos son aquellos que no tienen restricciones de desplazamientos, en comparación de los no holonómicos los cuales necesitan hacer giros para desplazarse. 4.

(11) hacia una dirección diferente a la actual, en la Figura 3 se muestra la configuración de un robot holonómico. Dentro del segundo grupo se encuentran los robots diferenciales.. Figura 3. Configuración robot holonómico. Puede moverse en cualquier dirección sin restricciones.. Los robots no holonómicos son los más conocidos ya que el sistema de movimiento de un automóvil pertenece a uno de los tipos de este grupo. La configuración de automóvil consta de dos ruedas traseras paralelas y dos delanteras también paralelas, además las ruedas delanteras indican la dirección del vehículo, sin embargo como una configuración más hábil encontramos robots diferenciales los cuales tiene principios de movimiento diferentes a la primera. En la Figura 4 se muestra la configuración de un robot móvil diferencial.. Los robots no holonómicos diferenciales se caracterizan por tener dos llantas las cuales manejan sus velocidades por separado, permitiendo un amplio control sobre los movimientos del robot. En primer lugar esta configuración permite dar giros sobre el eje del robot, lo cual se logra si cada llanta tiene velocidades iguales pero en direcciones opuestas, capacidad que no poseen los robots tipo vehículo los cuales tienen un radio mínimo de curvatura restringiendo el movimiento de éste. Dado esto es más fácil 5.

(12) parquear un robot diferencial que uno tipo vehículo. Por otra parte la configuración diferencial puede generar cualquier radio de curvatura haciendo que una llanta tenga mayor velocidad que la otra, ventaja que se aprovecha en el proyecto al momento de girar el robot hacia el objetivo [4].. (a). (b). Figura 4. Configuración robot diferencial. (a) Movimiento en línea recta. (b) Rotación sobre su eje.. 1.2 Procesamiento de Imágenes El interés por el humano de entender como el sistema de visión de nuestra especie es capaz de procesar toda la información recibida por el ojo y a partir de ésta poder conocer su ambiente e identificar diferentes aspectos, lo ha llevado a entender como se forman las imágenes y como se puede extraer información a partir de esta. Uno de los campos que trata este problema a nivel matemático y algorítmico es el procesamiento de imágenes.. Dentro de este campo existen varias técnicas que varían en complejidad, sin embargo todas tienen como objetivo principal extraer la información de una imagen adquirida. Encontramos por ejemplo el uso matemático del análisis de señales por medio de transformadas de Fourier y convoluciones para encontrar información de correlaciones. 6.

(13) entre regiones o detecciones de borde dentro de la imagen [7]. Una de las técnicas más usadas en este campo es la segmentación de imágenes.. 1.2.1 Segmentación de Imágenes La idea básica de esta técnica de procesamiento de imágenes es poder partir una imagen en regiones de interés. Existen varios tipos de segmentación como es la de escalas de grises por medio de límites, es decir que una parte de la imagen es aceptada si sobrepasa un límite definido sobre la escala [7]. Hay otros tipos más avanzados que hacen uso de histogramas lo cual permite una mejor separación de las regiones de interés.. Un caso particular de la segmentación es en la cual se usa el color de las partes de las imágenes para hacer la separación. La forma como normalmente se hace esta operación es por medio de filtros sobre los colores rojo (R), verde (G) y azul (A) para poder hacer una mejor caracterización del color que se esta buscando, sin embargo las imágenes digitales se pueden ver en formatos RGB (Red-Green-Blue), es decir que es la unión de todos los filtros, lo que permite identificar un color fácilmente con los valores de las tres variables.. Ya definidos el color o los colores que hacen parte de las regiones de interés se obtienen éstas, sin embargo se necesita un trabajo adicional para obtener buenos resultados. Este trabajo posterior se debe hacer ya que al segmentar la imagen se puede generar ruido o zonas pequeñas que no hacen parte de las regiones de interés. Por ejemplo si se requiere obtener la zona de una imagen sobre la cual se encuentra una pieza de metal, es necesario establecer un tamaño mínimo de la pieza para no incluir en la segmentación posibles zonas de no interés como los residuos del material. Es por esto que se hace necesario establecer restricciones sobre las regiones obtenidas.. Las restricciones que se establecen pueden variar según el objetivo de la aplicación sin embargo para nuestro caso se establece un tamaño mínimo para que una 7.

(14) región sea de interés y un número máximo de regiones de interés. La principal razón para establecer estos criterios es el cambio que sufren los colores dada la intensidad de la luz con la que están siendo iluminadas, es decir que un color de interés se puede generar sobre un superficie de no interés al cambiar la iluminación. Debido a este comportamiento se hace la suposición que esta superficie de no interés podrá ser pequeña y por lo tanto no será tomada en cuenta o por otra parte puede ser tomada en cuenta pero no tiene el tamaño necesario para ser introducida dentro del conjunto de las regiones de mayor tamaño cuya cardinalidad esta dada por el número máximo de regiones de interés.. En la Figura 5 podemos ver un ejemplo de segmentación con restricciones sobre tamaño de región y número de regiones. En la Figura 5.a se muestra la imagen sobre la cual se va a trabajar, suponemos que el objetivo es obtener la región donde se encuentra el tomate más grande. En la Figura 5.b se muestran con color azul las partes de la imagen que han sido segmentadas y en la 5.c se muestras 5 regiones cuadradas que encierran las regiones obtenidas de mayor tamaño. Claramente podemos ver que la región de mayor tamaño es la que queremos obtener, sin embargo existen otras regiones que cumplen con un tamaño mínimo, por lo tanto se impone la restricción de obtener la región de mayor tamaño, el resultado se muestra en la figura 5.d.. Estas restricciones presentadas sobre segmentación de imágenes se usan dentro del proyecto. El tamaño mínimo de región se usa para eliminar ruido que se pueda introducir dados los cambios de luz en el área de trabajo, por otra parte solo se busca una región de interés en donde estará el visitante para lo cual se usa la restricción una sola región que se debe obtener.. 1.3 Hardware del Robot El robot usado en el proyecto es un producto de la empresa MobileRobots [9], la cual fabrica robots para uso en investigación así como para tareas específicas de. 8.

(15) vigilancia entre otras. La referencia del robot es el PIONER P3-DX, el cual se muestra en la Figura 6. A continuación se muestran sus especificaciones:. -. Capacidad hasta de 3 Baterías (4 horas de trabajo continuo). -. 2 Ruedas y una de soporte, comúnmente llamada rueda loca. Figura 5. Ejemplo de segmentación en imágenes usando restricciones de tamaño mínimo de región y número máximo de regiones de interés. -. Motores con encoders. -. Cinturón frontal de 8 sonares. -. Microcontrolador Hitachi H8S. -. Software servidor ARCOS 9.

(16) -. Alto: 21cm, Ancho: 38cm, Largo: 51cm y altura de la base con respecto al piso: 5cm.. -. Peso: 9 Kg.. Figura 6. Robot PIONNER P3-DX. Equipado con sensores sonares y una cámara de video.. En cuanto a interfaz con el usuario posee leds indicadores de encendido y carga de baterías, así como botones de emergencia para bloquear los motores y de reset. También posee un puerto serial RS-232 para comunicación externa y una entrada para el adaptador de carga de baterías.. El robot posee un microcontrolador H8S fabricado por Hitachi, el cual trabaja a una velocidad de 18MHz tiene 32K de RAM una memoria FLASH de 128K. Este microcontrolador es quien controla todos los movimiento del robot y obtiene las medidas de los sonares, sin embargo no es posible accederlo directamente. MobileRobots ha desarrollado un sistema operativo llamado ARCOS el cual recibe peticiones de clientes trabajando como servidor en una arquitectura cliente-servidor y se encarga de hacer efectivas las peticiones. El sistema operativo ARCOS y al API de comunicación con este ARIA se encuentran explicados más adelante.. 10.

(17) Este modelo P3-DX es posible configurarlo de dos maneras, con o sin PC embarcado. MobileRobots da la opción al comprador de embarcar un PC dentro del robot el cual viene conectado directamente con el robot, generando así un sistema de comunicación integrado sin necesidad de conexiones externas alámbricas o inalámbricas. Dada las configuraciones del robot y su arquitectura de funcionamiento cliente-servidor existen diferentes formas de hacer la comunicación entre el robot que hace el papel de servidor y un computador cliente. En la Figura 7 se ven las diferentes formas de comunicación, (a) muestra la comunicación alámbrica por medio del puerto serial RS232, (b) se muestra la comunicación inalámbrica por medio de un access point, (c) muestra una conexión con un portátil sobre el robot y por último se muestra el robot con PC embarcado.. La Universidad de los Andes ha adquirido 2 robots tipo P3-DX, de los cuales uno viene con un PC embarcado y es el que se uso para este proyecto de grado.. (a). (b). (c). (d). Figura 7. Formas de comunicar el robot con un computador cliente [11].. 1.3.1 Sensores. A parte de los encoders que son sensores internos o propioceptivos [5] ubicados en los motores del robot, los sensores externos o exterioceptivos sonares y cámara son los principales sensores que se usan para tomar las decisiones de movimiento del robot correctamente. Los sonares proveen al robot de mediciones de distancia y la cámara le muestra el ambiente en el que se encuentra, pero aún más importante es una de las 11.

(18) principales herramientas para el desarrollo de aplicaciones. Unidos estos dos sensores forman una pareja poderosa para realizar tareas importantes como recorrido de trayectorias con marcas visuales para eliminar el error incremental ya explicado.. El robot P3-DX en su versión estándar cuenta con dos cinturones de sonares, uno trasero y uno delantero que le permite conocer las distancias a los objetos que los rodean. El funcionamiento de estos sonares se basa en la reflexión de ondas, el emisor envía una onda y el receptor mide la cantidad de energía acústica detectada después de la reflexión de la onda con un objeto, con esta información se puede obtener a que distancia se encuentra el objeto que reflejo la onda. Estos sensores trabajan en el espectro acústico de 20 a 200KHz y poseen varias ventajas así como desventantajas frente a otros sensores de distancia. En la Tabla 1 se muestran las ventajas y desventajas de estos sensores. Ventajas. Desventajas. •. Bajo costo. •. Bajo consumo de energía. onda se refleja fuera de este cono no. •. Se pueden encontrar en pequeños. será detectada.. tamaños. •. •. Campo de observación cónico. Si la. Cambios en la temperatura y altura cambian la densidad del aire y por lo tanto la propagación de las ondas.. •. Se pueden recibir falsos ecos.. •. Solo mide distancias cortas.. •. Limitación en precisión. Tabla 1. Ventajas y desventajas de los sensores de ultrasonido frente a otros sensores de medición de distancia.. Los sensores sonares con los que cuenta el robot P3-DX tienen una sensitividad mínima de 10cm y máxima de 4m, además están ubicados estratégicamente sobre el frente del robot como se muestra en la Figura 8. La adquisición de los datos se hace por medio de intervalos de tiempo adjudicados para cada sonar, por defecto se tienen 40ms. 12.

(19) por cada sonar, es decir toma un total de 320ms para saber las distancias a las cuales están ubicados los obstáculos en la parte frontal del robot.. Figura 8. Posición de los sonares en el cinturón frontal del robot [11].. Por otra parte tenemos el sensor más importante para este proyecto que es la cámara de video. Esta cámara de video es una cámara diseñada para labores de vigilancia ya que posee movimientos de Inclinación (Pan) y Giro (Tilt), además de la función de acercamiento (Zoom) y funciones de enfoque automático por cambios de intensidad de luz. Curiosamente el microcontrolador del robot no es quien recibe la información de la cámara pues esta adquisición requiere de un Frame Grabber o capturador de recuadros el cual debe ser instalado en un computador, lo que indica que el uso de la cámara se puede hacer únicamente por medio del PC embarcado o un portátil sobre el robot.. La cámara es de la marca CANON y su referencia es VCC50, ésta se muestra en la Figura 9. Cuenta con una resolución de 460 líneas horizontales y 350 verticales, Zoom óptico x26 y digital x12. Esta cámara solo necesita ser conectada al PC embebido ya que todas las conexiones vienes hechas de fábrica.. 13.

(20) Figura 9. Cámara PZT CANON VCC50. [12]. 1.4 Software Como se ha mencionado el microcontrolador del robot no puede ser accedido directamente ya que existe un sistema operativo que se hace cargo de las instrucciones que se le envían a éste, por lo tanto es necesario un API que contenga las formas de comunicación con este sistemas operativo. Además de este API ya se han creado diferentes aplicaciones que ayudan a mejorar el uso que se le puede dar al robot.. El software principal de manejo del robot se basa en ARCOS y ARIA, sin embargo existen otros que le brindan funcionalidades potentes para ejecución de tareas al robot, las relaciones entre estos es muestra en la Figura 10. Podemos ver unas de las aplicaciones de gran utilidad para el proyecto como lo son ACTS y MOBILEEYES [13], las cuales se apoyan en un API especializado en comunicar aplicaciones como lo es ArNetworking.. 1.4.1 ARCOS ARCOS es el sistema operativo desarrollado por MobileRobots para comunicar las aplicaciones con el microcontrolador del robot. Este sistema operativo recibe las instrucciones enviadas por ARIA por medio de conexiones TCP/UDP y las convierte en 14.

(21) lenguaje de máquina que pueda ser interpretado por el microcontrolador, además pide las respectivas medidas de sensores al microcontrolador para retornarlas al cliente ARIA. Es importante aclarar que ARCOS siempre funciona como servidor en espera de clientes que quieran usar los servicios del robot.. Figura 10. Relaciones entre el software que brinda el fabricante MobileRobots [13].. 1.4.2 ARIA ARIA es la base de todas las aplicaciones que quieran controlar y usar los servicios que ofrece el robot por medio de ARCOS. No es solo un API, es una interfaz orientada por objetos para manejar el robot y obtener las medidas de los sensores. Esta escrito en C++ y es la base de programación para todos los robots fabricados por MobileRobots.. Este API cuenta con varias características que hace de ésta una plataforma poderosa para el manejo de robots. Estas son una de las más importantes: 15.

(22) -. Se puede correr en Windows o Linux. -. Maneja y obtiene la información de sensores y elementos adicionales del robot. -. Maneja multi hilos si se desea.. -. Fácil uso gracias a ser orientada a objetos. -. Software gratis distribuido bajo licencia GNU. Figura 11. Ciclo de sincronización del robot [8].. Las principales clases con las que cuenta ARIA son ArRobot, ArAction y para el proyecto ArVCC4 y ArACTS_1_2. ArRobot crea la conexión con el robot y es necesaria para la inicialización de los sensores. ArAction es la clase encargada de crear las 16.

(23) instrucciones que se desean que ejecute el robot. En cuanto a las clases del proyecto ArVCC4 hace el control de cámara en cuanto a movimientos de ésta y ArACTS_1_2 toma la información entregada por ACTS. Todas las instrucciones que se envían al robot son entregadas de acuerdo a prioridades, es por esto que siempre se tendrá como mayor prioridad no chocar. En la Figura 11 se muestra el ciclo de sincronización del robot donde se puede ver que antes ejecutar las acciones se tiene que pasar con un interpretador de acciones el cual tiene en cuenta las interpretaciones de los sensores para enviar las acciones a ejecutar.. 1.4.3 ArNetworking ArNetworking es un protocolo de comunicación basado en ARIA para comunicar aplicaciones con el robot. La aplicación que usa el robot debe ser un cliente ArNetworking el cual le envía comandos simples a un servidor ArNetworking quien se encarga de hacer la comunicación con ARCOS para la ejecución de los comandos. La información viaja por medio de protocolos TCP o UDP haciendo uso de paquetes, ya sea una petición del cliente o respuesta del servidor. En la Figura 12 se muestra la arquitectura básica de uso de ArNetworking.. 1.4.4 ACTS Esta aplicación toma la información que obtiene el Frame Grabber de la cámara y ofrece varios servicios de procesamiento sobre el video obtenido. Además de tomar el video y procesarlo funciona como un servidor al cual se puede conectar cualquier cliente que conozca las instrucciones de pedido de información, es por esto que una aplicación que este conectada al robot y se conecte al mismo tiempo con ACTS puede pedir la información obtenida por la cámara luego de ser procesada por ACTS y luego mover el robot según ésta.. 17.

(24) Figura 12. Arquitectura básica de uso de ArNetworking [8].. Los servicios que presta ACTS son 2: Entrenamiento de colores y envío de zonas o blobs según los colores que el usuario ha determinado. El entrenamiento se hace por medio de un módulo específico para esta tarea. En la Figura 13 se muestra este módulo acompañado de una ventana en donde se muestra el video o imagen actual sobre la cual se esta trabajando. En este módulo se pueden agregar o quitar colores de interés, indicar el número de blobs a identificar, así como el canal por el que se estará leyendo la información. Este último servicio de canal tiene un gran poder pues se pueden hacer diferentes entrenamientos en diferentes canales obteniendo información por separado para una aplicación específica. 18.

(25) Figura 13. Ventanas de entrenamiento (izquierda) y venta de visualización (derecha) de ACTS.. 1.4.5 MOBILEEYES. Esta es una aplicación que se encuentra implementada sobre ARIA. Los servicios que presta son visualización del video actual de la cámara y del robot sobre un mapa específico, también puede manejar el robot mediante botones de avanzar y girar. La comunicación con el robot se hace por medio de ArNetworking comunicándose con el robot inalámbricamente ya que se puede utilizar como un observador remoto en la mayoría de las aplicaciones, como es la del proyecto.. 1.5 Modelo Cliente-Servidor El modelo de cliente – servidor se basa en peticiones y respuestas hechas por el cliente y respondidas por el servidor respectivamente. El cliente es por lo tanto un agente activo en la comunicación pues es quien usa los servicios prestados por el servidor por 19.

(26) medio de peticiones, por otra parte el servidor es un agente pasivo ya que su función es esperar las peticiones del cliente y responder de acuerdo a estas peticiones. Este modelo es muy usado en software de organizaciones ya que permite escalar en cuanto a número de clientes y servidores fácilmente, además difiere en cuanto a modelos anteriores por la ubicación física del cliente y servidor ya que pueden estar en diferentes lugares espacialmente.. El interés de este modelo para la comunicación con el robot y en general con la mayoría de las aplicaciones es distribuir el procesamiento de la información, así como para aplicaciones con más de un robot. Un ejemplo concreto de distribución de procesamiento es la herramienta ACTS, ésta toma la información de la cámara y actúa como servidor de la información que esta herramienta entrega como son los blobs para cualquier cliente que se conecte. En cuanto al uso de más de un robot se encuentra el campo de la robótica cooperativa en donde cada robot actúa como servidor y un solo cliente centralizado accede a todos estos servidores para ejecutar tareas en este campo.. 20.

(27) 2. PROPUESTA DE SOLUCIÓN La idea central de este proyecto es mostrar la funcionalidad de los nuevos robots, que la Universidad de los Andes ha adquirido, a partir del desarrollo de un prototipo operacional. Luego de conocer con lo que contaba el robot y las herramientas que brinda MobileRobots para el desarrollo de aplicaciones, se decidió usar el robot P3-DX con su cámara para hacer algún tipo de detección de objetos o personas con la extensión de poder seguir un objetivo (persona).. La. aplicación. fue desarrollada en. C++. haciendo. uso. de. ARIA. y. ARNETWORKING con la ayuda de la documentación de estos APIs y los ejemplos básicos que entrega MobileRobots con ARIA. Como primer paso del desarrollo de la aplicación se mostrará el trabajo previo y de base antes de empezar con la programación, nos referimos entonces al entrenamiento de ACTS. Luego se mostrará el proceso que se llevo para escoger la arquitectura final y por último el manejo y control que se hace sobre el robot de acuerdo a la información obtenida.. 2.1 Entrenamiento de ACTS Como ya se explico ACTS es una herramienta que captura las imágenes provenientes de capturador de video y realiza una segmentación de color de las imágenes entregando a los clientes, por medio de respuesta a peticiones, la información de las regiones o blobs de interés encontradas en la imagen. Esta información entregada corresponde a un entrenamiento que el usuario debe hacer sobre ACTS de acuerdo con lo que se quiera lograr.. El uso específico de ACTS en este proyecto es la detección, es decir que ACTS indicará en que parte de la imagen se encuentra el visitante quien para efectos de la aplicación deberá llevar un chaleco de un color diferente al que la mayoría de personas usa a diario como el naranja o verde fosforescente. Para lograr la correcta detección del. 21.

(28) color y por lo tanto del visitante se hace necesario un buen entrenamiento del color en ACTS.. Para hacer el entrenamiento se necesita ubicar tanto el robot como el visitante en el área de trabajo del robot y el visitante debe llevar puesto el chaleco. Esto se debe a que el ambiente en el que se encuentre el robot tiene una intensidad de luz intrínseca que determina los colores visibles por la cámara del robot, dado esto es necesario hacer el entrenamiento en el lugar de trabajo de éste. Además se necesita conectar el PC interno a un monitor, teclado y ratón para visualizar lo observado por ACTS e interactuar con la aplicación.. Lo primero que se debe hacer es indicar el canal con el cual se trabajará y el número de blobs que se quieren detectar sobre el módulo de entrenamiento. Luego se tomará una imagen instantánea del visitante seleccionando la opción de Single Frame en el panel de Comando de Entrenamiento y por medio de los botones que se encuentran en el panel de Herramientas de Entrenamiento se buscará obtener el blob más grande que encierre por completo el chaleco del visitante. Estas 3 últimas operaciones se deberán hacer con el visitante ubicado a diferentes distancias de la cámara con el objetivo de incluir dentro de los colores de segmentación las diferentes tonalidades que el chaleco puede presentar.. En la Figura 14 se muestran dos entrenamientos con diferentes cantidades de iluminación. Las imágenes superiores muestran las detecciones de la cámara a un intensidad entre 220 y 280 luxes, en éstas podemos apreciar que alrededor de la región que se quiere detectar existe mucho ruido. Las imágenes inferiores muestran las mismas tomas pero con una intensidad entre 900 y 1000 luxes, en éstas podemos ver que el objetivo esta mejor detectado. Este es un ejemplo de lo que sucede si no se hace un buen entrenamiento teniendo en cuenta el ambiente de trabajo.. 22.

(29) Figura 14. Cambios en la segmentación de color debido al cambio de iluminación.. 2.2 Arquitectura La arquitectura de la aplicación esta basada en el modelo cliente-servidor ya que todas las aplicaciones se comunican usando este modelo. Todas las comunicaciones establecidas se hacen por medio de los protocolos TCP o UDP sin contar con la conexión entre en PC embarcado y el robot, la cual se hace por medio de un puerto serial de tipo RS-232. En el proceso de desarrollo de la aplicación se desarrollaron 3 arquitecturas diferentes las cuales se presentan a continuación.. 23.

(30) 2.2.1Arquitectura de Prueba. La arquitectura de prueba se hizo pensando en la funcionalidad básica de detección y seguimiento. En la Figura 15 se muestra esta arquitectura. Esta arquitectura cuenta con ACTS el cual se conecta al PC embarcado y recibe los datos de la información y al mismo tiempo actúa como servidor de blobs según el entrenamiento hecho, el cliente ARIA se conecta a los servidores ACTS y el robot. En esta arquitectura de base no se hace un reporte o envío de información sobre el robot a un computador externo para tener control sobre el visitante, lo cual se busca hacer para la segunda arquitectura.. ACTS servidor. servidor. CPU. ARIA cliente Figura 15. Arquitectura básica de prueba. 2.2.2 Arquitectura con Cliente Remoto. Como se quería tener un cliente remoto que pudiera ver y manejar el robot en caso de que ocurriera una situación no esperada como que el robot perdiera de vista al visitante por algún motivo, se implementó la arquitectura con cliente remoto mostrada en la Figura 16. Esta arquitectura es una extensión de la base, en esta encontramos ACTS cumpliendo la misma función, sin embargo el cliente ARIA se convierte en cliente y 24.

(31) servidor, es decir es cliente del robot y es servidor para que un nuevo cliente maneje el robot remotamente. Aparece entonces un nuevo cliente que maneja el robot remotamente conectándose al servidor ARIA y adquiere la información entregada por ACTS. Además MOBILEYES muestra sobre un mapa el robot así como el video de lo que ve la cámara y las acciones que hace el robot. Esta arquitectura se implemento, pero tuvo el inconveniente que el cliente remoto se podía conectar con ACTS pero no podía recibir la información de la cámara ya que ACTS pide como parámetro para el envío de información la referencia al robot real, lo cual no se pudo lograr.. Dadas estos inconvenientes se pensaron nuevas arquitecturas concluyendo en la final, la cual elimina por completo el cliente remoto ARIA dejando como único cliente remoto a MOBILEEYES quien puede obtener el control sobre el robot en cualquier situación que se necesite.. ACTS servidor. servidor. CPU. ARIA servidor. cliente. MOBILE EYES. ARIA cliente. cliente. Figura 16. Arquitectura con cliente remoto.. 25.

(32) 2.2.3 Arquitectura Final. La arquitectura final se presenta en la Figura 17. En esta arquitectura el cliente ARIA controla el robot directamente y obtiene la información de ACTS ya que posee la referencia del robot. Por otra parte el servidor ARIA reenvía a MOBILEEYES el video que obtiene de la cámara, además puede ejecutar las acciones que esta aplicación envía para que sean realizadas por el robot.. ACTS servidor. ARIA servidor. servidor. CPU. cliente. MOBILE EYES cliente Figura 17. Arquitectura final de la aplicación.. 2.3 Ciclo de Ejecución. En la Figura 11 se muestra el ciclo de sincronización del robot el cual se hace cada 100ms teniendo en cuenta las instrucciones que llegan al robot con sus respectivas prioridades, sin embargo quien impone las prioridades es el programador, generando un ciclo de ejecución. El código ciclo de ejecución se presenta a continuación: robot.addAction(&limiter, 100); robot.addAction(&limiterFar, 99);. 26.

(33) robot.addAction(&backwardsLimiter, 98); robot.addAction(&seguir, 77); robot.addAction(&backup, 50); robot.addAction(&stop, 30);. El método addAction añade una acción al ciclo de ejecución del robot con su respectiva prioridad. Dentro de estas acciones ya se encuentran unas predeterminadas como limiter y limiterFar, sin embargo seguir, que es la clase que va a controlar todos los movimientos del robot para el seguimiento del visitante, debe tener un método ArActionDesired *seguir() :: fire() el cual será el que se ejecutara al llamar dentro del ciclo de ejecución del robot. Este método fire será quien tome la información de ACTS y envíe las instrucciones al robot.. 2.3.1 Método Fire Este método es el más importante para las ejecuciones de las acciones deseadas, por lo tanto es donde se hace toda la adquisición de datos y toma de decisiones. Este método recibe como parámetro un objeto de tipo ArActionDesired que puede contener una acción deseada a ejecutar y retorna por su parte un objeto de tipo ArActionDesired que indica la acción a ejecutar por el robot.. Para la toma de decisiones basada en la información que entrega ACTS se hacen diferentes cálculos y se determinan las acciones a seguir. Estos cálculos determinan la relación en X y Y del centro de gravedad del blob con respecto a la imagen. En cuanto a los movimientos de inclinación de la cámara simplemente se aumenta o disminuye un valor definido por cada ejecución del método. Los movimiento de giro se hacen sobre el robot y no sobre la cámara, además la velocidad del robot se indica como constante si se detecta al visitante, sin embargo por la cinética del robot se ve incremental al ejecutar las acciones. En la Figura18 se muestra el diagrama de flujo del método.. Para hacer los cálculos necesarios debemos tomar en cuenta la información que ACTS nos brinda, como lo es ancho, alto y la posición del centro del blob en X y Y con 27.

(34) respecto al centro de la imagen. Los dos cálculos principales son que tan lejos esta el punto de gravedad del centro de la imagen tanto en X como en Y. A continuación se presentan estos cálculos:. Relación en X entre el centro de gravedad del blob y la mitad en X de la imagen:. Relación en Y entre el centro de gravedad del blob y la mitad en Y de la imagen:. Figura 18. Diagrama de Flujo del método fire de toma de decisiones.. Tomando en cuenta que la imagen es más ancha que alta, se tomaron como valores mínimos absolutos |0.2| para relación en Y y |0.1| para la relación en X para inclinación 28.

(35) de la cámara y rotación del robot respectivamente. Si alguno de los cálculos sobrepasa el valor mínimo en valor absoluto se procede a tomar la acción de inclinar o girar un delta fijo dependiendo del signo de la relación. Por ejemplo si el centro de gravedad del blob se encuentra por encima de línea media en Y y a la izquierda de la línea media en X, se procede a aumentar, un δ de inclinación fijo, la inclinación de la cámara y a rotar el robot, un δ de rotación fijo, en contra de las manecillas del reloj.. 29.

(36) 3. Pruebas y Análisis de Resultados Las pruebas se realizaron en el laboratorio de visualización inmersiva y sistemas autónomos de la Universidad de los Andes, el cual cuenta con el espacio e iluminación necesaria para las pruebas. Se hicieron 4 tipos de pruebas: iluminación, velocidad del visitante, comunicación inalámbrica, distancia y área mínima de detección. 3.1 Iluminación. Con la ayuda de un luxómetro se hicieron pruebas encendiendo y apagando las diferentes luces del laboratorio al mismo tiempo que se adquiría la información brindada por ACTS. La prueba se realizaba midiendo la cantidad de luxes que indicaba el luxómetro y los colores que se segmentaban de acuerdo a ACTS. Lo que se pudo concluir es que para que la cámara pueda adquirir una buena imagen de los colores es necesario tener una intensidad de iluminación de 800 luxes mínimo. 3.2 Velocidad del Visitante. El tiempo en que tarda el robot en ciclo de sincronización es de 100ms, sin embargo el tiempo de respuesta puede aumentar considerablemente de acuerdo a los algoritmos utilizados para el desarrollo de las tareas. En el caso del proyecto la tarea de detección y seguimiento es compleja y el robot no responde tan rápido como lo necesita para poder seguir a un visitante que camina a una velocidad promedio, por lo tanto se estableció una velocidad máxima lineal en la que el robot puede mantener al visitante dentro de su ventana de observación la cual fue de 0.5m/s, al igual cuando el personaje hace giros teniendo como centro el robot este debe girar a una velocidad tangencial de 0.5m/s. Esto nos indica que el visitante debe ir despacio para que el robot pueda detectarlo y seguirlo.. 30.

(37) 3.3 Comunicación Inalámbrica. La arquitectura final de robot define que el cliente quien dará las instrucciones de movimiento se encontrará corriendo en el PC embarcado, sin embargo MOBILEEYES estará corriendo en un computador REMOTO. Esta conexión remota se debe hacer inalámbricamente. Para esta conexión se hicieron pruebas con las diferentes redes que tienen alcance en el laboratorio, como SENECA y una red privada creada específicamente para la comunicación con los robots.. En la primera prueba se conectaron tanto el PC embarcado como el remoto a SENECA y funciono bien, sin embargo la señal de esta red pública es baja en la sala y no es fácil establecer la conexión con ésta. Pensando en la red privada dedicada para los robots se pudo hacer la conexión del robot a esta red, pero el PC remoto no encontró la red, al parecer por problemas de Windows. Dado esto se probó una conexión del computador remoto a la red alámbrica de la Universidad y el robot a la red privada, terminando en un comunicación más robusta que la establecida con SENECA y que permite un mayor rango de operación pues el access point de la red privada se conecta directamente con el PC remoto que puede estar en cualquier parte del campus. 3.4 Distancia y área mínima de detección. La cámara tiene limitaciones físicas de sus movimientos y en especial en su inclinación, además el tamaño del robot comparado con el de una persona hace que la cámara se incline a su máximo cuando se encuentra cerca del visitante. Para lograr que el robot mantuviera una distancia mínima al visitante se intentó hallar la relación entre el área del blob actual y la distancia al visitante.. Se hicieron las pruebas ubicando al visitante a diferentes distancias y en diferentes posiciones mientras se media el área del blob en cada cambio, sin embargo los resultados no fueron los satisfactorios. Al estar el visitante a una misma distancia el tamaño del blob detectado cambiaba si el visitante se encontraba de espaldas o de lado, lo cual generaba 31.

(38) dos valores de tamaño del blob para una misma distancia, por lo tanto se necesito de otro método para mantener al robot a una distancia apropiada. Este método se implemento manteniendo el robot a una distancia de 1 metro del visitante por medio de detección de proximidad con los sonares frontales. Se tiene el inconveniente de que el visitante puede pasar cerca a un obstáculo y el robot puede detenerse si este obstáculo se encuentra dentro de sus campo de parada de 1 metro, sin embargo en espacios amplios como el laboratorio funciona.. Por otra parte, como se hablo en el entrenamiento de ACTS se necesito de un tamaño mínimo de detección establecido. Gracias al color no común del chaleco y los colores del laboratorio así como la iluminación, las detecciones incorrectas por parte de ACTS eran pocas, por lo tanto se uso el tamaño por defecto de la configuración de la herramienta que es 10 pixeles cuadrados. 3.5 Arquitectura. Luego de la implementación de las arquitecturas base e intermedia se desarrolló la arquitectura final descrita en la Figura 17. Se hicieron varias pruebas de recorridos y de conexiones de las aplicaciones y se encontró que dentro del laboratorio el robot puede seguir al visitante sobre cualquier ruta que este escoja, además cada uno de los módulos de la arquitectura cumple su función para lograr el objetivo del proyecto.. En las Figuras 19 y 20 muestran la aplicación MOBILEEYES corriendo en el computador remoto con el video que esta adquiriendo la cámara. En la Figura 19 se muestra al visitante cuando el robot comienza a hacer la tarea y se acerca al objetivo. La Figura 20 muestra al visitante lejos del robot sin embargo este lo sigue detectando y dirigiéndose hacia él.. Una de los resultados importantes es que el tratamiento de la imagen en el computador embarcado consume gran parte del procesador, por otra parte el envió de video no lo sobrecarga. Este resultado es importante ya que el computador embarcado es eficiente en 32.

(39) cuanto enviar comandos al robot pero no para hacer otro tipo de tareas, las cuales pueden ser ejecutadas en máquinas remotas más poderosas.. Figura 19. Aplicación MOBILEYES corriendo en un computador remoto. En esta se muestra al visitante antes de empezar la tarea de seguimiento.. Figura 20. Aplicación MOBILEYES corriendo en un computador remoto. En esta se muestra al visitante en su recorrido. 33.

(40) 4. Conclusiones y trabajo futuro Se logro hacer un primer acercamiento con el uso de los nuevos robots adquiridos por la Universidad de los Andes, así implementar un primer prototipo sobre el robot para que futuros estudiantes puedan referirse a éste y avanzar teniendo de base este proyecto.. Se hizo uso de las herramientas que provee el fabricante para tener un primer acercamiento de las funcionalidades que pueden ofrecer los robots así como mirar las ventajas y fallas que estos presentan. En particular ACTS y MOBILEEYES fueron de gran ayuda al proyecto, sin embargo son herramientas que se pueden implementar sin complicaciones y con mejoras para futuros proyectos.. Se experimento con un robot real comprobando sus limitaciones y ventajas. Se comprobó su poca capacidad de procesamiento ya que necesita de clientes ajenos que hagan esta tarea por ellos. Aunque se uso un robot con computador embarcado, presenta tiempos de respuesta altos y que pueden ser mejorados.. Para los futuros estudiantes de robótica o quienes quieran usar robots, hay un primer demo funcional que sirve de apoyo al aprendizaje de los APIs y estructura de la programación necesitada. Los estudiantes interesados podrán correr la aplicación y mirar el código, así entenderán más rápidamente los conceptos y particularidades de programar tareas para robots.. Como trabajo futuro se deben hacer mejoras en la arquitectura para soportar clientes que puedan manejar el robot remotamente, lo cual se logra quitando la dependencia de uso de ACTS. Con este trabajo también se disminuiría el tiempo de respuesta del robot, ya que se puede usar un computador remoto potente que realiza las operaciones que usan un alto porcentaje del procesador. De la mano de esta mejora va el mejoramiento del procesamiento y análisis de imágenes que abren el campo de tareas y acciones que el robot puede realizar.. 34.

(41) El robot debe ser más inteligente. Las decisiones del robot deben ser más complejas a tal punto se no se quede sin hacer nada si no sucede lo que se esperaba, como pasa en la implementación del proyecto, es decir que si no ve el visitante trate de buscarlo de diferentes formas.. La ubicación del robot sobre un mapa puede llegar a tener mucho error ente el mapa y la realidad, dado esto se pueden implementar métodos de localización que mejoren el error incremental que se produce por los errores obtenidos por métodos como Dead Reckoning.. Con base en este proyecto se pueden pensar muchas otras aplicaciones más poderosas, por ejemplo se podría usar este tipo de robots para entregar la correspondencia en las respectivas facultades del sexto piso del edificio de Ingeniería Mario Laserna, usando marcas especiales para las facultades y sus respectivos paquetes.. 35.

(42) Referencias [1] Fundamentos de Robótica. A. Barrientos, L.F. Peñin, C. Balaguer y R. Aracil. McGraw – Hill, 1998. [2] Principles of Robot Motion. H. Choset, K. Lynch, S. Hutchinson, G. Kantor, W. Burgard y L. Kavraki. The MIT Press, 2005.. [3] Robot Motion Planning. J. Latombe. Kluwer Academic Publisher, 1991.. [4] Sensors for mobile robots. H.R. Everett. A K Peters, Ltd, 1995.. [5] Computational principles of mobile robots. G. Dudek y M. Jenkin. Cambridge University Press, 2000.. [6] Introduction to autonomous mobile robots. R. Siegwart. MIT Press, 2004.. [7] Digital Image Processing and Computer Vision. Robert J. Schalkoff. Editorial John Wiley & Sons, Inc.. [8] Documentación ARIA y ARNETWORKING. http://robots.mobilerobots.com/. [9] Sitio Web del fabricante del robot, MobileRobots. www.activrobots.com. [10] Fabricante robots articulados. http://www.antenen.com/. [11] Manual del robot P3-DX. http://robots.mobilerobots.com/. [12] Sitio Web Canon. http://www.usa.canon.com/home. 36.

(43) [13] Software suministrado por MobileRobots. http://www.activrobots.com/SOFTWARE/index.html. 37.

(44) ANEXO 1. Manual de usuario de la aplicación En este manual se encuentran los pasos para correr la aplicación de detección y seguimiento de visitante.. 1. Antes de comenzar revise que tiene disponibles los siguientes objetos: •. Chaleco color naranja. •. Monitor, teclado y mouse (El teclado y mouse deben tener conexión serial no USB).. •. Robot con cámara y antena. 2. Encienda el robot y el computador embarcado de acuerdo al manual del robot P3OpMan4 (Disponible en el CD de software que acompaña el robot). 3. Ejecute la aplicación ACTS. a. En el panel de entrenamiento elija la opción: File → Load Channel b. Escoja el archivo canalDeteccionSeguimiento.lut 4. Vaya a la carpeta donde se encuentra instalado ARIA: C:\Program Files\ARIA\bin 5. Ejecute deteccionSeguimiento.exe. Nota: En cualquier momento puede oprimir la tecla ESC para cerrar la aplicación. En este punto la aplicación se encuentra corriendo en el computador embarcado, sin embargo se crearon comandos de activación del movimiento para evitar que comience a avanzar el robot con el monitor conectado. 6. Seleccione la ventana donde esta corriendo la aplicación deteccionSeguimiento.exe, desconecte el monitor y ponga el teclado y mouse sobre el robot. 7. Ubique el visitante con el chaleco a una distancia ente 3 y 4 metros frente al robot. 8. Teclee la letra a (activar) para activar la rutina de detección y seguimiento. 9. Si desea parar la rutina oprima la tecla d (desactivar), opcionalmente usted puede mover el robot con las flechas del teclado mientras no esté haciendo la 38.

(45) rutina de detección y seguimiento. Nota: Si quiere parar el robot luego de usar las flechas use la tecla de espacio o salir de la aplicación oprima la tecla ESC. 10. Si cuenta con un computador conectado a la red alámbrica de la Universidad y tiene la aplicación MobileEyes instalada, ejecútela. 11. Introduzca en el campo Robot Servers la dirección IP del computador del robot (157.253.170.10) y oprima Connect. Debe aparecer en la aplicación el video actual que esta captando la cámara. 12. Para acabar la rutina oprima la tecla ESC, conecte el robot al monitor y cierre ACTS.. 39.

(46) ANEXO 2. Código de la aplicación /* DETECCIÓN Y SEGUIMIENTO DE VISITANTES CON ROBOT MÓVIL Alfredo Morales Pinzón Asesor: Fernando De la Rosa Universidad de los Andes Archivo:servidorSeguidor.cpp En este archivo se encuentra en código fuente de la aplicación desarrollada para la detección y el seguimiento de visitantes con robot móvil. Este código ha sido generado a partir de códigos base de MobileRobots. En especifico se usaron los ejemplos: actsColorFollowingExample y serverDemo (ArNetworking). */ //Librerias #include "Aria.h" #include "ArNetworking.h" //Clase "Seguir" que hace la rutina de detección y seguimiento del visitante. //Es importante anotar que el método fire de la clase es el que se invocará //por cada ciclo de ejecución del robot. class Seguir : public ArAction { public: // The state of the Seguir action enum State { NO_TARGET, // There is no target in view TARGET, // This is a target in view }; // Constructor Seguir(ArACTS_1_2 *acts, ArVCC4 *camera, ArKeyHandler *keyHandler); // Destructor ~Seguir(void); // Activa la rutina de detección y seguimiento void activar(); //Desactiva la rutina de detección y seguimiento void desactivar(); // Cambia parámetros de movimiento para avanzar void avanzar(); // Cambia parámetros de movimiento para frenar (Disminuir velocidad). 40.

(47) void frenar(); // Cambia parámetros de movimiento para parar void parar(); // Cambia parámetros de movimiento para girar a la derecha void girarDerecha(); // Cambia parámetros de movimiento para girar a la izquierda void girarIzquierda(); // The action ArActionDesired *fire(ArActionDesired currentDesired); // Set the ACTS channel that we want to get blob info from bool setChannel(int channel); // Return the current state of this action State getState(void) { return myState; } // Height and width of pixels from frame-grabber enum { WIDTH = 160, HEIGHT = 120 }; protected: // Action que se desea ejecute el robot ArActionDesired myDesired; // Se encargada de hacer la conexión con ACTS ArACTS_1_2 *myActs; // Se encarga de hacer la conexión con la cámara para su control ArVCC4 *myCamera; // Ultimo tiempo en que se vio el objeto de detección ArTime myLastSeen; // Estado de la clase State myState; //Canal de obtención de datos de ACTS int myChannel; // Máximo tiempo de espera para obtener una detección int myMaxTime; // Handler de teclado ArKeyHandler *myKeyHandler; // Funtores de los métodos de movimiento. Se usan para estableces // funciones de callback. ArFunctorC<Seguir> activarCB; ArFunctorC<Seguir> desactivarCB; ArFunctorC<Seguir> avanzarCB; ArFunctorC<Seguir> frenarCB; ArFunctorC<Seguir> pararCB; ArFunctorC<Seguir> girarDerechaCB; ArFunctorC<Seguir> girarIzquierdaCB; // Estado de la rutina de seguimiento (Activada/Desactivada) bool seguirActivado; // Estado del movimiento dado por el usuario mediante el teclado bool mover; // Cantidad de giro mínima dada por el usuario al rotar el robot. 41.

(48) int deltaAngulo; // Cantidad de movimiento incremental dada por el usuario al mover el robot int deltaVelocidad; // Numero de incrementos en velocidad (Positivos o Negativos) int adelante; // Numero de incrementos en rotación (Positivos o Negativos) int izquierda; }; // Constructor: Initialize the Seguir action Seguir::Seguir(ArACTS_1_2 *acts, ArVCC4 *camera, ArKeyHandler *keyHandler) : myKeyHandler(keyHandler), ArAction("Seguir", "Seguir the largest blob."),activarCB(this, &Seguir::activar) ,desactivarCB(this, &Seguir::desactivar), avanzarCB(this, &Seguir::avanzar), pararCB(this, &Seguir::parar) ,girarDerechaCB(this, &Seguir::girarDerecha),girarIzquierdaCB(this, &Seguir::girarIzquierda), frenarCB(this, &Seguir::frenar) { //Inicialización de atributos myActs = acts; myCamera = camera; myChannel = 0; myState = NO_TARGET; setChannel(1); myLastSeen.setToNow(); myMaxTime = 1000; seguirActivado = false; mover = false; adelante = 0; izquierda = 0; deltaVelocidad = 15; deltaAngulo = 12; //Se añaden las funciones de CallBack al handler del teclado myKeyHandler->addKeyHandler('a', &activarCB); myKeyHandler->addKeyHandler('d', &desactivarCB); myKeyHandler->addKeyHandler(ArKeyHandler::UP, &avanzarCB); myKeyHandler->addKeyHandler(ArKeyHandler::DOWN, &frenarCB); myKeyHandler->addKeyHandler(ArKeyHandler::SPACE, &pararCB); myKeyHandler->addKeyHandler(ArKeyHandler::RIGHT, &girarDerechaCB); myKeyHandler->addKeyHandler(ArKeyHandler::LEFT, &girarIzquierdaCB); } // Destructor Seguir::~Seguir(void) { //Cerramos la conexión con ACTS if(myActs->isConnected()) { myActs->requestQuit(); myActs->closePort(); printf("Se desconecto\n"); }. 42.

(49) } // Método llamado al oprimir la tecla "a", para activar la rutina // de seguimiento void Seguir::activar(void) { printf("activar\n"); seguirActivado = true; } // Método llamado al oprimir la tecla "d", para desactivar la rutina // de seguimiento void Seguir::desactivar(void) { printf("desactivar\n"); seguirActivado = false; } // Método llamado al oprimir la tecla "UP". Aumenta el parámetro de // velocidad del robot void Seguir::avanzar(void) { if(!seguirActivado) { printf("Hacia arriba\n"); adelante += deltaVelocidad; mover = true; } } // Método llamado al oprimir la tecla "DOWN". Disminuye el parámetro de // velocidad del robot void Seguir::frenar(void) { if(!seguirActivado) { printf("Frenando\n"); adelante -= deltaVelocidad; mover = true; } } // Método llamado al oprimir la tecla "SPACE". Pone en ceros los parámetros de // movimiento del robot void Seguir::parar(void) { if(!seguirActivado) { printf("Parar\n"); mover = false; adelante = 0; izquierda = 0; } }. 43.

(50) // Método llamado al oprimir la tecla "RIGHT". Disminuye el parámetro de // Angulo de dirección del robot void Seguir::girarDerecha(void) { if(!seguirActivado) { printf("Girar Derecha\n"); mover = true; izquierda -= 1 ; } } // Método llamado al oprimir la tecla "LEFT". Aumenta el parámetro de // Angulo de dirección del robot void Seguir::girarIzquierda(void) { if(!seguirActivado) { printf("Girar Izquierda\n"); mover = true; izquierda += 1 ; } } // Acción de seguir que se ejecuta en la rutina del robot ArActionDesired *Seguir::fire(ArActionDesired currentDesired) { // Reset myDesired.reset(); if(!seguirActivado) { if(mover) { myDesired.setVel(adelante); myDesired.setDeltaHeading(izquierda*deltaAngulo); izquierda = 0; } else { myDesired.setVel(0); myDesired.setDeltaHeading(0); } return &myDesired; } // Se anula el movimiento del robot por parte del usuario adelante = 0; izquierda = 0; ArACTSBlob blob; ArACTSBlob largestBlob; bool flag = false;. 44.

(51) int numberOfBlobs; int blobArea = 10; double xRel, yRel; numberOfBlobs = myActs->getNumBlobs(myChannel); // If there are blobs to be seen, set the time to now if(numberOfBlobs != 0) { for(int i = 0; i < numberOfBlobs; i++) { myActs->getBlob(myChannel, i + 1, &blob); if(blob.getArea() > blobArea) { flag = true; blobArea = blob.getArea(); largestBlob = blob; } } myLastSeen.setToNow(); } // If we have not seen a blob in a while... if (myLastSeen.mSecSince() > myMaxTime) { if(myState != NO_TARGET) ArLog::log(ArLog::Normal, "Target Lost"); myState = NO_TARGET; } else { // If we see a blob and haven't seen one before.. if(myState != TARGET) ArLog::log(ArLog::Normal, "Target Aquired"); myState = TARGET; } if(TARGET && flag == true) { // Determine where the largest blob's center of gravity // is relative to the center of the camera xRel = (double)(largestBlob.getXCG() - WIDTH/2.0) / (double)WIDTH; yRel = (double)(largestBlob.getYCG() - HEIGHT/2.0) / (double)HEIGHT; // Tilt the camera toward the blob if(!(ArMath::fabs(yRel) < .20)) { if (-yRel > 0) myCamera->tiltRel(1); else myCamera->tiltRel(-1); }. 45.

(52) // Set the heading and velocity for the robot if (ArMath::fabs(xRel) < .10) { myDesired.setDeltaHeading(0); } else { if (ArMath::fabs(-xRel * 10) <= 10) myDesired.setDeltaHeading(-xRel * 10); else if (-xRel > 0) myDesired.setDeltaHeading(10); else myDesired.setDeltaHeading(-10); } myDesired.setVel(300); return &myDesired; } else { myDesired.setVel(0); myDesired.setDeltaHeading(0); return &myDesired; } } // Set the channel that the blob info will be obtained from bool Seguir::setChannel(int channel) { if (channel >= 1 && channel <= ArACTS_1_2::NUM_CHANNELS) { myChannel = channel; return true; } else return false; } int main(int argc, char **argv) { // Inicializamos ARIA Aria::init(); //ArLog::init(ArLog::StdErr, ArLog::Verbose); ArRobot robot; printf("Antes de crear la camara"); // The camera (Cannon VC-C4) ArVCC4 vcc4 (&robot); // ACTS, for tracking blobs of color ArACTS_1_2 acts; // our base server object ArServerBase server; // Parser de verificación de parametros ArArgumentParser parser(&argc, argv);. 46.

(53) ArSimpleConnector simpleConnector(&parser); ArServerSimpleOpener simpleOpener(&parser); // set up a gyro, if installed ArAnalogGyro gyro(&robot); // load the default arguments parser.loadDefaultArguments(); ArClientSwitchManager clientSwitchManager(&server, &parser); if (!Aria::parseArgs() || !parser.checkHelpAndWarnUnparsed()) { Aria::logOptions(); Aria::exit(1); } // Se añade un key handler para el manejo de acciones por medio del teclado ArKeyHandler keyHandler; Aria::setKeyHandler(&keyHandler); // Acciones limiter y limiter far para evitar que el robot choque ArActionLimiterForwards limiter("speed limiter near", 800, 1000, 600); ArActionLimiterForwards limiterFar("speed limiter far", 800, 1200, 600); ArActionLimiterBackwards backwardsLimiter; ArActionConstantVelocity stop("stop", 0); ArActionConstantVelocity backup("backup", -200); // Creacion de la clase que sigue al visitante Seguir seguir(&acts, &vcc4, &keyHandler); // Set up where we'll look for files such as user/password char fileDir[1024]; ArUtil::addDirectories(fileDir, sizeof(fileDir), Aria::getDirectory(), "ArNetworking/examples"); // first open the server up if (!simpleOpener.open(&server, fileDir, 240)) { if (simpleOpener.wasUserFileBad()) printf("Bad user/password/permissions file\n"); else printf("Could not open server port\n"); exit(1); } // Range devices: ArSonarDevice sonarDev; robot.addRangeDevice(&sonarDev);. 47.

(54) ArIRs irs; robot.addRangeDevice(&irs); ArBumpers bumpers; robot.addRangeDevice(&bumpers); ArSick sick(361, 180); robot.addRangeDevice(&sick);. // Se añaden servicios al servidor ArServerInfoRobot serverInfoRobot(&server, &robot); ArServerInfoSensor serverInfoSensor(&server, &robot); ArServerInfoDrawings drawings(&server); drawings.addRobotsRangeDevices(&robot); ArLaserReflectorDevice reflector(&sick, &robot); drawings.addRangeDevice(&reflector); // Modos de control de movimiento del robot ArServerModeStop modeStop(&server, &robot); ArServerModeDrive modeDrive(&server, &robot); ArServerModeRatioDrive modeRatioDrive(&server, &robot); ArServerModeWander modeWander(&server, &robot); modeDrive.addAsDefaultMode(); modeDrive.activate(); // set up the simple commands ArServerHandlerCommands commands(&server); ArServerSimpleComUC uCCommands(&commands, &robot); // send commands directly to microcontroller ArServerSimpleComMovementLogging loggingCommands(&commands, &robot); // control debug logging ArServerSimpleComGyro gyroCommands(&commands, &robot, &gyro); // configure gyro ArServerSimpleComLogRobotConfig configCommands(&commands, &robot); // control more debug logging ArServerSimpleServerCommands serverCommands(&commands, &server); // control ArNetworking debug logging modeDrive.addControlCommands(&commands); // configure the drive modes (e.g. enable/disable safe drive) // Reenviar el video al cliente que lo requiera ArHybridForwarderVideo videoForwarder(&server, "localhost", 7070); // Control de cámara pan/tilt/zoom ArPTZ *camera = NULL; ArServerHandlerCamera *handlerCamera = NULL; ArCameraCollection *cameraCollection = NULL;. 48.

(55) if (videoForwarder.isForwardingVideo()) { bool invertedCamera = false; camera = new ArVCC4(&robot, invertedCamera, ArVCC4::COMM_UNKNOWN, true, true); camera->init(); cameraCollection = new ArCameraCollection(); cameraCollection->addCamera("Cam1", "VCC4", "Camera", "VCC4"); handlerCamera = new ArServerHandlerCamera("Cam1", &server, &robot, camera, cameraCollection); } // Conección con el robot if (!simpleConnector.connectRobot(&robot)) { printf("Could not connect to robot... exiting\n"); Aria::shutdown(); return 1; exit(1); } // Abrir la conección con ACTS acts.openPort(&robot); // Inicializa la cámara vcc4.init(); // Prevenir que el robot vaya muy rápido robot.setAbsoluteMaxTransVel(400); // Habilitar la recepción de comandos robot.comInt(ArCommands::ENABLE, 1); // Apagar los sonidos de amigobot robot.comInt(ArCommands::SOUNDTOG, 0); // Se añadern las acciones con su respectivo nivel de importancia robot.addAction(&limiter, 100); robot.addAction(&limiterFar, 99); robot.addAction(&backwardsLimiter, 98); robot.addAction(&seguir, 77); robot.addAction(&backup, 50); robot.addAction(&stop, 30); //Habilitar los motores robot.enableMotors(); // log whatever we wanted to before the runAsync simpleOpener.checkAndLog(); // Corremos el servidor asincrono. 49.

(56) server.runAsync(); printf("Server is now running...\n"); // Se añade un key handler que maneje la salida oprimir escape //if ((keyHandler = Aria::getKeyHandler()) == NULL) if (Aria::getKeyHandler() == NULL) { keyHandler = new ArKeyHandler; Aria::setKeyHandler(&keyHandler); robot.lock(); robot.attachKeyHandler(&keyHandler); robot.unlock(); printf("To exit, press escape.\n"); } robot.lock(); robot.attachKeyHandler(&keyHandler); robot.unlock(); printf("To exit, press escape.\n"); clientSwitchManager.runAsync(); //Corremos el robot asincronamente robot.runAsync(true); //Esperamos escape para salir robot.waitForRunExit(); }. 50.

(57)