Desarrollo de un sistema embebido en FPGA para la deteccion de defectos en la fabricacion de baldosas

Vista previa del material en texto

Trabajo Final 
 Carrera Ingeniería de Sistemas 
 Facultad de Ciencias Exactas - UNICEN 
 Desarrollo de un Sistema Embebido en FPGA para la detección de 
 defectos en la fabricación de baldosas 
 Director: Mg. Lucas Leiva 
 Codirector: Dr. Martín Vázquez 
 Alumno: Tomás Ariel Medina 
 1. Introducción 4 
 1.1 Motivación 4 
 1.2 Objetivos 5 
 1.3 Trabajo propuesto 6 
 1.4 Organización de la tesis 6 
 2. Marco teórico 8 
 2.1 Inspección visual 8 
 2.2 Machine Vision 11 
 2.2.1 Sistemas embebidos en Machine Vision 12 
 2.2.2 Plataformas de Procesamiento para Sistemas Embebidos en Machine Vision 14 
 2.2.3 SoC FPGAs 15 
 2.2.4 Lógica Programable (PL) 17 
 2.2.5 Sistema de Procesamiento (PS) 19 
 2.3 Diseño de lógica programable 21 
 2.3.1 Enfoque tradicional para diseño de lógica programable 21 
 2.3.2 Síntesis de Alto Nivel 23 
 2.4 Síntesis de Alto Nivel para procesamiento de imágenes 25 
 3. Ambiente y metodología de desarrollo 27 
 3.1 Ambiente de desarrollo 27 
 3.2 Componentes hardware 33 
 3.3 Software para desarrollo 35 
 3.4 Plataforma de desarrollo 37 
 3.4.1 Diagrama de bloques simplificado 37 
 3.4.2 Programación de PS 39 
 3.5 Metodología de desarrollo 39 
 4. Corrección de distorsión de lente 43 
 4.1 Distorsión radial 43 
 4.2 Implementación con xfOpenCV 47 
 4.3 Solución basada en aproximación de funciones 49 
 4.3.1 Propuesta 49 
 4.3.2 Desarrollo del modelo matemático 50 
 4.3.3 Pruebas 52 
 4.4 Solución basada en aproximación con vectores precalculados 54 
 4.4.1 Propuesta 54 
 4.4.2 Cálculo de la solución 56 
 4.4.3 Análisis de resultados 58 
 4.5 Resultados en HLS 61 
 2 
 5. Desarrollo de algoritmos de detección de defectos 63 
 5.1 Inspección de bordes, esquinas y dimensión 63 
 5.1.1 Descripción del algoritmo 63 
 5.1.2 Implementación en Alto nivel 68 
 5.1.3 Migración a xfOpenCV y optimización 70 
 5.1.4 Resultados experimentales 77 
 5.2 Detección de defectos por gotas (blobs) 81 
 5.2.1 Descripción del algoritmo 81 
 5.2.2 Implementación en Alto nivel 83 
 5.2.3 Migración a xfOpenCV y optimización 88 
 5.2.4 Resultados experimentales 95 
 5.3 Detección de defectos de material (pinholes) 99 
 5.3.1 Descripción del algoritmo 99 
 5.3.2 Implementación en Alto nivel 102 
 5.3.3 Migración a xfOpenCV y optimización 106 
 5.3.4 Resultados experimentales 108 
 6. Conclusiones 112 
 6.1 Trabajo realizado y resultados obtenidos 112 
 6.2 Contribuciones 113 
 6.3 Trabajos futuros 114 
 Apéndice: Plataforma ZYNQ 116 
 Bibliografía 124 
 3 
 1. Introducción 
 1.1 Motivación 
 El control de calidad es una parte fundamental del proceso de fabricación. En esta 
 etapa se asegura que los productos cumplen con requerimientos determinados para continuar 
 su fabricación o que están listos para ser comercializados. La fabricación de baldosas de 
 textura aleatoria no es una excepción, ya que implica una inspección visual para determinar si 
 existen defectos en su forma o superficie que provoquen que no cumplan con los estándares 
 de calidad impuestos por el fabricante. En ocasiones, dicha inspección es realizada por 
 personas, quienes deben soportar condiciones perjudiciales para la salud, como la exposición 
 constante a altos niveles de ruido, altas temperaturas, además de que el simple hecho de estar 
 presente para visualizar los productos puede provocar accidentes de distinta gravedad. Por otro 
 lado, al ser ejecutadas por humanos, la calidad de detección de defectos está sujeta a la 
 subjetividad y experiencia de los operarios que la realicen, y debido a que es una tarea 
 repetitiva, la fatiga también afecta a esta inspección. 
 Como manera de suplantar a las personas en estas tareas, existen las soluciones de 
 visión computacional para automatizar este trabajo. Para la implementación de estos tipos de 
 sistemas en la fabricación de baldosas, se pueden emplear dispositivos ya preparados para 
 realizar tareas de Machine Vision [1, 2], pero este tipo de productos son de un muy alto costo, 
 lo que puede ser un impedimento para las industrias de la región. 
 También se puede realizar la implementación propia de un sistema de este tipo, para lo 
 que hay que tener en cuenta la plataforma sobre la que se va a trabajar. Una opción es utilizar 
 una solución basada en software. Por otro lado, existen plataformas que se apoyan en el 
 procesamiento por hardware, entre las que se destacan las que emplean FPGAs debido a su 
 muy alto rendimiento en procesamiento de imágenes (muy útil en el caso de aplicaciones de 
 tiempo real) por su paralelismo inherente, su tamaño reducido, su bajo consumo de energía, 
 entre otras ventajas. Como una solución híbrida, existen los SoC FPGA que brindan la 
 posibilidad de procesar por hardware y por software a la vez, por lo que son plataformas muy 
 flexibles a la hora de implementar este tipo de sistemas y se han vuelto muy populares en la 
 industria. Sin embargo, pese a sus ventajas, el desarrollo para FPGAs y SoC FPGAs no 
 4 
 siempre resultaba sencillo para este tipo de aplicaciones debido al bajo nivel de abstracción de 
 los lenguajes con los que se configuran. Por esta razón, los principales fabricantes de estas 
 plataformas comenzaron a ofrecer herramientas de desarrollo a partir de código de alto nivel 
 para realizar la llamada Síntesis de Alto Nivel ( High-Level Synthesis ), junto con bibliotecas para 
 el procesamiento de determinados tipos de datos, entre las que existen bibliotecas específicas 
 para el procesamiento de imágenes. 
 1.2 Objetivos 
 Se establece la hipótesis de que los sistemas embebidos basados en SoC FPGA son 
 apropiados para la implementación de sistemas de visión computacional para ser aplicados a la 
 industria regional. Esta hipótesis se apoya en que el uso de estas tecnologías responde a la 
 demanda del sector industrial, debido a el gran rendimiento que ofrecen para el procesamiento 
 de imágenes y las características de estas plataformas que hacen que sean físicamente aptas 
 para ser instaladas en un entorno de manufactura. 
 Partiendo del trabajo “Inspección visual automática en baldosas con texturas aleatorias”, 
 realizado por Echeverz y Melograno [3], donde se describen algoritmos para la detección de 
 distintos tipos de defectos en baldosas, el objetivo principal de este informe consiste en migrar 
 tres de los mismos para ser utilizados en una plataforma basada en SoC FPGA, basándose 
 principalmente en el uso de Síntesis de Alto Nivel para la implementación de éstos. En 
 particular, se seleccionan los algoritmos de detección de defectos en bordes, esquinas y 
 dimensión, defectos por gotas ( blobs ) y defectos de agujeros ( pinholes ). 
 Como objetivos secundarios se establecen: 
 ■ Contribuir al desarrollo de mecanismos y técnicas de trabajo para la 
 implementación de algoritmos de procesamiento de imágenes con Síntesis de 
 Alto Nivel. 
 ■ Proponer una plataforma general basada en SoC FPGA para el fácil y rápido 
 desarrollo de nuevos algoritmos de inspección visual. 
 ■ Contribuir al establecimiento de metodologías de pruebas visuales para 
 ambientes industriales. 
 5 
 1.3 Trabajo propuesto 
 Se propone el desarrollo de módulos IP de procesamiento de imágenes que ejecuten 
 los algoritmos de detección de defectos de bordes, esquinasy dimensión, defectos por gotas y 
 defectos de agujeros en baldosas cerámicas de textura aleatoria. El correcto funcionamiento de 
 los mismos será comprobado con simulación por software, con imágenes de baldosas tomadas 
 en un ambiente que se asimile al real de la industria. Estos módulos IP deben poderse importar 
 en la plataforma para su implementación en el equipo de hardware seleccionado. 
 Por otro lado, se propone también una plataforma de procesado de video compatible 
 con el equipo de hardware en la que sea posible incorporar los módulos IP cada uno de los 
 algoritmos. Sin embargo, no se realizaron las pruebas de funcionamiento sobre el hardware ya 
 que no se tuvo acceso a los equipos en las últimas etapas de desarrollo. 
 1.4 Organización de la tesis 
 El presente trabajo se encuentra dividido en 6 capítulos. 
 El primer capítulo es una Introducción, donde se describen las Motivaciones, Objetivos y 
 el trabajo que se propone en esta investigación. 
 El segundo capítulo está dedicado a establecer un marco teórico de Inspección visual, 
 Machine Vision y las tecnologías usadas comúnmente en estas áreas. 
 En el tercer capítulo se describen las herramientas de software utilizadas, metodologías 
 de desarrollo que se siguen, el ambiente empleado para generar las imágenes de prueba, los 
 componentes de hardware utilizados y una breve descripción de la plataforma base de 
 procesado de video propuesta. 
 El cuarto capítulo está dedicado a explicar cómo se llega a una solución para la 
 corrección de la distorsión de lente, que surge como necesidad de los algoritmos de inspección 
 de baldosas. 
 En el quinto capítulo se detalla cómo se desarrollan los tres algoritmos de detección de 
 defectos. Para cada uno se explica en qué consiste el algoritmo original, cómo es la primera 
 migración implementada sobre C++ con OpenCV, cómo es la siguiente migración a la 
 descripción en Alto Nivel de HLS con xfOpenCV, y el análisis de los resultados de las 
 simulaciones y de síntesis. 
 6 
 En el sexto capítulo se hacen las conclusiones sobre lo desarrollado, a su vez 
 nombrando posibles trabajos futuros. 
 Por último, se incluye también un Apéndice, en el cual se explica de forma más 
 exhaustiva la plataforma de procesado de video propuesta. 
 7 
 2. Marco teórico 
 Este capítulo tiene como objetivo establecer un marco teórico para la tesis, explicando 
 el estado del arte de Machine Vision y tecnologías de hardware para su implementación. En la 
 Sección 2.1 se introduce a la inspección visual en el ámbito industrial y las desventajas que 
 conlleva emplear personas para estas tareas. En la Sección 2.2 se presentan las alternativas 
 de Inspección visual basadas en Machine Vision , junto con descripciones de los distintos tipos 
 de soluciones comúnmente utilizadas. En la Sección 2.3 se explican distintos enfoques para el 
 desarrollo de Lógica Programable: el tradicional y el basado en Síntesis de Alto Nivel. Por 
 último, en la Sección 2.4 se explica el estado actual de tecnologías de Síntesis de Alto Nivel 
 para el procesamiento de imágenes. 
 2.1 Inspección visual 
 Inspección visual significa, en su definición más básica, inspeccionar con la mirada. 
 Esta inspección supone, por un lado, asegurar características de calidad específicas de bienes 
 intermedios o finales y, por otro lado, detectar y analizar variaciones de un proceso de 
 manufactura [4]. 
 En general, los procesos de fabricación suelen incluir etapas de inspección visual para 
 asegurar la calidad y correctitud del estado del producto. Históricamente, esto fue en principio 
 realizado exclusivamente por humanos, los cuales podían ser empleados normales dedicados 
 completa o parcialmente a realizar estas tareas, tanto como empleados especializados, 
 entrenados e instruidos para realizar inspecciones de gran calidad. El tipo de empleados 
 necesarios depende de cada producto, además de los estándares de calidad requeridos. 
 El sistema de visión humano, compuesto por los ojos y el cerebro, tiene grandes 
 capacidades, algunas de las cuales no pueden ser igualadas aún por las máquinas. Además de 
 la capacidad para ver, se suman capacidades cognitivas que pueden ser útiles para las 
 inspecciones, tales como la intuición, la aplicación de conocimientos previos y la fácil 
 adaptabilidad a distintas condiciones de trabajo. 
 Por otro lado, la capacidad de procesamiento del cerebro es también destacable, ya que 
 cuenta con más de 10 10 células neuronales, algunas de las cuales tienen más de 10.000 
 8 
 contactos (o sinapsis) con otras neuronas [5]. Estas neuronas conforman un sistema de 
 procesamiento de una naturaleza concurrente, capaz de procesar imágenes en instantes. 
 Sin embargo, a pesar de sus grandes capacidades, el sistema de visión humano no es 
 infalible. Diversas pruebas tales como ilusiones ópticas demuestran que hay ocasiones en las 
 que la visión del hombre no detecta claramente las propiedades de los objetos observados. 
 Algunas de las más conocidas son la ilusión Checker Shadow de Edward H. Adelson [6] (Figura 
 1), donde dos cuadrados A y B sobre un tablero pueden ser percibidos como de colores 
 distintos aunque en realidad tienen la misma tonalidad de gris; la ilusión Ebbinghaus de 
 Hermann Ebbinghaus (Figura 2), en la que distintos círculos de igual tamaño pueden ser 
 percibidos como de si fueran de tamaños distintos dependiendo de los objetos que los rodean; 
 y la ilusión café wall de Richard Gregory [7] (Figura 3), en la cual líneas divisorias paralelas 
 parecen inclinadas una con otra. Estas ilusiones ópticas dejan en evidencia que la visión del 
 humano en ciertas situaciones tiene problemas en la detección de colores, dimensiones y 
 ángulos u orientaciones. 
 Figura 1. Ilusión óptica Checker Shadow . Extraída de [8]. 
 Figura 2. Ilusión óptica Ebbinghaus . Extraída de [9]. 
 9 
 Figura 3. Ilusión óptica café walls . Extraída de [10]. 
 El sistema de visión humana también tiene desventajas en tareas de inspección. Estas 
 tareas a menudo son monótonas, laboriosas, fatigantes, subjetivas, carentes de buena 
 reproducibilidad. Además, el proceso es difícil de documentar en detalle, muy lento en la 
 mayoría de los casos y de gran costo económico. 
 También hay que tener en cuenta que las inspecciones visuales suelen suceder en 
 ambientes de producción hostiles, generalmente dentro de fábricas. Esto conlleva a que las 
 personas encargadas de estas tareas se tengan que exponer a peligrosas condiciones de 
 trabajo, tales como: 
 ■ Exposición a temperaturas perjudiciales para la salud. 
 ■ Exposición a ruidos intensos que pueden dañar el oído. 
 ■ Exposición a radiación. 
 ■ Exposición a sustancias tóxicas. 
 ■ Peligros físicos al estar cerca de máquinas en movimiento. 
 Además, al incluir al sujeto humano, se corre el riesgo de contaminación del ambiente de 
 producción, lo que es vital para la fabricación de productos como por ejemplo circuitos 
 integrados, displays y dispositivos de almacenamiento [11] o productos farmacéuticos [12]. 
 Por estas razones, junto con las otrasgrandes ventajas que ofrecen los sistemas 
 automatizados por computadora, es que se desarrollaron y adoptaron soluciones de Machine 
 Vision en los procesos de manufactura a pesar de que el sistema visual humano es excepcional 
 para muchas tareas. Sin embargo, se vuelve a destacar que la visión humana impulsada por el 
 sistema cognitivo todavía hoy tiene capacidades que no se pueden igualar por las 
 10 
 computadoras. Sobre esto último, se están realizando grandes avances tecnológicos en cuanto 
 al desarrollo de algoritmos para simular el aprendizaje y toma de decisiones humanos como 
 una manera de acercarse a estas capacidades, utilizando métodos de Machine Learning . 
 2.2 Machine Vision 
 A partir de la década de 1960 comenzaron las primeras investigaciones acerca del uso 
 de computadoras para la automatización de tareas industriales con procesamiento de 
 imágenes, pero no fue hasta la década siguiente que se lograrían gran cantidad de 
 implementaciones exitosas. Esta área de investigación fue llamada Machine Vision , y fue 
 rápidamente cobrando importancia en compañías líderes en la fabricación, lo que ayudó 
 también a la incubación y desarrollo de tecnologías de Machine Vision [13]. 
 En la actualidad, Machine Vision es una de las tecnologías clave en la fabricación por la 
 creciente demanda de documentación de calidad y trazabilidad de productos. Es necesario que 
 sistemas ingenieriles como máquinas o líneas de producción ejecuten inspecciones de calidad 
 para remover productos defectuosos de la producción o controlen a otras máquinas para 
 realizarlo [14], o para que se realicen acciones específicas sobre productos que lo requieran 
 (es decir, no necesariamente es para desechar productos con fallas). 
 Algunas de las tareas comunes a resolver con sistemas de Machine Vision son: 
 ■ Identificación de objetos para discernir diferentes los diferentes tipos de objetos, por 
 ejemplo, para controlar el flujo del material o decidir qué inspecciones realizar. Esto 
 puede estar basado en símbolos especiales de identificación, como cadenas de 
 caracteres o códigos de barra, o en características específicas de los mismos objetos, 
 como su forma. 
 ■ Detección de posición es utilizada, por ejemplo, para controlar robots que ensamblan 
 los componentes de un producto en sus posiciones correctas, como una máquina que 
 monta los componentes electrónicos en un circuito impreso (PCB). La detección de 
 posición puede hacerse considerando 2 o 3 dimensiones, dependiendo de los 
 requerimientos de la aplicación. 
 ■ Chequeo de completitud que es realizado típicamente luego de que cierta etapa de 
 montaje de un producto ha sido completada, por ejemplo, luego de que los 
 componentes electrónicos han sido situados, para así verificar que el producto se montó 
 correctamente, es decir, que los componentes correctos están en el lugar adecuado. 
 11 
 ■ Inspección de forma y dimensión, la cual es utilizada para chequear los atributos 
 geométricos de un producto y así asegurar que estos se encuentran dentro de los 
 límites preestablecidos. Esto puede ser realizado durante el proceso de producción, 
 pero también luego de que el producto ha sido usado durante algún tiempo, para 
 asegurar que aún cumple con los requerimientos a pesar del uso y desgaste. 
 ■ Inspección de superficie es utilizada para chequear la superficie de un producto 
 terminado, buscando imperfecciones tales como rayaduras, marcas, manchas. 
 2.2.1 Sistemas embebidos en Machine Vision 
 Si bien las soluciones de Machine Vision se podrían categorizar de varias maneras 
 teniendo en cuenta distintos criterios, en el presente trabajo se hace la distinción entre 
 soluciones de computación genéricas y soluciones embebidas. Ambas categorías tienen sus 
 cualidades, ventajas, desventajas, formas de desarrollo particulares y, dependiendo de los 
 requerimientos de la aplicación, un tipo de solución puede ser más adecuado que otro. 
 Las soluciones de computación genéricas son soluciones en las que se utilizan 
 computadoras de propósito general para su implementación. Son computadoras cuyo 
 funcionamiento en general está basado en software, y son usadas para realizar tareas de 
 distinta índole. Su flexibilidad en cuanto a las aplicaciones permite que sean adecuadas para 
 Machine Vision . Un sistema de Machine Vision de este tipo se puede conformar con un 
 dispositivo de captura de imágenes conectado a la computadora de propósito general, donde 
 con un software se procesan las imágenes obtenidas, se logran las mediciones buscadas y a 
 partir de ello se accionan los actuadores para que trabajen sobre los productos. En la Figura 4 
 se representa gráficamente un sistema de estas características, donde las imágenes de los 
 productos son captadas por una cámara, procesadas por software en la computadora que, de 
 ser necesario, puede accionar un brazo robótico para apartar los dispositivos defectuosos. 
 12 
 Figura 4. Representación gráfica de un sistema de Machine Vision con una computadora de uso general. 
 En contraposición, un sistema embebido es aquel diseñado para realizar una tarea 
 específica. Ejemplos de sistemas embebidos son los que controlan hornos microondas, 
 receptores GPS, dispositivos de telecomunicaciones, electrónica de aeronaves y equipamiento 
 médico. Estos sistemas pueden estar basados en software ejecutado por un procesador, pero 
 no siempre es necesario, ya que esto puede ser reemplazado por un circuito integrado que 
 realice las mismas funciones en hardware. Sin embargo, la combinación de procesador y 
 software típicamente ofrece más flexibilidad que un diseño en hardware [15]. 
 Muchas aplicaciones deben cumplir con restricciones de tiempo real. Si el 
 procesamiento no se completa dentro de una ventana de tiempo determinada puede resultar en 
 una seria pérdida de la calidad provista por el sistema [16]. Debido a esto, en ocasiones se 
 prefieren los sistemas embebidos ya que por definición no poseen programas adicionales 
 corriendo en el sistema que puedan interferir con la disponibilidad de la aplicación (aunque si 
 bien no son tan comunes, también existen sistemas operativos de tiempo real, o RTOS , para 
 computadoras de propósito general que buscan solucionar esta problemática [17]). De esta 
 manera, como el sistema embebido se centra en realizar una tarea determinada, se puede 
 optimizar en cuanto a tiempo de operación. 
 Así como el tiempo de operación, los sistemas embebidos también posibilitan la 
 reducción de sus dimensiones físicas (al haber plataformas de tamaños reducidos), peso, 
 consumo de energía, robustez en ambientes hostiles y costo. 
 13 
 2.2.2 Plataformas de Procesamiento para Sistemas Embebidos en 
 Machine Vision 
 Existen diversas tecnologías para conformar sistemas embebidos de Machine Vision , 
 algunas de las cuales son: 
 ■ Microcontroladores: son circuitos integrados programables. Incluyen CPU, memorias y 
 el manejo de periféricos en un solo chip. En general, su uso se orienta a tareas de 
 control que no requieran gran poder de cálculo. Un ejemplo de microcontroladores el 
 ATmega328P, presente en las placas de desarrollo Arduino Uno (Figura 5) 
 ■ DSPs ( Digital Signal Processors ): por sus siglas en inglés, procesadores de señales 
 digitales. Su forma de operación se basa en el procesamiento de señales como si 
 fueran secuencias de números. Son aplicables a problemas como procesamiento de 
 audio, compresión de información, telecomunicaciones. Ejemplos de DSPs son los de la 
 familia TMS320, fabricados por Texas Instruments. 
 ■ ASICs ( Application Specific Integrated Circuits ): por sus siglas en inglés, circuitos 
 integrados hechos a medida de la aplicación. Al tener la lógica implementada en 
 hardware puro, son sumamente eficientes en rendimiento, consumo de energía y 
 ocupación de área. Como desventajas, tienen costos de desarrollo y producción muy 
 elevados, siendo rentable cuando se fabrican al menos 50000 unidades para ser 
 vendidos en productos de ambientes comerciales [18]. 
 ■ FPGAs: son dispositivos de hardware reprogramable a medida de la aplicación. Se 
 asemejan a los ASICs en cuanto a que la lógica de la solución se implementa en 
 hardware, sin embargo su desarrollo es mucho más sencillo, y es más rentable para la 
 producción de pocas unidades. En contraste, son menos eficientes que los ASICs. 
 14 
 Figura 5. Arduino Uno, placa de desarrollo basada en el microcontrolador ATmega328P. Extraída de [19]. 
 2.2.3 SoC FPGAs 
 System on a Chip es un concepto que se aplica a circuitos integrados que contienen 
 todos o la mayoría de los componentes de una computadora en un mismo chip. De esta 
 manera y contrastando con las computadoras de uso estándar, los SoC suelen incluir CPU, 
 memoria principal, puertos de entrada/salida y memoria secundaria. Otros más avanzados 
 pueden incluir GPUs integrados, módulos WiFi, más de un CPU, co-procesadores, entre otros 
 componentes. 
 Que se integren todos estos componentes en un chip implica varias ventajas, pero 
 principalmente se reduce el consumo energético necesario, se mejora la performance general 
 (ya que se reduce la distancia de un componente a otro), el área total que ocupa disminuye y el 
 costo de producción es menor a comparación de la fabricación de cada módulo por separado. 
 Como principales desventajas se tiene que el desarrollo de los mismos es más complejo, el 
 costo de producción en pocas unidades puede no ser rentable, y se elimina la opción de 
 reemplazar un componente defectuoso (ya que con un SoC habría que cambiar el chip 
 completo, en lugar del componente específico). Pero estas cualidades los hacen adecuados 
 para aplicaciones de sistemas embebidos, teléfonos móviles y aplicaciones de Internet of 
 Things . 
 En particular, los SoC FPGAs son sistemas que integran FPGA (a lo que se le llama 
 lógica programable o PL) y un CPU (que conforma el sistema de procesamiento o PS) en un 
 mismo chip, pudiendo así tener en una placa de desarrollo una arquitectura similar a la que se 
 muestra en la Figura 6. Estos sistemas surgen como evolución de los otros tipos de placas con 
 15 
 FPGAs y CPUs, que en general siguen una arquitectura similar a la que se muestra en la 
 Figura 7. 
 Figura 6. Arquitectura de los sistemas SoC FPGA. 
 Figura 7. Arquitectura de los primeros sistemas con FPGA y CPU. 
 Debido a sus ventajas, las placas que integran SoC FPGAs han ganado gran 
 popularidad entre los desarrolladores de sistemas embebidos. Esto ha llevado a los principales 
 fabricantes de FPGAs a incluir en su catálogo opciones SoC FPGA, abriendo así un gran 
 abanico de posibilidades para diferentes tipos de aplicaciones. 
 En las siguientes subsecciones se explican en detalle los principales componentes de 
 los SoC FPGAs: la lógica programable y el sistema de procesamiento. 
 16 
 2.2.4 Lógica Programable (PL) 
 Las FPGAs ( Field Programmable Gate Arrays ) son circuitos integrados cuya principal 
 característica es que su lógica puede ser reconfigurada para una aplicación particular. La lógica 
 puede ser programada (y reprogramada) para proveer soluciones sobre hardware que se 
 adecuen a los problemas propuestos, razón por la que a este componente se lo llama “lógica 
 programable” o PL por sus siglas en inglés. Las soluciones en lógica programable tienen ciertas 
 ventajas con respecto a las soluciones en software. 
 Al realizar programas en software, estos son compilados (o interpretados) y llevados a 
 instrucciones para ser ejecutadas secuencialmente por el CPU de la computadora. La PL, por 
 el contrario, representa la funcionalidad como un circuito, donde el circuito puede ser 
 reprogramado para cumplir los requisitos de una aplicación. La principal distinción es que la 
 funcionalidad es implementada como un sistema paralelo, más que secuencial [20]. Este 
 paralelismo se logra al plasmar la solución como un diseño de hardware específico para esta 
 aplicación (a diferencia del CPU, que se puede pensar como un hardware multipropósito), lo 
 que les brinda un gran rendimiento y los hace adecuados para la implementación de sistemas 
 embebidos. Además del paralelismo, con esta tecnología es sencillo segmentar en etapas el 
 procesamiento, logrando una segmentación (o pipeline) en el procesamiento para un mayor 
 rendimiento en la aplicación. 
 En cuanto a los problemas específicos de procesamiento de imágenes, esto es de gran 
 conveniencia, ya que muchas de las operaciones comunes de procesado de imágenes se 
 pueden paralelizar o segmentar. Un ejemplo es un algoritmo que requiera que dos operaciones 
 distintas se le realicen la misma imagen, para sumar luego los resultados, como se ilustra en la 
 Figura 8. Como estas operaciones son independientes una de otra, se pueden realizar al 
 mismo tiempo en hardware, aprovechando el paralelismo que ofrece a fin de conseguir un 
 mayor rendimiento. Otro ejemplo es un algoritmo compuesto por una serie de operaciones 
 secuenciales, cada una conformando una etapa, como se muestra en la Figura 9. Mientras la 
 información de una imagen está en una etapa, otra puede estar siendo procesada en la 
 siguiente, conformando un diseño segmentado (o paralelización temporal). 
 17 
 Figura 8. Algoritmo con operaciones que se pueden realizar en paralelo. 
 Figura 9. Algoritmo compuesto por etapas secuenciales. 
 Sin embargo, estas ventajas frente al software conllevan un precio. Comparado con un 
 microprocesador, estos dispositivos son varios grados de magnitud más rápidos y eficientes en 
 consumo, pero el tiempo de desarrollo es mayor [21]. 
 Por sus grandes prestaciones en cuanto a rendimiento se refiere, hoy en día esta 
 tecnología es muy común para aplicaciones de procesamiento de señales, aeroespaciales, 
 automotrices, procesamiento de imágenes, prototipado de ASICs, redes neuronales, y muchas 
 otras. Entre los principales fabricantes de FPGAs se encuentran Xilinx, Intel, Microsemi y 
 Lattice. 
 Como una descripción básica de las FPGAs, es importante mencionar que se compone 
 de muchos bloques lógicos configurables, llamados CLBs por sus siglas en inglés. Cada CLB a 
 su vez estácompuesto por Flip-Flops, Look-Up Tables. Cada instancia de las CLBs está 
 conectada con otras por interconexiones programables, llamadas PIs. Además, también 
 contienen bloques de entrada/salida llamados IOBs (también configurables), que sirven para 
 conectar el chip con el sistema exterior. En la Figura 10 se observa un esquema de los 
 18 
 componentes de la FPGA nombrados. De esta manera, la configuración o programación de 
 FPGAs consiste en darle valores a los CLBs, configurar las interconexiones entre estos bloques 
 lógicos y establecer las rutas de entrada y salida de con los IOBs. 
 Figura 10. Esquema de los componentes internos de una FPGA. 
 Con el avance de la tecnología, estos dispositivos comenzaron a incluir bloques 
 hardware internos disponibles para su utilización, como Block RAMs, buffers de clock globales, 
 recursos aritméticos especializados, buffers tri-estado, y son particulares a cada chip. Los 
 componentes internos específicos de los CLBs, PIs y IOBs varían con respecto a cada 
 fabricante y familia de chips. 
 2.2.5 Sistema de Procesamiento (PS) 
 El sistema de procesamiento, o PS por sus siglas en inglés, de un SoC FPGA está 
 formado principalmente por un CPU que permite ejecutar instrucciones de software. Esto le 
 provee al dispositivo de cierta flexibilidad, de la cual carecen los FPGA por sí solos. 
 Comúnmente este CPU permite ejecutar tanto aplicaciones individuales sin soporte ( bare 
 19 
 metal ) como correr sistemas operativos para el manejo de las aplicaciones requeridas, siendo 
 estos a menudo de bajo consumo de recursos (como, por ejemplo, PetaLinux). 
 El desarrollo de programas y algoritmos a ejecutar sobre ellos es más sencillo y rápido 
 que para la lógica programable, debido en parte a que no se tienen tantas restricciones de 
 diseño: el programa puede tener un manejo de memoria dinámico, permite con facilidad la 
 implementación de funciones recursivas, manejo de punteros a datos y funciones, fácil manejo 
 de conversiones de tipos; estas soluciones de software se vuelven mucho más complejas a la 
 hora de querer implementarlas o simularlas en hardware. 
 Sin embargo, en cuanto a tiempo de procesamiento, las soluciones en lógica 
 programable tienen una performance mucho mayor. El paralelismo y posibilidad de 
 segmentación hace que ciertos ciertos tipos de problemas sea conveniente resolverlos en 
 hardware. Este es el caso de los problemas de Machine Vision , que debido a su naturaleza en 
 general se obtiene mayor rendimiento que si se procesan por software. Para este tipo de 
 aplicaciones, a menudo se prefiere que en el PS se ejecuten programas de control, mientras 
 que en la PL se ejecutan los algoritmos de computación intensiva orientados al procesamiento 
 de imágenes. Estos programas de control pueden ser utilizados para configurar parámetros del 
 algoritmo, modificar resoluciones de video, configurar el sensor de obtención de imágenes, etc. 
 Por otro lado, debido al tipo de aplicaciones que se corren en el PS y la posibilidad de 
 usar bibliotecas ya desarrolladas de comunicación, se hace sencillo ejecutar programas para la 
 configuración de la PL en tiempo de ejecución a través de otros equipos, como por ejemplo 
 puede ser una PC. La comunicación entre el PS y el equipo externo se puede establecer por 
 una interfaz UART, Ethernet, WiFi o cualquier otra con la que cuente el SoC. Una vez 
 establecida la comunicación con el equipo, estas aplicaciones se suelen manejar de forma 
 similar a aplicaciones de consola. Además, si el problema lo requiere, se puede usar este 
 medio para informar al usuario sobre ciertas características de la imagen, como puede ser la 
 correcta identificación de un objeto. En la Figura 11 se ve un ejemplo de arquitectura de un 
 sistema de procesamiento de imágenes, donde las imágenes son procesadas en la PL y la 
 configuración de este procesamiento se realiza a través del PS y desde una PC. 
 20 
 Figura 11. Arquitectura de una aplicación de procesamiento de imágenes sobre un dispositivo SoC. 
 2.3 Diseño de lógica programable 
 2.3.1 Enfoque tradicional para diseño de lógica programable 
 Cuando se busca diseñar algoritmos soluciones en lógica programable, la forma típica 
 ofrecida por los fabricantes para realizarlo es partiendo de descripciones a nivel RTL 
 ( Register-transfer level o Nivel de Transferencia entre Registros), que son sucesivamente 
 transformadas bajando su nivel de abstracción hasta llegar al archivo binario de configuración 
 de la FPGA, como se muestra en la Figura 12. El proceso de traducción es similar a lo que 
 sucede en la compilación de software, cuando de un lenguaje de alto nivel se traduce a código 
 assembler, que finalmente se traduce a código máquina a ser ejecutado por un procesador. 
 21 
 Figura 12. Niveles de abstracción del diseño de FPGA. 
 El diseño a nivel RTL consiste en la codificación utilizando lenguajes de descripción de 
 hardware (que comúnmente son VHDL o Verilog) y el uso de módulos IP en un diagrama de 
 bloques, configurando adecuadamente cada módulo, definiendo sus interconexiones y las 
 señales de entrada y salida al sistema mediante archivos de configuración. Como ya se 
 mencionó, lo que se define es el diseño a nivel RTL, que involucra definir el hardware en 
 componentes como registros y lógica combinacional, señales de distintos anchos de bit y 
 transferencias de datos entre módulos [22]. 
 Una vez realizado el diseño a nivel RTL, se pasa a la etapa de síntesis, donde este 
 diseño es traducido a una representación a nivel de compuertas lógicas. Las herramientas de 
 desarrollo usualmente realizan la síntesis automáticamente con configuraciones por defecto, 
 pero se pueden definir ciertas directivas para controlar al sintetizador, como por ejemplo elegir 
 estrategias a utilizar, con lo que se puede indicar que se priorice el tiempo (que el diseño 
 sintetizado tarde menos en procesar las señales) o el área (que utilice menos recursos físicos 
 de la FPGA tales como block RAMs, LUTs y Flip-Flops). Una vez sintetizado el diseño, es 
 posible ver los reportes de síntesis que muestran datos como estimaciones de tiempo y el 
 esquema lógico generado. 
 La siguiente etapa es la de implementación, que consiste en, a partir del diseño a nivel 
 lógico obtenido luego de la síntesis, obtener el diseño a nivel de transistores ubicando los 
 recursos específicos del hardware seleccionado. En otras palabras, se obtiene el diseño final 
 de la configuración de la FPGA, donde se tiene en cuenta el chip seleccionado. La 
 implementación también la realizan automáticamente las herramientas, y tiene varios pasos 
 que incluyen optimizar el diseño lógico, optimizar el uso energético, ubicar el diseño en la 
 FPGA y rutear los componentes. Al igual que en la síntesis, se pueden especificar directivas 
 22 
 para guiar la implementación y lograr un resultado optimizado en tiempo, recursos, balanceado, 
 entre otras configuraciones. Una vez implementado el diseño, se pueden ver los reportes detiempos, clocks utilizados, energía, ruido del sistema, entre otra información relevante. 
 2.3.2 Síntesis de Alto Nivel 
 La Síntesis de Alto Nivel o High-Level Synthesis ( HLS ) es una tecnología para el diseño 
 de circuitos de hardware que se basa la programación con un nivel mayor de abstracción que al 
 nivel de los anteriormente nombrados VHDL y Verilog. Hace décadas que los sistemas 
 embebidos se hacen más y más complejos, razón por la que la síntesis de alto nivel se está 
 volviendo una necesidad para la industria. No solo la abstracción permite facilitar ciertas tareas 
 de la programación, sino que hace a la programación de circuitos de hardware un área más 
 accesible para desarrolladores no tan cercanos a la electrónica, como los ingenieros de 
 software o sistemas. 
 El gran potencial de la síntesis de alto nivel radica en dejar los detalles de 
 implementación a los algoritmos de diseño y herramientas, incluyendo la habilidad de 
 determinar precisamente los tiempos de operaciones, transferencias de datos y 
 almacenamiento [23]. De esta manera, la tarea del desarrollador se enfoca en el desarrollo del 
 algoritmo en sí, de forma más similar a cuando se codifica en software. Esto hace que el 
 desarrollo pueda ser más rápido y sencillo. 
 En cuanto a los lenguajes en los que se puede codificar para realizar síntesis de alto 
 nivel, depende de cada herramienta que realice la síntesis. La mayoría de compiladores de 
 HLS , tanto comerciales como académicos, se suelen basar en programas de entrada escritos 
 en lenguaje C o derivados. Por ejemplo, la herramienta Intel High Level Synthesis Compiler, de 
 Intel, acepta programas en C y C++; la herramienta Vivado HLS, de Xilinx, acepta programas 
 en C, C++ y SystemC. Como salida de los compiladores, en general es en VHDL o Verilog. 
 Además, las herramientas de HLS actuales ofrecen características que permiten hacer 
 un análisis del diseño obtenido con herramientas de profiling y estimaciones (brindan nociones 
 de tiempos, latencias, y recursos que utilizará el diseño), mejoran el rendimiento en tiempo o la 
 utilización de recursos de hardware, e incluso simulan de manera rápida el resultado por 
 software. Esto último es de gran importancia, ya que brinda la posibilidad de no requerir (en 
 una primera instancia) de configuración del hardware para ejecutar pruebas funcionales. 
 23 
 A continuación se presenta, se toma un ejemplo basado en el del manual de usuario de 
 Vivado High-Level Synthesis [24] que expone el funcionamiento de la Síntesis de Alto Nivel. El 
 mismo está escrito en C/C++, y se usará como ejemplo de entrada al compilador HLS. En la 
 Figura 13 se ve gráficamente el resultado de la compilación de éste código: 
 int calculo(int x, int a, int b, int c) { 
 int resultado; 
 resultado = x * a + b + c; 
 return resultado; 
 } 
 Figura 13. Representación gráfica de la ejecución en tiempo del programa compilado con Síntesis de Alto Nivel. 
 Como se puede apreciar, el compilador se encarga de inferir los elementos necesarios para 
 sintetizar la función dada, es decir, un multiplicador y dos sumadores, además del registro 
 (marcado en color gris en la Figura 13) para guardar el valor temporal de x * a + b . Este registro 
 se genera automáticamente, ya que al hacer la planificación de tiempos de las operaciones el 
 sintetizador detecta que no se podrán hacer las tres operaciones en un único ciclo de reloj. 
 El anterior fue un ejemplo simple, pero el algoritmo puede llegar a ser de gran 
 complejidad, según el hardware objetivo lo permita. Para otros casos, donde el tiempo de 
 24 
 procesamiento puede ser una restricción importante del problema o el área de lógica 
 programable es una limitante, a menudo se deben aplicar optimizaciones configuradas 
 manualmente para lograr el funcionamiento deseado. Estas optimizaciones pueden implicar 
 paralelizar el procesamiento, segmentar el circuito, o especificar cómo se debe sintetizar una 
 determinada estructura (por ejemplo, asignando un arreglo se utilice un tipo de recurso 
 particular). Las herramientas de HLS ofrecen maneras de indicar estas optimizaciones, como 
 puede ser el uso de directivas en código. 
 Sin embargo, a pesar de sus virtudes, la síntesis de alto nivel está generalmente sujeta 
 a distintas restricciones que se suelen deber al hecho de que el algoritmo se plasma en 
 hardware, y una vez este es programado no se puede reprogramar en tiempo de ejecución. Es 
 decir, una vez alojados los recursos, configuradas las rutas en el circuito, estos no se pueden 
 cambiar. El diseño en hardware es estático en el tiempo de ejecución. Esto lleva a que ciertas 
 prácticas y soluciones de software no sean posibles en la síntesis de alto nivel o se vean 
 limitadas, y por ende se deba seguir otras prácticas o estilos de código. Entre las prácticas de 
 software que se ven limitadas se encuentran: 
 ■ El uso de memoria dinámica : la asignación y liberación de memoria en tiempo de 
 ejecución ( malloc() , free() en lenguaje C) no es posible debido a que cada estructura 
 debe tener un espacio definido en el hardware, por lo que no se puede asignar y liberar 
 memoria durante la ejecución. 
 ■ Uso de arreglos semi-dinámicos : arreglos cuyos límites no están definidos hasta el 
 tiempo de ejecución no son soportados. Como reemplazo se suelen usar arreglos de 
 límites fijos, definiendo el tamaño de estos arreglos con un valor suficientemente grande 
 para almacenar elementos según el problema. 
 ■ Uso de punteros : en general no están permitidos los punteros a funciones, ya que se 
 vuelve complejo el manejo de la ruta de datos en el tiempo de ejecución. Otros tipos de 
 punteros pueden ser soportados, dependiendo del compilador. 
 ■ Definición de funciones recursivas : debido a la posibilidad de recursión infinita. Esto 
 entra en conflicto con el cálculo de tiempos y la planificación. 
 2.4 Síntesis de Alto Nivel para procesamiento de imágenes 
 Los algoritmos de procesamiento de imágenes se ven beneficiados por las 
 características de los diseños en hardware. El paralelismo inherente de la lógica programable 
 25 
 es de gran valor para estos algoritmos, ya que en muchos casos varias operaciones se pueden 
 hacer en el mismo momento. Además, la segmentación del diseño puede permitir procesar 
 varias imágenes, cada una en una etapa diferente del pipeline de procesamiento, mejorando 
 así la performance . 
 Por otro lado, las bibliotecas de procesamiento de imágenes de software de la 
 actualidad se encuentran bastante desarrolladas y difundidas, entre las que se destacan Image 
 Processing Toolbox , para utilizar en MATLAB, y OpenCV , una librería de código abierto para 
 utilizar en lenguajes C++, Python, Java o MATLAB que es ampliamente utilizada por la cantidad 
 de algoritmos que ofrece. Sin embargo, pese a la gran adopción de estas tecnologías por parte 
 de la comunidad y la cantidad de documentación existente para guiar su uso, las soluciones en 
 software pueden no adaptarse a problemas con restriccionesde tiempo real. Esto se debe a 
 que a grandes resoluciones, las operaciones de procesamiento de imágenes pueden ser 
 costosas, y la característica secuencial del software (en contraposición a las paralelas del 
 hardware) hacen que se genere cierto overhead en el procesamiento. 
 Viendo la oportunidad de llevar las ventajas del software hacia el hardware, los 
 fabricantes de FPGAs proveen soluciones aplicables en sus compiladores de HLS, entre los 
 cuales se destaca xfOpenCV, de la compañía Xilinx. xfOpenCV es una biblioteca de C++ de 
 operaciones sobre imágenes basada en OpenCV que contiene un subconjunto de las funciones 
 definidas en OpenCV. Estas funciones están listas para sintetizar, y están totalmente 
 optimizadas para su uso en hardware. Con la nomenclatura de las funciones en muchos casos 
 idéntica a su contraparte para software, la migración de algoritmos de OpenCV hacia 
 xfOpenCV es en general sencilla, y al estar las dos disponibles para C++ hace que sea posible 
 comparar resultados en el mismo programa de simulación. 
 Con soluciones como estas, más la adición de optimizaciones de performance a los 
 diseños en HLS hacen que el procesado de imágenes en hardware sea mucho más accesible 
 que en la programación a nivel RTL. A su vez el tiempo de procesamiento es mucho menor que 
 las soluciones en software, lo que hace a HLS una buena alternativa para la implementación de 
 soluciones a problemas de tiempo real. 
 26 
 3. Ambiente y metodología de desarrollo 
 En este capítulo se describen los materiales utilizados para el desarrollo, así como la 
 metodología que se sigue. En la Sección 3.1 se muestra el ambiente controlado en el que se 
 toman imágenes de prueba, y se incluye una descripción del aspecto de las baldosas 
 existentes. En la Sección 3.2 se definen los componentes de hardware disponibles para 
 implementar las soluciones. En la Sección 3.3 se describen los distintos softwares que se 
 utilizan en el trabajo. En la Sección 3.4 se explica de forma simplificada la plataforma de 
 procesamiento de video propuesta para utilizar de base en el desarrollo (plataforma que se 
 describe con mayor profundidad en el Apéndice: Plataforma ZYNQ), que se separa en la parte 
 de la Lógica Programable y el programa que se ejecuta en el procesador. Por último, en la 
 Sección 3.5 se explica la metodología a seguir para desarrollar cada algoritmo. 
 3.1 Ambiente de desarrollo 
 La captura de imágenes se realiza utilizando un ambiente controlado construido a 
 medida, el cual simula un ambiente real de producción. El mismo es llamado CEMVA 1.0 
 ( Controlled Environment for Machine Vision Applications 1.0 ), y en particular simula el paso de 
 una manufactura por una cinta transportadora. En la Figura 14 se puede observar este 
 ambiente, junto con una baldosa. En la Figura 15 se muestra una representación del exterior 
 del CEMVA , y en la Figura 16 el interior. 
 27 
 Figura 14. Fotografía del CEMVA 1.0 . 
 El CEMVA consiste en una caja grande construida en madera con una plataforma móvil 
 en uno de sus costados (indicada en la Figura 15). Esta plataforma se usa para colocar la 
 manufactura, y es la que, mediante la ejecución de un movimiento manual, simula el 
 movimiento de la cinta transportadora. Además, la plataforma está recubierta de un material 
 que simula la textura de una cinta transportadora. Por otro lado, en la cara superior del CEMVA 
 existe un orificio por el que se puede introducir la cámara del equipo elegido para realizar la 
 detección con la aplicación de Machine Vision (marcado en la Figura 15). 
 28 
 Figura 15. Representación del exterior del CEMVA 1.0 . 
 En cuanto a su interior, el CEMVA posee sus paredes pintadas de color negro mate, 
 para de esta manera evitar reflejos de luz indeseados. Por el lateral, para evitar la entrada de 
 luz por el orificio de la plataforma, tiene una goma negra adherida cortada en forma de flecos 
 (como se marca en la Figura 15), de esta manera no interfiere con el movimiento de la 
 plataforma. 
 En cuanto a la iluminación, en el interior en la tapa superior se colocan luces de 
 distintos tipos, con intensidad regulable. Se ha probado utilizar una tira de luces LED RGB, las 
 cuales se pueden configurar en distintos colores, que puede ser útil para algunas aplicaciones. 
 Sin embargo, la potencia lumínica de estas luces puede no ser suficiente. Como otra 
 alternativa, se instalan dos hileras de LED blancas de mayor potencia, que se colocan 
 paralelas, una a cada lado del orificio para la cámara, de la manera en las que se puede ver en 
 la Figura 16. 
 29 
 Figura 16. Representación del interior del CEMVA 1.0 . 
 El CEMVA se utiliza con baldosas cerámicas reales, provistas por la empresa Loimar, 
 cuya fábrica se ubica en la ciudad de Tandil. Las mismas fueron cedidas por la empresa para el 
 desarrollo de esta aplicación, y estas originalmente conforman un conjunto de 33 baldosas, 
 cada una con un defecto de fabricación particular. Los defectos de las baldosas son los 
 siguientes: 
 ■ Blobs (por la izquierda de la Figura 17): son gotas que se encuentran en la superficie de 
 la baldosa, que se ven más oscuras a comparación del color original de la baldosa. 
 ■ Defectos de bordes (por la derecha de la Figura 17): roturas en las aristas. 
 ■ Defectos de esquinas (por la izquierda de la Figura 18): esquinas rotas en la baldosa. 
 ■ Cracks (por la derecha de la Figura 18): son grietas, fisuras o cortes en la superficie de 
 la baldosa. 
 ■ Defectos de dimensión: son baldosas más grandes o más pequeñas de lo normal. 
 ■ Pinholes (por la izquierda de la Figura 19): agujeros o cráteres pequeños en la 
 superficie, que se ven más oscuras sobre la superficie. 
 ■ Splashes (por la derecha de la Figura 19): salpicaduras, conjuntos de manchas 
 agrupadas siguiendo un patrón. Se diferencian de los blobs en el sentido en que las 
 gotas de los blobs suelen presentarse de forma individual. 
 30 
 Figura 17. Detalle de defectos en baldosas. A la izquierda, defectos de gotas. A la derecha, rotura en un borde. 
 Figura 18. Detalle de defectos en baldosas. A la izquierda, defectos de cracks. A la derecha, rotura en una esquina. 
 31 
 Figura 19. Detalle de defectos en baldosas. A la izquierda, defecto de pinhole . A la derecha, defecto de salpicadura. 
 De este conjunto de baldosas, se seleccionan algunas para realizar las pruebas. De ellas se 
 toman fotografías con la plataforma de hardware, conformando así un dataset de imágenes de 
 baldosas para realizar las pruebas sobre ellas. Debido a que algunas de estas fotografías 
 tienen una iluminación no uniforme sobre su superficie, fueron ajustadas utilizando software de 
 manipulación de imágenes, obteniendo imágenes como las que se muestran en la Figura 20. 
 Figura 20. Imágenes de baldosas tomadas en el CEMVA . Por la izquierda, una baldosa con un pinhole . Por la 
 derecha, una baldosa con una rotura de borde. 
 32 
 3.2 Componentes hardware 
 Como sensor para la captura de imágenes, se utiliza la cámara Pcam 5C de Digilent 
 [25]. La misma cuentacon un sensor de imagen OV5640 con una montura de lente M12, que 
 permite acoplar e intercambiar una óptica de acuerdo a las necesidades específicas del 
 problema, y una interfaz de conexión MIPI CSI-2. Es un módulo de imagen pensado para su 
 uso con placas de desarrollo FPGA. El sensor de imagen es de 5 megapíxeles, obteniendo 
 imágenes a color. Además, este sensor incluye varias funciones internas para mejorar y/o 
 preprocesar los datos obtenidos, como por ejemplo ajuste de saturación, nitidez y color. La 
 información puede ser transmitida con suficiente ancho de banda como para lograr una señal 
 de video de 720p a 60 cuadros por segundo o 1080p a 30 cuadros por segundo. En la Figura 
 21 se puede ver la cámara Pcam 5C. 
 Figura 21. Pcam 5C de Digilent. Extraída de [25]. 
 Para el procesamiento de imágenes se utiliza el kit de desarrollo Zybo Z7-20 de Digilent 
 [26]. Cuenta con 6 puertos Pmod para posibilitar la conexión de sensores y actuadores, puertos 
 de entrada y salida de audio, un puerto HDMI para recepción y otro para transmisión de video, 
 conector MIPI CSI-2 (que es de utilidad para conectar con la Pcam 5C), entre otras 
 características. Además, la placa posee un System on Chip FPGA XC7Z020-1CLG400C de 
 33 
 Xilinx, perteneciente a la familia Zynq, el cual posee tanto una parte de lógica programable 
 (FPGA) como un procesador ARM Cortex-A9 de dos núcleos (PS). Debido a su amplia 
 conectividad en cuanto a video (puertos HDMI, MIPI CSI-2) y la inclusión del SoC FPGA, esta 
 placa es adecuada para soluciones embebidas de Computer Vision de alta complejidad, siendo 
 a su vez una alternativa relativamente económica. En la Figura 22 se puede ver una imagen de 
 la Zybo Z7-20. 
 Figura 22. Zybo Z7-20 de Digilent. Extraída de [26]. 
 Para la visualización de las imágenes procesadas se han utilizado tanto monitores de 
 computadora con resolución de 1080p, como una pantalla táctil LCD de 7 pulgadas con 
 resolución 1024x600 de la compañía SpotPear Electronics. En la Figura 23 se puede ver a la 
 Zybo Z7-20, la Pcam 5C y la pantalla LCD de SpotPear Electronics en conjunto. 
 34 
 Figura 23. Zybo Z7-20 con la cámara Pcam 5C y el display LCD conectados. 
 3.3 Software para desarrollo 
 En cuanto a las herramientas de software para el desarrollo, se utilizaron principalmente 
 las que están contenidas en Vivado Design Suite, de la compañía Xilinx. Estas son: 
 ■ Vivado 2018.2: Vivado® es un software desarrollado por Xilinx para analizar, sintetizar, 
 testear, implementar diseños de hardware a ser llevados a FPGAs. Se basa en la 
 utilización de módulos IP (unidades de lógica reusable con propiedad intelectual) y 
 diseños propios en algún lenguaje de descripción de hardware (ya sea VHDL o Verilog). 
 ■ Xilinx SDK 2018.2: Xilinx SDK es un Entorno de Desarrollo Integrado (IDE, por sus 
 siglas en inglés) para el desarrollo sobre los diseños de hardware de Vivado. En este 
 caso particular, esta herramienta sirve para desarrollar el software que se ejecutará en 
 la Zybo Z7-20. Además, se usa para subir el programa codificado y permite 
 comunicarse con la placa en tiempo de ejecución. 
 ■ Vivado HLS 2019.1: Vivado HLS ( High-Level Synthesis ) es un entorno incluido dentro 
 del paquete de software de Xilinx que permite acelerar el desarrollo de módulos IP 
 mediante la posibilidad de definir los algoritmos requeridos en lenguajes de 
 programación de más alto nivel que los lenguajes de descripción de hardware como 
 VHDL o Verilog. De esta manera, algoritmos se pueden desarrollar en C o C++ de forma 
 relativamente más ágil y probarse fácilmente. No sólo se facilita la codificación, sino que 
 35 
 es posible optimizar en utilización de recursos y/o tiempo mediante el uso de directivas 
 predefinidas. Además, Xilinx provee soporte para incluir interfaces comunes, tales como 
 AXI4, AXI4-Stream, FIFO. También provee la biblioteca xfOpenCV (llamada en 
 versiones anteriores como HLS Video Library), que contiene gran cantidad de 
 operaciones de procesado de imágenes similares a las de OpenCV, las cuales además 
 están optimizadas y son sintetizables en FPGA. Estas últimas en el presente caso serán 
 de especial utilidad para el procesado de las imágenes capturadas. 
 Por otro lado, en algunas de las etapas del desarrollo se busca encontrar nuevas 
 soluciones o algoritmos para resolver ciertas problemáticas con respecto al procesamiento de 
 imágenes. En estos casos se decide cambiar de herramienta, ya que el ambiente de desarrollo 
 de Vivado se enfoca directamente en la implementación para SoC FPGAs. Se busca entonces 
 otra forma más rápida y ágil para hacer pruebas y cálculos, con soporte para el procesamiento 
 de imágenes. 
 El otro ambiente de desarrollo seleccionado es el que ofrece Google en Google 
 Colaboratory, que está construido sobre Jupyter y permite ejecutar código en lenguaje Python. 
 Este código es escrito directamente desde un navegador web para ser procesado en los 
 servidores de Google, característica que permite procesar rápidamente un gran volumen de 
 datos. 
 Como ventajas de usar Python, dentro del ambiente de Colab, se tienen que: 
 ■ Es un lenguaje interpretado: se pueden ejecutar instrucciones según se necesite, sin 
 tener que recompilar y ejecutar todo el código cada vez. 
 ■ Es muy rápido para realizar grandes cálculos matemáticos. 
 ■ Es un lenguaje no tipado: las variables no requieren definir el tipo en su declaración, por 
 lo que no están ligadas a un único tipo de dato. Esto es útil, por ejemplo, para realizar 
 cálculos matemáticos sin preocupaciones sobre la precisión del tipo de dato, ya que el 
 intérprete lo ajusta automáticamente. 
 ■ Tiene soporte de bibliotecas de visualización de datos: esto facilita graficar funciones y 
 resultados matemáticos. La biblioteca más utilizada para estos fines es matplotlib [27]. 
 ■ Tiene soporte para OpenCV: al igual que para C y C++, Python tiene su versión de la 
 biblioteca OpenCV, que es fácil de asimilar debido a que ya se utiliza en Vivado HLS. 
 36 
 3.4 Plataforma de desarrollo 
 Una parte fundamental de este proyecto para la detección de fallas en baldosas es la 
 implementación de una plataforma en FPGA de procesamiento de video con la que se puedan 
 realizar pruebas rápidamente, evitando tener que lidiar con el diseño de hardware. Además, se 
 especifica también el programa que correrá en el procesador de la placa, con el que se pueden 
 configurar ciertos parámetros de video en tiempo de ejecución. Es decir, define el diseño 
 completo en SoC de la plataforma base de procesamiento de video que sirve para el desarrollo 
 sencillo de los algoritmos (así como para otros proyectos). 
 Profundizando un poco más en la definición de la plataforma, obtiene las señales crudas 
 de imágenes desde la Pcam 5C a través de la interfaz MIPI CSI-2 de la Zybo Z7-20, para 
 convertirlas a un espacio de color RGB estándar, para luego procesar la imagen según un 
 determinado algoritmo de detección de fallas, y finalmente realizar el tratamiento de la señalresultante para ser transferida a través de un HDMI y visualizada. Además de esto, permite 
 modificar los parámetros de resolución y cuadros por segundo, en tiempo de ejecución, 
 mediante la comunicación serial por el puerto USB de la Zybo. 
 A continuación se explica de forma general la plataforma propuesta para estas tareas. 
 En el Apéndice: Plataforma ZYNQ se describe la misma de forma exhaustiva. 
 3.4.1 Diagrama de bloques simplificado 
 Un esquema simplificado del diagrama de bloques se puede ver en la Figura 24. 
 37 
 Figura 24. Diagrama de bloques simplificado de la plataforma de procesamiento de imágenes, junto con las 
 comunicaciones con la Pcam 5C y una PC. 
 En la parte de lógica programable (PL), las señales de la imagen ingresan a la placa a 
 través de la interfaz MIPI, se convierten a un AXI-Stream, se pasan de un formato de Bayer 
 Pattern a un espacio de color RGB, se le realiza una corrección gamma, se almacenan en 
 memoria (con el bloque AXI VDMA) para el control de los parámetros del video, y finalmente se 
 pasan de AXI-Stream a una señal transmisible por el puerto de salida HDMI de la Zybo Z7-20. 
 Además, en el diseño se incluye también al Sistema de Procesamiento (PS) Zynq, el 
 procesador propio del chip, el cual se encargará de configurar ciertos parámetros de video en 
 tiempo de ejecución. Algunos de estos parámetros, como se ve en la Figura 24, son la 
 resolución y cuadros por segundo del video, y el factor de corrección gamma que se le aplica a 
 la imagen. Cabe destacar que estas configuraciones se podrán establecer al comunicarse con 
 la placa mediante UART, con una PC conectada al puerto USB de la placa por ejemplo. 
 Por último, esta configuración de diagrama de bloques permite incorporar los módulos 
 IP correspondientes a los algoritmos de detección de fallas. Esto se podrá hacer de forma 
 sencilla ubicando el o los módulos IP preferentemente entre el módulo de corrección gamma y 
 38 
 el AXI VDMA, y definiendo sus interfaces de entrada salida como AXI-Streams de imágenes en 
 espacio de color RGB, como se muestra en la Figura 25. Este módulo IP agregado puede estar 
 conectado al AXI Interconnect para que tenga comunicación con el microprocesador Zynq y 
 poder configurar sus parámetro en tiempo de ejecución. 
 Figura 25. Lugar de adición de módulo IP de algoritmo de detección de fallas en el pipeline de procesamiento de 
 imágenes. 
 3.4.2 Programación de PS 
 Para configurar los parámetros de video en tiempo de ejecución de la aplicación, se 
 codifica un programa en el IDE Xilinx SDK. A modo de menú de configuración, en el programa 
 se puede seleccionar la resolución y cuadros por segundo (720p a 60 cuadros por segundo, 
 1080p a 15 o 30 cuadros por segundo), factor gamma (1, 0,83, 0,66, 0,55, 0,45), y otras 
 configuraciones del sensor de la cámara para definir cómo se leen los valores lumínicos. 
 Esto se realiza cargando los archivos de drivers de HDMI y del sensor OV5640 que 
 contienen las direcciones de memoria para establecer los valores por AXI4-Lite, que es la 
 forma de comunicación entre el microprocesador y la FPGA. 
 Una vez compilado, desde Xilinx SDK se puede configurar la lógica programable, a 
 través de bitstream y programar el procesador para iniciar su funcionamiento en la Zybo Z7-20. 
 Además, utilizando una terminal de comunicación serial, como TeraTerm, es posible configurar 
 los parámetros anteriormente nombrados. 
 3.5 Metodología de desarrollo 
 Con Vivado HLS se busca desarrollar módulos IP de procesamiento de imágenes a 
 partir de una codificación en un lenguaje de alto nivel como C++. Para ello se parte de la 
 descripción de algoritmos del trabajo de Echeverz y Melograno [3], para finalizar en la 
 39 
