Smart cities: Aprendizaje profundo con imágenes

Universidad Complutense de Madrid Facultad de Informática Smart cities: Aprendizaje profundo con imágenes Smart cities: Deep learning with images Ana Laura Corral Descargue Guillermo Delgado Yepes Víctor Goicoechea Enrique Manuel Guerrero Moñús Trabajo de Fin de Grado en Ingeniería del Software Curso: 2019 - 2020 Director: Gonzalo Pajares Martinsanz 1 Dedicatoria Ana Laura Corral Descargue A toda mi familia, que siempre ha estado ahí dando tanto apoyo emocional como económico, a todas las personas que he conocido a lo largo de la carrera que me han aportado cosas positivas y negativas y aprender de todo ello, e ir madurando. Guillermo Delgado Yepes A mi familia, que me ha acompañado en todo momento, en lo bueno y en lo malo, y me ha brindado su apoyo. A mis amigos y compañeros de la UCM, por todas las risas y buenos momentos que han facilitado el paso por la universidad. A mis profesores que han aportado conocimientos y momentos míticos que nunca olvidaremos. A mis compañeros de trabajo, por acogerme tan fácilmente y ayudarme con su propia experiencia. Víctor Goicoechea Enrique A mi familia, que siempre ha estado ahí para apoyarme en los momentos más difíciles, a los profesores y compañeros, que han hecho más llevaderos estos años de universidad. Manuel Guerrero Moñús A toda mi familia, que siempre ha creído en que puedo alcanzar cualquier reto que me proponga. A mi grupo de amigas del instituto, que tanto me aprecian. A mis amigos y excompañeros de formación profesional de Joyfe, así como a mis amigos y compañeros de la facultad de informática de la UCM, que siempre me animaron a ir a más. A Lu, quien tanto me ha enseñado. Agradecimientos Queremos agradecer a nuestro tutor del TFG y profesor de la asignatura Ingeniería del Conocimiento, Gonzalo Pajares Martinsanz, la oportunidad de haber realizado bajo su orientación, un trabajo que ha resultado tan interesante como útil de cara al futuro de la Ingeniería Informática. 2 Resumen Con el paso del tiempo los sistemas de la información y la comunicación se han integrado en las sociedades humanas de tal forma que pasan desapercibidos en el entorno, para proporcionar, cada vez más y de forma más rápida, una gran cantidad de información que, al ser tratada, puede hacer que la vida de las personas sea más cómoda y sencilla. Gracias a esta computación ubicua que monitoriza constantemente los datos de las actividades humanas han surgido paradigmas como Aprendizaje Profundo (Deep Learning) en Inteligencia Artificial o IoT (Internet of Things), que presta una especial atención a problemas del mundo real resolubles y automatizables, mediante el empleo de sistemas hardware y software que aplican los mejores modelos de procesamiento y análisis de datos para lograr una mejor toma de decisiones. En particular, en el presente trabajo se pone el foco en el problema del análisis del flujo de vehículos existente en las ciudades modernas, que evolucionan hacia el concepto de ciudades inteligentes. Se trata de un problema relevante de cara a la sostenibilidad, un problema de la historia reciente que trata algunas cuestiones, como por ejemplo la optimización de las rutas de transporte, la movilidad eficiente, la determinación de los flujos de transporte en función de los itinerarios de las ciudades, la gestión eficiente de las plazas de aparcamiento, entre otros aspectos relacionados. Para abordar esta problemática se ha desarrollado un sistema software pensado para su implantación y uso en el mencionado contexto de las ciudades inteligentes. Dicho sistema contiene las siguientes funcionalidades: ● Técnicas de análisis del movimiento en secuencias de imágenes mediante el cálculo del flujo óptico. ● Determinación de las regiones en movimiento mediante la aplicación técnicas de segmentación basadas en umbralización y etiquetado. ● Identificación de los vehículos en movimiento mediante técnicas basadas en Aprendizaje Profundo con Redes Neuronales Convolucionales. ● Desarrollo de un módulo de predicción del flujo de tráfico de vehículos con fines de prevención y planificación. ● Desarrollo de una arquitectura cliente-servidor para la implementación de métodos basados en el paradigma IoT, que permitan publicar y visualizar los datos en crudo y los resultantes del análisis del flujo de vehículos. 3 Palabras clave ● Flujo óptico. ● Aprendizaje automático. ● Aprendizaje profundo. ● Redes neuronales convolucionales. ● Análisis predictivo. ● Visión por computador. ● Internet de las cosas. ● Ciudades inteligentes. Abstract Over time, information and communication systems have been introduced into human societies in such a way that they are unnoticed in the environment to provide even more and more quickly, a lot of information that, when it’s processed, can make people's lives more simple and comfortable. Thanks to this ubiquitous computing that is permanently monitoring the data of human activities, paradigms such as Deep Learning in artificial intelligence or IoT have emerged, they pay special attention to real world problems that can be solved and automated by using hardware and software systems by applying the best data processing and analysis models to achieve a better decision making. Particularly, in the present work, the focus is put on the problem of vehicle flow analysis in modern cities, which are evolving to the concept of smart cities. This is a relevant problem in terms of sustainability, a problem of recent history that think about some questions, such as the optimization of transport routes, efficient mobility, determination of transport flows according to the timetables of the cities, efficient management of parking spaces, etc. To solve this problem we have developed a software system thought for it’s implantation and use in the context of smart cities. 4 This system contains the following functionalities: ● Determination of regions in movement applying segmentation techniques based on umbralization and labeling. ● Movement analysis techniques applied to image sequences through the computation of optical flow. ● Vehicles identification in movement through techniques based on Deep Learning with Convolutional Neural Networks. ● Development of a prediction module for vehicle traffic flow with the aim of prevention and planification. ● Development of a client-server architecture for the implementation of methods based on the IoT paradigm, which allows to publish and to visualize raw data and the resulting data of vehicle flow analysis. Keywords ● Optical flow. ● Machine learning. ● Deep Learning. ● Convolutional Neural Networks. ● Predictive analysis. ● Computer Vision. ● Internet of Things. ● Smart cities. 5 Índice Dedicatoria ................................................................................................................. 1 Agradecimientos......................................................................................................... 1 Resumen .................................................................................................................... 2 Palabras clave ............................................................................................................ 3 Abstract ...................................................................................................................... 3 Keywords ................................................................................................................... 4 1. Introducción ............................................................................................................ 7 1.1 Antecedentes ................................................................................................ 7 1.2 Motivación ......................................................................................................... 9 1.3 Objetivos ........................................................................................................... 9 1.4 Plan de trabajo ................................................................................................ 10 1.5 Estructura de la memoria ................................................................................ 12 1.6 Contribuciones personales .............................................................................. 13 1.6.1 Ana Laura Corral Descargue .................................................................... 13 1.6.2 Guillermo Delgado Yepes ......................................................................... 15 1.6.3 Víctor Goicoechea Enrique ....................................................................... 17 1.6.4 Manuel Guerrero Moñús ........................................................................... 20 1.7 Introduction ..................................................................................................... 22 1.7.1 Preliminary ................................................................................................ 22 1.7.2 Objectives ................................................................................................. 24 1.7.3 Work plan.................................................................................................. 25 2. Métodos conceptuales aplicados ......................................................................... 26 2.1 Visión por Computador ................................................................................... 26 2.1.1 Cálculo del flujo óptico .............................................................................. 27 2.1.2 Detección de regiones en movimiento ...................................................... 28 2.2 Redes Neuronales Convolucionales ............................................................... 31 2.2.1 Capas del modelo AlexNet ....................................................................... 33 2.3 Series temporales: Autorregresión .................................................................. 41 3. Diseño y análisis de la plataforma ........................................................................ 42 3.1 Análisis arquitectónico .................................................................................... 45 3.1.1 Lado del cliente ......................................................................................... 45 3.1.2 Lado del servidor ...................................................................................... 50 3.1.2.1 Canal de detección de vehículos ........................................................ 52 3.1.2.2 Canales de predicción ........................................................................ 54 3.2 Metodología de desarrollo empleada .............................................................. 57 3.3 Herramientas y recursos software .................................................................. 58 6 4. Resultados ........................................................................................................... 60 4.1 Interfaz de la aplicación .................................................................................. 61 4.1.1 Learning .................................................................................................... 62 4.1.1.1 Retraining ........................................................................................... 63 4.1.2 Car Detection ............................................................................................ 63 4.1.3 ThingSpeak............................................................................................... 64 4.1.3.1 Queries de ThingSpeak ...................................................................... 65 4.1.4 Forecast .................................................................................................... 66 4.2 Visión por computador .................................................................................... 67 4.2.1 Detección de movimiento.......................................................................... 67 4.2.2 Proceso de binarización ........................................................................... 68 4.2.3 Proceso de segmentación ........................................................................ 69 4.2.4 Clasificación del flujo de tráfico ................................................................. 69 4.2.5 Cómputo del flujo del tráfico ..................................................................... 71 4.3 Aprendizaje profundo ...................................................................................... 75 4.3.1 Ajustes del entrenamiento e interpretación de los resultados ................... 75 4.3.2 Clasificación post-entrenamiento .............................................................. 79 4.4 Procesamiento y predicción en ThingSpeak ................................................... 80 4.4.1 Resultados obtenidos ............................................................................... 81 4.5 Resultados del contador de vehículos de ThingSpeak ................................... 83 5. Conclusiones y trabajo futuro ............................................................................... 85 6. Conclusions and future Work ............................................................................... 87 7. Bibliografía ........................................................................................................... 91 8. Anexos ................................................................................................................. 94 AnexoⅠ: Diagrama de clases de la capa de presentación. .................................. 94 AnexoⅡ: Diagrama de clase de la capa de negocio. ........................................... 95 Anexo Ⅲ: Resultados ThingSpeak Predicción...................................................... 96 Anexo Ⅳ: Resultados ThingSpeak CarDetection. ................................................ 99 Anexo Ⅴ: Manual de usuario. ............................................................................... 99 7 1. Introducción 1.1 Antecedentes Con el paso del tiempo el ser humano ha ido orientando su desarrollo tecnológico hacia la sostenibilidad, cambiando su modo de vida de forma intencional para apostar cada vez más por el ahorro de los recursos energéticos, las energías renovables, el consumo responsable y el respeto por el medio ambiente. Bajo este planteamiento las ciudades inteligentes constituyen un elemento clave en este complejo engranaje. Dentro de ellas, la gestión de la movilidad se establece como uno de los objetivos prioritarios, para lo cual es necesario el manejo del tráfico de vehículos de forma eficiente y controlada. Por otra parte, el desarrollo tecnológico está posibilitando la aparición de soluciones tecnológicas eficientes para abordar la problemática derivada de estos planteamientos. A ello contribuyen, la mejora de los sensores, la capacidad de procesamiento de los sistemas disponibles y el desarrollo de paradigmas tales como internet de las cosas (Internet of Things, IoT). Es aquí donde se centra el proyecto que se presenta en este trabajo, orientado a contribuir a una disminución de las emisiones contaminantes, el ruido y los tiempos de viaje hacia la sostenibilidad. Actualmente, existen soluciones enmarcadas dentro de lo que se conocen como Advanced Traffic Management Systems (ATMS) y Advanced Traveler Information Systems (ATIS) para un control y manejo eficiente de los flujos de tráfico, con especial énfasis en los contextos urbanos25. Son diversos los sistemas ATMS/ATIS diseñados con tal propósito, destacando por ejemplo el uso de redes celulares de sensores que envían información a las estaciones de procesamiento o sistemas de localización espacial como Waze26, basados en el movimiento de los usuarios. Bajo esta perspectiva, aunque desde una posición diferente, en el presente trabajo se plantea una solución de concepto, de forma que mediante la captura de imágenes a color a través de una cámara, es posible aplicar técnicas de Visión por Computador para determinar el movimiento de vehículos, y realizar su identificación mediante la aplicación de técnicas de Aprendizaje Profundo, y el manejo de esta información procediendo a su publicación con posibilidades de procesamiento bajo el mencionado paradigma IoT, que facilita el acceso a la misma por parte de usuarios, particulares o institucionales, para el conocimiento y la gestión eficiente del tráfico rodado o la predicción del mismo. Es evidente que este planteamiento se diferencia de los anteriores en el sentido de que se trata de un único sensor (cámara) cuyos datos son imágenes que se procesan en unidades con capacidad suficiente y cuyos resultados se ponen a disposición de usuarios con fines de visualización y predicción. 8 En cualquier caso, tanto en los sistemas anteriores como en la propuesta del presente trabajo, el objetivo final se encamina al procesamiento y análisis inteligente de los datos disponibles para la extracción de información, y el desarrollo de modelos para realizar una mejor toma de decisiones en cuanto a eficiencia y sostenibilidad, que en el caso del presente proyecto se orienta hacia una mejor distribución de los flujos de tráfico de vehículos en las ciudades. Dentro de esta gestión eficiente del tráfico en las ciudades inteligentes, se contemplan las estaciones de recarga de vehículos eléctricos, tanto de carácter público como privadas en centros de trabajo, de forma que se garantice un flujo apropiado de cara a sus posibilidades, evitando así esperas y pérdidas de tiempo innecesarias. Tal es el caso de la empresa Elmec Informática en Varese (Italia), que ha automatizado al completo su sede central en asociación con Everynet mediante tecnologías IoT1. En el parking del edificio la empresa ha situado siete nodos Libelium Smart Parking22 para gestionar de forma eficiente los puntos de carga de los vehículos eléctricos. Estos dispositivos informan del grado de ocupación del parking, de forma que en soluciones integradas con la propuesta que se formula en este proyecto, esta información ha de resultar de gran utilidad para resolver el problema de la movilidad, que es en definitiva el objetivo final. Por otro lado, en algunas ciudades como Dordrecht (Holanda) se ha desarrollado un proyecto de investigación2 en el que se muestra la utilidad de aplicar el paradigma IoT a algunos de los problemas anteriormente mencionados. Para ello se instalaron en los cruces de varias de sus calles ocho equipos Meshlium IoT Gateways de Libelium22, éstos sirven para conseguir que los datos recibidos por los sensores lleguen hasta una plataforma que permita la gestión de la información. Los dispositivos Meshlium están sincronizados por un reloj digital externo y a través de un escáner wifi detectaban la dirección física (mac address) de los smartphones y de los dispositivos manos libres de los vehículos. La recogida de datos se realiza accediendo a la base de datos local de cada sensor para luego ser almacenados en una base de datos PostgreSQL, una vez comprobada la persistencia de los datos, éstos son analizados mediante scripts de Python y visualizados en un mapa geográfico gracias a la herramienta QGIS. Con los datos recogidos y conociendo la relación de distancia entre dos sensores, se puede obtener la cantidad de movimiento de cada dispositivo detectado. Teniendo en cuenta lo anterior, junto con los criterios de uso de cada calle de la ciudad sobre la que se estaba realizando la monitorización, se pueden reconocer tres tipos de usuarios de estos dispositivos: peatones, ciclistas y vehículos. Esto ha servido para estudiar la relación entre estas tres categorías a lo largo del día, lo que ha sido útil tanto para identificar las calles preferidas por cada tipo de usuario, como para conocer los hábitos de los usuarios a lo largo del tiempo. 15 ● Depuración del código fuente de la aplicación para el subsanamiento de los errores hallados, realización de pruebas y detección de incompatibilidades de la aplicación al ser usada en sistemas de tipo GNU/Linux. Tarea realizada en colaboración con el resto de compañeros del equipo. Parte de memoria: ● Revisión de la memoria. ● Desarrollo de los puntos 1.5, 2.3 de la memoria. ● Apartados redactados en colaboración con mis compañeros: 4.4, 4.4.1 y 7. 1.6.2 Guillermo Delgado Yepes Como en el caso anterior, las tareas se estructuran según las siguientes secciones, teniendo en cuenta que algunas de ellas se solapan, dado el planteamiento de trabajo en grupo. Labores de investigación: ● En colaboración con el miembro del equipo Víctor Goicoechea, realicé un prototipo de interfaz de prueba para determinar cómo se realiza la lectura y escritura entre ThingSpeak24 y MATLAB. ● Análisis del problema de la ubicación de un sistema de conteo de vehículos, basado en el uso de las propiedades básicas de las regiones conexas extraídas de una imagen. En colaboración con los otros tres miembros del equipo. ● Investigar la implementación de interfaces usando la herramienta que MATLAB pone a disposición de los usuarios llamada “App Designer”, que hace posible el diseño y desarrollo de interfaces. ● Investigar cómo unir los distintos elementos gráficos resultantes de la detección de vehículos en una única interfaz con los componentes que nos ofrece MATLAB. ● Investigar la posible arquitectura de la aplicación mediante los patrones establecidos y siguiendo las metodologías de Ingeniería de Software y Modelado de Software. 16 ● Investigar los Toolbox de MATLAB que es necesario instalar para añadir las funcionalidades necesarias para la detección de vehículos. ● Investigar metodologías de Programación Orientada a Objetos y el uso de clases en Matlab, los modificadores de acceso a variables y funciones de la clase, así como el uso de la instanciación única. Gestión del proyecto software: ● Identificación de las tareas del módulo de Arquitectura del Software (SA), Interfaces de Usuario (UI) y Experiencia de Usuario (UX), módulo del cual soy el principal responsable. ● Gestión de las tareas y del Work in Progress del módulo de Arquitectura del Software (SA), Interfaces de Usuario (UI) y Experiencia de Usuario (UX), mediante el uso de un tablero Kanban. Diseño y desarrollo de software: ● Realización de diagramas de clase como parte de la fase de diseño. ● Realización de varios mockups de ejemplo como parte del diseño de las interfaces de la aplicación, para visualizar resultados provisionales, cuyo objetivo es determinar el progreso de los desarrollos y validación en su caso. ● Colaboré con Víctor Goicoechea para comunicar las interfaces que hacen uso de ThingSpeak24 para conseguir la funcionalidad adecuada. ● Implementación de las interfaces siguiendo los mockups realizados previamente y siguiendo los principios básicos de claridad, flexibilidad, unificación y coherencia para con los usuarios de la aplicación, de forma que su uso sea lo más sencillo y amigable posible. ● Colaboré con Manuel Guerrero para conectar el módulo de Visión por Computador (Computer Vision)4 y Aprendizaje Profundo (Deep Learning)27 con sus respectivas interfaces de usuario, para que así éstas contasen con las funcionalidades necesarias para su utilización. ● Colaboré con Ana L. Corral para conectar la parte de predicción en el servidor con la interfaz que implementa dicha funcionalidad. ● Adaptar todo el código de la aplicación a la arquitectura diseñada previamente, siguiendo un modelo multicapa. 17 ● Estructurar el código de la aplicación en los distintos paquetes y directorios de forma que los distintos módulos queden perfectamente definidos. ● Implementación de un sistema de conteo de vehículos mediante el uso de las propiedades que fueron extraídas de aquellas regiones conexas en las que se ha detectado una cantidad de movimiento superior al valor umbral. Tarea realizada en colaboración con los compañeros Ana L. Corral y Manuel Guerrero. ● Depuración del código fuente de la aplicación para el subsanamiento de los errores hallados, realización de pruebas y detección de incompatibilidades de la aplicación al ser usada en sistemas de tipo GNU/Linux. Tarea realizada en colaboración con el resto de miembros del equipo. Memoria: ● Revisión técnica y de redacción. ● Redacté los apartados: 3, 3.1.1. y 4.1 ● Apartados redactados en colaboración con mis compañeros: 3.1.2.1, 3.1.2.2, 4.4, 4.4.1 y 7. 1.6.3 Víctor Goicoechea Enrique Como en los casos anteriores, las tareas realizadas se estructuran como sigue: Labores de investigación: ● Investigué cómo realizar la comunicación entre el canal de ThingSpeak24 y MATLAB, realizando un prototipo de interfaz de prueba para determinar cómo se realiza la lectura y escritura entre ThingSpeak y MATLAB realizada en colaboración con el miembro del equipo Guillermo Delgado. ● Estudié si la licencia de ThingSpeak era viable para poder ser utilizada en el proyecto, analizando las funcionalidades necesarias sin restricciones y determinado si éstas eran viables en relación a los objetivos planteados. ● Investigué las diferentes Apps que facilita ThingSpeak24 para poder hacer que los datos fueran visualizados en diferentes dispositivos/plataformas, como puede ser el teléfono móvil o Twitter. 18 ● Investigué diferentes datasets para alimentar con imágenes el entrenamiento de la CNN Alexnet9, comprobando que tuvieran la correspondiente licencia para su uso con fines académicos. Gestión del proyecto software: ● Colaboré en la identificación de las diferentes tareas en Trello que se tenían que llevar a cabo para la realización del proyecto. ● Gestioné las diferentes tareas en Trello, moviéndolas entre las diferentes columnas para que el tablero Kanban estuviera constantemente actualizado. ● Valoración de las imágenes y vídeos a utilizar para el aprendizaje de la Red Neuronal Convolucional (Convolutional Neural Network, CNN). Finalmente nos decantamos por la grabación de nuestros propios vídeos y su posterior tratamiento, extrayendo de los mismos las imágenes para poder enriquecer el entrenamiento de la CNN. Diseño y desarrollo de software: ● Implementé la llamada de escritura en el canal de ThingSpeak que guarda el conteo de los diferentes tipos de vehículos (FrontCar, BackCar, FrontMotorbike, BackMotorbike, FrontTruckVan, BackTruckVan, FrontBus, BackBus), en la parte de la aplicación donde se realiza la detección de vehículos. ● Participé en el diseño de la interfaz de la aplicación referente a ThingSpeak, comentando las condiciones necesarias para poder realizar las consultas a ThingSpeak, y poder mostrar los datos en la interfaz. ● Implementé la llamada de lectura para el canal de ThingSpeak para realizar la representación de los datos en la interfaz de la aplicación, que hace referencia al apartado de ThingSpeak->Query, donde se podrán hacer consultas indicando dos intervalos de tiempo entre sí y señalando los tipos de vehículos, mostrando los datos en un tabla dentro de la interfaz de MATLAB y una gráfica donde se representan con líneas de diferentes colores en función del tipo de vehículo. ● Creé el canal de ThingSpeak24 donde se suben y consultan todos los datos referentes al conteo de vehículos por parte de la aplicación desarrollada en Matlab. 19 ● Creé la cuenta de Twitter que posteriormente fusionaría con ThingSpeak, mediante las apps de ThingTweet y React, propias de ThingSpeak, que permiten mostrar avisos sobre los datos que entran en el canal de ThingSpeak. ThingTweet, sirve para enlazar la cuenta de Twitter con el canal deseado de ThingSpeak y React para crear una especie de disparador por el cumplimiento de las condiciones prefijadas, en cuyo caso se lanza un mensaje indicando qué campo ha sido modificado. Realicé un React por cada campo a controlar. ● Realicé varios recortes de los diferentes videos grabados en la autovía A-2, para mejorar la identificación de coches por delante, coches por detrás y asfalto. Comentar que en un principio realice 200 recortes de coches por delante y coches por detrás, pero al entrenar la CNN Alexnet9, se producía un sobreajuste de los coches por delante y por detrás, siendo necesario realizar un reequilibrio entre todos los modelos de datos para el entrenamiento. En cuanto al tipo asfalto, simplemente contiene imágenes de asfalto y líneas de carretera, que sirven a Alexnet para descartar posibles zonas del video con falso movimiento. Esta tarea fue realizada en colaboración con Manuel Guerrero. ● Llevé a cabo la redimensión de todas las imágenes extraídas de los videos usando la función de redimensionar implementada en la propia aplicación, subiendo las imágenes redimensionadas al repositorio drive, para posteriormente ser utilizadas en el entrenamiento del modelo de red Alexnet, ya que solo acepta imágenes con dimensiones: 227x227x3. ● Depuración del código fuente de la aplicación para el subsanamiento de los errores hallados, realización de pruebas y detección de incompatibilidades de la aplicación al ser usada en sistemas de tipo GNU/Linux. Tarea realizada en colaboración con el resto de miembros del proyecto. Memoria: ● Revisé la memoria. ● Redacté el apartado 3.1.2, 3.1.2.1, 3.3 y 6 ● Apartados redactados en colaboración con mis compañeros: 3.1, 4.3, 5, 7. 20 1.6.4 Manuel Guerrero Moñús Al igual que en los casos anteriores, las tareas realizadas se estructuran como sigue: Labores de investigación: ● Estudio de las capas, y las operaciones de éstas, del modelo de Red Neuronal Convolucional AlexNet9. ● Investigación sobre la aplicación específica del concepto “transferencia de aprendizaje”13. Qué implica y cuándo ha de usarse. ● Investigar, comprender y estudiar la forma de aplicar métodos eficientes de entrenamiento de las Redes Neuronales Convolucionales. ● Estudio del concepto y posibilidades de aplicación del método del gradiente o método de Lucas-Kanade4 para el cálculo del flujo óptico en imágenes digitales. Búsqueda de herramientas y métodos alternativos para el cálculo del flujo óptico en tiempo real. ● Investigación sobre la aplicación del proceso de binarización de imágenes a color. ● Comprensión del algoritmo de dos fases de Haralick y Shapiro (1992)3 para la extracción de regiones en imágenes binarizadas. ● Análisis del problema de la ubicación de un sistema de conteo de vehículos basado en el uso de las propiedades básicas de las regiones conexas extraídas de una imagen. En colaboración con el resto de miembros del equipo. Diseño y desarrollo de software: ● Implementación del concepto “transferencia de aprendizaje”. ● Preprocesamiento de las imágenes de los conjuntos de entrenamiento y validación, así como preparación de lo que se denomina aumento de imágenes (image augmentation) para mejorar el entrenamiento y favorecer la clasificación posterior. ● Configuración del proceso de entrenamiento del modelo de Red Neuronal Convolucional AlexNet. 21 ● Inclusión de un analizador de Redes Neuronales Convolucionales11 que sirve para proporcionar, tanto información como ayuda con respecto al modelo de red empleado. ● Inclusión de la Matriz de Confusión12, para verificar y validar el proceso de entrenamiento. ● Cálculo del flujo óptico sobre imágenes binarias. ● Desarrollo del proceso de binarización de una imagen a color mediante umbralización, extracción de las regiones conexas y su posterior etiquetado. ● Obtención de las propiedades (Bounding Box, Area y Centroid) requeridas para el reconocimiento de los vehículos. ● Implementación de un sistema de conteo de vehículos utilizando las propiedades anteriores. Tarea realizada en colaboración con el resto de miembros del equipo. ● Conexión del módulo de inteligencia artificial en el lado del cliente con sus respectivas interfaces de usuario, para que éstas incluyan lo necesario para su utilización. Tarea realizada en colaboración con Guillermo Delgado. ● Depuración del código fuente de la aplicación para el subsanamiento de los errores hallados, realización de pruebas y detección de incompatibilidades de la aplicación al ser usada en sistemas de tipo GNU/Linux. Tarea realizada en colaboración con el resto de miembros del equipo. Gestión del proyecto software: ● Identificación de las tareas del módulo de Deep Learning27 y Computer Vision4, del que soy el principal responsable. ● Gestión de las tareas y del Work in Progress del módulo de Deep Learning y Computer Vision, mediante el uso de un tablero Kanban. Trabajo de campo: ● Grabación previa y procesamiento de vídeos en la parte del cliente para proporcionar datos de tráfico al lado del servidor con fines de predicción. 22 ● Extracción de imágenes de vehículos y otros elementos presentes en las vías de circulación a partir de vídeos de tráfico y sets de imágenes gratuitos de uso no comercial, para utilizar dichas imágenes para el entrenamiento de la red. Esta tarea fue realizada en colaboración con Víctor Goicoechea. Memoria: ● Redacción de los apartados: 1.1, 1.2, 1.3, 1.6.4, 2.1, 2.2, 3.2, 3.4, 4.1 y 4.2. ● Apartados redactados en colaboración con mis compañeros: 1.4, 5 y 7. 1.7 Introduction 1.7.1 Preliminary Over time humans have oriented their technological development to sustainability, changing their way of life intentionally to contribute more and more for saving the energy resources, the renewable energies, the responsible consumption and the respect for the environment. Under this approach, smart cities are a key element in this complex gear. Among them, mobility management is established as one of the priority objectives, for which it is necessary to manage vehicle traffic in an efficient and controlled manner. On the other hand, technological development is making possible the appearance of efficient technological solutions to tackle the problems derived from these approaches. Definitively, an important contribution on this area becomes from the improvement of sensors, the processing capacity in the available systems and the development of paradigms such as the Internet of Things (IoT). Here is where this work is focused, aimed at contributing to a reduction in pollutant emissions, noise and travel times towards sustainability. Currently, there are solutions within what are known as Advanced Traffic Management Systems (ATMS) and Advanced Traveler Information Systems (ATIS) for efficient control and management of traffic flows, with special emphasis on urban contexts25. Different ATMS / ATIS systems, designed for this purpose, have been developed, including cellular sensor networks that send information to be processed on specific stations or systems with spatial location such as Waze26, this last based on the movement of users. Under these considerations, although from a different point of view, in this work a concept solution is proposed, so that by capturing color images through a camera, it is possible to apply Computer Vision4 techniques to determine the movement of 23 vehicles, and its identification through by using Deep Learning27 techniques and the handling of this information with its public access and with options to be processed under the aforementioned IoT paradigm, providing access to users (personal or institutional) for knowledge and management efficient traffic or for prediction. It is obvious how this approach differs from the previous ones as it consists of a single sensor (camera) whose data are images to be processed in computerized units with sufficient capacity and whose results are made available to users for visualization purposes and traffic flow prediction. Both, the previous systems and the proposed in this work, the final goal is aimed at the intelligent processing and analysis of data available for extracting information, and the development of models to carry out better decision-making according to efficiency and sustainability, which in the case of this project is oriented towards a better distribution of vehicle traffic flows in cities. Within actions for efficient traffic management in smart cities, electric vehicle charging stations are considered, both with public and private usage, so as to guarantee an appropriate traffic flow according to their possibilities, thus avoiding unnecessary waiting and waste of time. The Elmec Informatic company in Varese (Italy), has fully automated its facilities in association with Everynet and using IoT technologies1. In the car parking, seven Libelium Smart Parking nodes22 were installed for efficient management of charging points for electric vehicles. These devices report car parks' occupancy rates, so that for integrated solutions involving the proposed approach in this work, this information becomes very useful for solving mobility problems, which is the final objective. On the other hand, in some cities such as Dordrecht (Netherlands), a research project2 has been developed, proving the utility of the IoT paradigm to some of the aforementioned problems. Eight Meshlium IoT Gateways of Libelium22 equipment were installed at the intersections of several of its streets, these serve to ensure that the data received by the sensors reach a platform that allows correct information management. Meshlium devices are synchronized by an external digital clock and through a wi-fi scanner by detecting physical addresses (mac addresses) of smartphones and vehicle hands-free devices. Data collection is carried out by accessing the local database of each sensor and then being stored in a PostgreSQL database, once the persistence of data is verified, these are analyzed using Python scripts and displayed on a geographic map thanks to the QGIS tool. With the collected data and knowing the distance relationship between two sensors, the amount of movement of each detected device can be obtained. Taking into account the above, together with the criteria for the use of each street in the city on which monitoring was being carried out; three types of users of these devices can be recognized: pedestrians, cyclists and vehicles. This has served to 24 study the relationship between these three categories throughout the day, which has been useful to identify the preferred streets for each type of user, as well as to know the habits of users over time. It is clear that all the information available, and especially that related to traffic movement and density, as in this work, allows defining the most effective routes when traveling within and outside cities, avoiding traffic congestion, which justifies the proposal in the present project. 1.7.2 Objectives The general objective of this project is the development of a conceptual application that can be implemented in the framework of the smart cities in a near future, for the detection of traffic flow (vehicles) in the access roads, it will be made through the analysis of the images detected in videos. Most part of the processing will be made on the client side of the proposed application, by using processing and graphic units, supporting the required computational load for retraining a convolutional neural network and for detecting objects (vehicles) in images as fast as possible. The resulting data of the processed information on the client side will be transferred to a ThingSpeak24 remote server, there they will be stored for its visualization, queries and other processing tasks. As aforementioned, a smart conceptual application is proposed, including Computer Vision4 and Deep Learning27 techniques, integrated under an IoT context, generating, by itself, the main objective developed on this work. The previous approach results in the following specific objectives: ● Development of techniques based on optical flow analysis of images for the detection of vehicles in movement. ● Development of image segmentation techniques to extract the regions in movement through umbralization and labeling of associated regions. ● To develop a method to compute vehicles in image sequences to upload data in the cloud. ● To develop a module for transfer learning through the use of pre-trained and re-trained convolutional neural networks. 31 Figura 2.3 Final de la fase 2 del algoritmo de Haralick y Shapiro. Una vez finaliza el algoritmo se obtienen una serie de propiedades de la imagen, una de las más importantes es la obtención de la ubicación y el tamaño de las áreas conexas, etiquetadas y delimitadas por un rectángulo (Bounding Box). Su obtención se realiza a través de la comparación de aquellas zonas que tengan una magnitud de movimiento significativo determinado por el valor umbral, previamente obtenido, entre dos frames de vídeo consecutivos. Una vez se obtienen todas las regiones candidatas que son representativas del movimiento, éstas se ubican y localizan sobre la imagen original, realizando un recorte sobre ésta usando las coordenadas del rectángulo delimitador (Bounding Box). Este recorte es el que se proporciona a la Red Neuronal Convolucional como entrada, para que trate de identificar el tipo de vehículo en movimiento (FrontCar, BackCar, FrontMotorbike, BackMotorbike, FrontTruckVan, BackTruckVan, FrontBus, BackBus). Otra de las propiedades de interés que también se calcula son los centroides de las áreas en las que se ha detectado un movimiento superior al valor umbral. Esto ha permitido implementar un sistema de conteo de vehículos, ya que podemos ubicar dichos centroides dentro de una franja delimitada en la imagen que se procesa. 2.2 Redes Neuronales Convolucionales Las Redes Neuronales Convolucionales (Convolutional Neural Networks, CNN) están ubicadas dentro de lo que se conoce como Aprendizaje Profundo (Deep Learning)27. Éstas poseen unas estructuras de rejilla, donde se ubican principalmente los pesos aprendidos de la red y que permiten obtener los mapas de características cuando se procesan los datos de entrada, imágenes en este caso. 32 Estos dos tipos de estructuras también son conocidas como tensores, los cuales tienen un volumen determinado pero variable en función de las capas de la red, por lo que poseen ancho, alto y profundidad. Se llaman convolucionales por hacer uso de la operación de convolución, ésta se aborda desde el punto de vista de las redes neuronales, que no se corresponde con el mismo concepto en matemáticas o en la teoría de procesamiento de señales. En este proyecto se ha optado por utilizar AlexNet9, ya que ésta hace uso de una arquitectura secuencial, más simple que otras CNN como GoogleNet. Se trata de un modelo cuya arquitectura se muestra en la figura 2.4, lo conforman 25 capas. Figura 2.4 Arquitectura de la Red Neuronal Convolucional AlexNet. Este modelo está pre-entrenado, lo que permite aprovechar su contenido para llevar a cabo un proceso de re-entrenamiento con los datos de los vehículos específicos de nuestra aplicación. Para ello han rediseñado las capas 23 y 25 (Fully Connected y Classification) de forma que ambas cuenten con tantas neuronas como clases tiene el problema de clasificación de vehículos, sustituyendo así las 1000 clases de imágenes de la red original. Esta técnica es lo que se conoce como “transferencia de aprendizaje”13 y permite reutilizar los núcleos convolucionales de la CNN AlexNet original para re-adaptarlos al problema de clasificación de vehículos en lugar de tener que entrenar la red desde cero para obtenerlos, lo cual es más costoso y requiere de mucho tiempo de cómputo. Los recortes sobre la imagen original, obtenidos según se explica durante el proceso de detección y segmentación de imágenes, descrito previamente, constituyen las entradas a la red, que en el caso del modelo AlexNet necesita un redimensionado a 227 x 227 píxeles en las dimensiones ancho y alto, independientemente del tamaño del recorte. Esto es así debido a los requisitos del propio diseño de esta red. 33 A continuación se explican las capas que componen el modelo de la Red Neuronal Convolucional AlexNet y las operaciones involucradas en cada una de ellas. Éstas son básicamente: convolución (conv), ReLU (relu), pooling (pool), normalización (norm), fully connected (fc) o capa totalmente conectada, y softmax. En la figura 2.4 se muestran las distintas capas de este modelo, identificadas por su tipo y un número identificativo. Por otra parte, a través de las relaciones 5 y 6, tal y como están definidas en este modelo y que podemos ver en la figura 2.4, se determinan las dimensiones de cada bloque, o mapa de características de cada capa, a partir de las dimensiones del bloque precedente y de las operaciones aplicadas. Las relaciones son las siguientes: Para cada i (dimensión de entrada), k (tamaño del núcleo del filtro de convolución), s > 1 (pasos de desplazamiento del núcleo) y p = 0 (padding, añadido de ceros en las filas y columnas externas). La salida o, se obtiene como sigue: Relación 5: 𝑜=[𝑖− 𝑘]/𝑠 +1 ; Relación 6: 𝑜=[𝑖−2𝑝−𝑘]/𝑠+1 A modo de ejemplo en la primera capa se aplica un núcleo de convolución de tamaño 11x11, por lo que k = 11, para una entrada (imagen) de tamaño 227 x 227 y por tanto i = 227, con s = 4 y p = 0, para obtener como salida o = 55, por aplicación de la Relación 5. 2.2.1 Capas del modelo AlexNet a) Capa Convolution Convolución en el ámbito del procesamiento de señales: Para entender de forma más intuitiva lo que implica la operación de convolución se parte de un ejemplo ilustrativo (Romero-Pérez, J. 2019)8. Supongamos que tenemos una fuente de luz variable cuya intensidad es percibida por un sensor fotoeléctrico, éste genera una salida en un instante de tiempo 𝒕, es decir 𝑥(𝑡), siendo tanto 𝒕 como 𝑥(𝑡) números reales. Debido a las variaciones de la fuente de luz, se pueden obtener diferentes lecturas en distintos instantes de tiempo, además la captura de la señal puede estar contaminada por ciertos ruidos de distinta procedencia. Por lo que para obtener una señal más limpia calcularemos el promedio de las salidas obtenidas a lo largo del tiempo. 34 Se realiza una ponderación dando más relevancia a las lecturas más recientes que a aquellas más distantes en el tiempo, ésto se consigue mediante la función 𝑤(𝑎), donde a representa lo que la medición se ha alejado en el tiempo. La realización de este promedio ponderado en cada instante de tiempo puede expresarse como una nueva función como la proporcionada en la ecuación (2.7). 𝑠(𝑡)=∫ 𝑥(𝑎) 𝑤(𝑡− 𝑎) 𝑑𝑎 (2.7) Esta operación se denomina convolución y se suele representar como en (2.8). 𝑠(𝑡)=∫(𝑥∗ 𝑤)(𝑡) 𝑑𝑡 (2.8) Hay que puntualizar que 𝒘 ha de ser una función de densidad de probabilidad para asegurar que la salida esté promediada y que devuelva cero cuando su valor de entrada sea negativo, con esto último evitamos la toma de valores en instantes de tiempo futuros, algo que no es posible. Convolución en el ámbito de las Redes Neuronales Convolucionales: Desde un punto de de vista computacional se trabaja con variables discretas, es decir, sólamente con valores enteros, por lo que se define la convolución discreta dada por la ecuación (2.9). 𝑠(𝑡)=(𝑥∗𝑤)(𝑡)= ∑ 𝑥(𝑎) 𝑤(𝑡− 𝑎) ∞ 𝑎=−∞ (2.9) En el ámbito de las CNN a la variable 𝒙 se la conoce como entrada (input), a 𝒘 se la conoce como núcleo de convolución (convolution kernel) y a la salida 𝒔 se le da el nombre de mapa de características (feature map). La entrada es un vector o una matriz de una o más dimensiones que contiene datos. El núcleo convolucional por lo general también es un vector o matriz de una o varias dimensiones, solo que este último alberga los valores de una serie de parámetros que serán ajustados durante el proceso de entrenamiento. Estas estructuras multidimensionales reciben el nombre de tensores y sus elementos se almacenan por separado, cualquier valor que no pertenezca a una de estas dos estructuras se considera nulo, por lo que esta operación se traduce en una suma finita de valores para un número finito de elementos. En este ámbito las convoluciones se realizan sobre más de un eje a la vez, ya que se trabaja sobre una imagen bidimensional 𝑰 que actúa como entrada, ésta será tratada por otra estructura bidimensional 𝑲, un núcleo convolucional, como vemos en (2.10). 35 𝑆(𝑖,𝑗)=(𝐼∗𝐾)(𝑖,𝑗)=∑∑𝐼(𝑚,𝑛) 𝐾(𝑖−𝑚,𝑗− 𝑛) 𝑛 𝑚 (2.10) La convolución es conmutativa por lo que podemos reescribirla como en (2.11), esta forma resulta en una menor variación en los valores de m y n, lo que la haría más eficiente en términos computacionales. 𝑆(𝑖,𝑗)=(𝐾∗𝐼)(𝑖,𝑗)=∑∑𝐼(𝑖− 𝑚,𝑗−𝑛) 𝐾(𝑚,𝑛) 𝑛 𝑚 (2.11) La conmutación se interpreta como la reflexión del núcleo respecto de la entrada. Otra concepción matemática que también se utiliza mucho debido a su sencillez y que suele confundirse con la convolución es la correlación cruzada (2.12), la cual tiene un efecto muy parecido a la operación de convolución. 𝑆(𝑖,𝑗)=(𝐾∗𝐼)(𝑖,𝑗)=∑∑𝐼(𝑖+ 𝑚,𝑗+𝑛) 𝐾(𝑚,𝑛) 𝑛 𝑚 (2.12) A continuación podemos ver en la figura (2.5) un ejemplo de correlación cruzada. Figura 2.5 Ejemplo de aplicar correlación cruzada a la imagen I, con el núcleo K, obteniendo C. b) Capa Pooling Esta capa sirve para obtener una nueva representación aproximadamente invariante a partir de pequeñas traslaciones de la entrada (Romero-Pérez, J. 2019)8. Existen dos tipos de operaciones de agrupación (Zhou y Chellapa, 1988)5: a) Máximo (Max-Pooling), consiste en dividir la imagen de entrada en varias ventanas, sin solapamiento entre ellas, produciendo como salida el máximo de cada ventana. 36 b) Media (Average-Pooling), divide la imagen de entrada en diversas ventanas, sin solapamiento, produciendo como salida la media de cada una de ellas. Esta operación ha demostrado que si se aplica una pequeña traslación a la imagen de entrada los valores de muchas salidas sobre las que se ha aplicado el pooling no cambian, esto se interpreta como que alguna función se repite sobre subconjuntos (ventanas) de la imagen de entrada (Romero-Pérez, J. 2019)8, lo cual es útil ya que por ejemplo si se realiza pooling sobre la salida de la convolución de una imagen es posible aprender qué transformaciones son invariantes para una misma imagen de entrada . La operación de pooling se usa para identificar si alguna característica está presente en la imagen de entrada. En la figura 2.8 se muestra un ejemplo práctico de cómo una imagen binaria puede dividirse en varias ventanas de igual cantidad de píxeles. Figura 2.8 Imagen binaria y debajo de esta, ventanas de 3x3 sobre sus distintas regiones. Aplicando sobre las ventanas las dos operaciones de pooling anteriores obtenemos los resultados de la figura 2.9 Figura 2.9 Resultado matemático y visual de aplicar Max-pooling y Average-Pooling. 37 c) Capa Dropout Un problema muy típico de las redes neuronales es el “overfitting” (sobreajuste). En las CNN se ajustan un número elevado de pesos en varias neuronas, la cuestión es cómo realizar el mejor ajuste posible de éstos. Hay varias propuestas para abordar este problema, como por ejemplo generar un modelo que pase por todos los puntos mediante el uso de un polinomio de alto grado o la generación de un modelo lineal que se ajuste lo mejor posible a todos los puntos (Romero-Pérez, J. 2019)8. La figura 2.10 muestra de forma ilustrativa los problemas de cada enfoque. En el modelo lineal el ajuste a los datos no es suficientemente bueno (underfitting), mientras que en el modelo polinómico el ajuste a los datos es bueno, pero falla cuando hacemos uso de este para la realización de clasificaciones (overfitting). Figura 2.10 Problemas del ajuste lineal y el ajuste polinómico, se requiere algo intermedio. Para paliar el efecto del overfitting se propone desconectar o anular (dropout) determinado número de neuronas para prevenir que éste se produzca al ajustar los pesos (Srivastava y col., 2014)6 durante el proceso de entrenamiento. La selección de las neuronas a desconectar se realiza de forma aleatoria, de esta forma la CNN queda definida por las neuronas que sobreviven al efecto de dropout. Podemos ver un ejemplo ilustrativo de esto en la figura 2.11. Figura 2.11 Ejemplo visual de la desconexión neuronal aleatoria que produce dropout. 38 Otra estrategia que se podría usar es añadir un hiperparámetro a las neuronas, éste se usaría para asignar una probabilidad que regule la influencia de sus pesos (Romero-Pérez, J. 2019)8. d) Capa totalmente conectada (Fully Connected) Todas las neuronas de esta capa reciben una entrada de todas las neuronas de la capa anterior, éstas son representadas por la función mostrada en la ecuación (2.13), que sigue un modelo lineal. 𝑦 = ∑(𝑥𝑖∗𝑤𝑖𝑗)+ bj 𝑛𝑖 (2.13) Donde 𝒙𝒊 representa el valor de una característica obtenida en una capa anterior, 𝒘𝒊𝒋 es el peso o la importancia que se le concede al valor obtenido de la neurona 𝒊 de la capa anterior en la neurona actual 𝒋, la constante 𝐛 es lo que se conoce como “bias” o umbral de disparo y sirve para controlar si la neurona debe activarse (Brío y SanzMolina, 2006)7. El objetivo de las neuronas en estas capas es la de aplicar funciones lógicas (AND, OR, NOT, etc) sobre las características de la entrada que le son pasadas para así lograr la extracción de características a distintos niveles. La capa de entrada busca obtener las características primarias de una imagen, como los bordes. En las capas ocultas se obtienen características de otros rasgos tales como los contornos, y finalmente la capa de salida está orientada a describir el objeto de forma general. En el modelo de Red Neuronal Convolucional AlexNet9 se dispone de tres de estas capas puestas de forma casi consecutiva ya que necesitan ser seguidas inmediatamente por una capa de tipo función de activación que aplique una modificación no lineal a la salida de la neurona, ya que de lo contrario, estas capas colapsarían y serían equivalentes a una única neurona, lo que sería desastroso, pues con una única neurona no se puede realizar el suficiente número de operaciones lógicas como para poder definir una imagen. e) Capa ReLU (Rectified Linear Unit) Las funciones de activación son utilizadas para indicar de forma matemática el grado en que se posee una característica, muy presente o poco presente. Una de las funciones de activación más clásica es la función sigmoide, ésta se define matemáticamente como se indica en la ecuación (2.14) cuya representación gráfica se muestra en la figura 2.6. 39 𝑓(𝑎,𝑥,𝑐) = 1 1 +𝑒−𝑎(𝑥−𝑐) (2.14) La función sigmoide proyecta, para todo valor real de su entrada, un valor de salida en el intervalo [0,1], si bien posee dos problemas: 1. La rápida saturación del gradiente. El valor de la función de activación tiende a los extremos, mayoritariamente a 0, lo que afecta al ajuste de los pesos. 2. La contínua obtención de pesos positivos, ya que el valor medio no es 0. Otra función de activación que también es muy utilizada es la tangente hiperbólica (tanh), cuyas salidas son números reales en el rango [−1,+1]. Esta función es una variante de la función sigmoide, ya que esta se incluye en su definición, la cual se describe como: 𝑡𝑎𝑛ℎ(𝑥)=2∗𝑠𝑖𝑔𝑚𝑜𝑖𝑑(2𝑥)−1. También presenta el problema de la saturación del gradiente. Figura 2.6 Función sigmoide a la izquierda, función tangente hiperbólica a la derecha. Actualmente, la función que más se usa en este ámbito es a función ReLU (Rectified Linear Unit), definida como 𝑓(𝑥)=𝑚𝑎𝑥(0,𝑥) y representada en la figura 2.7. Las ventajas de esta función son (Romero-Pérez, J. 2019)8: a) Gradiente no saturado para cualquier valor positivo. b) Es computacionalmente simple. Las desventajas de la función ReLU, proviene del hecho de que si todos los datos que pasan por esta capa resultan con valor cero debido a la configuración de los pesos de una neurona anterior, entonces esta neurona resulta ser un problema, ya que al intentar aplicar el método del descenso del gradiente, se obtiene un gradiente nulo, lo que no permite realizar ajustes en los pesos hacia atrás durante la aplicación del algoritmo de retropropagación. Cuando esto le ocurre a una neurona ReLU se dice que ésta está muerta. Para evitar esta situación se puede usar la función Leaky ReLU (ReLU con fugas), definida como: 𝑓(𝑥)=𝑚𝑎𝑥(0.001𝑥,𝑥). 40 Figura 2.7 Gráficas de ejemplo, función ReLU a la izquierda y función Leaky Relu a la derecha. f) Capa Normalization El objetivo de esta capa es la de normalizar la salida de la capa ReLU para mejorar la convergencia hacia el error mínimo durante el entrenamiento. Para lograrlo aplica una normalización de valores a nivel de canal en el mapa de características. Por lo general, la normalización ajusta los valores de los canales al intervalo [0,1] o [-1,1]. Esto es importante ya que hay casos en los que las neuronas reciben valores muy grandes, y al mismo tiempo otros demasiado pequeños, lo que resulta perjudicial pues los valores demasiado grandes influyen demasiado sobre el resultado que se va a obtener mientras que los valores pequeños prácticamente no tienen ningún efecto sobre éste. g) Capa Softmax La función softmax o función exponencial normalizada aparece por lo general en las últimas capas ocultas de una Red Neuronal Convolucional, ésta se define según la ecuación (2.15). 𝑠𝑜𝑓𝑡𝑚𝑎𝑥(𝑥)𝑖=𝑒𝑥𝑝(𝑥𝑖) ∑𝑒𝑥𝑝(𝑥𝑗) 𝑛 𝑗=1 ∀ i = 1 … 𝑛 ; 𝒙𝒋 = (𝑥1,… ,𝑥𝑛) ∈ℝn (2.15) Esta función se aplica a cada elemento 𝒙𝒋 de un vector de entrada n-dimensional 𝒙, normalizando los valores de éste en el rango [0,1] mediante la aplicación de la función exponencial y dividiendo entre la suma de las exponenciales. Se genera de esta forma un nuevo vector n-dimensional 𝑠𝑜𝑓𝑡𝑚𝑎𝑥(𝑥)𝑖 cuya suma de elementos es 1, pudiendo interpretarse este hecho de tal forma que la suma de todos los grados de pertenencia de una imagen a todas las clases del problema de clasificación ha de ser exactamente 1. 47 ● Command: Este patrón permite solicitar una operación a un objeto sin conocer realmente el contenido de esta operación, ni el receptor real de la misma.29 ● Context: Es un patrón que nos ayuda a encapsular los eventos producidos por las vistas y los datos para ejecutar los comandos.28 ● Factory: Consiste en utilizar una clase dedicada a la construcción de objetos del mismo tipo.29 ● Dispatcher View: Este patrón permite crear un objeto que se encarga únicamente de recibir un evento y redirigir a la vista correspondiente.28 ● Application Controller: Gestiona los eventos producidos en las interfaces.28 ● Application Service: Implementa la lógica del sistema.28 La capa de presentación se muestra en el diagrama de clases de la Figura 3.3. El proceso se realiza de la siguiente manera: 1. Ante cualquier acción en la interfaz, se crea un objeto contexto, que contiene el evento (acción a realizar) y el transfer (datos necesarios para realizar la acción), enviándole así ambos al controlador. 2. El controlador gestiona los eventos como sigue: ○ Se crea el comando correspondiente mediante la factoría de comandos. Por ejemplo, si el evento es executeCarDetection, se crea el comando CommandCarDetection. ○ Se ejecuta el comando creado con los datos del contexto. ○ El comando devuelve un contexto y el controlador se encarga de dárselo al Dispatcher, para que éste genere la vista. 3. El Dispatcher redirige a la vista correspondiente y ésta se actualiza para mostrar la información resultante. 48 Figura 3.3 Diagrama de clases de la capa de presentación. La capa de negocio está representada por el diagrama de clases de la Figura 3.4. El proceso se realiza de la siguiente manera: 1. El comando usa la clase ASFactory que se encarga de gestionar la creación de los diferentes servicios de aplicación. 2. Se ejecuta la función del servicio de aplicación correspondiente con el comando a realizar. Por ejemplo el comando CommandCarDetection ejecutará la función detection de ASSmartCities. 3. El resultado de la ejecución se devolverá al controlador. 49 Figura 3.4 Diagrama de clases de la capa de negocio. Para cada una de las funcionalidades siguientes se describe el flujo de la aplicación, considerando las funcionalidades descritas en las figuras 3.3 y 3.4: ● Añadir imágenes al set de entrenamiento: ○ La clase Learning es la interfaz en la que se pulsa el botón para abrir el set de entrenamiento. Como la funcionalidad consiste en abrir un directorio se realiza directamente desde la interfaz. ● Redimensionar imágenes: ○ La clase Learning es la interfaz en la que se pulsa el botón para redimensionar las imágenes. Se abre un selector de archivos en el que se seleccionan una o varias imágenes que se redimensionan desde la propia interfaz. 50 ● Reentrenar la CNN AlexNet: ○ La clase Learning es la interfaz en la que se pulsa el botón para reentrenar la CNN. ○ Se abre entonces la interfaz Retraining en la que seleccionan los parámetros del reentrenamiento. ○ Se envía la petición al controlador. Éste crea el comando CommandRetraining que llama a la función retraining de la clase ASSmartCities. ○ CommandRetraining y devuelve el resultado de la operación al controlador. El controlador usa el Dispatcher para devolver el resultado a la vista correspondiente, en este caso Retraining. ● Procesar los vídeos sin publicar los resultados a ThingSpeak: ○ La clase CarDetection es la interfaz en la que se pulsa el botón para leer un video y procesarlo. ○ Se envía la petición al controlador. Éste crea el comando CommandCarDetection que llama a la función detection de la clase ASSmartCities. ○ CommandCarDetection devuelve el resultado de la operación al controlador. El controlador usa el Dispatcher para a su vez devolver el resultado a la vista correspondiente, en este caso CarDetection. Más información a cerca de la arquitectura disponible en los AnexosⅠI yⅡII. 3.1.2 Lado del servidor En el lado del servidor se llevan a cabo las siguientes funcionalidades de las que aparecen en la figura 3.2: ● Publicar los resultados del procesamiento de videos en ThingSpeak. ● Realizar predicciones del flujo de tráfico ● Publicar resultados en la red social Twitter ● Consultar datos en la nube 51 En cuanto a la arquitectura del servidor decir que está basado en ThingSpeak24, con la particularidad de que facilita considerablemente el trabajo de diseño ya que se trata de una herramienta muy completa. A continuación se describe la estructuración y configuración aplicada en el servidor con dicha herramienta. ThingSpeak permite la creación de canales específicos, de forma que durante su creación es posible ajustar campos tales como, nombre del canal, breve descripción del canal, número de campos y los nombres asignados a éstos, haciendo que se pueda diseñar la arquitectura del servidor en función de las necesidades del proyecto. El orden de los campos es importante ya que son utilizados por defecto en el orden creado a la hora de insertar datos mediante procesos de escritura y hacer consultas de lectura de los datos almacenados, que son los que luego se pueden visualizar en el interfaz de la aplicación. Para ello, ThingSpeak proporciona las denominadas “api keys” que sirven para que cuando se quiera acceder a ThingSpeak en modo lectura o escritura baste con utilizar dichas claves en la llamada correspondiente desde Matlab. Estas “api keys” son generadas automáticamente por ThingSpeak en la creación del canal, pudiéndose modificar mediante la opción correspondiente. Por motivos de seguridad no se especifican las api keys en este documento, lo único indicar que es una palabra formada por números y letras con 17 caracteres. También es importante el identificador del canal “channel ID” o ID de canal, que es la clave para conectar ThingSpeak con el teléfono móvil, Figura 3.5, permitiendo visualizar el contenido del canal si está en modo público. Conviene señalar que ThingSpeak ofrece la opción de canal público o privado. El primer caso con acceso a cualquier usuario y en el segundo restringido al creador. El identificador de canal es necesario para los accesos de lectura y escritura. Dado que conocidas las claves de acceso e identificador del canal, es posible el acceso múltiple e incluso por diferentes usuarios al mismo, se hace necesario el control de los accesos concurrentes en escritura para evitar posibles fallos de actualización de datos y sincronización cuando se intenta escribir al mismo tiempo. ThingSpeak controla estos casos de concurrencia obligando a que haya un intervalo de 15 segundos entre cada acceso de escritura, de forma que en el caso de que lleguen al mismo tiempo dos o más accesos de escritura o sin respetar el intervalo de 15 segundos, ThingSpeak devolverá el siguiente mensaje: "accesos de escritura demasiados frecuentes", aceptando únicamente el que llegue primero y denegando el resto. Como se ha indicado previamente, la figura 3.5 muestra la visualización de datos contenidos en el canal en los diferentes campos mostrados, utilizando la aplicación 52 ThingView instalada en el dispositivo móvil. En este caso concreto se muestran los ocho campos de un mismo canal (Field 1 a Field 8) mostrando el tipo de vehículos detectados en cada uno de ellos a lo largo del tiempo, cuya descripción y configuración se describe posteriormente. Por ejemplo, en el diagrama Field 1 aparece el número de coches vistos por delante y detectados como tal por la aplicación, esto es por la Red Neuronal Convolucional, en distintos momentos del mes de Abril de 2020, según aparece en el eje horizontal. En el resto de gráficos aparecen representadas las detecciones de otros tipos de vehículos, también con indicación del momento de su detección en el tiempo. Figura 3.5 Imagen de cómo se ve el canal de ThingSpeak que contabiliza los diferentes tipos de vehículos en la aplicación para móviles ThingShow. 3.1.2.1 Canal de detección de vehículos El canal de detección de vehículos, tiene por título “SmartCities”, siendo configurado con los ocho campos que permite como máximo la licencia de ThingSpeak24. 53 Cada uno de los campos identifica el tipo de vehículo detectado, guardando dentro del campo el número de vehículos detectados de esa categoría durante la fase de clasificación llevada a cabo por la CNN. La Figura 3.2 muestra la definición y estructuración del canal con los campos siguientes: ● Campo 1 - Front Car (coches por delante). ● Campo 2 - Back Car (coches por detrás) ● Campo 3 - Front Truck (camiones por delante) ● Campo 4 - Back Truck (camiones por detrás) ● Campo 5 - Front Motorbike (motos por delante) ● Campo 6 - Back Motorbike (motos por detrás) ● Campo 7 - Front Bus (buses por delante) ● Campo 8 - Back Bus (buses por detrás) Figura 3.6 Visualización de las opciones de configuración del canal de ThingSpeak. 54 A través del enlace SmartCities se puede acceder a la versión web del canal de ThingSpeak24, donde se encuentran almacenados todos los datos referentes al conteo de los diferentes tipos de vehículos, tal y como como se puede observar en la Figura 3.6. El identificador de este canal de ThingSpeak es “986255”. Figura 3.7 Visualización gráfica de los diferentes campos del canal de ThingSpeak. ThingSpeak proporciona Apps específicas para su interconexión con otras plataformas. En el diseño propuesto se conecta a una cuenta de Twitter, de forma que ésta lance avisos del número de vehículos de un determinado tipo que son almacenados cada vez que se complete el análisis de un video. Para ello se hace uso de la app ThingTweet, que conecta la cuenta de Twitter con el canal de ThingSpeak y una segunda app de tipo React que sirve para explorar los valores de todos los campos y enviar el tweet correspondiente cada vez que se actualice un determinado valor de campo en el canal de ThingSpeak correspondiente. El enlace a la cuenta de Twitter utilizada para lanzar los avisos es Cuenta Twitter, donde se puede ver cómo se muestran los mensajes. 3.1.2.2 Canales de predicción Para la tarea de predicción del flujo de vehículos se cuenta con tres canales de ThingSpeak. En el primero se almacenan los datos parseados del DataSet del Ayuntamiento de Madrid15. Se tienen datos desde enero del 2017 hasta febrero de 2020 (no se han considerado los meses de Marzo y Abril dada la situación anómala en cuanto al flujo de vehículos por las restricciones derivadas de COVID-19, ya que 55 alterarían los valores de predicción en situaciones normales). Este primer canal consta de los siete campos que se muestran en la figura 3.7 de forma que sobre el eje horizontal se muestra el día del mes correspondiente al día de la semana, que aparece sobre el eje vertical. ● Campo 1 - Lunes ● Campo 2 - Martes ● Campo 3 - Miércoles ● Campo 4 - Jueves ● Campo 5 - Viernes ● Campo 6 - Sábado ● Campo 7 - Domingo Figura 3.7: Representación gráfica del conteo de vehículos. En el segundo de los canales de predicción se almacenan los datos de entrada para realizar la predicción propiamente dicha. Para hacer el cálculo se necesita el día de la semana y el número de predicciones que se quieren obtener. El cálculo se realiza en el servidor, usando la funcionalidad de MATLAB Analysis. 56 Como no se puede comunicar directamente la aplicación con MATLAB Analysis, lo que se hace desde el punto de vista del diseño es guardar en un campo cada parámetro de entrada, de forma que al detectar una nueva entrada en el canal, automáticamente se lanza la función que realiza la predicción. Esta función lee los datos recién introducidos desde la aplicación y realiza la predicción. El canal está configurado con los dos campos siguientes: ● Campo 1: Horizonte - Indica el número de días que se quieren predecir. ● Campo 2: Día de la semana - Indica el día de la semana sobre el que se realiza la predicción. La figura 3.8 muestra sendas representaciones gráficas del contenido de los dos campos anteriores, de forma que en la parte izquierda aparece el resultado de la predicción según el horizonte indicado mediante el modelo AR y en el eje X aparece el número de vehículos predichos según el día del mes. En la parte derecha aparece un gráfico con indicación del campo 2, que no puede representarse por ser los datos de tipo texto. Figura 3.8 Representación gráfica de los campos del canal modelo AR. Por ejemplo si se introduce un 10 como horizonte y sábado como día de la semana, se obtienen datos de los próximos 10 sábados comenzando desde el último sábado del que se tienen datos reales. En el tercer canal de predicción se almacena el resultado de la predicción realizada. Tiene los siguientes siete campos, cuya visualización se muestra gráficamente en la figura 3.9 con la misma interpretación que en el caso anterior. ● Campo 1 - Lunes ● Campo 2 - Martes 63 Figura 4.2 Interfaz del menú Learning. 4.1.1.1 Retraining Al pulsar en el botón Retraining de la Figura 4.2 aparece una ventana como la mostrada en la Figura 4.3 a la izquierda, de forma que en la parte superior contiene una pestaña para acceder al menú mostrado en la misma figura de la derecha. Ambas permiten seleccionar los parámetros que tendrá el entrenamiento. Figura 4.3 Interfaces del menú de Retraining. 4.1.2 Car Detection Al pulsar en el botón Car Detection de la Figura 4.1 aparece una ventana como la mostrada en la Figura 4.4, con los siguientes elementos: 64 ● En el panel izquierdo se muestra el video frame a frame con las etiquetas de identificación de los vehículos detectados. ● En el panel superior derecho aparecen las imágenes en las que se ha detectado movimiento. ● En el panel inferior derecho se muestra el resultado de la matriz de detección. ● En el panel de botones inferior se permite seleccionar el vídeo y detener la ejecución del vídeo actual. Figura 4.4 Interfaz de Car Detection. 4.1.3 ThingSpeak Al pulsar sobre el botón ThingSpeak24 de la Figura 4.1 aparece el menú representado por la Figura 4.5, con las siguientes opciones: ● Queries: Permite lanzar consultas al canal para la realización de comparativas y estadísticas. ● ThingSpeak Web: Acceso directo a la web del canal de ThingSpeak en el que se guardan los datos de los contadores de vehículos detectados por la aplicación. 65 Figura 4.5 Interfaz de ThingSpeak. 4.1.3.1 Queries de ThingSpeak Al pulsar en el botón Queries de la Figura 4.6 aparece el menú representado por la Figura 4.7, con los siguientes elementos: ● En el panel superior izquierdo se seleccionan las fechas entre las que se quiere realizar la consulta. ● En el panel inferior izquierdo se seleccionan los tipos de vehículos que se quieren buscar. ● En el panel superior derecho se muestra una tabla con el resultado de la consulta realizada. ● En el panel inferior derecho se muestra una representación gráfica mostrando los datos consultados. 66 Figura 4.6 Interfaz de Queries de ThingSpeak. 4.1.4 Forecast Al pulsar sobre el botón Forecast de la Figura 4.1 aparece el menú mostrado en la Figura 4.7, con los siguientes elementos: ● En el panel superior izquierdo se selecciona el día de la semana y cuántos días se quieren predecir. ● En el panel superior derecho se muestra una tabla con el resultado de la predicción realizada. ● En el panel inferior se muestra una representación gráfica usando los datos predichos. 67 Figura 4.7 Interfaz de Forecast. 4.2 Visión por computador A continuación se describen los resultados obtenidos al aplicar los métodos teóricos para la detección del movimiento en imágenes, la extracción de dichas regiones y la identificación de los diferentes vehículos. 4.2.1 Detección de movimiento La primera acción que se realiza en este sistema inteligente es el cálculo del flujo óptico, es decir, para todo píxel de una imagen, se calcula un vector que indica la dirección y el sentido en el que se mueve un objeto determinado dentro de un frame de vídeo. Podemos ver un ejemplo de la realización de este proceso a través de la figura 4.8. Figura 4.8 Representación del flujo óptico en una imagen de tráfico. 68 Como se observa en líneas generales, la detección del movimiento es muy fiel a lo que cabría esperar, pues refleja correctamente la dirección y el sentido de la marcha de los objetos (vehículos) en movimiento. Un problema que cabe mencionar con respecto a este proceso es que, a nivel de efectividad, los métodos para el cálculo del flujo óptico de Farneback10 o LucasKanade4 no se ejecutan lo suficientemente rápido bajo el ecosistema de MATLAB, ya que éste emplea un lenguaje de programación interpretado, lo que hace que la ejecución del programa se ralentice durante el procesamiento de los frames. 4.2.2 Proceso de binarización Una vez se ha identificado la magnitud de movimiento detectado en una imagen, tal y como se muestra en la figura 4.9, el sistema tendrá que identificar en qué ubicación del frame de vídeo se ha detectado este movimiento. El primer paso para conseguir este objetivo es aislar la zona de movimiento, para ello se procede a binarizar esta imagen. Figura 4.9 Ejemplo del cómputo del flujo óptico previo al proceso de binarización. Recordemos que el proceso de binarización es un proceso que genera una nueva imagen en blanco y negro a partir de una imagen en color. Para generarla se recorren todos los píxeles de la imagen original. Cuando uno de ellos cumpla que la magnitud del flujo óptico en dicho punto sea superior a la suma de la media del flujo de todo el frame y la desviación típica de éste, lo que se conoce como valor umbral, tal y como se ha descrito previamente, entonces a dicha región se le asigna el valor lógico uno (blanco). En caso contrario, a dicho píxel se le asignaría el valor lógico cero (negro). La figura 4.10 muestra un ejemplo de este proceso a partir de la imagen mostrada en la figura 4.9, sobre la que se detectó el flujo óptico. 69 Figura 4.10 Resultado del proceso de binarización aplicado a la figura 4.9. 4.2.3 Proceso de segmentación En este punto, a partir de la imagen binaria se procede al etiquetado de las componentes conexas, con el fin de detectar el número de objetos en movimiento y otras propiedades como su área, centroide y Bounding Box. Para ello se utiliza el algoritmo de etiquetado de componentes conexas de Haralick y Shapiro (1992)3 descrito en la sección 2.1.2. Cada región recibe una etiqueta numérica, cuya representación en etiquetas de color se muestra en la figura 4.11, como un ejemplo. Figura 4.11 Segmentación de las regiones de la figura 4.10. 4.2.4 Clasificación del flujo de tráfico Ahora que se han obtenido todas las regiones candidatas a representar un vehículo en movimiento, se extraen una serie de propiedades de éstas, una muy importante es su ubicación y su tamaño (Bounding Box). Esta propiedad nos permitirá extraer la imagen del frame de vídeo mediante la realización de un recorte para poder pasar la 70 imagen al modelo AlexNet9, así este determinará si efectivamente la imagen que le ha sido pasada como entrada es un vehículo o si bien esta debe de ser descartada. La figura 4.12 muestra un ejemplo de como AlexNet ha clasificado varios vehículos y los ha enmarcado dentro de su área limítrofe. Figura 4.12 Ejemplo de clasificación de vehículos y enmarcado dentro de su Bounding Box. Los resultados obtenidos en la clasificación del flujo de tráfico también entrañan una serie de problemas, éstos se deben a que se ha partido del cálculo del flujo óptico para el reconocimiento de vehículos. Uno de los problemas más notables es lo que hemos denominado “el problema de la sombra”, ya que si un objeto proyecta una sombra, ésta se mueve en la misma dirección que el objeto en movimiento y a la misma velocidad. Esto es perjudicial, ya que en el cómputo del flujo óptico no se aplica ningún método para distinguir que las cantidades de movimiento detectadas no son un mismo objeto en movimiento, lo que hará que en procesos posteriores ya no se pueda distinguir qué parte pertenece a la sombra y qué parte pertenece al objeto que se encuentra en movimiento. Finalmente se observó que “el problema de la sombra” se generaliza para concluir que en cualquier situación en la que se detecten dos o más objetos en movimiento que se encuentren muy próximos entre sí, tras el cómputo del flujo óptico se hace imposible la distinción individual de éstos. En la figura 4.13 podemos ver dos ejemplos ilustrativos, observándose cómo aparece un solapamiento de dos vehículos y uno sólo, en ambos casos con sus “sombras” asociadas, que hacen que el rectángulo delimitador rebase a los objetos a los que debería representar. Esto conduce a la posibilidad de que la Red Neuronal Convolucional cometa errores de detección, lo que hará que posteriormente también falle el sistema de de cómputo de vehículos para el cálculo del flujo de tráfico, ya que se contabiliza un único vehículo en lugar de los dos. 71 Figura 4.13 Problema de la segmentación regiones a partir de del cálculo del flujo óptico. Otro de los problemas detectados es la sensibilidad del método del gradiente para el cálculo del flujo óptico. Este problema proviene del hecho de que si entre dos frames de vídeo consecutivos se produce un ruido en la imagen debido al movimiento del dispositivo digital que graba el flujo de transporte, éste se detecta como si realmente se hubiera producido un movimiento real. Por lo que en este caso la detección y ubicación de los vehículos es muy propensa a fallos e incluso se puede llegar a identificar erróneamente la categoría de una imagen o, lo que es peor, es posible que no se reconozca ninguna característica del vehículo debido a la cantidad de ruido presente. Podemos ver un ejemplo de esta situación en la figura 4.14. Figura 4.14 Problema de la sensibilidad del cálculo del gradiente del flujo óptico. 4.2.5 Cómputo del flujo del tráfico Para la implantación de un sistema de cómputo del flujo de tráfico se ha optado por fijar sobre la imagen una franja imaginaria, de forma que cuando los centroides de las regiones asociadas a imágenes que han sido clasificadas como vehículos en movimiento por la Red Neuronal Convolucional, se encuentren dentro de esta franja, se contabilice el paso de un vehículo. En la figura 4.15 se muestra una representación de la franja posicionada sobre una localización fija, para contabilizar los coches que pasan por una autopista. 72 Figura 4.15 Posicionamiento de una franja de conteo que actúa como un dispositivo sensor. La franja se ha ubicado sobre la imagen considerando lo siguiente: 1) Cuanto más cerca está un vehículo de la parte inferior de la imagen, y por tanto del dispositivo de captura, mayor es su tamaño, lo que tal vez provoque que el vehículo sea contabilizado más de una vez. 2) Algo parecido ocurre en la parte superior de la imagen, debido al reducido tamaño de los vehículos en esta zona. El hecho de seguir estas directrices permitió minimizar parte del error por defecto y por exceso del conteo del flujo. A continuación se muestran dos ejemplos ilustrativos de los resultados obtenidos a partir de vídeos reales de tránsito del tráfico. Éstos fueron tomados manualmente en la autopista del nordeste de Madrid (A-2) en el tramo que pasa por Canillejas. En la figura 4.16 (Vídeo 1) se muestra una gráfica con los resultados obtenidos en relación a la detección de vehículos. En el eje horizontal se muestra el número de aciertos y fallos totales, mientras que en el vertical el tipo de vehículo detectado. La interpretación de la misma es como sigue: para cada uno de los vehículos en tránsito el sistema lo detecta, de forma que la observación a través del experto humano determina si se trata de un acierto o fallo. A continuación se describe el análisis de los errores cometidos en este primer vídeo:  El 42% de los fallos se deben a que el modelo AlexNet9 no fué capaz de clasificar correctamente la imagen que se le pasó como entrada a partir de un recorte del frame de vídeo. Esto se debió a que algunas clases son a veces confundidas con otras, como por ejemplo BackTruckVan con BackCar o bien al revés.  Un 33% de los fallos cometidos por el sistema en el procesamiento de este vídeo se debió a que se contabilizó más de una vez un vehículo al quedar su vector centroide atrapado más de un instante de tiempo en la franja de conteo. 79 4.3.2 Clasificación post-entrenamiento Para profundizar en el análisis y con carácter más general que el realizado durante el entrenamiento, se procede a volver a clasificar todas las imágenes que componen el conjunto de imágenes disponibles, es decir, tanto las que fueron seleccionadas para el proceso entrenamiento, como las que fueron seleccionadas para el proceso de validación, aún conscientes de que en los procesos de aprendizaje no es habitual probar la red con las mismas imágenes utilizadas durante el entrenamiento. Todos los resultados obtenidos se anotan, indicando cuántas predicciones fueron correctas e incorrectas con respecto de cada clase, también se contabilizará el total de aciertos y fallos obtenidos con respecto al total de imágenes de cada clase. Esta información se muestra en forma de matriz y sirve para identificar de forma más clara qué clases necesitan una mayor cantidad de imágenes para que la red pueda aprender a generalizar sus características. Esta matriz se muestra en la figura 4.21 y es conocida como matriz de confusión12. Figura 4.21 Matriz de confusión representando la eficacia del proceso de entrenamiento. Como se puede observar, esta matriz es cuadrada (clases x clases), y cada fila representa la clase real a la que pertenece un objeto determinado, mientras que las distintas columnas de dicha fila indican las distintas clases en las que la red puede clasificarlo. Por lo tanto, los números de la diagonal principal se han de interpretar como el total de imágenes o vehículos que han sido correctamente clasificados para una categoría concreta. En este caso, como cada clase posee un máximo de 100 80 imágenes, éste es el acierto máximo que la Red Neuronal Convolucional puede tener con respecto al total de imágenes de una categoría. Para una mejor interpretación de la figura 4.21, diremos que la cuarta línea de la matriz representa la clase BackMotorbike. Partiendo de aquí se puede reconocer que el elemento de esta línea, que coincide con la diagonal principal, es el número de motos vistas por detrás que se han clasificado correctamente sobre un total de 100 motos vistas desde atrás, en este caso, se tendría un 77% de aciertos para esta clase. El resto de elementos numéricos ubicados en esa misma fila son predicciones incorrectas con respecto a esta clase, por ejemplo, en 20 ocasiones se ha confundido esta imagen como si fuera un una moto por delante, e incluso en otras 3 ocasiones como si fuera un coche por detrás. Se concluye pues, que esta matriz proporciona una ayuda de cara al análisis de los resultados del entrenamiento, de forma que es posible determinar qué clases necesitan un mayor número de imágenes para que el modelo AlexNet pueda generalizar el conocimiento que tiene sobre ellas y así evitar caer en el problema del sobreajuste (overfitting). 4.4 Procesamiento y predicción en ThingSpeak La herramienta ThingSpeak24 ha sido de gran utilidad para la realización de la aplicación, ya que ha facilitado el manejo de los datos en un servidor en la nube, generados por el análisis de los diferentes tipos de vehículos, estando disponible para cualquier integrante del equipo y pudiendo facilitar su consulta de una forma rápida y sencilla, mostrando todos los datos recopilados en gráficas para una mejor visualización y entendimiento de los mismos. También proporciona un control de la concurrencia que ayuda a que el servidor gestione las peticiones de escritura de los datos que le llegan en varias peticiones al mismo tiempo. Decir que ThingSpeak proporciona diferentes apps para conectar el canal a otros sitios web, por ejemplo, permite conectar el canal a una cuenta de Twitter para poder monitorear cuándo se producen escrituras en el canal de ThingSpeak seleccionado y poder interactuar con los usuarios de la red social, haciendo uso de IoT. Los datos utilizados en los experimentos con fines de predicción provienen del repositorio de Tráfico de la comunidad de Madrid, un histórico de datos del tráfico desde 2013 hasta 2020. Concretamente se ha realizado un conteo de los vehículos que pasan entre las las 16:00hs y las 18:00hs por un mismo punto kilométrico de la carretera de circunvalación M30 en Madrid. 81 4.4.1 Resultados obtenidos En la figura 4.22 se muestran los resultados de las predicciones realizadas para los siguientes días: ● Lunes: Se realizó una predicción de los 5 lunes posteriores al día 24 de Febrero de 2020. Con resultados variando entre 22800 y 21200 vehículos. ● Martes: Se realizó una predicción de los 10 martes posteriores al 25 de Febrero de 2020. Se obtuvieron resultados ligeramente decrecientes variando entre 22700 y 22200 vehículos. ● Miércoles: Se realizó una predicción de los 15 miércoles posteriores al 26 de Febrero de 2020. Los resultados muestran un decrecimiento inicial desde 24100 hasta 22900, con un posterior crecimiento hasta los 23200 y finalmente un decrecimiento hasta los 22100 vehículos. ● Jueves: Se realizó una predicción de los 9 jueves posteriores al 27 de Febrero de 2020. Los resultados en general son decrecientes, desde 23900 hasta 23200. Figura 4.22 Representación resultados de predicción de lunes – jueves. 82 En la figura 4.23 se muestran los resultados de las predicciones realizadas para los días que se indican a continuación: ● Viernes: Se realizaron 7 predicciones de los viernes posteriores al 28 de Febrero de 2020. Los valores obtenidos variaron entre 22700 y 21700 vehículos. ● Sábado: Se realizaron 11 predicciones de los sábados posteriores al 29 de Febrero de 2020. Los valores oscilaban entre 18500 y 17300 vehículos. ● Domingo: Se realizaron 8 predicciones de los domingos posteriores al 23 de Febrero de 2020. Los resultados obtenidos muestran una tendencia decreciente oscilando entre 18600 y 17700 automóviles. Figura 4.23 Representación resultados de predicción de viernes – domingo. Los días de la semana con menor flujo de vehículos son el sábado y el domingo con una media de 18000 vehículos, mientras que el día con mayor flujo es el jueves. El resultado más alto se corresponde con el jueves 5 de Marzo de 2020, con más de 23900 vehículos. El resultado más bajo se corresponde con el sábado 16 de Mayo de 2020 con algo más de 17350 vehículos. En el AnexoⅢIII se muestran las tablas detalladas con todos los resultados obtenidos. 83 No es posible derivar conclusiones de utilidad real informativa, dado que no se conocen al detalle las características de los datos en relación a variables asociadas con la meteorología u otros factores determinantes, no siendo el objetivo del trabajo dicho análisis, sino la integración de los modelos de predicción en la plataforma IoT para consultas externas. 4.5 Resultados del contador de vehículos de ThingSpeak A partir del análisis de resultados mostrados en la tabla del Anexo ⅣIV, se observa una gran afluencia de vehículos del tipo coche, tanto vistos por delante como por detrás, seguidos de un menor número de furgonetas y camiones, dejando en un segundo plano a las motocicletas y autobuses, con números bastante bajos. Estas cifras admiten la posibilidad de errores, ya que la CNN Alexnet falla a la hora de identificar los diferentes vehículos, pudiendo afirmar que resulta más fácil identificar vehículos del tipo coche, debido a su gran número registrado en el canal de ThingSpeak24, y que resulta más difícil visualizar el tránsito de vehículos de tipo buses ya que hay un menor número de ellos contabilizados en el canal. En las figuras figuras 4.24, 4.25, 4.26 y 4.27 se muestran las gráficas de cada tipo de vehículo contabilizado en el canal ThingSpeak. Figura 4.24 Representación resultados del conteo de tipos de vehículos de Coches por delante y por detrás. Figura 4.25 Representación resultados del conteo de tipos de vehículos de Furgonetas y Camiones por delante y por detrás. 84 Figura 4.26 Representación resultados del conteo de tipos de vehículos de Motos por delante y por detrás. Figura 4.27 Representación resultados del conteo de tipos de vehículos de Buses por delante y por detrás. En la figura 4.28 se muestra la gráfica en la que se representa de forma unificada el número de vehículos contabilizados en el canal ThingSpeak24 dedicado a tal fin. La visualización de esta gráfica es posible gracias a la aplicación desarrollada específicamente con tal finalidad en ThingSpeak, que permite realizar consultas con visualización conjunta del número de vehículos en cada uno de los días representados en el eje horizontal. Figura 4.28 Representación comparativa de todos los diferentes tipos de vehículos. ThingSpeak24 resulta ser una opción de gran utilidad, que permite mantener un registro histórico de los vehículos detectados por el sistema. De esta forma, tal y como 85 se puede visualizar y deducir a partir de la representación gráfica de la figura 4.28 y las 4.24 a 4.27, el hecho de disponer de esos datos permite poder realizar análisis de los mismos, bien con fines de predicción o para otro tipo de estudios tales como por ejemplo determinar el tipo de vehículos que circulan y su nivel contaminante o capacidad del transporte público de viajeros. Si desea saber como hacer uso de la aplicación, vaya al AnexoⅤV. 5. Conclusiones y trabajo futuro Conclusiones En el presente trabajo se ha desarrollado una aplicación para la identificación de diferentes tipos de vehículos a partir de imágenes de vídeo, circulando en ambos sentidos de una vía mediante el uso de diversas tecnologías en el ámbito de IoT, incluyendo técnicas de Visión por Computador4 para análisis del movimiento y segmentación de las imágenes, con el objetivo de proporcionar a la Red Neuronal Convolucional Alexnet9 las entradas necesarias para la identificación del tipo de vehículos. Junto con las técnicas mencionadas se ha desarrollado un procedimiento para contar los vehículos en circulación de la forma más precisa posible para evitar duplicidades, de forma que un mismo vehículo sea contabilizado más de una vez. El diseño global de las técnicas implementadas hace posible que el sistema funcione correctamente con una amplia tasa de acierto. El objetivo principal ha sido la puesta en funcionamiento de un sistema software para poder determinar la cantidad y el tipo de vehículos que pasan por una determinada zona de una carretera, para más adelante poder hacer predicciones en base a esos datos y poder proporcionar al usuario, en tiempo real, qué es lo que está sucediendo. La estructura está formada por una cámara que graba los vehículos en movimiento y actúa como sensor generador de datos, enviando la información a un servidor para analizar el tipo de vehículos presentes en cada frame. Si bien, dado que la solución aportada no es real, sino una solución de concepto, se ha sustituido la captura de imágenes en tiempo real por secuencias de vídeo pregrabadas. La estrategia que se utiliza para el reconocimiento de los vehículos se basa en la aplicación de técnicas de Aprendizaje Profundo27, concretamente mediante el uso de una CNN convenientemente entrenada, habiendo elegido el modelo Alexnet preentrenado para mil objetos, que es rediseñada y re-entrenada para adaptarse a la clasificación de vehículos del tipo previsto en la aplicación. 86 De esta forma se ha realizado lo que se conoce como “transferencia de aprendizaje”13, aprovechando el mencionado modelo pre-entrenado la Red Neuronal recibe imagenes para llevar a cabo la clasificación de ocho tipos de vehículos definidos (FrontCar, BackCar, FrontMotorbike, BackMotorbike, FrontTruckVan, BackTruckVan, FrontBus, BackBus). Para obtener en las imágenes de la secuencia de vídeo las zonas donde se ha producido el movimiento y por tanto la determinación de las regiones correspondientes a los vehículos, se utiliza una combinación de técnicas de visión computacional basadas en la detección del flujo óptico y de segmentación de regiones, que permite identificar la posición de los vehículos en cada una de las imágenes pertenecientes a la secuencia recibida en función del movimiento detectado. Los resultados del análisis se almacenan en la plataforma pública de ThingSpeak24, utilizando así el concepto de ubicación en la nube, quedando a disposición de cualquier persona o institución. Además de los datos obtenidos relativos al cómputo de los vehículos mediante las técnicas de Visión por Computador4 y el uso de del Aprendizaje Profundo27, también se ha desarrollado un módulo de predicción, basado en el tratamiento de datos públicos del Ayuntamiento de Madrid15, en cuanto al número de vehículos que se desplazan a lo largo de los años 2017, 2018, 2019 y parte de 2020, este último con datos de los primeros meses, que son los disponibles a la hora de realizar el presente trabajo. A partir de estos datos, que conforman las correspondientes series temporales16, se lleva a cabo la estimación de los parámetros del modelo y la posterior predicción bajo demanda a ThingSpeak. El modelo utilizado para la predicción es de regresión lineal de primer orden del tipo AR. El hecho de utilizar estos datos, se debe a la imposibilidad de utilizar datos reales a lo largo de distintos años con fines predictivos. De esta forma la idea consiste en determinar la validez de la propuesta de forma que en el futuro, y ante el posible despliegue de un sistema real, no haya más que sustituir estos datos por los obtenidos a partir de la aplicación y a lo largo del tiempo en varios años. Se han realizado las pruebas necesarias, con resultados satisfactorios, para validar la aplicación integrada en su conjunto, así como de los diferentes módulos que conforman la misma a nivel individual. Trabajo futuro ● Detectar aquellos vehículos que no siguen el sentido correcto de la marcha, es decir, los llamados “kamikazes”, de esta forma se podría enviar una notificación tanto a los conductores como a los equipos de emergencias, avisando de la 87 existencia de peligro en la vía con fines de actuación inmediata ante un escenario de semejante naturaleza. ● Enriquecer el entrenamiento de la Red Neuronal con imágenes de vehículos en condiciones climatológicas adversas, tales como: lluvia, nieve, etc. ● Obtener más videos para enriquecer el canal de ThingSpeak24 encargado del conteo de los diferentes tipos de vehículos y poder hacer predicciones en base a los datos obtenidos de los análisis de los vehículos siendo mucho más amplios y precisos. ● Aplicar técnicas que permitan el procesamiento del flujo óptico de los frames de vídeo en tiempo real. ● Inclusión de un algoritmo que evite que las “sombras” de los vehículos no formen parte del movimiento asociado a los vehículos, sino como otros elementos que se mueven por sí mismos. ● Dar la posibilidad al usuario de usar su propia Red Neuronal Convolucional en lugar de trabajar siempre con AlexNet9, para ello se diseñarán otros modelos basados en GoogleNet, ResNet u otros ya pre-entrenados. ● Se dejará que sean los usuarios quienes posicionen la franja de detección de vehículos, ya que así podrá ajustarla mejor al emplazamiento donde se ha realizado la grabación. También se le permitirá establecer de forma manual el tamaño de la franja. ● Estudiar nuevos modelos de predicción para comparar con el modelo AR e incluir la posibilidad de técnicas basadas en redes neuronales recurrentes. La solución conceptual propuesta se ha centrado en el cómputo del flujo de varios tipos de vehículos. Esta misma estrategia se puede plantear en otros ámbitos tanto dentro del concepto de las ciudades inteligentes del futuro como en otras aplicaciones, sin más que realizar las correspondientes adaptaciones en los diferentes módulos y en su integración. 6. Conclusions and future Work Conclusions In the present work an application has been developed for the identification of different types of vehicles, from video images, driving in both directions of a road through the 88 use of several Computer Vision4, Deep Learning27 and IoT technologies for analysis of movements and segmentation of the images, with the objective of providing the Alexnet Convolutional Neural Network with the necessary inputs to identify the type of vehicle. Along with the mentioned techniques, a procedure has been developed to count the number of vehicles in circulation as precisely as possible to avoid duplication, so that the same vehicle is counted more than once. The global design of the implemented techniques makes it possible for the system to work correctly with a wide hit rate. In the present work a solution has been proposed to achieve the identification of different types of vehicles. The different techniques for detecting and classifying the traffic of vehicles passing through a road have been explained in detail, as well as the structure that makes it possible for the system to work correctly with a wide hit rate. The main objective has been the implementation of a software system in order to determine the number and type of vehicles that cross through a defined area on the road. Finally, predictions techniques have been also developed considering these data in the future. The structure is made up of a camera that captures images with moving vehicles and acts as a data-generating sensor, sending the information to a server to analyze the type of vehicles present at each frame. Although, since the solution provided is not real, but a concept solution, the capture of images in real time has been replaced by prerecorded video sequences. The strategy used for vehicle recognition is based in the application of Deep Learning27 techniques, specially through the use of properly trained CNN, having chosen the pre-trained Alexnet model for a thousand objects, which is redesigned and re-trained to adapt it to the classification of the vehicles of the type provided in the application. In this way, what is known as learning transfer has been carried out, taking advantage of the aforementioned pre-trained model. The neural network receives images to carry out the classification of eight types of defined vehicles (FrontCar, BackCar, FrontTruckVan, BackTruckVan, FrontMotorcycle, BackMotorcycle, FrontBus, BackBus). To obtain in the sequence of video images the areas where the movement has occurred and therefore the determination of the regions corresponding to the vehicles, it is used a combination of computational vision techniques based on the detection of optical flow and segmentation of regions that allows identifying the position of the vehicles at each of the images belonging to the received sequence based on the detected movement. Results of the analysis are stored on the public ThingSpeak24 95 AnexoⅡ: Diagrama de clase de la capa de negocio. 96 Anexo Ⅲ: Resultados ThingSpeak Prediction. En la tabla siguiente se muestran los datos de flujo de tráfico, según la cantidad de vehículos detectados y suministrados por el Ayuntamiento de Madrid en la vía de circunvalación M30 para los días de la semana y fecha que se indican, que por otra parte son los utilizados para estimar los parámetros del modelo de predicción AR. Lunes Fecha Cantidad 02/03/2020 22.867 09/03/2020 21.280 16/03/2020 22.141 23/03/2020 21.584 30/03/2020 21.626 Martes Fecha Cantidad 03/03/2020 22.766 10/03/2020 22.769 17/03/2020 22.769 24/03/2020 22.567 31/03/2020 22.629 07/04/2020 22.489 14/04/2020 22.411 21/04/2020 22.333 28/04/2020 22.333 05/05/2020 22.185 97 Miércoles Fecha Cantidad 04/03/2020 24.121 11/03/2020 23.436 18/03/2020 22.975 25/03/2020 23.121 01/04/2020 23.225 08/04/2020 23.116 15/04/2020 22.935 22/04/2020 22.799 29/04/2020 22.720 06/05/2020 22.643 13/05/2020 22.546 20/05/2020 22.440 27/05/2020 22.338 03/06/2020 22.243 10/06/2020 22.148 Jueves Fecha Cantidad 05/03/2020 23.939 12/03/2020 23.523 19/03/2020 23.781 26/03/2020 23.926 02/04/2020 23.653 09/04/2020 23.556 16/04/2020 23.371 23/04/2020 23.314 30/04/2020 23.246 98 Viernes Fecha Cantidad 06/03/2020 22.708 13/03/2020 22.726 20/03/2020 22.097 27/03/2020 21.939 03/04/2020 22.038 10/04/2020 21.967 17/04/2020 21.750 Sábado Fecha Cantidad 07/03/2020 18.507 14/03/2020 18.632 21/03/2020 17.732 28/03/2020 17.811 04/04/2020 17.946 11/04/2020 17.817 18/04/2020 17.650 25/04/2020 17.606 02/05/2020 17.553 09/05/2020 17.461 16/05/2020 17.375 99 Domingo Fecha Cantidad 01/03/2020 18.664 08/03/2020 18.115 15/03/2020 18.208 22/03/2020 17.939 29/03/2020 17.764 05/04/2020 17.851 12/04/2020 17.796 19/04/2020 17.706 Anexo Ⅳ: Resultados ThingSpeak CarDetection. En la siguiente tabla se puede observar el número de los diferentes tipos de vehículos detectados en los análisis de video y que fueron subidos a ThingSpeak, éstos están ordenados por fecha y hora. Anexo Ⅴ: Manual de usuario. 1. Descarguese el código del repositorio: https://github.com/GDelga/TFG 100 2. Para poder ejecutar la aplicación se necesita tener instalado el IDE MATLAB R2019a con los siguientes add-ons (toolboxes): a. Image Processing Toolbox b. Deep Learning Toolbox c. Computer Vision Toolbox d. Deep Learning Toolbox Model for AlexNet Network e. Parallel Computing Toolbox 3. Asegúrese de que la estructura de carpetas es como la mostrada a continuación. Obligatoriamente deben existir las siguientes carpetas. ● src: ○ ImageCategories: debe contener todos los directorios e imágenes para realizar el entrenamiento. ○ Images: contiene las imágenes usadas en las interfaces de la aplicación. ○ Others: directorio en el que se guarda y lee la Red Neuronal. ○ ResizedImages: carpeta en la que se guardan las imágenes redimensionadas. 101 4. Al iniciar la aplicación nos encontraremos con la siguiente interfaz. 5. Para entrenar la red se selecciona la opción “Learning”. Se mostrará el siguiente interfaz de usuario: 102 6. Seleccionaremos la opción “Retraining”. A continuación se selecciona la pestaña “Training Options” que muestra la siguiente vista donde son cargados los valores por defecto para entrenar la red. Al terminar de ejecutarse esta vista se genera el archivo AlexNet.mat que contiene el modelo de la Red Neuronal Convolucional AlexNet ya entrenada y por tanto con los pesos ajustados según las imágene con las que ha sido entrenada la red. AVISO: Las funcionalidades “Image Resizer” y “Update Training” Data se explican en el apartado 4.1 de la memoria. 103 7. Tras el entrenamiento de la red se puede utilizar la funcionalidad de detección de vehículos. Para ello se vuelve al menú principal pulsando la flecha de retroceso. Y a continuación se selecciona la opción “Car Detection”. Se habrá de mostrar el siguiente interfaz de usuario: 1. Al seleccionar la opción “Play” se abrirá un explorador de ficheros para seleccionar el video que se desea procesar. 104 2. Tanto el comienzo como la finalización del procesamiento del video se avisa con un mensaje informativo. 3. La opción “Stop” sirve para detener el procesamiento del video, saltando un mensaje informativo cuando esta es seleccionada. A continuación se muestra el procesamiento del vídeo presentándose en una interfaz como la mostrada a continuación que se actualiza tras cada imagen procesada. 8. Volviendo a pulsar al botón retroceso se volverá al menú principal, donde se selecciona la opción “ThingSpeak” para la consulta de los datos obtenidos en el apartado anterior.