Co-diseño de un sistema de detección de señales de tráfico con SDSoC

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Intensificación en Sistemas Electrónicos Co-diseño de un sistema de detección de señales de tráfico con SDSoC Departamento de Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Autor: Álvaro Arjona Gamito Tutor: Hipólito Guzmán Miranda Sevilla, 2017 iii Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Co-diseño de un sistema de detección de señales de tráfico con SDSoC Autor: Álvaro Arjona Gamito Tutor: Hipólito Guzmán Miranda Profesor contratado doctor Dep. de Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2017 v Trabajo Fin de Grado: Co-diseño de un sistema de detección de señales de tráfico con SDSoC Autor: Álvaro Arjona Gamito Tutor: Hipólito Guzmán Miranda El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2017 El Secretario del Tribunal vii A mi familia A mis amigos A mis maestros ix Agradecimientos Quería agradecer a mi familia por todo el apoyo que me ha dado siempre. A mis padres, por todo su esfuerzo y hacer posible que haya llegado hasta aquí. También quería agradecer a Natividad, por hacerme mejor persona cada día. Por supuesto, también doy las gracias a todos mis compañeros y amigos que han hecho que mi etapa universitaria sea inolvidable. Álvaro Arjona Gamito Sevilla, 2017 5 Diseño de un sistema de detección de señales de tráfico 29 5.1 El problema de la detección de señales de tráfico 29 5.2 Esquema de un detector de señales de tráfico 29 5.3 Etapa de detección 30 5.3.1 Lectura de la imagen 31 5.3.2 Preprocesamiento de la imagen 31 5.3.3 Segmentacio n 31 5.3.4 Etiquetado de componentes conectados y extraccio n de las regiones de intere s 35 5.4 Etapa de reconocimiento 36 5.4.1 Clasificacio n por caracterí sticas locales 36 5.4.2 Descriptor basado en Histograma de Gradientes Orientados 39 5.4.3 Clasificador de Ma quinas de Vectores Soporte 42 5.4.4 Etapa de reconocimiento en otros trabajos de deteccio n de sen ales de tra fico 48 5.5 Aceleración hardware en el diseño de detectores de señales de tráfico 48 6 Estructura del detector de señales de tráfico desarrollado y resultados experimentales 51 6.3 Esquema general del detector de señales de tráfico 51 6.3.1 Etapa de deteccio n 52 6.3.2 Etapa de reconocimiento 55 6.3.3 Esquema del sistema completo 56 6.4 Resultados 56 6.4.1 Eficiencia del sistema 56 6.4.2 Aceleracio n del sistema 58 7 Conclusiones y trabajos futuros 61 7.3 Conclusiones 61 7.4 Trabajos futuros 61 Referencias 63 xvii ÍNDICE DE TABLAS Tabla 1: Modelos de la familia Zynq-7000 (Fuente: Xilinx) 6 Tabla 2: SDSoC Data Movers 25 Tabla 3: Resumen de las interfaces empleadas 55 Tabla 4: Señales de tráfico que pueden ser detectadas 55 Tabla 5: Resultado para todas las señales tras el experimento con las imágenes de test 57 Tabla 6: Resultado total tras el experimento con las imágenes de test. 58 Tabla 7: Rendimiento obtenido cuando se acelera la etapa de detección 59 xix ÍNDICE DE FIGURAS Figura 2-1: Esquema interno de un dispositivo Zynq-7000 (Fuente: Xilinx) 4 Figura 2-2: Esquema simple de una FPGA (Fuente:Xilinx) 5 Figura 2-3: Esquema de las interfaces AXI de los dispositivos Zynq-7000 [3] 8 Figura 2-4: Placa Zedboard [4] 10 Figura 3-1: Procesos de Scheduling y Binding 12 Figura 3-2: Flujo de desarrollo de un proyecto en Vivado HLS [6] 13 Figura 3-3: Vista del entorno gráfico de Vivado HLS 14 Figura 3-4: Vista del entorno gráfico de SDSoC 15 Figura 3-5: Ventana donde se selecciona OS (izquierda) y plataforma (derecha) para un nuevo proyecto en SDSoC 16 Figura 3-6: Ventana donde se seleccionan las funciones que serán aceleradas en la PL 16 Figura 3-7: Diseño por bloques de la plataforma Zed incluida en SDSoC 17 Figura 3-8: Frecuencias de reloj y recursos disponibles en la plataforma Zed 17 Figura 4-1:Aplicaciones para los sistemas heterogéneos con lógica programable (Fuente: Xilinx) 20 Figura 4-2: Ejemplo de un bucle ejecutado sin pipeline(iquierda) y con pipeline(derecha) [8]. 21 Figura 4-3: Ejemplo de tres funciones ejecutándose sin pipeline(iquierda) y con pipeline(derecha) [8]. 23 Figura 4-4: Ejemplo de tres bucles ejecutándose sin pipeline (izquierda) y con pipeline (derecha) [8]. 24 Figura 5-1: Esquema de un detector de señales de tráfico 30 Figura 5-2: Ejemplo de regiones de búsqueda en una imagen 32 Figura 5-3: Ejemplos de ventanas para un algoritmo de etiquetado 36 Figura 5-4: Efecto de aplicar un filtro Gaussiano sobre una imagen con distintos valores de σ 37 Figura 5-5: Respuesta a la DoG con diferentes escalas [29] 37 Figura 5-6: Búsqueda de extremos locales [29] 38 Figura 5-7: Pirámide de imágenes 38 Figura 5-8: Ejemplo de puntos SIFT detectados con su orientación 39 Figura 5-9: Ejemplo de aplicación del gradiente para buscar los bordes de una imagen 40 Figura 5-10: Ejemplo para el cálculo del gradiente 40 Figura 5-11: Representación de la magnitud y orientación del gradiente 41 Figura 5-12: Ejemplo de histograma de una celda en una imagen 41 Figura 5-13: Ejemplo de cómo dividir los intervalos para un histograma 42 Figura 5-14: Hiperplanos de separación en un espacio bidimensional de un conjunto de muestras separables en dos clases: (izquierda) ejemplo de hiperplano de separación y (derecha) otros ejemplos de hiperplanos de separación, entre los infinitos posibles. 43 Figura 5-15: Representación en un ejemplo de la distancia entre el hiperplano hasta la muestra más cercana de cada clase (izquierda) y del hiperplano óptimo y de las distancias máximas a los vectores de soporte (derecha) 44 Figura 6-1: Ejemplo de salida de la etapa de segmentación 52 Figura 6-2: Ejemplo de salida de la etapa de CCL 53 Figura 6-3: Interfaces de comunicación PS-PL 54 Figura 6-4: Esquema completo del detector de señales de tráfico 56 Figura 6-5: Ejemplo de señales con poca luminosidad, indetectables por la etapa de detección 58 xxi Notación AMS Agile Mixed Signal APU Application Processor Unit ASIC Application-Specific Integrated Circuit ASSP Application Specific Standard Product AXI Advanced eXtensible Interface BSD Berkeley Software Distribution BSP Board Support Packages CLB Configurable Logic Blocks CPU Central Processing Unit DDR Double Data Rate DMA Direct Memory Access DoG Difference of Gaussians EPP Embedded Processing Platform EMIO Extended Multiplexed I/Os FF Flips Flops FIFO First In First Out HDL Hardware Description Language HDMI High Definition Multimedia Interface HLS High Level Synthesis HOG Histogram of Gradient HW Hardware IP core Intellectual Property core JTAG Joint Test Action Group LPC Low Pin Count LUT Look-Up Tables PL Programmable Logic PS Processing System QSPI Queued Serial Peripheral Interface RoI Region of Interest RoS Region of Search RTL Registrer Transfer Languaje SDSoC Software-Defined System On Chip SoC System on Chip Soft IP Sotf Intellectual Property SVM Support Vector Machine SW Sofware UART Universal Asynchronous Receiver-Transmitter USB Universal Serial Bus VGA Video Graphics Array VHDL VHSIC Hardware Description Language 1 1 INTRODUCCIÓN 1.1 Motivación El desarrollo del vehículo autónomo es uno de los campos de investigación con más actividad hoy en día. Desde hace varios años, multitud de grupos de investigación y de empresas, principalmente del automóvil, trabajan en ello para que en el futuro puedan tener un lugar privilegiado en el sector de la automoción. Según varios expertos, se espera que el coche autónomo se pueda comprar libremente a partir del año 2025. Los vehículos autónomos serán vehículos conectados al medio y compartirán grandes cantidades de información entre sí y con el resto de la infraestructura. Es por esto, que el vehículo autónomo forma una importante parte del internet de las cosas (IoT). Varios son los factores que hacen que se alargue la fecha de lanzamiento al mercado y que van más allá del estado del arte de la tecnología: El marco legal, tener que construir costosas infraestructuras que son necesarias, las aseguradoras o la seguridad de estos nuevos sistemas. Los coches autónomos serán también coches conectados, por lo que estarían expuestos a ciberataques. Los nuevos coches autónomos reducirían el consumo, disminuirían o harían desaparecer los atascos, mejorarían el medio ambiente. Pero uno de los objetivos más importantes serían sin duda la reducción de la mortalidad en las carreteras. Según la comisión europea [1], más de 40 mil personas mueren al año en las carreteras y más de 1 millón y medio resultan heridas. Antes de llegar al vehículo completamente autónomo, existen híbridos entre coche autónomo y coche completamente manual. Muchos de los coches actuales disponen de asistentes al conductor, como frenado automático en caso de detección de colisión o atropello, aparcamiento automático, detección de obstáculos en la carretera, de peatones o de señales, y otros sistemas. El campo de la visión artificial está muy presente en la mayoría de estos sistemas que complementan al coche de hoy en día y que esperan mejorarlo hasta llegar al coche autónomo. Sensores de imagen, algoritmos de procesado de la imagen digital y algoritmos de aprendizaje son la parte fundamental de los sistemas de detección de objetos y conducción automática. La mayoría de estas aplicaciones tienen una característica en común: son aplicaciones de tiempo real. Es por esto, que la latencia de estas aplicaciones se convierte en algo crítico. Existen dos formas de reducir el tiempo de ejecución de estas aplicaciones: haciendo un algoritmo más eficiente o mejorando el hardware que lo procesa. De aquí surge el empleo de sistemas hardware heterogéneos capaces de procesar datos a gran velocidad gracias al paralelismo de sus circuitos. Introducción 2 2 1.2 Objetivos El objetivo de este trabajo es el del diseño de un sistema de detección de señales de tráfico. Este diseño será en realidad un co-diseño HW/SW que correrá sobre un dispositivo Zynq-7000 AP SoC de Xilinx. Para el desarrollo, se estudiarán distintos métodos de segmentación de la imagen y de reconocimiento de objetos. Parte del algoritmo del sistema irá implementado en hardware con el objetivo de mejorar las prestaciones del sistema en cuanto a velocidad. El tiempo de ejecución de la parte acelerada será comparada con la misma implementada sobre el microprocesador. Como resultado, el sistema será capaz de cargar desde una tarjeta de memoria fotografías reales de carreteras y de ciudad que contienen señales de tráfico, detectar las señales y reconocerlas. 1.3 Organización del documento A lo largo de esta memoria, se hará una introducción teórica sobre las herramientas y tecnologías utilizadas para la realización de este trabajo, se mostrarán los detalles del sistema implementado y de los resultados finalmente obtenidos. La memoria está compuesta de un total de 7 capítulos. Tras esta introducción, en el segundo capítulo se hablará sobre los dispositivos de la familia Zynq-7000 y la Zedboard, que es la plataforma donde será probado el detector desarrollado. En el tercer capítulo, se hablará sobre las herramientas necesarias para desarrollar el sistema, tanto del entorno de desarrollo utilizado, como de las librerías y tecnologías necesarias. En el cuarto capítulo, se presentarán algunas técnicas de desarrollo hardware cuando se utiliza la síntesis de alto nivel y se hablará de buenas prácticas para mejorar el rendimiento del sistema. Después, en el quinto capítulo, se hablará de la estructura general de un detector de señales de tráfico. En el capítulo seis, se hablará del sistema finalmente implementado, hablando de sus detalles y de los resultados de eficiencia y latencia obtenidos tras su implementación sobre una placa Zedboard. La memoria termina con un capítulo de conclusiones y trabajos futuros. 3 2 DISPOSITIVOS DE LA FAMILIA ZYNQ – 7000 Y LA ZEDBOARD En este capítulo se hará una presentación sobre los dispositivos System-on-chip (SoC) o sistema en chip. Explicaremos qué son y en qué consisten. Así, presentaremos la familia de dispositivos Zynq®-7000 de la compañía Xilinx®. Por último, presentaremos la placa de desarrollo Zedboard (creada en conjunto por Xilinx, Digilent® y Avnet®) que contiene uno de los dispositivos chip de la familia Zynq-7000 y es sobre la cual está desarrollado este trabajo. 2.1 Dispositivos System-on-chip (SoC) Los dispositivos SoC son unos circuitos integrados cada vez más utilizados hoy en día. Estos circuitos incluyen, dentro del mismo silicio, distintos módulos o tecnologías con el fin de poder utilizarlos de manera conjunta y aprovechar lo mejor de cada uno en un mismo proyecto. Los SoC permiten reducir el consumo, mejorar el rendimiento y la escalabilidad de los sistemas, y están presentes en multitud de aparatos de uso cotidiano como portátiles, móviles, tablets y otros aparatos. Los SoC suelen incluir en su interior: CPUs, GPUs, memorias, controladores (de sistema, de memoria, de datos, de interfaces), osciladores, dispositivos de lógica programable, conectividad y otros circuitos. 2.2 La familia Zynq-7000 Los dispositivos de la familia Zynq-7000 se basan en la arquitectura All Programmable SoC creada por Xilinx [2]. Estos dispositivos combinan un sistema de procesamiento (PS) dual-core ARM® Cortex™-A9 MPCore™ y una lógica programable (PL) de Xilinx fabricada con tecnología de 28nm dentro del mismo dispositivo. El sistema PS incluye, entre otras cosas, memoria on-chip, interfaces de memoria externa y un elevado conjunto de periféricos de entrada/salida. La familia Zynq-7000 ofrece todas las ventajas de flexibilidad y escalabilidad de una FPGA, y el rendimiento, potencia y la facilidad de uso típicamente asociado a los ASIC y ASSPs. La familia Zynq7000 de Xilinx incluye un amplio rango de dispositivos pensados para abarcar un amplio rango de aplicaciones. Todos los dispositivos de la familia Zynq-7000 comparten la misma PS, variando entre ellos la parte de PL y los periféricos. Según la compañía Xilinx, entre el elevado rango de aplicaciones que se pueden desarrollar con la familia Zynq-7000 se incluyen las siguientes [2]: Dispositivos de la familia Zynq – 7000 y la zedboard 10 10 Figura 2-4: Placa Zedboard [4] 11 3 HERRAMIENTAS PARA EL DESARROLLO En este capítulo se hablará de aquellas herramientas y entornos de desarrollo que empleamos para el diseño de este trabajo. Se hablará también de la síntesis de alto nivel para el diseño en lógica programable y se introducirán las librerías que se emplean en este trabajo. 3.1 Vivado HLS y la síntesis de alto nivel La síntesis de alto nivel (HLS) es una técnica que permite desarrollar hardware a partir de código software, tal como C o C++ [5]. HLS aumenta la abstracción del diseño hardware y proporciona un diseño optimizado con las características de rendimiento, área y consumo requeridos, sin la necesidad de utilizar lenguajes de descripción de hardware (HDL). El código fuente de un proyecto realizado con lenguaje de alto nivel debe estar compuesto por un código que describa la funcionalidad del sistema, y un conjunto de directivas y restricciones que ayudarán al diseñador a indicarle al compilador como quiere que sea implementado el sistema (temas de arquitectura del sistema final). Los requisitos a cumplir de nuestro diseño pueden ser restrictivos en velocidad o en área hardware utilizada. Las directivas que empleemos en nuestro código dependerán directamente de qué índole son estas restricciones. Si queremos reducir la latencia de la aplicación, emplearemos directivas que aumenten el paralelismo aumentando los recursos necesarios. Por otro lado, si los requisitos a cumplir son de área máxima empleada (como podría ser, por ejemplo, para aplicaciones espaciales donde el tamaño y el peso de los dispositivos está limitado) las directivas indicarán que se debe reducir el paralelismo. De esta manera se reducen los recursos empleados a cambio de aumentar la latencia. Existen dos ideas fundamentales en las herramientas de síntesis de alto nivel: el scheduling y el binding.  El scheduling es el proceso en el cual se decide en qué momento se ejecuta cada parte de un algoritmo. Esto es, cada tarea del algoritmo se divide en partes y se decide en qué ciclos de reloj se realiza cada una.  El binding consiste en decidir cuáles son los componentes de bajo nivel que se van a encargar de ejecutar cada parte del algoritmo. Herramientas para el desarrollo 12 12 Figura 3-1: Procesos de Scheduling y Binding El scheduling y el binding dependerán de las directivas utilizadas en nuestro código. Por ejemplo, si con nuestras directivas queremos aumentar la velocidad de ejecución de nuestro código habrá más partes que se ejecuten en el mismo ciclo de reloj y más recursos empleados a cada una. Estas decisiones las hacen las herramientas de HLS de forma automática. En un proceso de diseño hardware con lenguaje de bajo nivel HDL estas decisiones se habría que codificarlas manualmente. Las dos principales ventajas que ofrece HLS son: aumentar la productividad y reducir el coste de desarrollo. A cambio, obtenemos un diseño que se ve rebajado en rendimiento pero que puede ser válido si cumple con los requisitos mínimos requeridos. A pesar de que el diseño hardware mediante HLS aumenta la abstracción, no deja de ser necesario tener unos conocimientos básicos del dispositivo, de su funcionamiento y de su arquitectura. La herramienta que ha desarrollado Xilinx para el diseño en HLS es Vivado High-Level Synthesis (HLS). Vivado HLS transforma un código C (como puede ser código C, C++, SystemC u OpenCL) junto con una serie de directivas en una implementación RTL. Después, esta implementación RTL se transforma en un bloque IP que puede ser introducido dentro de otro diseño mediante otra herramienta llamada IP Integrator. En la siguiente figura podemos ver cómo es este proceso. 13 13 Co-diseño de un sistema de detección de señales de tráfico con SDSoC 3.1.1 Arquitectura de un Proyecto de Vivado HLS Figura 3-2: Flujo de desarrollo de un proyecto en Vivado HLS [6] Como se indica en [7] y como podemos observar en la figura anterior, en un proyecto de Vivado HLS tenemos las siguientes entradas:  Archivos C, C++ o SystemC: Estos archivos contienen las funciones que tienen que ser sintetizadas. Puede tratarse de un único archivo con una única función o, en caso de proyectos más complejos, de varios ficheros y una función principal con una jerarquía de sub-funciones.  Archivos testbenches: Son testbenches escritos en lenguaje C, C++ o SystemC que permiten verificar el funcionamiento del diseño tanto del modelo en C como del modelo RTL generado.  Restricciones: Restricciones al diseño, como pueden ser restricciones de timing (establecer un periodo de reloj deseado).  Directivas: Las directivas que indican al compilador las instrucciones necesarias de cómo tiene que ser la arquitectura final del diseño. Se pueden controlar términos de pipeline, paralelismo y, de forma general, la optimización del diseño. Igualmente, como se indica en [7] y como podemos ver en la figura anterior, en un proyecto de Vivado HLS tenemos las siguientes salidas:  Modelo SystemC: modelo del diseño a nivel RTL utilizado para verificación.  Archivos VHDL o Verilog: Modelo RTL en lenguaje VHDL o Verilog. Se trata de código sintetizable que puede ser introducido en un proyecto y usado para generar un bitstream (archivo .bit) para programar una FPGA o un dispositivo Zynq.  Paquete IP para Vivado, System Generator, o XPS: Paquete que contiene el modelo para ser implementado en proyectos de Vivado, diseños de System Generator o proyectos XPS. Es también, por lo tanto, código sintetizable. 3.1.2 Interfaz de usuario de Vivado HLS El entorno de trabajo de Vivado HLS está basado en Eclipse. Incluye 3 perspectivas principales [6]:  Perspectiva de síntesis. La perspectiva de síntesis es la que se utiliza para desarrollar el código de Herramientas para el desarrollo 14 14 los bloques IP y de los testbenches para validarlos y verificarlos, de la verificación se hablará más adelante. Se trata de la perspectiva por defecto.  Perspectiva de debug. La perspectiva de debug permite depurar el código que hemos creado permitiendo simular línea a línea el código y comprobar el valor de las variables en cada momento.  Perspectiva de análisis. Esta permite ver los detalles de síntesis de los bloques IPs generados. Estos detalles se refieren a la cantidad de recursos necesarios para la creación de cada bloque, la latencia, qué se hace en cada ciclo de reloj, etc. Para ello, primero es necesario realizar la síntesis del código, es decir, generar el bloque IP desde el código C. En la imagen de la figura 3-3 podemos ver la vista general de Vivado HLS en su perspectiva de síntesis. La perspectiva puede ser cambiada a través de las pestañas de arriba a la derecha. Figura 3-3: Vista del entorno gráfico de Vivado HLS 3.1.3 Simulación y verificación en Vivado HLS Vivado HLS permite, además de tomar código C y convertirlo en código RTL, comprobar que los bloques IP generados cumplen con el funcionamiento esperado. Para ello, podemos simular el comportamiento de un nuevo bloque a través de testbenches creados también con C (a lo que Xilinx llama como validación del código). A esto se suma que Vivado HLS permite utilizar estos testbenches, los mismos de validación, para la verificación del bloque RTL una vez que este ha sido creado. Vivado HLS permite simular directamente nuestro circuito con el código testbench, como también permite simular paso a paso el código en modo debug. En este modo, se permite ver el valor de cada variable en el paso a paso de nuestro código, así como poner puntos de parada, entre otras técnicas de depuración de código. Las directivas que aplicamos a nuestro código también permiten optimizar el rendimiento del sistema generado. Existen varias formas de optimizar un sistema, de lo que se hablará más detalladamente en el capítulo 4. 3.2 El entorno de desarrollo SDSoC SDSoC es un entorno de desarrollo de Xilinx basado en Eclipse que se utiliza para la implementación de sistemas completos hardware/software que se basen en los chips de Zynq-7000 o los chips de la familia UltraScale de Xilinx. Los compiladores de sistema (sdscc/sds++) transforman código C/C++ en un sistema 15 15 Co-diseño de un sistema de detección de señales de tráfico con SDSoC hardware/software completo. Primeramente, se tiene que especificar una plataforma de trabajo, donde quedará definido el hardware que se va a emplear. Se especifican los periféricos, las tarjetas de expansión, etc, que se van a utilizar y las funciones que serán aceleradas en la lógica programable. Al elegir la plataforma también van incluidos archivos de arranque (boot loaders) y archivos del sistema de archivos raíz [8]. En SDSoC todo el código que se escribe es en C/C++. Para el diseño de funciones en hardware se utiliza la herramienta Vivado High-Level Synthesis (HLS), que se encarga de pasar el código C/C++ a código RTL. 3.2.1 Aspecto del entorno de desarrollo El aspecto general del entorno SDSoC es el que podemos ver en la figura 3-4. De la ventana principal se pueden destacar las siguientes partes más importantes:  En el lado izquierdo suele estar la ventana exploradora de proyectos, donde podemos navegar a través de todos los archivos correspondientes al proyecto con el que estamos trabajando. Estos pueden ser los ficheros con código del proyecto o los archivos generados tras la compilación, entre otros.  La ventana del centro es la ventana que se utiliza para abrir los archivos, para programar o para abrir el archivo resumen de un proyecto.  En la ventana consola se puede ver toda la información de compilación de los proyectos. Figura 3-4: Vista del entorno gráfico de SDSoC 3.2.2 Creación de un nuevo proyecto Para crear un nuevo proyecto se debe pulsar sobre la pestaña File. A continuación, se pulsa sobre New>SDSoC proyect y aparecerá una nueva ventana donde se configuran las características de nuestro nuevo proyecto. Las opciones más importantes entre las que tenemos que elegir cuando creamos un nuevo proyecto son: el sistema operativo del sistema y la plataforma del sistema. En la figura de abajo podemos ver cómo es la elección de estas opciones. SDSoC permite crear diseños que contenga el sistema operativo Linux, sistema FreeRTOS o Standalone Herramientas para el desarrollo 16 16 (sin sistema operativo). La distribución Linux que se puede incluir a los proyectos SDSoC es Petalinux. Esta distribución de Linux ya viene compilada en la instalación de SDSoC, lo que permite agilizar el proceso de generación de un sistema. Con las herramientas de Vivado Design Suite se permite crear nuevas plataformas hardware sobre las que diseñar en SDSoC. Figura 3-5: Ventana donde se selecciona OS (izquierda) y plataforma (derecha) para un nuevo proyecto en SDSoC Tras generar un nuevo proyecto, ya se pueden codificar los ficheros fuente donde queda programado el funcionamiento de nuestro sistema. Las funciones que se quieran acelerar en la lógica programable serán seleccionadas desde la ventana Hardware Functions, la cual aparece cuando abrimos el archivo resumen del proyecto. Cuando queramos implementar una nueva función, esta debe cumplir los requisitos necesarios para que sea sintetizable. Figura 3-6: Ventana donde se seleccionan las funciones que serán aceleradas en la PL 17 17 Co-diseño de un sistema de detección de señales de tráfico con SDSoC 3.2.3 Plataformas para SDSoC Las plataformas para SDSoC pueden ser creadas con las herramientas de Vivado Design Suite e IP integrator. En las dos siguientes imágenes se puede ver el diseño por bloques de la plataforma utilizada en este proyecto y las características del dispositivo Zynq-7000 incluido. Figura 3-7: Diseño por bloques de la plataforma Zed incluida en SDSoC Figura 3-8: Frecuencias de reloj y recursos disponibles en la plataforma Zed Herramientas para el desarrollo 18 18 3.3 OpenCV OpenCV es una biblioteca libre de visión artificial originalmente desarrollada por Intel que cuenta con una enorme comunidad de usuarios. Al estar bajo la licencia de BSD, puede ser utilizada gratis tanto para uso académico como comercial. OpenCV es multiplataforma, por lo que existen versiones para distintos sistemas operativos como GNU/Linux, MAC OS, Windows, iOS y Android. Además, puede ser compilada para distintas arquitecturas de máquina. Esta librería se puede emplear con múltiples lenguajes como C++, C, Python y Java. OpenCV fue desarrollada para ser eficiente y fuertemente enfocada en aplicaciones de tiempo real, como diseñar sistemas de seguridad basados en detección de movimiento, reconocimiento de objetos, monitorización de sistemas industriales, sistemas de ayuda al conductor, como es nuestro proyecto, y otras aplicaciones. La versión que se emplea para el diseño de este trabajo es la 2.4.5. No es la última versión lanzada, pero es la última versión que incluye Xilinx ya pre-compilada para sistemas ARM, como el que está incluido en la placa de desarrollo Zedboard que se utiliza en este proyecto. Toda la información sobre OpenCV puede encontrarse en su página web oficial [9]. 3.4 Librería HLS Video Uno de los objetivos de este proyecto es el de acelerar algoritmos de procesamiento de imágenes en la FPGA para mejorar las prestaciones del sistema. Para ello, sería útil poder utilizar las librerías de OpenCV en la FPGA. El problema es que estas funciones no son sintetizables en ella, es decir, que no pueden ser implementadas en una FPGA. Xilinx ha creado la librería HLS_VIDEO que contiene un conjunto de funciones de OpenCV creadas a partir de código C++ sintetizable. Esta contiene funciones dedicadas al procesamiento de imágenes y al traspaso de imágenes entre PS-P a través de las interfaces AXI. Según se indica en [10] el flujo normal de trabajo para diseñar un sistema acelerado mediante lógica programable es como sigue. Primero, diseñar el algoritmo completo empleando funciones OpenCV. En segundo lugar, averiguar cuáles de estas funciones serían sintetizables en una FPGA. Por último, pasar estas partes del algoritmo a la FPGA empleando la librería sintetizable HLS_VIDEO. Solo algunas de las funciones incluidas en la librería OpenCV están también incluidas en la librería de Xilinx. Algunas de ellas no son sintetizables o, sencillamente, no están incluidas. 19 4 OPTIMIZACIÓN DE ALGORITMOS ACELERADOS EN UNA FPGA Una FPGA es un dispositivo programable compuesto por bloques de lógica configurable (CLB), interconexiones y bloques. Estas interconexiones pueden ser reconfiguradas para poder conseguir la funcionalidad del circuito deseada. Debido a la estructura que compone la FPGA, esta proporciona un alto grado de capacidad de procesamiento en paralelo. Es capaz de proporcionar un alto grado de rendimiento en aplicaciones que requieren una gran cantidad de operaciones computacionales. Esta es la gran ventaja de una FPGA frente a un microprocesador, el cual descompone cada algoritmo en pequeñas operaciones que realiza de forma secuencial. Las aplicaciones que suelen ser buenas candidatas para ser implementadas sobre lógica programable como la FPGA son los siguientes [3]:  Aplicaciones de comunicaciones: Las FPGAs tienen una gran capacidad para manejar grandes cantidades de datos y de información, lo que las convierten en grandes herramientas en tareas de codificación y encriptación empleadas, por ejemplo, en las comunicaciones. Además, las FPGAs permiten velocidades de transferencia más altas ya que, al procesar la información más rápido que un procesador, es capaz de vaciar los buffers más rápido.  Aplicaciones de visión artificial: De manera resumida, la visión artificial consiste en recibir información visual del exterior, procesarla y actuar en consecuencia. En la visión artificial, la capacidad de procesamiento es crítica ya que se suelen manejar una gran cantidad de datos que deben de ser procesados en poco tiempo. Esta información está en forma de píxeles que pueden ser procesados en paralelo. Es por esto que la FPGA proporciona un gran rendimiento en el campo de la visión artificial.  Automoción: Sistemas de ayuda al conductor, posicionamiento, control automático, detectores de señales, peatones o colisión. Existen una gran cantidad de aplicaciones dedicadas a mejorar la automoción y que requieren un gran procesamiento de datos en tiempo real.  Aeronáutica y espacio: Debido a la gran capacidad de procesamiento de la FPGA y a su reducido consumo, tamaño y peso resultan muy útiles en aplicaciones espaciales y aeronáuticas donde el área empleada y el consumo resultan críticos.  Otras aplicaciones industriales. Optimización de algoritmos acelerados en una fpga 26 26 Almacenar los datos que van a ser transmitidos en memoria físicamente continua tiene claramente sus ventajas como, por ejemplo, poder emplear data movers más eficientes para transferirlos. En SDSoC, podemos asegurarnos de que un array de datos está almacenado en memoria físicamente continua empleando la función sds_alloc de la librería sds_lib [8]. Para indicar al compilador de que un array está almacenado en memoria físicamente continua, en el caso de que no lo detectara de manera automática, es posible emplear la directiva: #pragma SDS data mem_attribute (A:PHYSICAL CONTIGUOUS) 4.3.3 Acceso a los datos de forma secuencial o aleatoria. Las directivas de código también deben indicar qué patrón queremos seguir a la hora de trasmitir datos a través de las interfaces AXI. Generalmente existen dos opciones [8]:  Cuando una función hardware transmite un array en forma de streaming de datos (es decir, siguiendo el orden índice de la lista) se debe de emplear la directiva: #pragma SDS data access_pattern(A:SEQUENTIAL)  En el caso de que el streaming no sea posible, sino que los valores de la lista serán transmitidos de forma distinta a la de su índice, la directiva que deberá indicarse es la de: #pragma SDS data mem_attribute (A:RANDOM) El streaming es el método más eficiente de transmitir datos ya que se reduce el número de accesos a la memoria externa. Debe de elegirse esta forma por defecto y la aleatoria en caso contrario. 4.4 Procesamiento de imágenes en FPGA con herramientas de HLS Los algoritmos de procesamiento de imagen y video son algoritmos que contienen una alta carga de procesamiento de datos. El tratamiento que se hace con cada uno de los píxeles suele ser repetitivo y suele admitir el procesamiento en paralelo. Esto quiere decir que estos algoritmos son candidatos perfectos para ser acelerados en la lógica programable. Para conseguir el mayor rendimiento posible, existen una serie de buenas prácticas que se deben de llevar a cabo. Estas buenas prácticas tienen que ver en el empleo de la memoria y cómo no generar cuellos de botella ni dejar a un bloque a la espera de datos. Xilinx ha redactado una nota de aplicación donde habla de estas buenas prácticas [11]. A continuación, se resumirán estos métodos que serán empleados en el proyecto para el procesamiento de imágenes de entrada antes del reconocimiento de las señales de tráfico. Puede consultarse la referencia mencionada para más información. 4.4.1 Empleo de estructuras de memoria Las imágenes pasan a la lógica programable como un streaming de píxeles. Debido a las limitaciones de latencia y de espacio, no resulta viable almacenar una imagen completa en la memoria de la PL, aunque la mayoría de algoritmos de procesamiento de imágenes necesitan conocer en cada momento el valor de los píxeles vecinos del píxel sobre el que estamos trabajando. ¿Cómo se puede conocer el valor de los pixeles vecinos sin la necesidad de almacenar la imagen completa en memoria? Existen 3 estructuras de memoria muy utilizadas en el procesamiento digital de imágenes en una lógica programable:  Registros de desplazamiento: Los registros de desplazamiento permiten almacenar de manera temporal un buffer de una dimensión de datos. Estos datos llegan como un streaming y van almacenándose en el registro de desplazamiento de forma que se pueda acceder a cualquiera de los píxeles en cualquier momento.  Ventanas de memoria: Una ventana de memoria permite almacenar un conjunto de 𝑁 píxeles vecinos que rodean a un pixel 𝑃 central. Puede accederse a cualquiera de ellos en cualquier momento. 27 27 Co-diseño de un sistema de detección de señales de tráfico con SDSoC  Buffers de línea: Un buffer de línea es un registro de desplazamiento multidimensional capaz de almacenar varias líneas de píxeles de una imagen. Los bufferes de línea son implementados mediante block RAMs. Puede consultarse más información al respecto en la referencia [12]. 4.4.2 Evitar los cuellos de botella en los accesos a datos Un patrón de acceso a datos incorrecto puede hacer a nuestra aplicación tener que esperar por la lectura y escritura de datos. A continuación, se resumen los detalles que hay que tener en cuenta:  Evitar releer datos de la memoria externa por parte de la lógica programable. Reutilizar los datos ya leídos almacenándolos en cualquiera de las estructuras de memorias vistas en el apartado anterior.  Minimizar el acceso a arrays, especialmente si son grandes arrays. Los arrays están implementos en block RAMs, los cuales solo tienen un número limitado de puertos de entrada/salida. Los arrays pueden ser particionados en arrays más pequeños o incluso en registros individuales para permitir el acceso en paralelo a más datos y así evitar los cuellos de botella. Los métodos de partición de arrays han sido vistos en el apartado anterior.  Minimizar las veces de escritura de datos en memorias externas ya que, de la misma manera que en la lectura de datos, los accesos a memorias externas son las que producen más latencia. Optimización de algoritmos acelerados en una fpga 28 28 29 29 Co-diseño de un sistema de detección de señales de tráfico con SDSoC 5 DISEÑO DE UN SISTEMA DE DETECCIÓN DE SEÑALES DE TRÁFICO En este capítulo se va a presentar cómo es el desarrollo de un sistema de detección de señales de tráfico. En primer lugar, se plantean los principales problemas a los que hay que enfrentarse a la hora de reconocer un objeto en una imagen y, concretamente, a la hora de reconocer una señal de tráfico en su contexto normal. Después, se analizarán distintas arquitecturas e implementaciones posibles y estudiadas en otros papers o trabajos. 5.1 El problema de la detección de señales de tráfico Los entornos en los que existen las señales de tráfico, como pueden ser las carreteras o la ciudad, suelen ser escenarios complejos, con multitud de objetos que pueden dificultar bastante la detección de señales de tráfico para un sistema de visión artificial. Los factores que dificultan la detección de señales de tráfico pueden ser:  Oclusiones por objetos que tapan a las señales, como por ejemplo: peatones, coches, arboles u otras señales.  Señales que aparecen rotadas o giradas, lo cual dificulta su reconocimiento.  Distintas condiciones de luz que pueden alterar la percepción de los colores por la cámara. Esto puede pasar en situaciones como: en el ocaso del día, de noche o en el amanecer; o con condiciones meteorológicas adversas, como lluvia o nieve.  El vandalismo, que puede afectar a la forma y al color de la señal.  Objetos parecidos en forma o en color, los cuales pueden ser reconocidos como una señal de tráfico si se utilizan métodos de reconocimiento poco robustos.  La gran variedad de señales que existen también es una dificultad añadida importante. No solo se trata de determinar si una imagen contiene una señal de tráfico, sino que también hay que determinar de cuál se trata. La mayoría de las señales presentan características parecidas de color y de forma, y casi siempre la principal dificultad para el clasificador está en diferenciarlas. 5.2 Esquema de un detector de señales de tráfico Como se ha visto, el entorno de una señal de tráfico es un entorno complejo. Para que sea efectivo un “Knowing a great deal is not the same as being smart; intelligence is not information alone but also judgement, the manner in which information is coordinated and used.”. - Carl Sagan - Diseño de un sistema de detección de señales de tráfico 30 30 sistema de detección de señales resulta necesario eliminar el exceso de información de la imagen sin perder la que resulta de interés. Pero esto es algo que ocurre prácticamente en todos los campos de reconocimiento de objetos y de visión artificial. Así pues, cualquier sistema de procesamiento de imágenes se suele dividir en dos niveles: procesamiento de nivel bajo y procesamiento de nivel alto [13].  Procesamiento de nivel bajo: Es el primero que se aplica a la imagen. Antes del procesamiento de nivel bajo tenemos la imagen completa y original, y tenemos poco conocimiento sobre ella. Los 4 procesos principales que se hacen en el nivel bajo son: adquisición de la imagen, preprocesamiento, segmentación de la imagen, descripción y clasificación de objetos.  Procesamiento de nivel alto: Es el siguiente paso tras el procesamiento de nivel bajo. En el procesamiento de nivel alto tenemos suficiente información como para tomar decisiones respecto al contenido de la imagen. En este trabajo, al igual que en la mayoría de investigaciones sobre detectores de señales de tráfico, al procesamiento de nivel bajo se le suele llamar etapa de detección y al procesamiento de nivel alto, etapa de reconocimiento. A continuación, se explicarán, por separado y en detalle, las dos etapas. Figura 5-1: Esquema de un detector de señales de tráfico 5.3 Etapa de detección El objetivo de la etapa de detección, como se acaba de comentar, es el de reducir la información de la imagen de entrada todo lo posible para facilitar la tarea de reconocimiento a la siguiente etapa. La etapa de detección debe determinar, de la imagen de entrada, qué regiones tienen probabilidad de contener una señal de tráfico y qué regiones deben de ser descartadas. De las primeras, debemos calcular las coordenadas para utilizarlas en la etapa de reconocimiento. Veamos de qué tipo de operaciones está compuesta esta etapa. La etapa de detección suele incluir las siguientes tareas, que no tienen por qué ser todas:  Lectura de la imagen. Evidentemente, el primer paso para la etapa de detección es cargar el primer frame. Las imágenes pueden venir como imágenes individuales o ser un video, que es una composición de imágenes igualmente. Estas imágenes son leídas en un formato de color determinado, normalmente en el espacio de color RGB, y debe de ser adaptado al sistema. Las imágenes pueden proceder de una cámara o de la memoria. Lectura de la imagen Etapa de detección Etapa de reconocimiento 31 31 Co-diseño de un sistema de detección de señales de tráfico con SDSoC  Preprocesamiento de la imagen. Consiste en el tratamiento de la imagen para mejorarla. Se pueden aplicar filtros, como el filtro Gaussiano o el filtro de mediana, para suavizar la imagen y eliminar ruido. También, se suelen emplear operaciones morfológicas para eliminar pequeños objetos que son demasiado pequeños como para reconocerlos.  Segmentación. Se procesan los píxeles de la imagen en busca de sus características. El objetivo es poder clasificar los píxeles según algún criterio. Normalmente, en los sistemas de detección de señales se suele analizar el color y la textura de los píxeles. De esta manera, se filtrarán aquellos píxeles de un color específico o el conjunto de píxeles que tenga una forma geométrica específica.  Descripción y clasificación de objetos. Se trata de clasificar, según algún criterio, a aquellos píxeles que han pasado el umbral en la segmentación. Por ejemplo, separar píxeles rojos de azules o separar píxeles que forman una figura circular de los que forman una cuadrada. 5.3.1 Lectura de la imagen No será objeto de este trabajo la lectura de imágenes desde una cámara, sino que las imágenes serán leídas desde la memoria flash. El hecho de añadir una cámara implicaría el diseño de bloques IP, implementaciones de interfaces DMA, drivers, etc. Las imágenes serán leídas de la memoria empleando funciones definidas en la librería OpenCV. Después, las imágenes se adaptarán al formato empleado en el sistema. Esta parte será mejor explicada en segmentación. 5.3.2 Preprocesamiento de la imagen Como ya se ha dicho, el preprocesamiento de la imagen sirve para mejorarla de cara a las etapas de segmentación, clasificación y reconocimiento. Existen multitud de técnicas de procesamiento de la imagen, como por ejemplo técnicas de suavizado de la imagen mediante filtros o eliminación de pequeños puntos de la imagen mediante operaciones morfológicas. 5.3.3 Segmentación Segmentación por regiones de búsqueda Uno de los métodos más simples para segmentar la imagen consiste en separar el marco de la imagen en partes. El criterio de esta separación es considerar que, si una cámara está grabando la carretera o la calle por la que se conduce, las señales de tráfico solo aparecerán en algunas zonas de las imágenes grabadas y no en cualquiera. Estas zonas pueden ser, por ejemplo, los lados de la acera o colgadas de un semáforo, las cuales suelen quedar en los extremos del marco. A estas zonas, que son las únicas de la imagen original que son procesadas, se les llama comúnmente regiones de búsqueda (RoS). En [14] se aplica esta técnica de segmentación. En la siguiente imagen podemos ver un ejemplo de cómo se pueden establecer las RoS: Diseño de un sistema de detección de señales de tráfico 32 32 Figura 5-2: Ejemplo de regiones de búsqueda en una imagen Como podemos observar en el contexto de esta imagen, gracias al establecimiento de unas RoS adecuadas se evitaría el tratamiento de la parte central de la imagen, que en la mayoría de las veces no contendrá señales de tráfico y sí otros objetos que podrían pasar por otros umbrales y acabar clasificándose erróneamente como una señal. Segmentación por color Una de las ventajas de las señales de tráfico es que están compuestas de formas y colores muy definidos. En la mayoría de países, las señales de tráfico suelen estar compuestas de los siguientes colores: rojo, azul, amarillo y blanco. Por lo tanto, este es uno de los puntos fuertes que hay que tener en cuenta para filtrar las señales de tráfico. En el método de segmentación por color se hace uso de los colores característicos de las señales para tratar de diferenciarlas del resto de la imagen. Según este método, la imagen es recorrida píxel a píxel de forma que de cada uno de ellos se extrae el color y se hace pasar por un umbral para determinar si es del color que buscamos. El resultado de esta etapa es una imagen binaria, es decir, una imagen donde sus píxeles pueden valer ‘1’ (en caso de que ese píxel haya pasado el umbral por color) o ‘0’ (en caso de que no lo haya pasado y, por lo tanto, contiene fondo). La desventaja de los métodos basados en el color es que este puede verse afectado por diversos factores, de los que ya se ha hablado al comienzo del capítulo. 5.3.3.2.1 Espacio de color Cuando se emplea la segmentación por color hay que tener en cuenta qué espacio de color se va a utilizar. La mayoría de las veces, las imágenes son obtenidas en formato RGB. Este espacio tiene la ventaja de que es el sistema más fácil de implementar ya que suele ser el formato que se obtiene por defecto. Lo único que habría que hacer es extraer de cada píxel los 3 canales (R, G y B) y comparar esos valores con un umbral. Para la umbralización del color en RGB, en [15] se estudian varios métodos y ecuaciones. Tras varias pruebas, se llega a la conclusión de que las ecuaciones con las que mejores resultados se obtienen para umbralizar el color rojo y el color azul son las siguientes:  Para el color rojo: 33 33 Co-diseño de un sistema de detección de señales de tráfico con SDSoC 𝑅′(𝑖,𝑗)=𝑘1𝑅(𝑖,𝑗) 𝑘1𝜖[1−1.492] ( 1) 𝑝𝑖𝑥𝑒𝑙(𝑖,𝑗)=𝑟𝑜𝑗𝑜 𝑠𝑖{𝑅′(𝑖,𝑗)>2𝐺(𝑖,𝑗) 𝑦 𝑅′(𝑖,𝑗)>2𝐵(𝑖,𝑗) ( 2)  Para el color azul: 𝑅′(𝑖,𝑗)=𝑘2𝑅(𝑖,𝑗) 𝑘2𝜖[0.5−0.992] ( 3) 𝑝𝑖𝑥𝑒𝑙(𝑖,𝑗)=𝑎𝑧𝑢𝑙 𝑠𝑖{𝐵(𝑖,𝑗)>2𝑅′(𝑖,𝑗) 𝑦 𝐵(𝑖,𝑗)>𝐺+𝑜𝑓𝑓𝑠𝑒𝑡_𝑑𝑖𝑓𝑓 ( 4) donde 𝑜𝑓𝑓𝑠𝑒𝑡_𝑑𝑖𝑓𝑓 = 16 es un umbral que se utiliza para mejorar los resultados. Los valores de 𝑘1 y 𝑘2 dependen de los intereses del diseñador y sirven para compensar las diferentes condiciones de luz. El problema del RGB es que resulta muy sensible a los cambios de luminosidad de la imagen. Los cambios de las condiciones de luminosidad, debido a zonas oscuras o deslumbramientos, afectan de forma aleatoria a la captación del color. Uno de los espacios de color más utilizados es el HSI. HSI junto con HSV o HSL tienen la ventaja de que son invariantes a los cambios de luz de la imagen. La desventaja es que su implementación es más compleja, sobre todo cuando quieren ser diseñados sobre lógica programable. Para implementar la segmentación por color con alguno de estos formatos debe calcularse primero la componente de tono (𝐻), cuya fórmula es la siguiente [16]: 𝐻= {𝜃 𝑠𝑖 𝐵≤𝐺 360°− 𝜃 𝑠𝑖 𝐵≥𝐺} ( 5) con: 𝜃=𝑐𝑜𝑠−1{12[(𝐸−𝐺)+(𝑅−𝐵)] [(𝑅−𝐺)2+(𝑅−𝐵)(𝐺−𝐵)12]} ( 6) Como puede verse, calcular 𝐻 puede ser muy complejo si queremos sintetizar el cálculo en una FPGA. Sin embargo, se puede calcular de forma más rápida empleando la aproximación dada por [17]: Diseño de un sistema de detección de señales de tráfico 34 34 𝐻= { 0 𝑠𝑖 𝑅=𝐺=𝐵 (𝐺−𝐵)60° max(𝑅,𝐺,𝐵)−min (𝑅,𝐺,𝐵)𝑚𝑜𝑑 360°,𝑅≥𝐺,𝐵 (𝐵−𝑅)60° max(𝑅,𝐺,𝐵)−min(𝑅,𝐺,𝐵)+120°,𝐺≥𝑅,𝐵 (𝑅−𝐺)60° max(𝑅,𝐺,𝐵)−min (𝑅,𝐺,𝐵)+240°,𝐵≥𝑅,𝐺 ( 7) Si quisiéramos ahora calcular los valores de saturación (𝑆) e intensidad (𝐼) para el espacio HSI, podemos aplicar las siguientes ecuaciones [18]: 𝑆=1− 3 (𝑅+𝐺+𝐵)[min(𝑅,𝐺,𝐵)] ( 8) 𝐼= 13(𝑅+𝐺+𝐵) ( 9) Podemos clasificar un píxel por color, cuando se tiene en formato HSI, con el siguiente criterio [16]: 𝑝𝑖𝑥𝑒𝑙(𝑖,𝑗) { 𝑅𝑜𝑗𝑜, 𝑠𝑖 10 ≤𝐻(𝑖,𝑗) ó 𝐻(𝑖,𝑗)≤300 𝐴𝑧𝑢𝑙, 𝑠𝑖 𝐻(𝑖,𝑗)≥190 𝑦 𝐻(𝑖,𝑗)≤270 𝐴𝑚𝑎𝑟𝑖𝑙𝑙𝑜, 𝑠𝑖 20≤𝐻(𝑖,𝑗)≤60 𝑦 𝑆(𝑖,𝑗) 𝐵𝑙𝑎𝑛𝑐𝑜, 𝑠𝑖 𝑆(𝑖,𝑗)≤48 𝑦 𝐼(𝑖,𝑗)≥60 ( 10) Para tener más información sobre los espacios de color puede consultarse [19]. 5.3.3.2.2 Segmentacio n por color en otros trabajos Otros trabajos de investigación donde se ha empleado la segmentación por color son:  En [16] se extrae la crominancia de cada píxel para clasificarlo por umbralización. En el estudio, se establecen de manera experimental diferentes valores de umbral para diferentes condiciones de luz y meteorológicas. Para más información sobre la crominancia de una imagen y del espacio de color YCbCr (basado en la crominancia) puede consultarse [20].  En [21] y [22] se utiliza el espacio de color RGB, haciendo uso de umbrales adaptativos.  En [23] se considera la implementación en hardware de la segmentación por color basado en HSV por delante de HSI al considerarse que se obtiene mejor latencia.  En [24] los píxeles en RGB también son transformados a HSV para su umbralización.  En [25] el espacio de color empleado es HSI.  En [26] se realiza un amplio repaso de numerosas investigaciones sobre detección de señales de tráfico en el que se concluye que HSV y HSL son los espacios de color más utilizados. Segmentación por forma Además de la segmentación por color, en la detección de señales de tráfico también se suele utilizar la segmentación por forma. La segmentación por forma consiste en identificar objetos de la imagen que tengan una forma geométrica determinada. En el caso de las señales de tráfico, estas suelen ser octogonales, rectangulares, triangulares o circulares. En la mayoría de los casos, la segmentación por forma suele ir precedida por la segmentación por color. Esto quiere decir que, de una imagen, primero se extraen las regiones que contienen colores determinados, como rojo, azul, etc, y después son clasificadas por su forma. Así, por ejemplo, una señal de ‘prohibido’ será segmentada por ser roja y después por ser circular. 35 35 Co-diseño de un sistema de detección de señales de tráfico con SDSoC Pero no tiene porque ser así, existen trabajos en los que solo se utiliza la segmentación por color y trabajos donde solo se utiliza la segmentación por forma. Existen diversos métodos algorítmicos para encontrar formas geométricas dentro de una imagen. El método empleado dependerá de si la imagen ha sido previamente segmentada por color o no. En el caso de haber sido segmentada por color, la segmentación por forma se procesará, normalmente, sobre una imagen binaria, lo que lo hace mucho más sencillo. 5.3.3.3.1 Segmentacio n por forma en otros trabajos Vemos algunos ejemplos donde se aplica la segmentación por forma:  En [27] se emplea la técnica de pattern matching para detectar formas después de la etapa de segmentación por color. Esta técnica consiste en comparar la forma de los objetos previamente detectados con formas geométricas almacenadas en memoria.  En [23] se utiliza la transformada de Hough para encontrar objetos circulares. Primero, se utiliza la segmentación por color. De la imagen binaria obtenida, se detectan los bordes de los objetos basándose en el gradiente de la imagen. Finalmente, se utilizan estos bordes para encontrar círculos con la transformada de Hough.  En [24] se utiliza el algoritmo de Ramer-Doublas-Peucker para reducir el número de puntos utilizados en la aproximación de una curva y determinar la forma de un objeto según el número de puntos obtenidos. 5.3.4 Etiquetado de componentes conectados y extracción de las regiones de interés El etiquetado de componentes conectados (CCL, connected component labeling) es uno de los procesos más importantes y utilizados en los sistemas de visión artificial. CCL supone la interfaz entre el procesamiento de imágenes a bajo nivel y el de alto nivel. CCL consiste en asignar un identificador único a cada conjunto conexo de píxeles de una imagen [28]. Este conjunto conexo suele recibir el nombre de objeto. La entrada del CCL es una imagen binaria que ha sido producto del procesamiento de nivel bajo del sistema. Como salida, el CCL devuelve un identificador único para cada objeto encontrado en la imagen binaria y sus coordenadas para ser localizado dentro de la imagen. Estas coordenadas son después necesarias para que en el procesamiento de nivel alto se puedan localizar los objetos y tratarlos. Para determinar si dos píxeles de una imagen están conectados se utiliza el siguiente criterio: en una imagen binaria B, dos píxeles p y q están conectados cuando estos pertenecen al primer plano (Foreground) o al fondo (Background) y existe un camino de píxeles del mismo tipo entre ellos, es decir, que se cumple (11), donde S es un subconjunto de píxeles de la imagen binaria B [13]. 𝑝 𝑐𝑜𝑛𝑒𝑐𝑡𝑎𝑑𝑜 𝑎 𝑞 ↔ ∋{𝑠𝑖∈𝑆 | 𝑠1=𝑝,𝑠𝑛+1=𝑞,𝑠𝑖+1∈𝑁(𝑠𝑖),𝑖=1,…,𝑛}, ( 11) siendo 𝑁(𝑠𝑖) el conjunto de vecinos del píxel 𝑠𝑖. Los algoritmos de CCL van recorriendo la imagen píxel a píxel analizando cada uno de ellos y a sus vecinos. Para ello, se establece una ventana alrededor del píxel que recoge, según el algoritmo, a cuatro o a ocho de sus vecinos más cercanos. Esta ventana puede tener alguna de las formas que se muestran a continuación: Diseño de un sistema de detección de señales de tráfico 42 42 dividir el rango de valores es con intervalos de 20º de manera que el rango 0º-180º queda dividido en 9 intervalos. Una vez fijados, el histograma se formará sumando los gradientes que se clasifican en cada uno de los intervalos. Figura 5-13: Ejemplo de cómo dividir los intervalos para un histograma Matemáticamente se puede expresar lo anterior de la siguiente manera: 𝑘= ∑ 𝜔𝑘(𝑥,𝑦)𝑔(𝑥,𝑦) (𝑥,𝑦)∈𝐶 ( 16) 𝜔𝑘(𝑥,𝑦)={1 𝑠𝑖 (𝑘−1)𝛿𝜃≤𝜃(𝑥,𝑦)<𝑘𝛿𝜃 0 𝑒𝑛 𝑐𝑎𝑠𝑜 𝑐𝑜𝑛𝑡𝑟𝑎𝑟𝑖𝑜 ( 17) donde 𝑘 es cada intervalo del histograma y 𝜔𝑘(𝑥,𝑦) es la asociación de cada píxel con su intervalo. Cálculo del descriptor HOG Una vez obtenido el histograma de cada una de las celdas que divide la imagen, el siguiente paso es calcular el descriptor de la imagen. Este es un vector que representa a dicha imagen y su dimensión vendrá determinada por ciertos parámetros configurables. El descriptor HOG se obtiene de la concatenación de los histogramas calculados. Se dice, por lo tanto, que una imagen queda representada por el conjunto de todos sus histogramas. Antes de realizar la concatenación, estos tienen que ser normalizados para disminuir efectos indeseados debido a agentes externos, como cambios en la iluminación de la imagen. 5.4.3 Clasificador de Máquinas de Vectores Soporte Según como se define en [29], las máquinas de vectores soporte (o support vector machine, SVM) son un tipo de clasificador binario, cuya solución se basa en encontrar el margen máximo entre dos clases a partir de unos vectores determinados conocidos como vectores soporte. SVM es un clasificador lineal, es decir, su solución es un hiperplano que permite dividir el espacio de características en dos regiones completamente disjuntas. Este hiperplano se calcula a partir de las muestras más cercanas de cada clase para, de esta forma, conseguir que el espacio libre de muestras a cada lado del hiperplano sea lo mayor posible. Para definir este hiperplano solo se consideran las muestras de entrenamiento de cada clase que quedan más cerca del hiperplano de separación. Estas muestras son las conocidas como vectores soporte. 43 43 Co-diseño de un sistema de detección de señales de tráfico con SDSoC SVM para clasificación binaria de muestras separables linealmente El escenario más simple para un SVM es el caso en el que se tienen dos únicas clases separables linealmente y sin muestras ruidosas. En la siguiente figura vemos un ejemplo gráfico. Se ha supuesto que todos los vectores de dos clases diferentes pueden representarse en un espacio bidimensional en el que el hiperplano equivalente que separaría las dos clases de forma lineal sería una recta. Figura 5-14: Hiperplanos de separación en un espacio bidimensional de un conjunto de muestras separables en dos clases: (izquierda) ejemplo de hiperplano de separación y (derecha) otros ejemplos de hiperplanos de separación, entre los infinitos posibles. Dado un conjunto de muestras 𝑆={(𝑥1𝑦1),… ,(𝑥𝑑𝑦𝑑)} , donde 𝑥𝑖 𝜖 ℝ𝑑 e 𝑦𝑖 𝜖 {+1,−1} , se puede definir un hiperplano de separación como una función lineal que es capaz de separar dicho conjunto sin error [32]: 𝐷(𝑥)=(𝜔1𝑥1+⋯+ 𝜔𝑑𝑥𝑑)+𝑏=<𝜔,𝑥>+𝑏 ( 18) donde 𝜔 𝜖 ℝ𝑑, 𝑏 𝜖 ℝ y el operador <𝑥1,𝑥2> representa el producto escalar de los vectores 𝑥1 y 𝑥2. Para todo el conjunto de muestras 𝑥𝑖, el hiperplano cumplirá las siguientes restricciones: <𝜔,𝑥𝑖>+ 𝑏≥0 𝑠𝑖 𝑦𝑖=+1 <𝜔,𝑥𝑖>+ 𝑏 ≤0 𝑠𝑖 𝑦𝑖=−1, 𝑖=1,…,𝑛 ( 19) o también: 𝑦𝑖(<𝜔,𝑥𝑖> +𝑏)−1 ≥0 𝑖=1,…,𝑛 ( 20) o de forma más compacta: 𝑦𝑖𝐷(𝑥𝑖)≥0, 𝑖=1,…,𝑛 ( 21) Como podemos imaginar, no existe un único hiperplano de separación para las muestras, sino que el conjunto de hiperplanos que cumple con las restricciones impuestas anteriormente es infinito. El objetivo de SVM es encontrar aquel hiperplano en el que el margen de separación entre muestras es máximo. Si definimos el margen, denotado por 𝜏 como la mínima distancia entre el hiperplano de separación y la Diseño de un sistema de detección de señales de tráfico 44 44 muestra más cercana, la solución óptima de SVM es aquel hiperplano cuyo margen será máximo. Podemos ver en la siguiente figura la solución óptima a unas muestras dadas que hay representadas. Figura 5-15: Representación en un ejemplo de la distancia entre el hiperplano hasta la muestra más cercana de cada clase (izquierda) y del hiperplano óptimo y de las distancias máximas a los vectores de soporte (derecha) Como se indica en [32], la distancia entre un hiperplano de separación y una muestra 𝑥′ viene dada por: 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎 (𝐷(𝑥),𝑥′)=|𝐷(𝑥′)| ||𝜔||, ( 22) siendo |.| el comando operador absoluto, ||.|| el operador norma de un vector y 𝜔 el vector que, junto con el parámetro 𝑏, define el hiperplano 𝐷(𝑥) y que, además, tiene la propiedad de ser perpendicular al hiperplano considerado. Por la definición de margen máximo, y por (21) y (22), todos los ejemplos de entrenamiento cumplirán que la distancia de cada uno de ellos al hiperplano de separación óptimo es mayor o igual que dicho margen, es decir: 𝑦𝑖𝐷(𝑥𝑖) ||𝜔|| ≥𝜏, 𝑖=1,…,𝑛 ( 23) Para el caso de los vectores soporte, que son las muestras situadas justo en la frontera que delimita el margen a cada lado del hiperplano de separación, se cumple por definición: 𝑦𝑖𝐷(𝑥𝑖) ||𝜔|| =𝜏, ∀𝑖∈𝑉𝑠 ( 24) donde 𝑉𝑠 denota el conjunto de todos los vectores soporte. Como se indica definitivamente en [32], la búsqueda del hiperplano óptimo para la clasificación binaria de ejemplos linealmente separables, se puede formalizar como el problema de encontrar los valores 𝜔 y 𝑏 que minimizan el funcional 𝑓(𝜔)=||𝜔|| sujeto a las restricciones dadas por (20) o, de forma equivalente 1 : 1 Obsérvese que es equivalente minimizar 𝑓(𝜔)=||𝜔|| o el funcional 1/2||𝜔||2 propuesto en (20). El proceso de minimización de este nuevo funcional equivalente, en lugar del original, permitirá simplificar la notación posterior, obteniendo expresiones más compactas. 45 45 Co-diseño de un sistema de detección de señales de tráfico con SDSoC min 12 ||𝜔||2≡ 12<𝜔,𝜔> 𝑠.𝑎. 𝑦𝑖(<𝜔,𝑥𝑖> +𝑏)−1 ≥0, 𝑖=1,…,𝑛 ( 25) Este problema de optimización con restricciones, como se indica en el documento anteriormente citado, corresponde a un problema de programación cuadrático y es abordable mediante la teoría de la optimización. Según la teoría de optimización, que se puede consultar en la referencia anterior y en [33], se establece que un problema de optimización, denominado primal, tiene una forma dual si la función a optimizar y las restricciones son funciones estrictamente convexas. En estas circunstancias, resolver el problema del dual permite obtener la solución del problema primal. Se puede demostrar que el problema de optimización (25) es convexo y, por lo tanto, tiene un dual. A continuación, se resumen los pasos establecidos en [32] para transformar el problema primal en su dual. En primer lugar, se construye la función lagrangiana [33]: 𝐿(𝜔,𝑏,𝛼)= 12<𝜔,𝜔> − ∑𝛼𝑖[𝑦𝑖(<𝜔,𝑥𝑖>+𝑏)−1] 𝑛 𝑖=1 ( 26) donde 𝛼𝑖 son los denominados multiplicadores de Lagrange. A continuación, se aplican las condiciones de Karush-Kuhn-Tucker(KKT): 𝛿𝐿(𝜔,𝑏,𝛼) 𝛿𝜔 ≡𝜔− ∑𝛼𝑖𝑦𝑖𝑥𝑖 𝑛 𝑖=1 =0 ( 27) 𝛿𝐿(𝜔,𝑏,𝛼) 𝛿𝑏 ≡∑𝛼𝑖𝑦𝑖 𝑛 𝑖=1 =0 ( 28) 𝛼𝑖[1−𝑦𝑖(<𝜔,𝑥𝑖>+𝑏)]=0, 𝑖=1,…,𝑛 ( 29) Las restricciones (27) y (28) corresponden al resultado de aplicar la primera condición KKT y las expresadas en (29) al resultado de aplicar la denominada condición complementaria (segunda condición KKT). Concretamente, la restricción dada por (27) permite expresar 𝜔 en terminos de 𝛼𝑖: 𝜔=∑𝛼𝑖𝑦𝑖𝑥𝑖 𝑛 𝑖=1 ( 30) La restricción (30) establece una restricción adicional para los coeficientes 𝛼𝑖: ∑𝛼𝑖𝑦𝑖 𝑛 𝑖=1 =0 ( 31) Y, finalmente, las dadas por (29), tal y como se verá más adelante, permitirán obtener el valor de 𝑏. Para construir el problema dual, se hace uso de (30) para expresar la función lagrangiana únicamente mediante los 𝛼𝑖. Antes de ello, se puede reescribir (26) como: Diseño de un sistema de detección de señales de tráfico 46 46 𝐿(𝜔,𝑏,𝛼)= 12<𝜔,𝜔> − ∑𝛼𝑖𝑦𝑖<𝜔,𝑥𝑖> 𝑛 𝑖=1 −𝑏∑𝛼𝑖𝑦𝑖 𝑛 𝑖=1 +∑𝛼𝑖 𝑛 𝑖=1 ( 32) Teniendo en cuenta (31), el tercer sumando de la parte derecha de la función anterior es nulo, por lo que la sustitución de (30) en dicha función resulta ser: 𝐿(𝛼)=12(∑𝛼𝑖𝑦𝑖𝑥𝑖 𝑛 𝑖=1 )(∑𝛼𝑗𝑦𝑗𝑥𝑗 𝑛 𝑗=1 )− (∑𝛼𝑖𝑦𝑖𝑥𝑖 𝑛 𝑖=1 )(∑𝛼𝑗𝑦𝑗𝑥𝑗 𝑛 𝑗=1 )+∑ 𝛼𝑖 𝑛 𝑖=1 𝐿(𝛼)=−12(∑𝛼𝑖𝑦𝑖𝑥𝑖 𝑛 𝑖=1 )(∑𝛼𝑗𝑦𝑗𝑥𝑗 𝑛 𝑗=1 )+∑ 𝛼𝑖 𝑛 𝑖=1 𝐿(𝛼)=+∑ 𝛼𝑖 𝑛 𝑖=1 −12∑𝛼𝑖𝛼𝑗𝑦𝑖𝑦𝑗<𝑥𝑖,𝑥𝑗> 𝑛 𝑖=1 ( 33) De esta forma se obtiene el problema dual, consistente en encontrar un 𝛼∗ que maximice la función (33) sujeta a las restricciones dadas por (32) y aquellas otras asociadas a los multiplicadores de Lagrange (𝛼𝑖≥0). Esto es: max 𝐿(𝛼)=∑ 𝛼𝑖 𝑛 𝑖=1 −12∑𝛼𝑖𝛼𝑗𝑦𝑖𝑦𝑗<𝑥𝑖,𝑥𝑗> 𝑛 𝑖,𝑗=1 𝑠.𝑎. ∑ 𝛼𝑖𝑦𝑖 𝑛 𝑖=1 =0 𝛼𝑖≥0,𝑖=1,…,𝑛 ( 34) Al igual que el problema primal, el problema dual es abordable mediante técnicas estándar de programación cuadrática, pero siendo más fácil de solucionar. La solución del problema dual, 𝛼∗, permitirá obtener la solución del problema primal. Para ello, bastará sustituir dicha solución en la expresión (30) y, finalmente, sustituir el resultado en (18), es decir: 𝐷(𝑥)=∑ 𝛼𝑖∗𝑦𝑖<𝑥,𝑥𝑖>+𝑏∗ 𝑛 𝑖=1 ( 35) Ahora necesitamos calcular 𝑏∗ para obtener la definición completa del hiperplano. Analizando la formulación del problema dual, fijándonos en (35), podemos ver que 𝜔 viene definido por la combinación lineal de las muestras de entrenamiento, pero solo de aquellas en las cuales su multiplicador de Lagrange asociado cumple 𝛼𝑖>0. Son, por lo tanto, estas muestras las únicas denominadas vectores soporte. De esta afirmación se puede confirmar que el hiperplano de separación (35) se construye con una combinación lineal de los vectores soporte, ya que el resto de muestras del conjunto de entrenamiento tendrán asociado un 𝛼𝑗=0. Para calcular 𝑏∗ empleamos la siguiente ecuación: 𝑏∗= 𝑦𝑉𝑠 − <𝜔∗,𝑥𝑉𝑠> ( 36) donde 𝑉𝑠 representa al conjunto de vectores soporte. 47 47 Co-diseño de un sistema de detección de señales de tráfico con SDSoC Se observa que tanto la definición del problema dual (34) como el hiperplano de separación óptimo (35) dependen del producto escalar de los vectores muestra. Esta propiedad se utiliza para calcular hiperplanos de separación óptimos en espacios transformados de alta dimensionalidad. SVM para clasificación binaria de muestras que no son separables linealmente En la mayoría de los casos prácticos las muestras de entrenamiento no podrán ser separadas linealmente como se ha visto hasta ahora, es decir, que no existirá un hiperplano definido como función lineal que separe las muestras de distintas clases. Cuando tenemos un espacio muestral en el que las muestras de distintas clases no pueden ser separadas linealmente existe la posibilidad de hacer una transformación no lineal de este espacio y construir un clasificador lineal en este nuevo espacio transformado. Dicho de otra forma, una frontera lineal en el espacio transformado puede representar una frontera no lineal en el espacio original. Esto permitiría resolver el problema mediante las técnicas de resolución vistas hasta ahora. Para hacer esta transformación se utiliza la técnica del kernel, que permite proyectar un espacio de características en otro de mayor dimensión en el que las muestras sí pueden ser separadas de manera lineal. Por lo tanto, la solución de un problema SVM en el que las muestras no son separables linealmente pasa por transformar, mediante una función de transformación, el espacio de muestras original a otro espacio de mayor dimensión con la esperanza de que en éste sus muestras sí sean linealmente separables. Esta función de transformación se suele expresar como 𝜙(𝑥) donde 𝑥 es cada vector del espacio de muestras original. En el nuevo contexto del espacio transformado, se demuestra [32] que la función de decisión del problema dual se obtiene transformando la expresión de la frontera de decisión en: 𝐷(𝑥)=∑ 𝛼𝑖∗𝑦𝑖𝐾(𝑥,𝑥𝑖) 𝑛 𝑖=1 ( 37) donde 𝐾(𝑥,𝑥′) se denomina función Kernel. Una función Kernel se define como una función 𝑘:𝕩 𝑥 𝕩→ℝ que asigna a cada par de elementos del espacio de entrada, 𝕩, un valor real correspondiente al producto escalar de las imágenes de dichos elementos en un nuevo espacio ℱ (espacio de características) [32], es decir, 𝐾(𝑥,𝑥′)=<𝜙(𝑥),𝜙(𝑥′)> ( 38) donde 𝜙:𝕩→ℱ es la función de transformación del espacio original 𝕩 al espacio transformado ℱ. De esta manera, el problema a resolver pasa a ser ahora la búsqueda del valor de los parámetros 𝛼𝑖∗;𝑖= 1,…,𝑛 que optimiza el problema dual expresado como [32]: max ∑ 𝛼𝑖 𝑛 𝑖=1 −12∑𝛼𝑖𝛼𝑗𝑦𝑖𝑦𝑗𝐾(𝑥𝑖,𝑥𝑗) 𝑛 𝑖,𝑗=1 𝑠.𝑎. ∑ 𝛼𝑖𝑦𝑖 𝑛 𝑖=1 =0 0≤𝛼𝑖≤𝐶,𝑖=1,…,𝑛 ( 39) donde 𝐶 es un parámetro de regularización del cual no existe una forma teórica de encontrar, pero se le suele asignar un valor grande. La metodología de solución a un problema SVM de clasificación de muestras no separables linealmente pasar por calcular los los parámetros 𝛼𝑖∗ conocidas las muestras de entrenamiento, el kernel 𝐾 y el parámetro de regularización 𝐶. Diseño de un sistema de detección de señales de tráfico 48 48 SVM para la clasificación multiclase Cuando se aplica el problema SVM en un caso multiclase se tienen en cuenta dos cosas básicas [34]:  Cada categoría debe ser dividida en otras y todas ellas combinadas entre si.  Se construyen k(k−1)/2 modelos, donde 𝑘 es el número de clases. Luego, cuando tenemos un problema SVM de clasificación multiclase, pasamos de tener un problema binario a varios problemas binarios. Para clasificar una muestra, esta tendrá que ser evaluada en cada modelo de clasificación tratado y será clasificada entre dos clases en cada uno. 5.4.4 Etapa de reconocimiento en otros trabajos de detección de señales de tráfico Existen multitud de estudios sobre la implementación de detectores de señales de tráfico y casi todos tienen su propio sistema diferente. En cuanto a la etapa de reconocimiento, existen muchas posibilidades, pero casi todas están basadas en los estudios de las características locales de la imagen. A continuación, se presentan algunos métodos empleados y trabajos:  El descriptor HOG es uno de los métodos más empleados para la detección de objetos desde que, en el año 2005, fuera presentado un detector de peatones basado en este método. En [35] se tiene un ejemplo donde se emplea este descriptor junto con SVM como clasificador.  El descriptor SIFT es también un método bastante empleado en aplicaciones de reconocimiento de objetos, podemos verlo aplicado en [36].  Las redes neuronales son otro ejemplo muy empleado en la etapa de reconocimiento. Podemos ver cómo se aplican en [24], [27], y [37].  Otro método también empleado es el de template matching. Template matching consiste en comparar las imágenes que se quieren clasificar con unas plantillas almacenadas en memoria. Finalmente, se obtiene la clase de la plantilla a la que más se asemeja la imagen. Podemos ver los ejemplos de [14], [23] y [38]. 5.5 Aceleración hardware en el diseño de detectores de señales de tráfico Los sistemas de detección de señales de tráfico son sistemas complejos con alto coste computacional que tardan mucho tiempo en ejecutarse. Sin embargo, estos sistemas deben de cumplir (en la mayoría de los casos) con un requisito fundamental, que es ser un sistema de tiempo real. Normalmente, la etapa con mayor coste computacional suele ser la de reconocimiento. Aplicar una etapa de detección previa a la etapa de reconocimiento hace que esta última requiera de mucho menos trabajo, pero los algoritmos de preprocesamiento de la imagen y de detección también tienen un alto coste computacional. La ventaja de estos algoritmos es que son buenos candidatos para ser implementados en hardware ya que aplican procesos muy repetitivos que pueden ser ejecutados en paralelo. Es por esto que, para mejorar el rendimiento de estos sistemas, suelan ser implementados en arquitecturas heterogéneas con lógica programable, en dispositivos DSPs o GPUs. A continuación, se analiza el rendimiento (en el sentido de la velocidad de procesamiento del sistema) de algunas de las publicaciones estudiadas:  En [14] un sistema de detección de señales de tráfico es implementado y sintetizado completamente en una FPGA Virtex-5 de la compañía Xilinx. El rendimiento conseguido para el sistema completo es de una frecuencia de 14.7 frames por segundo y un acierto del 91% de las señales. El diseño completo es desarrollado con lenguaje HDL. En la publicación se incluye una tabla comparativa de rendimiento de otros trabajos implementados en diferentes arquitecturas hardware.  En [16] se ponen a prueba dos versiones de un sistema de detección de señales de tráfico en los que la diferencia entre las dos está en la etapa de reconocimiento. En la primera versión, el reconocimiento de las señales se lleva a cabo mediante una técnica de template matching basada en el cálculo de la distancia entre la señal candidata y cada una de las plantillas mediante el método de Hausdorff. En la segunda versión, se emplea un detector de características tipo SURF y un 49 49 Co-diseño de un sistema de detección de señales de tráfico con SDSoC clasificador basado en el método del vecino más cercano. La primera versión es implementada en dos dispositivos diferentes: una FPGA Virtex-5 de Xilinx y un SoC Zynq-7020 de una Zedboard. En ellos se obtiene un rendimiento de 1.3 frames/s en la FPGA y 10.3 frames/s en el SoC. La segunda versión es implementada solo en el SoC de la Zedboard, en el que se obtiene un rendimiento de 1 frame/s. La segunda versión toma la ventaja de ser más robusta que con el método de template matching, pero no consigue un rendimiento suficiente para ser un sistema de tiempo real. El diseño también es desarrollado con lenguaje HDL.  En [39] se propone un complejo algoritmo basado en template matching para el reconocimiento de señales circulares en entornos de noche o de condiciones meteorológicas adversas. El sistema es implementado sobre un SoC Zynq-7020 y el rendimiento estimado es de 83 frames/s (es estimado porque solo está desarrollada la etapa de detección). Esta publicación también incluye una tabla comparativa de rendimiento de otros trabajos con otras arquitecturas hardware. Según la mayoría de estudios analizados, para poder lograr un alto rendimiento en velocidad resulta necesario la aceleración de funciones en hardware. Diseño de un sistema de detección de señales de tráfico 50 50 51 51 Co-diseño de un sistema de detección de señales de tráfico con SDSoC 6 ESTRUCTURA DEL DETECTOR DE SEÑALES DE TRÁFICO DESARROLLADO Y RESULTADOS EXPERIMENTALES 6.3 Esquema general del detector de señales de tráfico Como ya se ha visto en el capítulo 5, un sistema de detección de señales de tráfico está compuesto por dos etapas fundamentales: la etapa de detección y la de reconocimiento. A continuación, se explicará en detalle qué se ha realizado en cada etapa del detector desarrollado en este proyecto:  Etapa de detección: la etapa de detección determina qué regiones de la imagen tienen alta probabilidad de contener una señal de tráfico. El objetivo es reducir la inmensa cantidad de información que suelen contener las imágenes de entornos normales de una señal. A aquellas regiones que puedan contener una señal de tráfico y que han sido detectadas por esta etapa son conocidas como regiones de interés, del inglés regions of interest (RoIs). Para el cometido de esta etapa se han empleado dos técnicas vistas en el capítulo 5: segmentación por color y etiquetado de componentes conectados (CCL). Esta etapa tiene un alto coste computacional, pero es muy sintetizable en dispositivos de computación en paralelo. Es por ello que esta etapa queda implementada sobre la lógica programable del sistema.  Etapa de reconocimiento: La etapa de reconocimiento se encarga de identificar las señales de tráfico contenidas en las RoIs detectadas en la etapa de detección. Para ello, intenta clasificar cada RoI como una señal de tráfico utilizando las características locales de la imagen. El sistema completo de reconocimiento queda compuesto por la técnica HOG+SVM. HOG como técnica para extraer las características locales de la imagen y SVM como clasificador, ambos explicados en el capítulo anterior. El sistema completo se ha desarrollado sobre una placa Zedboard como la que se muestra en el capítulo 2, la cual contiene un chip de la familia Zynq-7000. Para la elaboración del sistema, se han empleado las herramientas de desarrollo de Xilinx SDSoC y Vivado HLS, presentadas en el capítulo 3. La etapa de detección queda implementada sobre la lógica programable del dispositivo, mientras que la etapa de reconocimiento es ejecutada por el microprocesador. La parte sintetizable sobre la PL ha sido desarrollada mediante lenguaje de alto nivel y aplicando las técnicas de optimización explicadas en el capítulo 4. Estructura del detector de señales de tráfico desarrollado y resultados experimentales 58 58 En esta tabla se representan los resultados obtenidos para cada señal de tráfico que el sistema puede detectar. Teniendo en cuenta que el número total de señales de tráfico contenidas en las 900 imágenes de test es conocido, se ha procedido a calcular qué tanto por ciento de las imágenes han sido reconocidas. En la columna de % ef detección podemos ver la efectividad de la etapa de detección acelerada sobre la FPGA y en la columna % ef reconocimiento tenemos la efectividad de la etapa de reconocimiento, es decir, el tanto por ciento de imágenes correctamente reconocidas de las que previamente han sido detectadas. En la tabla 6 se tiene la media calculada para todas las señales en conjunto. Número de señales Detectadas Reconocidas % reconocidas % ef detección % ef reconocimiento Total 591 388 353 59,73 65,65 90,98 Tabla 6: Resultado total tras el experimento con las imágenes de test. Observándose la tabla de resultados, se podría pensar rápidamente que la efectividad del sistema en el reconocimiento de señales de tráfico no es buena. Si bien es cierto que el porcentaje obtenido no es alto, hay que tener varias cosas en cuenta antes de tomar un juicio.  En primer lugar, cabe decirse que del número total de señales de tráfico que hay contenidas en las imagenes, muchas de ellas aparecen claramente perjudicadas por consecuencias del entorno, como pueden ser una mala luminosidad u oclusiones por otros objetos. Podemos ver algún ejemplo: Figura 6-5: Ejemplo de señales con poca luminosidad, indetectables por la etapa de detección  En segundo lugar, hay que tener en cuenta que cada imagen del conjunto para test está tomada de un paisaje distinto. Esto quiere decir que cada imagen solo tiene una oportunidad de ser reconocida. En el caso de utilizarse este sistema con una cámara de video, se obtendrían muchas imágenes del mismo paisaje, por lo que, si una imagen no ha obtenido la calidad suficiente para poder detectar la señal, es probable que sí lo haga en la siguiente. Se tendrían varias oportunidades de detectar la misma señal y, por lo tanto, multiplica la probabilidad de éxito. Hay que indicarse también que, para este trabajo, no se han tenido en cuenta los falsos positivos. Los falsos positivos son aquellas RoIs que han pasado la etapa de detección sin contener una señal de tráfico pero que han sido clasificadas como tal. El motivo es que el clasificador creado para este trabajo debería contener una clase excluyente, es decir, una clase a la que deberían ser asignadas todas aquellas señales que no contienen una señal de tráfico. 6.4.2 Aceleración del sistema Otro de los aspectos importantes que hay que medir es la mejora en cuanto a velocidad de ejecución de la etapa de detección cuando ésta es acelerada. Gracias a las funciones de reloj definidas en la librería sds_lib podemos determinar que la etapa de detección, cuando esta es acelerada, tan solo necesita 0,04 segundos en extraer las RoIs de una imagen. Por otro lado, la misma etapa, pero ejecutada por el microprocesador, necesita un total de 1,42s para la misma acción. Todo esto medido durante su ejecución sobre la Zedboard. Podemos notar una mejoría notable en cuanto a velocidad, hasta 71 veces más rápido cuando se aprovecha el paralelismo de la FPGA. En total, teniendo en cuenta también la etapa de reconocimiento, obtendríamos una tasa de 16,7 imágenes procesadas por segundo. Podemos ver de forma resumida estos resultados en la siguiente tabla. 59 59 Co-diseño de un sistema de detección de señales de tráfico con SDSoC Etapa de detección Etapa de reconocimiento Tiempo/frame Frames/segundo2 Etapa de detección no acelerada 1,42s 0,02s 1,44s 0,69 f/s Etapa de detección acelerada 0,04s 0,02s 0,06s 16,7 f/s Tabla 7: Rendimiento obtenido cuando se acelera la etapa de detección Un dato importante a tener en cuenta es que las imágenes de entrada a la etapa de detección tienen un tamaño de 1280x720 píxeles. Resulta evidente que cuanto mayor sea el tamaño de cada frame, más tiempo se requerirá para procesarlo. Este rendimiento podría ser mayor si el mismo algoritmo hubiera sido desarrollado con lenguaje VHDL. 2 Este resultado se obtiene teniendo en cuenta la latencia de la etapa de detección más la de reconocimiento. No se tiene en cuenta el tiempo requerido en leer cada imagen de la memoria mediante las funciones de OpenCV y almacenar dicha imagen en memoria continua. Estas dos tareas no serían necesarias en el caso de utilizar una cámara. Estructura del detector de señales de tráfico desarrollado y resultados experimentales 60 60 61 61 Co-diseño de un sistema de detección de señales de tráfico con SDSoC 7 CONCLUSIONES Y TRABAJOS FUTUROS 7.3 Conclusiones  SDSoC fue creado para facilitar el desarrollo de diseños HW/SW sin la necesidad de tener grandes conocimientos sobre diseño HW. A pesar de esto, he comprobado que sigue siendo muy necesario tener unos conocimientos básicos de la arquitectura hardware del dispositivo.  A la hora de desarrollar un detector de señales de tráfico, el principal obstáculo para obtener un buen rendimiento suele estar en la etapa de detección, ya que suele contener algoritmos de alta carga computacional. Para mejorar este, resulta clave acelerar esta etapa implementándola sobre dispositivos de computación en paralelo. La mejora en cuanto a latencia de la etapa de detección cuando es implementada sobre la FPGA ha sido notable en este proyecto, hasta 71 veces más rápido en la ejecución del algoritmo. Se hubiera obtenido mejor rendimiento si el mismo algoritmo se hubiera desarrollado con algún lenguaje de descripción de hardware.  Como consecuencia directa de acelerar algoritmos en dispositivos heterogéneos, se tiene que también es necesario implementar una comunicación eficiente entre las distintas partes del dispositivo para que el rendimiento siga siendo alto. Se ha aprendido que tener un buen manejo de las interfaces de interconexión y de los accesos a memoria externa son claves para que un sistema funcione de manera óptima.  Los sistemas heterogéneos, como es el dispositivo Zynq-7000 utilizado en este proyecto, demuestran tener una gran capacidad de versatilidad y de flexibilidad pudiendo hacer uso de las mejores características de los sistemas de procesamiento y de la lógica programable.  Se ha demostrado en el desarrollo de este trabajo que es posible obtener muy buena eficiencia en los clasificadores de características locales como el SVM que se ha aplicado. Por otro lado, resulta más compleja la etapa de detección, la cual es muy sensible a agentes externos. 7.4 Trabajos futuros Entre las posibles mejoras y ampliaciones para este trabajo se podría considerar:  Mejorar la eficiencia obtenida por la etapa de detección aplicando técnicas más complejas. Se ha demostrado en otros trabajos que el uso de otros espacios de color como el HSI puede mejorar el rendimiento cuando las condiciones de luz son adversas. Además, es posible complementar la segmentación por color con la segmentación por la forma aplicando técnicas complejas como pattern matching o empleando clasificadores previamente entrenados para encontrar formas Conclusiones y trabajos futuros 62 62 geométricas.  Un trabajo futuro y necesario sería entrenar al clasificador SVM con una clase excluyente, es decir, una clase a la que quedarán asignadas todas las RoIs que han pasado con éxito la etapa de detección pero que en realidad no contienen ninguna señal de tráfico. Para ello, sería necesario recopilar una gran base de datos de imágenes que contengan fondo, esto es, cualquier cosa que no sea en este caso una señal de tráfico y entrenar al clasificador con esta nueva clase.  Se desearía encontrar el clasificador SVM óptimo para el caso de este proyecto. Para ello, la estrategia a seguir sería la de tratar el problema de encontrar el hiperplano de separación como un problema no lineal y encontrar el kernel con los parámetros más eficientes. 63 63 Co-diseño de un sistema de detección de señales de tráfico con SDSoC REFERENCIAS [1] S. Pillath, «Automated vehicles in the EU,» Enero 2016. [En línea]. Available: http://www.europarl.europa.eu/RegData/etudes/BRIE/2016/573902/EPRS_BRI(2016)573902_EN .pdf. [Último acceso: 30 Mayo 2017]. [2] Xilinx, «Zynq-7000 All Programmable SoC: Technical Reference Manual (UG 585,» 27 Septiembre 2016. [En línea]. Available: https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf. [Último acceso: 25 Junio 2017]. [3] L. H. Crockett, «The Zynq Book: Embedded Processing with th ARM Cortex - A9 on the Xilinx Zynq-7000 All Programmable SoC,» Strathclyde Academic Media, 2014, pp. 202-211. [4] Avnet, «Zedboard,» [En línea]. Available: Zedboard.org. [Último acceso: 03 Junio 2017]. [5] G. Sutter, «Síntesis de Alto Nivel para FPGAs con Vivado-HLS: Como describir HW desde C/C++,» 25 Mayo 2016. [En línea]. Available: https://www.youtube.com/watch?v=j8ijuzNC02g&t=1404s. [Último acceso: 25 Junio 2017]. [6] Xilinx, «Vivado Design Suite User Guide: High-Level Synthesis (UG 902),» 2016. [7] L. H. Crockett, R. A.Elliot, M. A. Enderwitz y R. W.Stewart, de Embedded Processing with the ARM Cortex - A9 on the Xilinx Zynq-7000 All Programmable SoC, 2014, pp. 281-331. [8] Xilinx, «SDSoC Environment User Guide,» 2016. [9] OpenCV, «OpenCV,» [En línea]. Available: http://opencv.org/. [10] S. Neuendorffer y a. D. W. Thomas Li, «Accelerating OpenCV Applications with Zynq-7000 All Programmable SoC using Vivado HLS Video Libraries,» 2016. [11] Xilinx, «SDSoC Environment Optimization Guide,» 2016. [12] F. Vallina Martinez, «Implementing Memory Structures for Video Processing in the Vivado HLS Tool,» 2012. [13] E. Calvo, P. Brox y Sanchez-Solano, «Un algoritmo en tiempo real para etiquetado de componentes conectados en imágenes,» Marzo 2012. [En línea]. Available: https://idus.us.es/xmlui/handle/11441/56394. [Último acceso: 20 Junio 2017]. [14] R. Hmida, «Hardware implementation and validation of a traffic road sign detection,» 2016. [En línea]. Available: https://www.researchgate.net/publication/299432433_Hardware_implementation_and_validation_ of_a_traffic_road_sign_detection_and_identification_system. [Último acceso: 5 Junio 2017]. [15] N. A. Dobernack, «Implementación de un sistema de detección de señales de tráfico mediante Referencias 64 64 visión artificial basado en FPGA,» Abril, pp. 151-173. [16] K. V. E. V. S. P. a. E. O. Yan Han, «Hardware/Software Co-Design of a Traffic Sign Recognition System Using Zynq FPGAs,» Marzo 2016. [En línea]. Available: http://www.mdpi.com/20799292/4/4/1062/pdf. [Último acceso: 05 Junio 2017]. [17] D. G. Bailey, Design for Embedded Image Processing on FPGAs, Wiley-Blackwell, 2011. [18] A. V. K.N. Plataniotis, «Color Image Processing and Applications,» 18 February 2000. [En línea]. Available: http://www.comm.toronto.edu/~kostas/Publications2008/pub/bookchapters/2000SpringerMonograph.pdf. [Último acceso: 07 Junio 2017]. [19] Wikipedia, «Wikipedia,» [En línea]. Available: https://es.wikipedia.org/wiki/Espacio_de_color. [Último acceso: 2 Junio 2017]. [20] Wikipedia, «Wikipedia,» 17 Junio 2017. [En línea]. Available: https://es.wikipedia.org/wiki/YCbCr. [21] R. Timofte, K. Zimmermann y L. V. Gool, «Multi-view traffic sign detection, recognition, and 3D localisation,» 2014. [22] V. A. Prisacariu, R. Timofte, K. Zimmermann, I. Reid y L. V. Gool, «Integrating Object Detection with 3D Tracking Towards a Better Driver Assistance System,» 2010. [23] S. F. Matthew Russell, «OpenCV based road sign recognition on Zynq,» Julio 2013. [En línea]. Available: https://www.researchgate.net/publication/261147904_OpenCV_based_road_sign_recognition_on_ Zynq. [24] A. Salhi, B. Minaoui y M. fakir, «Robust Automatic Traffic Signs Recognition Using Fast Polygonal Approximation of Digital Curves and Neural Network,» 2014. [25] B. Saturnino Maldonado, A. Sergio Lafuente, J. Pedro Gil, M. Hilario Gomez y F. Francisco Lopez, «Road-Sign Detection and Recognition Based on Support Vector Machines,» 2007. [26] A. Mogelmose, M. M. Trivedi y T. B. Moeslund, «Vision-Based Traffic Sign Detection and Analysis for Intelligent Driver Assistance Systems: Perspectives and Survey,» 2012. [27] b. Alberto, P. Cerri, P. Medici y P. P. Porta, «Real Time Road Signs Recognition,» 2007. [28] E. Calvo y S. S.-S. Piedad Brox, «Un algoritmo en tiempo real para etiquetado de componentes conectados en imágenes,» 2012. [29] E. Valveny, J. G. Sabaté y R. B. Caselles, «Coursera: Clasificación de imágenes: ¿cómo reconocer el contenido de una imagen?,» [En línea]. Available: https://www.coursera.org/learn/clasificacionimagenes/. [30] OpenCV, «Docs OpenCV: Introduction to SIFT (Scale-Invariant Feature Transform),» [En línea]. Available: http://docs.opencv.org/trunk/da/df5/tutorial_py_sift_intro.html. [31] Wikipedia, «Wikipedia: Scale-invariant feature transform,» 31 Mayo 2017. [En línea]. Available: 65 65 Co-diseño de un sistema de detección de señales de tráfico con SDSoC https://es.wikipedia.org/wiki/Scale-invariant_feature_transform. [Último acceso: 20 Junio 2017]. [32] E. J. Suárez Carmona, «Tutorial sobre Máquinas de Vectores de Soporte (SVM),» 2016. [33] V. Blanco, «Universidad de Granada: Departamento de Métodos Cuantitativos para la economía y la empresa. Teoría Lagrangiana». [34] Wikipedia, «Máquinas de vectores soporte,» [En línea]. Available: https://es.wikipedia.org/wiki/M%C3%A1quinas_de_vectores_de_soporte. [35] C. Yao, F. Wu y H.-j. Chen, «Traffic sign recognition using HOG-SVM and grid search». [36] N. Cai, W. Z. Liang, S. Q. Xu y F. Z. Li, «Traffic Sign Recognition Based on SIFT Features». [37] A. Lorsakul y J. Suthakorn, «Traffic Sign Recognition Using Neural Network on OpenCV: Toward Intelligent Vehicle/Driver Assistance System». [38] J. Miura y Y. Shirai, «An active vision system for on-line traffic sign recognition». [39] M. Y. T. K. Anh-Tuan Hoang, «High Accuracy and Simple Real-Time Circle Detection on LowCost FPGA for Traffic-Sign Recognition on Advanced Driver Assistance System,» 2015. [En línea]. Available: http://sasimi.jp/new/sasimi2015/files/archive/pdf/p397_R4-13.pdf. [Último acceso: 05 Junio 2017]. [40] INSTITU FÜR NEUROINFORMATIK, «The German Traffic Sign Recognition Benchmark,» [En línea]. Available: http://benchmark.ini.rub.de/?section=gtsrb&subsection=news. [41] A. L. Peña, E. Valveny y M. Vanrell, «Coursera: Detección de objetos,» [En línea]. Available: https://www.coursera.org/learn/deteccion-objetos. [42] Xilinx, «Vivado Design Suite User Guide: High-Level Synthesis,» 2016.