https://app.diagrams.net/?page-id=dWZIHltL9wqawjVgOjfx&scale=auto#G1d0bD2yyyMFxUuPxod4oU4z1TSnlerzDu
 implementación de módulos IP que lleven a cabo esos algoritmos. Cabe aclarar que el proceso 
 que se describe a continuación de desarrollo de módulos IP con Vivado HLS se repetirá con 
 cada uno de los algoritmos de procesado de video. En la Figura 26 se puede ver un esquema 
 con las etapas del desarrollo de cada módulo IP. 
 Figura 26. Etapas de desarrollo de cada módulo IP de procesado de imágenes. 
 Dado que se parte de la descripción de los algoritmos de un trabajo anterior, lo primero 
 que se hace es analizar ese algoritmo y separarlo en partes. Se busca clasificar cada parte del 
 algoritmo en las etapas de procesamiento de imágenes clásicas, es decir, preprocesamiento, 
 segmentación, medición de características y clasificación (se omite la etapa de adquisición de 
 imágenes, ya que esto se realizará en la plataforma de procesado de video propuesta). Si bien 
 en algunas secciones del trabajo se nombran las funciones de MATLAB específicas que se 
 usan, en otras se describe solo qué se realiza (y no cómo), por lo que es importante identificar 
 esto. De esta manera se logra un entendimiento a nivel abstracto del algoritmo, lo que facilita la 
 migración a otro conjunto de funciones de biblioteca o a la implementación de funciones 
 personalizadas según los alcances de Vivado HLS y el hardware disponible. 
 En segundo lugar, a partir de esa descripción abstracta se hace una primera 
 implementación del algoritmo en C++, utilizando funciones propias de OpenCV y estructuras de 
 datos de uso común en C++ (vectores, listas, arreglos). Esto se realiza en Vivado HLS 2019.1, 
 aunque no se hace uso de las herramientas de síntesis y testing para desarrollo de módulos IP, 
 40 
 sino que se usa su compilador de C++ (GCC). En esta etapa, cada parte del algoritmo es 
 ajustada para su correcto funcionamiento sobre el dataset de imágenes utilizado en el trabajo 
 de Echeverz y Melograno [3]. 
 Una vez logrados los resultados buscados con OpenCV, se pasa a la tercera etapa, que 
 consiste en desarrollar la solución en HLS para ser exportada como un módulo IP. En esta 
 etapa sí se hace uso de las herramientas de Vivado HLS para desarrollo de hardware. Es 
 necesario migrar las funciones de OpenCV a su equivalente en xfOpenCV, y en caso de que no 
 exista implementación de alguna función específica, se debe realizar una solución 
 personalizada. El correcto funcionamiento de cada algoritmo es validado con el dataset de 
 imágenes tomadas en el CEMVA , mediante la simulación por software que provee Vivado HLS. 
 Por último, se hace la síntesis, análisis de resultados de tiempos y ocupación de 
 recursos del módulo IP sintetizado, y la co-simulación del diseño para verificar la equivalencias 
 entre los resultados obtenidos de las ejecuciones en software y las simulaciones del hardware 
 desarrollado. 
 Las últimas dos etapas hacen uso de Vivado HLS. El flujo de diseño propuesto por 
 Xilinx consta de las siguientes partes: 
 ■ Codificación en C/C++ : se codifica la función que se desea implementar como módulo 
 IP. 
 ■ Simulación en C/C++ : tras la codificación en lenguaje de alto nivel, Vivado HLS permite 
 hacer una simulación basada únicamente en software del módulo IP a partir deun 
 testbench definido por el usuario. Para ello se pueden hacer uso de todas las bibliotecas 
 y estructuras de datos disponibles en estos lenguajes sin ningún problema, ya que se la 
 compilación se hace con el compilador clásico GCC. La herramienta de simulación es 
 muy útil ya que posibilita hacer una ejecución y testeo rápido de la implementación. 
 Como punto débil se tiene que no se pueden verificar las restricciones propias del 
 sintetizador de HLS (lo que hace que se pierda tiempo en las siguientes etapas de 
 desarrollo). 
 ■ Síntesis : se sintetiza el código escrito en alto nivel. En esta etapa se traduce el código 
 en C/C++ hacia una implementación en RTL, teniendo en cuenta las restricciones para 
 diseñar en hardware (no se pueden usar bibliotecas no sintetizables como OpenCV 
 estándar, ni se pueden usar punteros o estructuras de datos dinámicas o 
 semi-dinámicas, entre otras). Además, esta etapa utiliza las directivas para la 
 41 
 aceleración u optimización de recursos, sumado a las optimizaciones automáticas que 
 realiza la herramienta. 
 ■ Análisis de resultados de síntesis : Vivado HLS provee herramientas para visualizado, 
 análisis de performance estimada y uso de recursos estimado (a estos últimos se les 
 dice estimados ya que el resultado posterior en hardware puede ser distinto al supuesto 
 en la síntesis). También contiene un visualizador de registros y operaciones del diseño 
 RTL obtenido en la síntesis. Por último, también posibilita la comparación de soluciones. 
 ■ Co-simulación : realiza la simulación en C/C++ del testbench (la misma que la anterior) 
 en conjunto con la simulación del diseño a nivel RTL obtenido de la síntesis para 
 verificar que ambos diseños retornan el mismo resultado. Es una herramienta muy útil, 
 ya que permite verificar que el resultado por software se condice con el resultado del 
 diseño RTL. Como desventaja, se tiene que en general toma mucho tiempo para 
 realizarse, pudiendo tardar horas para un módulo IP medianamente grande. Esta etapa 
 es opcional para la obtención del módulo IP exportado. 
 ■ Exportación del módulo IP: tras una síntesis exitosa, se puede exportar el módulo IP 
 para ser utilizado por otra herramienta de diseño de hardware (como por ejemplo 
 Vivado). 
 Este flujo de diseño se muestra gráficamente en la Figura 27. 
 Figura 27. Flujo de diseño en Vivado HLS. 
 42 
 4. Corrección de distorsión de lente 
 La distorsión de barril ( barrel distortion ) es un defecto ocasionado por las lentes que 
 hace que las líneas rectas se doblen hacia afuera y es más notable a lo largo de los bordes. La 
 distorsión puede ser corregida a través del software, por ejemplo utilizando la función 
 cv::remap() provista en OpenCV. Sin embargo, la implementación contenida dentro de 
 xfOpenCV presenta una gran demanda de recursos, impidiendo su utilización en el dispositivo 
 seleccionado. En este capítulo se explica el proceso de desarrollo de una aproximación de la 
 función Remap adecuada para la implementación en Lógica Programable, que es necesaria 
 para el correcto funcionamiento de los algoritmos de inspección de defectos. En la Sección 4.1 
 se hace una introducción a qué es la distorsión radial en imágenes, por qué es un problema y 
 cómo caracterizarla. En la Sección 4.2 se explica cómo fue la primera implementación con la 
 biblioteca xfOpenCV y los problemas que conlleva. En la Sección 4.3 se aborda una solución 
 basada en aproximaciones de funciones matemáticas, explicando el desarrollo del modelo 
 matemático y los resultados de las pruebas. En la Sección 4.4 se explica la segunda nueva 
 solución propuesta basada en vectores de valores precalculados, cómo se calcula y los 
 resultados de las pruebas. Por último, en la Sección 4.5 se exponen los resultados de la 
 implementación en HLS. 
 4.1 Distorsión radial 
 La distorsión radial es un tipo de aberración óptica (una desviación de la luz que genera 
 efectos muchas veces no deseados) provocada por los lentes de las cámaras. En particular, la 
 distorsión radial es un tipo de distorsión geométrica, que cambia la forma en la que se ven los 
 objetos. Se le llama radial porque esa es la manera en la que se presenta: en forma radial a 
 partir de un determinado punto de la imagen resultante. Los efectos más comunes producidos 
 por la distorsión radial son el efecto barril ( barrel distortion ) y efecto almohada ( pincushion 
 effect ). En la Figura 28 se puede ver cada uno de estos tipos de distorsión sobre una 
 cuadrícula, en comparación a la cuadrícula original. 
 43 
 Figura 28. Representaciones gráficas de los tipos de distorsión radial. 
 La cámara Pcam 5C, elegida para conformar la plataforma de procesado de imágenes, 
 introduce distorsión radial del tipo barrel effect , que genera problemas para los algoritmos, en 
 especial para el algoritmo de detección de defectos en bordes, esquinas y dimensión (Sección 
 5.1) que se basa en las características geométricas de las baldosas para decidir si tienen o no 
 defectos. En los algoritmos se asume que la baldosa se acerca a su forma real, es decir, 
 cuadrada. Sin embargo, al tomar imágenes con la plataforma, la forma de una baldosa se 
 observa como la silueta blanca en la Figura 29, mientras que la forma deseada se muestra en 
 color verde en la misma imagen. Lo que sobresale del cuadrado coloreado es un efecto no 
 deseado, provocado por la distorsión radial introducida por el lente. 
 44 
 Figura 29. Silueta de baldosa de imagen obtenida con la plataforma. En verde se marca la silueta deseada (sin 
 distorsión radial). 
 Para solucionar este problema, el primer paso es caracterizar la distorsión. Con el 
 objetivo de modelar la distorsión, el modelo más utilizado es el de Brown-Conrady [30], que se 
 basa en el cálculo de varios coeficientes, algunos correspondientes a la distorsión radial y otros 
 a la distorsión tangencial. Estos coeficientes son propios de cada lente. Las ecuaciones del 
 modelo son las que se muestran en las Ecuaciones 1. 
 𝑥 
 𝑢 
