Detección y evitación de objetos flotantes en el contexto de un vehículo autónomo de superficie

DETECCIÓN Y EVITACIÓN DE OBJETOS FLOTANTES EN EL CONTEXTO DE UN VEHÍCULO AUTÓNOMO DE SUPERFICIE. ALUMNA: LAURA DEL PINO DÍAZ TUTOR : JORGE CABRERA GAMEZ TRABAJO DE FINAL DE GRADO CURSO 2015/16 1 [Página intencionadamente dejada en blanco] 2 AGRADECIMIENTOS Me gustaría comenzar esta memoria agradeciendo a todas aquellas personas que de forma directa o indirecta han colaborado en la realización de este proyecto. Empezando por el profesor José Daniel Hernández por habernos llevado de visita al Instituto Universitario de Sistemas Inteligentes y Aplicaciones Numéricas en Ingeniería (SIANI) sin la cual no hubiese conocido a mi tutor Jorge Cabrera Gámez. A éste mismo por su apoyo, asesoramiento y paciencia a lo largo del desarrollo del Trabajo Final de Grado (TFG). A Antonio Carlos Domínguez Brito por prestarme parte del material utilizado para el desarrollo del TFG. También quiero agradecerle a mi familia por el apoyo y el consejo que me han prestado durante estos meses. Y por último y no por ello menos importante a mis amigos, compañeros de clase y de laboratorio por estar siempre ahí sacándome de la caja del problema para mostrarme que la solución de mis problemas está delante de mis narices. A todos muchas gracias. 3 [Página intencionadamente dejada en blanco] 4 RESUMEN El Instituto Universitario de Sistemas Inteligentes y Aplicaciones Numéricas en Ingeniería y en especial la División de Robótica y Oceanografía Computacional está desarrollando un velero autónomo de superficie que requiere de un sistema de visión por computador para la detección y evasión de obstáculos. Dicho sistema se ha desarrollado desde cero sobre una Raspberry Pi en la que se ha desarrollado un servicio para la captura de imágenes, así como un servidor web que permita la modificación de la configuración de la cámara a través de una página web. Una vez completada dicha infraestructura se tomarán las fotografías que conformarán el conjunto de entrenamiento para el sistema de visión por computador y se desarrollará este último. Como último paso se han integrado los resultados del sistema de visión por computador con el sistema del control del vehículo modificando el rumbo cuando se detecte un obstáculo. 5 [Página intencionadamente dejada en blanco] 6 ABSTRACT University Institute of Intelligent Systems and Numerical Applications in Engineering and, in special, the Division of Robotics and Computational Oceanographic is developing an autonomous sailing ship which requires a computer vision system for the detection and avoidance of obstacles. That system will be developed from scratch on a Raspberry Pi. A service for taking photos will be programmed, as well as a web service which allows modifications of the camera configuration from a web environment. Once this phase is completed, an image database is obtained using the previous system. This dataset will be used by the Computer Vision System to detect the possible obstacles. The last step in this process is the integration of the computer vision system with the control system to correct the course when an obstacle is detected. 7 [Página intencionadamente dejada en blanco] 8 Tabla de contenido AGRADECIMIENTOS ........................................................................................................... 2 RESUMEN .......................................................................................................................... 4 ABSTRACT .......................................................................................................................... 6 1 INTRODUCCIÓN ........................................................................................................ 10 1.1 INTRODUCCIÓN ............................................................................................................... 10 1.2 ESTADO ACTUAL .............................................................................................................. 10 1.3 OBJETIVOS ....................................................................................................................... 11 1.4 JUSTIFICACIÓN DE LAS COMPETENCIAS ESPECÍFICAS CUBIERTAS .................................. 12 1.5 APORTACIONES ............................................................................................................... 13 1.6 METODOLOGÍA DE TRABAJO ........................................................................................... 14 1.6.1 MATERIALES PARA EL DESARROLLO ........................................................................ 14 1.6.2 ENTORNO DE DESARROLLO ..................................................................................... 15 1.6.3 METODOLOGÍA DE DESARROLLO ............................................................................ 16 2 DESARROLLO DE LA INFRAESTRUCTURA BÁSICA ...................................................... 17 2.1 DEFINICIÓN DE INFRAESTRUCTURA BÁSICA ................................................................... 17 2.2 DESARROLLO DEL SERVICIO WEB PARA EL CONTROL DE LA CÁMARA ........................... 17 2.2.1 TIPOS DE USUARIOS ................................................................................................ 17 2.2.2 CASOS DE USO ......................................................................................................... 18 2.2.3 LA INTERFAZ GRÁFICA ............................................................................................. 19 2.2.4 EL SERVIDOR ............................................................................................................ 20 2.2.5 COMUNICACIÓN ENTRE EL SERVIDOR WEB Y EL CONTROL DE LA CÁMARA .......... 23 2.2.6 DESARROLLO DEL CONTROL DE LA CÁMARA .......................................................... 23 2.3 ELABORACIÓN DE UNA CARCASA PARA LA PROTECCIÓN DEL SISTEMA ......................... 26 2.4 PRUEBAS .......................................................................................................................... 29 2.4.1 TOMA DE FOTOS EN EXTERIORES ............................................................................ 29 2.4.2 COMPROBACIÓN DEL INTERVALO DE CAPTURA ..................................................... 32 2.4.3 ESTIMACIÓN DE LA DURACIÓN DE LA BATERÍA ...................................................... 35 3 DESARROLLO DEL SISTEMA DE VISIÓN POR COMPUTADOR ..................................... 37 3.1 CAPTURA DE LAS IMÁGENES ........................................................................................... 37 3.2 SISTEMA DE VISIÓN POR COMPUTADOR ........................................................................ 38 3.3 RESULTADOS DEL SISTEMA DE VISIÓN POR COMPUTADOR ........................................... 43 3.4 BONDAD DEL SISTEMA DE VISIÓN POR COMPUTADOR.................................................. 49 3.5 SISTEMA DE APRENDIZAJE DEL UMBRAL ........................................................................ 50 3.6 COMUNICACIÓN CON EL CONTROL DEL BARCO ............................................................. 50 4 SISTEMA DE EVASIÓN DE OBSTÁCULOS .................................................................... 54 4.1 DESCRIPCIÓN DEL PROBLEMA ......................................................................................... 54 4.2 ANÁLISIS DE LOS CASOS A AFRONTAR ............................................................................ 54 4.3 ALGORITMO DE CONTROL .............................................................................................. 55 5 CONCLUSIONES Y TRABAJO FUTURO ........................................................................ 57 6 REFERENCIAS ............................................................................................................ 59 APÉNDICE A: MÓDULO DE LA CÁMARA ........................................................................... 60 15 o Posee:  Entrada para batería de 3,7 V  Entrada para panel solar  Entrada para miniUSB tipo A para carga de la batería  Salida USB tipo A. o Extendido con:  Batería de 3,7V 6000mAh  Portátil Macbook Pro: o Posee:  Procesador de dos núcleos Intel Core i5. (2,7GHz)  8 GB de memoria RAM.  Interfaz WiFi, Bluetooth, FireWire para conexiones externas o Ejecuta el sistema operativo Mac OSX “El Capitan”. o Posee las siguientes aplicaciones destacables:  Compilador cruzado Linaro (versión no oficial para Mac OSX).  Entorno de desarrollo integrado Eclipse.  CMake para la compilación cruzada de librerías.  Netbeans como entorno de desarrollo integrado para programación web.  Servidor web MAMP.  MatLab 2014b.  Smartphone BQ Aquaris E5 o Permite generar una red Wifi local perfecta para comunicar ambos dispositivos. 1.6.2 ENTORNO DE DESARROLLO El entorno de trabajo consiste en conectar los tres componentes principales, presentados en el apartado anterior (Raspberry Pi, Macbook Pro y Aquaris E5) mediante la creación de una red Wifi generada por el smartphone a la que se conectan los otros dos componentes, permitiendo así que exista una comunicación entre ellos. No se ha conectado el portátil directamente a la Raspberry Pi porque utilizando el Smartphone se puede transmitir los ejecutables del portátil a la Raspberry Pi haciendo uso de la red creada por el Smartphone y permite prescindir del portátil a la hora de visualizar las imágenes en la playa ya que se puede acceder directamente desde el Smartphone manteniendo así el portátil seguro del salitre. El desarrollo de los programas involucrados en este trabajo se realiza en el Macbook Pro dentro del entorno de desarrollo integrado Eclipse. Éste permite la fácil integración con el compilador cruzado Linaro para la producción de ejecutables preparados para la arquitectura ARM propia de la Raspberry Pi. Dichos ejecutables se transmiten mediante una conexión segura a través de nuestra red WiFi particular y se ejecutan en la Raspberry Pi como si hubiesen sido desarrollados en este sistema. 16 1.6.3 METODOLOGÍA DE DESARROLLO La metodología de desarrollo elegida para este proyecto es el Proceso Unificado de Desarrollo de software, caracterizado por estar dirigido por los casos de uso, centrado en la arquitectura y por ser iterativo e incremental. Los casos de uso se determinaban en reuniones semanales y se daba un plazo de una semana para el desarrollo de los mismos. En estas mismas reuniones se validaban si el desarrollo se hacía de forma efectiva. La temporización estimada de cada uno de los puntos mostrados en la sección de OBJETIVOS se muestra a continuación: Configuración básica de la Raspberry Pi: interfaces e instalación de la librería OpenCV para visión por computador. 25 horas Desarrollo del servicio de captura de imágenes. 35 horas Desarrollo de un servidor web para la monitorización de la captura de las imágenes mientras se obtienen. 80 horas Integración del servidor web con el servicio de captura de imágenes. 20 horas Construcción de un contenedor que proteja la Raspberry Pi. 10 horas Obtención del conjunto de imágenes. 5 horas Estructura del algoritmo básico para la segmentación fondo-frente. 50 horas Desarrollo de una estrategia de control para la evitación de obstáculos teniendo en cuenta la información obtenida del sistema de visión y la información obtenida por otros sensores. 40 horas Documentación y defensa 35 horas 17 2 DESARROLLO DE LA INFRAESTRUCTURA BÁSICA 2.1 DEFINICIÓN DE INFRAESTRUCTURA BÁSICA El sistema de detección de obstáculos debe ser capaz de adaptarse a las condiciones del medio en las que se encuentra. Para comprobar que el algoritmo es capaz de realizar esta tarea es necesario disponer de un conjunto de imágenes con situaciones diversas a las que podría enfrentarse. Si identificamos los diferentes tipos de imágenes que podemos recoger tenemos tres casos principales:  La superficie del mar únicamente.  La superficie del mar con el horizonte y el cielo.  La superficie del mar con el horizonte, el cielo y un perfil de la costa. En nuestro caso nos centraremos únicamente en el primer caso. En ausencia de un conjunto de imágenes con estas características desarrollaremos una infraestructura que nos permita llevar la Raspberry Pi al entorno acuático similar a las condiciones que se tendrá que enfrentar cuando el sistema se integre en el vehículo autónomo de superficie. Para obtener dicho conjunto de imágenes nos vemos en la necesidad de: 1. Visualizar las imágenes mientras se capturan. 2. Ser capaces de modificar los parámetros de la cámara mientras se realiza la captura de las imágenes. 3. Proteger la Raspberry Pi para que no sea dañada por el agua o el salitre. Para lograrlo definimos como infraestructura básica para este proyecto el desarrollo de un servicio web que permita a un conjunto de usuario visualizar las imágenes obtenidas por la cámara mientras ésta las captura. Limitando el número de usuarios que pueden modificar los parámetros de la cámara a uno. Siendo éste el primero que pida los permisos de superusuario. También forma parte de esta infraestructura básica la construcción de una carcasa externa para proteger la Raspberry Pi del salitre. 2.2 DESARROLLO DEL SERVICIO WEB PARA EL CONTROL DE LA CÁMARA Con el objetivo de tomar las imágenes que formarán parte del conjunto de entrenamiento, y también para permitir el ajuste de los parámetros de la cámara, se ha desarrollado una página web en la Raspberry Pi que permita el acceso a cualquier dispositivo de cualquier plataforma que esté en dentro de su red. 2.2.1 TIPOS DE USUARIOS Para este servidor existen dos tipos de usuarios: el superusuario y usuarios normales. El superusuario es el primer usuario que pide permiso para acceder a la configuración de la cámara, dejando así como usuarios normales todos los demás que intenten acceder a la configuración de la cámara. 18 2.2.2 CASOS DE USO Las acciones que pueden realizar ambos tipos de usuarios son las siguientes:  Ver la imagen que ha capturado la cámara.  Pedir privilegios de superusuario para modificar la cámara. Las acciones que pueden realizar únicamente el superusuario son las siguientes:  Cambiar el estado de la cámara de apagado a encendido o viceversa.  Apagar por completo la Raspberry Pi.  Cargar la configuración por defecto de la cámara. 1  Proponer una configuración para ser enviada a la Raspberry Pi.  Enviar la configuración a la Raspberry Pi.  Seleccionar entre las resoluciones propuestas en la pestaña para la propuesta de la configuración. Los parámetros de configuración que se pueden ajustar desde la página web se muestran en la Tabla 1: Tabla 1: Parámetros configurables de la cámara desde la web con sus rangos y su valor por defecto. Todos ellos se determinan en un slider o barra deslizante que permite seleccionar los valores en una escala continua de números enteros. Al ser la escala de los parámetros ancho y alto muy amplia, dificultando así el ajuste con precisión de estos parámetros. Se aporta una pestaña con algunos de los valores de resolución más comunes y otras presentes en las especificaciones del sensor. Todos ellos los podemos ver en la Tabla 2 . 1 Para saber más de las características de la cámara consultar APÉNDICE A: MÓDULO DE LA CÁMARA . Parámetro Rango Valor por defecto Ancho [16,2592] 2592 Alto [16,1944] 1944 Nitidez [-100,100] 0 Contraste [-100,100] 0 Brillo [0,100] 50 Saturación [-100,100] 0 Tiempo de exposición [0, 6000] 0 ISO {100,200,400,800} Automático Balance de blancos: ganancia azul [0,  ) acotado a [0, 3000] 100 Balance de blancos ganancia roja [0,  ) acotado a [0, 3000] 100 19 Tabla 2: Resoluciones facilitadas en la pestaña de la página web. Resolución Dimensiones (en píxeles) Observaciones VGA 640x480 Presente en la especificación del sensor. Ratio ancho/alto = 1,3. XGA 1024x768 Ratio ancho/alto = 1,3. Widescreen 1600x1200 Ratio ancho/alto = 1,3. 720p 1280x720 Presente en la especificación del sensor. 980p 1280x980 Presente en la especificación del sensor. 1080p 1080x720 Presente en la especificación del sensor. QSXGA 2590x1944 Por defecto. Se especifica en la web al presionar el botón para cargar la configuración por defecto. Presente en la especificación del sensor. 2.2.3 LA INTERFAZ GRÁFICA El diseño de la página web es el que se muestra a continuación en la Ilustración 2 y la Ilustración 3 . Ilustración 2:Vista de la página web de la Raspberry Pi vista desde el Macbook Pro como superusuario con una imagen de prueba. 20 Ilustración 3: Vista de la página web de la Raspberry Pi vista desde el Macbook Pro como usuario normal con una imagen de prueba. Se ha optado por un diseño en horizontal que permita tener toda la información en el sentido de la lectura. De forma que la información que recibe el usuario está situado a la izquierda, siendo así el primer elemento que procesa el usuario, y las acciones a la derecha de forma que sigue el flujo natural de “recibir información” seguido de “tomar decisiones al respecto”. Los botones de la franja interior están colocados de forma que el botón de “logIn/logOut” que es el que primero se usa está en la parte superior, seguido de los botones del superusuario: el botón que controla en encendido y apagado de la cámara y el botón que apaga la Raspberry Pi. En la franja de la parte derecha de la Ilustración 2 se encuentra el panel que contiene los deslizadores correspondientes a los parámetros presentados en la Tabla 1. De esta franja solamente cabe destacar el bloque superior en el que se encuentra el botón que carga los valores por defecto en la web del cliente, proponiéndola para su envío, y la opción de seleccionar de donde viene la información de las dimensiones de la imagen: con el parámetro “User defined” la información se tomará de los deslizadores de ancho y alto mientras que con la opción “Standard defined” se tomarán los valores de la pestaña que fueron presentados en la Tabla 2 . 2.2.4 EL SERVIDOR La página web de la Raspberry Pi se construye sobre el servidor Apache. Este servidor no está instalado por defecto en la versión mínima del sistema operativo que ejecuta la Raspberry Pi sino que tiene que ser instalado y complementado con el módulo del intérprete de PHP 5 para ello se usa el comando ‘sudo apt-get install apache2 php5’. Una vez completada la instalación se podrán colocar los ficheros del servidor web en la ruta /var/www/html y se modifican los permisos para que el grupo propietario sea el correspondiente con www-data y su usuario propietario sea www-data que se trata del usuario que controla el servidor Apache. 21 El conjunto de ficheros que se encuentran en el servidor web se lista a continuación:  Ficheros PHP: o downgradeStatus.php : cambia el estatus del usuario de superusuario a usuario corriente. o index.php : genera la página principal. o lib_php.php : librería de funciones para generar la página principal dinámicamente. o lib.php : librería de funciones para generar el contenido estático (cabeceras HTML) de la página principal. o upgradeStatus.php : cambia el estatus del usuario de usuario común a usuario corriente siempre que no haya ningún otro usuario. o postHandler.php : recibe la información de la cámara del superusuario y se la retransmite al control de la cámara.  Ficheros Javascript o Jquery.js : framework de Javascript. o Script.js : conjunto de funciones para la modificación de la página web, sin la intervención del servidor.  Fichero CSS o wide_screen.css : hoja de estilo para la página web.  Fichero TXT o cache.txt : fichero donde se almacena la dirección ip del usuario para saber si existe o no un superusuario. El motivo por el que es necesario un fichero de text (.txt) es porque no existe una memoria que esté activa desde el momento en el que se inicia el intérprete PHP hasta que éste se desactiva. 22 El flujo de interacción entre los ficheros presentados anteriormente se muestra en la Ilustración 4 Ilustración 4: Diagrama de casos de uso interactuando con los ficheros del servidor. 23 2.2.5 COMUNICACIÓN ENTRE EL SERVIDOR WEB Y EL CONTROL DE LA CÁMARA La comunicación entre el servidor y el control de la cámara se realiza mediante el envío de objetos JSON a través de sockets. Cada vez que el superusuario quiera apagar o encender la cámara, cambiar la configuración de la misma o apagar la Raspberry Pi se abrirá un socket de comunicación desde el intérprete de PHP que trabaja en el puerto 80 al control de la cámara que estará escuchando en el puerto 3490. El tipo de conexión será orientado a conexión bajo el protocolo TCP que nos asegura la recepción de lo paquetes correctos y en orden. Los tipos de objetos JSON que puede transmitirse al control de la cámara a través del script de PHP ‘postHandler.php’ se representan en la Tabla 3. Cambio de estado de la cámara Apagado del sistema Cambio de configuración de la cámara Control ‘camStatus’ ‘shutDown’ ‘camSettings’ Width - - Valor entero Height - - Valor entero Sharpness - - Valor entero Contrast - - Valor entero Brightness - - Valor entero Saturation - - Valor entero ShutterSpeed - - Valor entero ISO - - Valor entero ExposureCompensation - - Valor entero redGain - - Valor entero blueGain - - Valor entero Tabla 3: Tipos de objetos JSON 2.2.6 DESARROLLO DEL CONTROL DE LA CÁMARA El objetivo de acceder a la cámara es obtener una imagen por segundo con la configuración que se decida desde el cliente web, para ello se ha desarrollado un programa concurrente que tiene las siguientes funcionalidades:  Escuchar en el puerto 3490 a la espera de objetos JSON para la modificación de los parámetros de la cámara.  Tomar una imagen desde la cámara y guardarla en una matriz de OpenCV.  Grabar la matriz de OpenCV en la memoria y en el servidor web.  Apagar el sistema operativo.  Apagar o encender la cámara. La concurrencia se realiza mediante la creación de dos hilos de ejecución uno para la escucha desde el puerto y otro para la captura de las imágenes. La región crítica que comparten ambos procesos es la estructura que contiene todos los parámetros de configuración de la cámara cuyo acceso está controlado por un mutex. 24 Otra variable de control de concurrencia que aparece en este programa es la variable condición que controla el encendido y apagado de la cámara. Esta variable pone en reposo el hilo de la cámara al comienzo de la ejecución (gracias a esto la cámara comienza apagada) y no es hasta que el hilo que escucha de la red recibe la orden de cambiar el estado de la cámara que la cámara no se enciende. Los dos hilos están desvinculados del proceso principal que los generó, por lo que al morir este proceso principal ambos hilos siguen ejecutándose en el sistema. Para el sistema operativo este estado en el que los hilos del proceso siguen vivos pero el programa padre no lo está se etiqueta como defunct . Ilustración 5:Creación de hilos Las tareas que realiza el hilo del control de la cámara son las que se muestran en la ilustración 5. 31 Ilustración 16: Imagen tomada con el obturador abierto 300ms Ilustración 17:Iimagen tomada con el obturador abierto 900ms Ilustración 18: Imagen tomada con el obturador abierto 4200ms (modo nocturno) Como se puede comprobar a partir de 900ms de exposición las imágenes empiezan a perder color y no nos interesan al igual que no nos interesan aquellas en modo nocturno, es por ello que preferimos aquellas imágenes que se obtienen con un tiempo de exposición de más de 1 ms a 300ms. Sin embargo, si planteamos un escenario donde tenemos un objeto que se mueve a 0.5m/s * 0.3s = 0.15m , el objeto se habrá movido 15 cm antes de que se cierre el obturador es por ello que tenemos que buscar otra forma de obtener las imágenes con tanto color con menos tiempo de exposición. Para ello haremos una prueba muy similar a la anterior donde no solo tocamos el tiempo de exposición sino 32 también la sensibilidad ISO que nos permite equilibrar la cantidad de luz. Los resultados de esta segunda prueba los encontramos en las ilustraciones de la Tabla 4: Tabla 4:Comparación de las imágenes obtenidas respondiendo a su valor ISO y a su tiempo de exposición. Tiempo de exposición ISO 100 ISO 200 ISO 400 ISO 800 10ms 20ms 30ms 80ms 100ms A la vista de las imágenes parece que tienen mejor calidad aquella con 80ms y 200 de ISO así como aquella con 30ms y 400 de ISO. Escogemos aquella que tiene menor tiempo de exposición para evitar que los objetos en la escena puedan moverse una distancia considerable durante el tiempo en que se tarda en tomar una fotografía. Al establecer estos nuevos parámetros como configuración inicial podemos proceder a realizar las fotos en el exterior. 2.4.2 COMPROBACIÓN DEL INTERVALO DE CAPTURA El objetivo es tomar una fotografía por cada segundo una vez el usuario haya dado la orden de encender la cámara, esto lo comprobamos añadiendo código que nos permita saber cuánto ha tardado en ejecutar cada uno de los pasos y obtenemos que para la resolución definida por defecto el sistema tarda aproximadamente unos 6 segundos. Al ser este dato inesperado tomamos los datos de tiempo de ejecución para cada una de las resoluciones que hemos definido en la pestaña de la interfaz gráfica, obteniendo así los siguientes resultados: 33 Tabla 5: Tiempo de ejecución por paso, para la resolución 2590x1944 2590x 1944 t(s) para la primera imagen t(s) para la segunda imagen t(s) para la tercera imagen t(s) para la cuarta imagen t(s) para la quinta imagen Media por paso Tomar la foto 1,43 1,39 1,47 1,42 1,43 1,428 Convertir buffer en matriz 1,53 1,53 1,47 1,48 1,49 1,5 Escritura en disco 1 1,72 1,67 1,67 1,69 1,67 1,684 Escritura en disco 2 1,66 1,66 1,66 1,68 1,67 1,666 Suma 6,34 6,25 6,27 6,27 6,26 6,278 Tabla 6: Tiempo de ejecución por paso, para la resolución 1080p 1080x720 (1080p) t(s) para la primera imagen t(s) para la segunda imagen t(s) para la tercera imagen t(s) para la cuarta imagen t(s) para la quinta imagen Media por paso Tomar la foto 0,4 0,38 0,38 0,39 0,38 0,386 Convertir buffer en matriz 0,29 0,3 0,3 0,31 0,31 0,302 Escritura en disco 1 0,33 0,34 0,33 0,33 0,33 0,332 Escritura en disco 2 0,33 0,33 0,33 0,33 0,33 0,33 Suma 1,35 1,35 1,34 1,36 1,35 1,35 Tabla 7: Tiempo de ejecución por paso para la resolución 980p 1280x980 (980p) t(s) para la primera imagen t(s) para la segunda imagen t(s) para la tercera imagen t(s) para la cuarta imagen t(s) para la quinta imagen Medi a por paso Tomar foto 0,65 0,64 0,62 0,62 0,63 0,632 Buffer a matriz 0,44 0,44 0,44 0,44 0,44 0,44 Escritura en disco 0,5 0,5 0,5 0,5 0,5 0,5 Escritura en disco 2 0,5 0,5 0,5 0,5 0,53 0,506 Suma 2,09 2,08 2,06 2,06 2,1 2,078 34 Tabla 8: Tiempo de ejecución por paso para la resolución 720p 1280x720 (720p) t(s) para la primera imagen t(s) para la segunda imagen t(s) para la tercera imagen t(s) para la cuarta imagen t(s) para la quinta imagen Media por paso Toma foto 0,41 0,4 0,4 0,4 0,42 0,406 Buffer a matriz 0,3 0,31 0,3 0,31 0,31 0,306 Escritura en disco 0,34 0,34 0,34 0,34 0,34 0,34 Escritura en disco 2 0,34 0,34 0,34 0,34 0,34 0,34 Suma 1,39 1,39 1,38 1,39 1,41 1,392 Tabla 9:Tiempo de ejecución por paso para la resolución widescreen 1600x1200 (widescreen) t(s) para la primera imagen t(s) para la segunda imagen t(s) para la tercera imagen t(s) para la cuarta imagen t(s) para la quinta imagen Media por paso Toma foto 0,96 0,94 0,98 0,93 0,98 0,958 Buffer a matriz 0,66 0,66 0,66 0,66 0,66 0,66 Escritura en disco 0,77 0,77 0,78 0,77 0,77 0,772 Escritura en disco 2 0,86 0,77 0,82 0,76 0,77 0,796 Suma 3,25 3,14 3,24 3,12 3,18 3,186 Tabla 10: Tiempo de ejecución por paso para la resolución XGA. 1024x768 (XGA) t(s) para la primera imagen t(s) para la segunda imagen t(s) para la tercera imagen t(s) para la cuarta imagen t(s) para la quinta imagen Media por paso Tomar foto 0,35 0,34 0,33 0,34 0,33 0,338 Buffer a matriz 0,26 0,25 0,26 0,26 0,26 0,258 Escritura en disco 0,29 0,29 0,28 0,29 0,29 0,288 Escritura en disco 0,28 0,28 0,28 0,28 0,28 0,28 Suma 1,18 1,16 1,15 1,17 1,16 1,164 35 Tabla 11: Tiempo de ejecución por paso para la resolución VGA 640x480 (VGA) t(s) para la primera imagen t(s) para la segunda imagen t(s) para la tercera imagen t(s) para la cuarta imagen t(s) para la quinta imagen Media por paso Tomar foto 0,15 0,14 0,15 0,15 0,14 0,146 Buffer a matriz 0,1 0,1 0,1 0,1 0,1 0,1 Escritura en disco 0,11 0,1 0,11 0,1 0,1 0,104 Escritura en disco 0,11 0,1 0,1 0,11 0,11 0,106 Suma 0,47 0,44 0,46 0,46 0,45 0,456 Como es de esperar el tiempo de ejecución disminuye al disminuir la resolución puesto que se reduce el número de bytes a transmitir. Lo que llama la atención es que el tiempo de ejecución de la toma de la fotografía y el guardado en el sistema de ficheros es comparable cuando la toma de la fotografía debería ser mucho más rápida. Con esta incógnita me puse en contacto con el desarrollador de la librería con la que se captura la imagen (OMXCam), Gabriel Llamas, quien me explicó que las operaciones con la cámara por lo general se suelen realizar en la GPU, pero con su librería se realizan en la CPU puesto que la documentación para implementar operaciones en la GPU de la Raspberry Pi no está liberado. Otro punto sobre el que arrojó luz Gabriel Llamas, es que la cámara, además de tomar la imagen, realiza operaciones como el balanceo de blanco que pueden producir que tarde más tiempo la captura de la fotografía. Sabiendo esto se opta por modificar la resolución por defecto de la cámara a la resolución 720p que da una imagen mayor y es más interesante para las fases de desarrollo en las que el sistema de visión por computador está aún en fase experimental. En la práctica se utilizará una resolución de 640x480 (VGA) para reducir el tiempo de ejecución de los cálculos. 2.4.3 ESTIMACIÓN DE LA DURACIÓN DE LA BATERÍA Para estimar la duración de la batería tenemos que tener en cuenta los siguientes factores:  La batería que está integrada en el sistema tiene una carga de 6000mAh según el fabricante y suministra un voltaje de 3,7V.  La Raspberry Pi demanda 5V de entrada por el puerto mini-USB.  La batería se conecta a la Lipo Rider Pro, la cual se encargará de subir el voltaje de los 3,7 V de la batería a los 5V que requiere la Raspberry Pi. En un caso ideal la intensidad suministrada por la batería llegaría íntegramente a la Raspberry Pi, pero como esto no es cierto sino que se pierde parte al pasar por la Lipo 36 Rider consideramos que existe un cierto factor λ que juega en nuestra contra decrementando la duración de la batería. De forma experimental medimos la intensidad demandada por la Raspberry Pi montando el siguiente circuito: Ilustración 19: Circuito elaborado para medir el consumo de la Raspberry Pi. Las medidas obtenidas se muestran en la tabla Tabla 12: Tabla 12: Relación de medidas obtenidas del experimento. Estado de la Raspberry Pi Intensidad máxima leída (mA) Duración aproximada de la batería Con la cámara apagada y sin conexión Wifi. 280 21,42 horas Con la cámara apagada y con una conexión 400 15 horas Cámara encendida(tomando y guardando imágenes) y con conexión 500 12 horas Este último caso es con el que nos vamos a encontrar a la hora de tomar el conjunto de imágenes de entrenamiento. Por tanto, tenemos como máximo 12 horas para tomar tantas fotografías como nos sea posible. 37 3 DESARROLLO DEL SISTEMA DE VISIÓN POR COMPUTADOR 3.1 CAPTURA DE LAS IMÁGENES Podemos clasificar las imágenes que se pueden tomar en el medio marino en tres categorías:  Solo la superficie del agua  La superficie del agua con el horizonte y el cielo  La superficie del agua con el horizonte, el cielo y un perfil orográfico. En cada una de estas categorías podremos encontrar objetos flotantes de diferentes dimensiones. En este proyecto circunscribiremos el problema de detección objetos flotantes a la primera categoría y con objetos flotantes de pequeñas dimensiones. Así pues, nos dirigimos a Sardina del Norte a tomar las fotografías con una serie de objetos, compatibles con muchos de los objetos de origen antrópico que se pueden encontrar flotando en el mar como “basura marina”. Los objetos poseen distintas características y que se detallan en la tabla: Tabla 13: Relación de los objetos utilizados y sus principales características Objeto Característica principal Foto. Bote de refrigerante Su superficie es de color uniforme. Brick de zumo Su superficie tiene distintos colores y texto. Brick de leche Su superficie tiene distintos tonos del mismo color. Botella de refresco Es transparente Del total de imágenes se seleccionaron 203 para utilizarlas como conjunto de entrenamiento y validación del sistema de visión por computador. 38 3.2 SISTEMA DE VISIÓN POR COMPUTADOR El sistema de visión por computador tiene por objetivo determinar si hay un objeto en el agua para - eventualmente - evitarlo. La detección de los objetos se realiza bajo la suposición de que todos los píxeles que pertenecen al mar son similares en cuanto a color entre ellos. La definición de color depende del espacio de color en el que se está trabajando, para este caso utilizaremos el espacio de color YCbCr. Este espacio de color está formado por tres canales: Y correspondiente información de la luminosidad de la imagen, Cb y Cr son las componentes de información de color azul y rojo respectivamente. Ilustración 20: Representación del espacio YCbCr r Ilustración 211: Plano de colores en el espacio YCbCr cuanod Y =0.5 En este espacio de color definiremos el color como el vector (Cb Cr) para cada píxel. En Matlab los valores que pueden adoptar cada uno de estos componentes pertenecen al intervalo entero [16, 240]. Al utilizar únicamente las componentes de color se obtiene un sistema que muestra a los cambios de intensidad debidos a las olas superficiales. 39 La imagen que captura la cámara se subdivide en ventanas de n x m píxeles que en este caso son 40 x 40 píxeles. Sobre cada una de ellas aplicamos un descriptor que nos ayude a decidir si el contenido de la ventana es objeto o no. Aprovechando que un canal del espacio de color contiene información sobre el color azul, y las escenas tienen en su mayoría mar, como primera intuición se desarrolla un descriptor basado en la media del componente Cb del espacio YCbCr. Se prueba utilizando un umbral que discrimina entre fondo y objeto puesto a mano para cada uno de los ejemplos: Tabla 14: Resultados del descriptor Cb Original Umbral Resultado 5 2.5 2 3 4 40 4 6 De estos resultados extraemos como conclusión que los objetos de color rojo no son se discriminan bien porque no se tiene información sobre este color. Por ello se desarrolla un descriptor basado en la multiplicación de los valores medios de los dos canales mostrados anteriormente, 𝐷 = 𝐶𝑏𝑚𝑒𝑑𝑖𝑜 ∗ 𝐶𝑟𝑚𝑒𝑑𝑖𝑜 de todos los píxeles de la ventana. Esta nueva dimensión nos da un valor para color que nos permite ordenarlos en la escala mostrada en la Tabla 16 según los valores de la Tabla 15. Tabla 15: Valores de los principales colores en los canales RGB y sus correspondientes valores CbCr del espacio de color YCbCr. Color R G B Cb Cr Cb*Cr Rojo 255 0 0 90 240 21600 Azul 0 0 255 240 110 26400 Verde 0 255 0 54 34 1836 Magenta 255 0 255 202 222 44844 Amarillo 255 255 0 16 146 2336 Celeste 0 255 255 166 16 2656 Blanco 255 255 255 128 128 16384 Negro 0 0 0 128 128 16384 Tabla 16: Escala de colores según su valor Cb*Cr. Verde Amarillo Celeste Blanco/Negro Rojo Azul Magenta La diferenciación entre mar y objeto está sujeta, al menos en esta primera versión, a la hipótesis de que la mayoría de las ventanas contendrán agua. Esto nos lleva a asumir 47 Admisible Admisible Admisible Admisible Admisible Admisible Admisible Admisible 48 Admisible Admisible Admisible Admisible No admisible: Tipo 1 No admisible Tipo 1 Admisible No admisible: Tipo 2 49 No admisible: Tipo 1 Admisible No admisible: Tipo 1 Admisible Admisible 3.4 BONDAD DEL SISTEMA DE VISIÓN POR COMPUTADOR De los resultados mostrados anteriormente extraemos las siguientes estadísticas: Admisibles 29 67% No admisibles 14 Clases 1 y 3: 7 16% Clase 2: 7 16% De ellas podemos concluir que el sistema no es muy fiable puesto que falla el 32% de los casos. Pero en los casos de los errores de tipo 1 y tipo 3 se pueden corregir si en lugar de recalcular el umbral en cada imagen, el umbral obtenido para la imagen anterior tuviera influencia en el umbral actual, en otras palabras, el sistema aprendiera el umbral basado en la imagen anterior. 50 De esta forma los casos de los errores de tipo 1 y tipo 3 serían corregidos y los podríamos añadir al conjunto de los admisibles consiguiendo así el sistema un 83% de acierto. 3.5 SISTEMA DE APRENDIZAJE DEL UMBRAL La corrección de los resultados no admisibles de tipos 1 y 3 consiste en el aprendizaje del umbral de forma que el umbral para la nueva imagen se ve influenciado por el umbral de la imagen anterior y el umbral calculado para la imagen actual, siguiendo el modelo matemático siguiente: 𝑇𝑡=(1 − 𝛼)𝑇𝑡−1 + 𝛼𝑇 Donde:  𝑇𝑡 es el umbral que se está calculando para esta imagen.  𝑇𝑡−1 es el umbral calculado para la imagen anterior.  𝛼 es el factor de aprendizaje. Este factor toma valores dentro del intervalo [0,1].  𝑇 es el umbral calculado al calcular el punto de inflexión sobre el historial para la imagen actual. 3.6 COMUNICACIÓN CON EL CONTROL DEL BARCO El sistema de visión por computador devuelve a su salida una imagen. Esta imagen coincide en dimensiones con el número de ventanas en la horizontal y en la vertical. Los valores que pueden tomar lo píxeles es negro ( 0 ) o blanco (1), de forma que los píxeles negros representan objetos y las blancas fondo. Dado que la cámara es fija, y tiene un ángulo fijo, podemos asociar a cada uno de estos píxeles una distancia aproximada a la que se encontraría el objeto. El cálculo de esta distancia se basa en la geometría del sistema, tal y como se muestra en la simulación creada con el motor para el desarrollo de videojuegos Unity 3 de la Ilustración 26. 3 Este motor de videojuegos se caracteriza por tener las unidades del mundo en metros de forma que la simulación se corresponde con una situación real. También permite modificar el ángulo de la cámara para que concuerde con las especificaciones del sensor de la cámara de la Raspberry Pi. 51 Ilustración 26:Simulación del barco en Unity. En la Ilustración 26, tenemos a la izquierda un esquema en 3D de lo que sería el barco con la cámara, representada con la esfera amarilla, colocada a 0,5 metros sobre la superficie del mar. La cámara está inclinada -26,6º sobre la horizontal para garantizar que la parte superior de la imagen tomada coincide con la línea del horizonte tal y como se muestra en la parte derecha de la Ilustración 26. Conociendo el ángulo de cobertura en la vertical del sensor, 41.4º según las especificaciones, podemos calcular la distancia a la que están los puntos de la imagen en la realidad. Ilustración 27: Cálculos de la geometría de la imagen. De la Ilustración 27 extraemos que los píxeles de la parte inferior de la imagen se encuentran a una distancia de 0.46 metros de la cámara, los puntos situados en la mitad de la imagen están a una distancia de 0.99 metros y los puntos de la parte superior de la imagen están a 4.83 metros. De las especificaciones del sensor extraemos que el ángulo de cobertura en la horizontal es de 53.3º por lo que los límites de la imagen están a -0.44m y a 0.44m a izquierda y derecha respectivamente. Con toda esta información podemos determinar a qué distancia están los cuatro vértices de la imagen en la realidad. 52 Ilustración 28: Medidas de los vértices de la imagen la realidad, respecto del sistema de coordenadas 2D coincidente con la superficie del mar, con el eje Y alineado con la línea de crujía del barco y cuyo origen se sitúa en la vertical del poste que sostiene a la cámara. En el sistema definitivo de visión por computador se van a usar una resolución de imagen de 640 x 360 píxeles para acelerar el proceso de detección de obstáculos. Esta nueva resolución al ser 4 veces inferior nos permite mantener el tamaño de ventana que teníamos anteriormente de 40 x 40píxeles. La salida del algoritmo de visión por computador es una imagen que tiene de ancho el número de ventanas en la horizontal en las que se subdividió la imagen de entrada y de alto el mismo número de ventanas en la vertical que las que se subdividió la imagen de entrada. Es decir, obtendremos una imagen de 16 x 9 píxeles. Tener una imagen más pequeña no facilita el cálculo del punto más cercano al barco al tener un menor número de puntos. Conociendo este punto más cercano al velero, tenemos sus índices en la horizontal y en la vertical. Esto junto con las coordenadas de los vértices nos permite dar una estimación de a qué distancia está el objeto siguiendo las Ilustración 29. Ilustración 29: Función que devuelve la estimación de la distancia a la que está. 53 La nueva coordenada en x se calcula como el i-ésimo paso a partir de la posición -0.44, donde el paso se calcula como la división del intervalo en 16 partes iguales correspondiendo cada parte a un píxel en la horizontal de la imagen resultado. De manera similar se calcula la coordenada en y, pero en este caso el paso se calcula restando al valor 4.8384 puesto que la coordenada 0 para la j está en la esquina superior izquierda y al ir aumentando los valores de j deben ir disminuyendo los valores de la y. 54 4 SISTEMA DE EVASIÓN DE OBSTÁCULOS 4.1 DESCRIPCIÓN DEL PROBLEMA La evasión de obstáculos es el fin último de este trabajo. La presente aproximación es a nivel teórico y acota el problema de la siguiente forma:  Se asume que la densidad de obstáculos es muy baja, de manera que sólo puede haber un obstáculo en cada imagen.  Las direcciones en las que el barco puede evitar el obstáculo quedan determinadas por la dirección del viento.  Los puntos marcados como destino están lo suficientemente lejos como para permitir que la evasión de inicie y se recalcule la ruta en vez de describir una trayectoria curva en un periodo breve de tiempo para esquivar el objeto. 4.2 ANÁLISIS DE LOS CASOS A AFRONTAR Es necesario definir el concepto de ángulo crítico 𝛽0, es aquel ángulo mínimo definido sobre la dirección del viento que permite que el velero pueda seguir navegando. Con la anterior simplificación del problema nos podemos encontrar con los siguientes casos:  El nuevo rumbo permite seguir navegando al no entrar dentro del ángulo crítico con el viento. |𝛽| > 𝛽0  El nuevo rumbo entra dentro del ángulo crítico |𝛽|< 𝛽0, pero el obstáculo está en la misma banda(estribor o babor) desde la que sopla el viento.  El nuevo rumbo entra dentro del ángulo crítico |𝛽|< 𝛽0, pero el obstáculo está en la banda contraria desde la que sopla el viento.  El nuevo rumbo coincide con la dirección del viento. |𝛽|= 0 55 4.3 ALGORITMO DE CONTROL El algoritmo de control se describe a continuación: A continuación, se adjunta una descripción de apoyo al algoritmo para mejor entendimiento: El sistema de control recibe la estimación de la posición del obstáculo en el caso en el que se detecte alguno. Con ella se estima un nuevo rumbo 𝜃. Se lee la dirección del viento aparente, AWD. La diferencia entre ellos da un ángulo 𝛽. Si el valor absoluto de 𝛽 es mayor que el ángulo crítico del sistema 𝛽0, la nueva dirección está bien calculada y se procede a modificar el rumbo. En caso de que el valor absoluto sea menor o igual pero distinto de 0: Si el obstáculo está en la misma banda que el viento: Se incrementa el ángulo 𝜃 como mínimo en la diferencia entre 𝛽 − 𝛽0 y se procede a modificar el rumbo. En caso contrario, es necesario cambiar bruscamente la trayectoria. Este cambio se representa como ∆𝜃 depende de lo próximo que esté el objeto. En caso de que el valor absoluto sea 0 se cambia el rumbo a la banda contraria al viento. función control_evasión_obtáculos { entrada real x,y ; // salida del sistema de visión por computador salida betha; constante betha_critico; theta := estimación_nuevo_rumbo(x,y); awd := lee_sensor_direccion_viento_aparente(); betha := theta – awd; abs_betha := abs(betha); //valor absoluto. si abs_betha > betha_critico modifica_rumbo(betha); si abs_betha > 0 si están_en_la_misma_banda (x,y,awd) betha += betha – betha_critico; sino betha := obtener_cambio_brusco_trayectoria(x,y,awd); fin si si abs_betha == 0 betha := obtener_nueva_trayectora_banda_contraria_al_viento(x,y,awd); fin si } 56 El anterior algoritmo no se ha podido probar porque el velero está siendo modificado y no se ha podido llevar al mar para probarse. 63 móvil protegido por varias capas de software del sistema operativo Android tendremos que configurar la dirección de la interfaz de red inalámbrica en la propia Raspberry Pi. La configuración de la interfaz la realizaremos sobre el fichero /etc/dhcp/dhcpcd.conf en el que añadiremos al final las siguientes líneas: Ilustración 33: Configuración estática de la interfaz En estas líneas se indica que para la interfaz wlan0 la dirección, el punto de acceso por defecto y el servidor de nombres de dominio son estáticos y son los que se establecen. 3. INSTALACIÓN DE LAS LIBRERÍAS NECESARIAS PARA EL DESARROLLO DEL TFG: OPENCV Y OMXCAM El sistema final será un sistema que necesita de una capacidad de reacción rápida, para minimizar los tiempos de ejecución se opta por utilizar los lenguajes C y C++ para el desarrollo del software involucrado ya que está a un nivel más cercano al nivel máquina. En este nivel utilizaremos las librerías OMXCam para el acceso a la cámara y a sus parámetros de configuración, OpenCV y BGSlibrary para las operaciones de separación del fondo y el frente. Nótese que la instalación de las librerías sólo se realiza en la Raspberry Pi; añadiéndose en los directorios de librerías correspondientes del sistema operativo, mientras en el Macbook Pro solamente se compilan usando el compilador cruzado en una carpeta destinada a almacenar las librerías compiladas de forma cruzada y se enlazan a la hora de crear los proyectos. OMXCAM La librería OMXCam sirve como capa de abstracción sobre las librerías OpenMax IL que controlan las operaciones de la cámara. Funciona a través de la creación de un hilo secundario conectado a la cámara que realiza sucesivas llamadas a un método llamado on_data definido por el usuario pasándole un búffer con una sección de la imagen. Se espera que el método on_data del usuario almacene dicha información para transformarla finalmente en una imagen completa. Esta librería es una librería compartida por lo que para utilizarla tras haberla compilado hay que trasladar una copia a la carpeta de librerías /usr/lib OPENCV OpenCV es la librería más conocida relacionada con los problemas de visión por computador. Está continuamente actualizándose, saliendo la versión 3 a comienzos de septiembre del año 2015, pero se prefirió utilizar una versión más estable como es la versión 2.4.11. 64 La instalación se realiza mediante el uso del programa CMake. Éste programa se usa de modo generalizado para la compilación cruzada pero también tiene la opción de utilizar el propio compilador del sistema para llevar a cabo la compilación. Al abrir CMake lo primero que tenemos que determinar son las rutas donde se encuentran los ficheros CMake.list y la ruta en la que se quiere guardar el código de instalación producido por CMake (éste último suele ser una nueva carpeta llamada build dentro del directorio anterior). Una vez establecidas ambas rutas hay que realizar dos pasos dentro de CMake: Configurar y Generar. Configurar permite elegir tanto el compilador que se va a utilizar como las opciones de compilación que más se ajustan a nuestro sistema como pueden ser la integración con otras librerías así como las rutas de instalación si se establece en el fichero CMake.lists que todo se puede modificar. Un ejemplo de los parámetros de configuración de esta fase se muestran en la Ilustración 34. El paso de Generar genera archivos Make (también conocidos como Makefiles) para la instalación correcta según lo que hayamos establecido en los parámetros de la fase de configuración. Ilustración 34: Algunos parámetros de configuración de la librería OpenCV. Con todo lo anterior hecho solamente queda ejecutar los comandos make; make install; para que se comience la instalación de la librería.