= 𝑥 
 𝑑 
+ ( 𝑥 
 𝑑 
− 𝑥 
 𝑐 
)( 𝐾 
 1 
 𝑟 2 + 𝐾 
 2 
 𝑟 4 +...)
+ ( 𝑃 
 1 
( 𝑟 2 + 2 ( 𝑥 
 𝑑 
− 𝑥 
 𝑐 
) 2 ) + 2 𝑃 
 2 
( 𝑥 
 𝑑 
− 𝑥 
 𝑐 
)( 𝑦 
 𝑑 
− 𝑦 
 𝑐 
)) ( 1 + 𝑃 
 3 
 𝑟 2 + 𝑃 
 4 
 𝑟 4 + ...)
 𝑦 
 𝑢 
= 𝑦 
 𝑑 
+ ( 𝑦 
 𝑑 
− 𝑦 
 𝑐 
)( 𝐾 
 1 
 𝑟 2 + 𝐾 
 2 
 𝑟 4 +...)
+ ( 2 𝑃 
 1 
( 𝑥 
 𝑑 
− 𝑥 
 𝑐 
)( 𝑦 
 𝑑 
− 𝑦 
 𝑐 
) + 𝑃 
 2 
( 𝑟 2 + 2 ( 𝑦 
 𝑑 
− 𝑦 
 𝑐 
) 2 )) ( 1 + 𝑃 
 3 
 𝑟 2 + 𝑃 
 4 
 𝑟 4 + ...)
 siendo: 
 45 
 un punto en la imagen distorsionada, ( 𝑥 
 𝑑 
, 𝑦 
 𝑑 
)
 el punto en la imagen no distorsionada, ( 𝑥 
 𝑢 
, 𝑦 
 𝑢 
)
 el punto del centro de distorsión, ( 𝑥 
 𝑐 
, 𝑦 
 𝑐 
)
 el n-ésimo coeficiente de distorsión radial, 𝐾 
 𝑛 
 el n-ésimo coeficiente de distorsión tangencial, 𝑃 
 𝑛 
 , y 𝑟 = ( 𝑥 
 𝑑 
− 𝑥 
 𝑐 
) 2 + ( 𝑦 
 𝑑 
− 𝑦 
 𝑐 
) 2 
 ... = una serie infinita. 
 Ecuaciones 1. Modelo de distorsión radial de Brown-Conrady. 
 De estos