diseÑo de un sistema de semaforizaciÓn inteligente …

96
1 DISEÑO DE UN SISTEMA DE SEMAFORIZACIÓN INTELIGENTE PARA CONTROLAR FLUJO VEHÍCULAR A PARTIR DE PROCESAMIENTO DE IMÁGENES. CÓDIGO DE PROYECTO: PG-19-1-22 MONTERREY CAÑAS ANGEL MAURICIO CÓDIGO 1420926 IDENTIFICACIÓN C.C. 1018490296 SOSA RAMÍREZ CAMILO ANDRÉS CÓDIGO 1420313 IDENTIFICACIÓN C.C. 1073168313 UNIVERSIDAD PILOTO DE COLOMBIA FACULTAD DE INGENIERÍA PROGRAMA DE INGENIERÍA MECATRÓNICA BOGOTÁ, D.C. 2020

Upload: others

Post on 01-Mar-2022

5 views

Category:

Documents


0 download

TRANSCRIPT

1

DISEÑO DE UN SISTEMA DE SEMAFORIZACIÓN INTELIGENTE PARA CONTROLAR FLUJO VEHÍCULAR A PARTIR DE PROCESAMIENTO DE

IMÁGENES.

CÓDIGO DE PROYECTO: PG-19-1-22

MONTERREY CAÑAS ANGEL MAURICIO CÓDIGO 1420926

IDENTIFICACIÓN C.C. 1018490296

SOSA RAMÍREZ CAMILO ANDRÉS CÓDIGO 1420313

IDENTIFICACIÓN C.C. 1073168313

UNIVERSIDAD PILOTO DE COLOMBIA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA MECATRÓNICA BOGOTÁ, D.C.

2020

2

DISEÑO DE UN SISTEMA DE SEMAFORIZACIÓN INTELIGENTE PARA CONTROLAR FLUJO VEHÍCULAR A PARTIR DE PROCESAMIENTO DE

IMÁGENES.

CÓDIGO DE PROYECTO: PG-19-1-22

MONTERREY CAÑAS ANGEL MAURICIO CÓDIGO 1420926

IDENTIFICACIÓN C.C. 1018490296

SOSA RAMÍREZ CAMILO ANDRÉS CÓDIGO 1420313

IDENTIFICACIÓN C.C. 1073168313

PROYECTO DE GRADO PARA OPTAR POR EL TÍTULO DE INGENIERO MECATRÓNICO DE LA UNIVERSIDAD PILOTO DE COLOMBIA

DIRECTOR: MARCO ANTONIO JINETE GÓMEZ M.Sc En Automatización Industrial

Ing. Electrónico

UNIVERSIDAD PILOTO DE COLOMBIA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA MECATRÓNICA BOGOTÁ, D.C.

2020

3

NOTA DE ACEPTACIÓN

Una vez realizada la revisión metodológica y técnica del documento final de proyecto de grado, doy constancia de que el (los) estudiante (s) ha cumplido a cabalidad con los objetivos propuestos, cumple a cabalidad con los Lineamientos de Opción de Grado vigentes del programa de Ingeniería Mecatrónica y con las leyes de derechos de autor de la República de Colombia, por tanto, se encuentra(n) preparado(s) para la defensa del mismo ante un jurado evaluador que considere idóneo el Comité de Investigaciones del Programa de Ingeniería Mecatrónica de la Universidad Piloto de Colombia.

Marco Antonio Jinete Gómez. Director del Proyecto

4

AGRADECIMIENTOS

A MIS PADRES. Por brindarme el apoyo y la oportunidad de desarrollar mis estudios universitarios en la Universidad Piloto de Colombia. A MIS TIAS, ABUELOS Y HERMANOS. Por ser ese gran apoyo y mano derecha en todo momento. Angel Monterrey. Por parte de nuestro grupo de trabajo, un agradecimiento especial al Ingeniero Néstor Penagos, maestro y gran apoyo en el camino recorrido que pronto culmina. A él, muchas gracias. De igual manera a nuestro tutor Marco Jinete por su orientación y acompañamiento en el desarrollo de este proyecto. Camilo Sosa & Angel Monterrey.

5

TABLA DE CONTENIDO

Contenido

NOTA DE ACEPTACIÓN .................................................................................................................. 3

INTRODUCCIÓN ............................................................................................................................. 11

RESUMEN ....................................................................................................................................... 12

ABSTRACT ..................................................................................................................................... 13

1. GENERALIDADES ...................................................................................................................... 14

1.1 PLANTEAMIENTO DEL PROBLEMA .................................................................................... 14 1.1.1 Antecedentes del Problema ............................................................................................ 14 1.1.2 Descripción del problema ................................................................................................ 14 1.1.3 Formulación del problema ............................................................................................... 15 1.1.4 Línea de investigación del programa ............................................................................... 15

1.2 JUSTIFICACIÓN .................................................................................................................... 15

1.3 OBJETIVOS ........................................................................................................................... 15 1.3.1 Objetivo General ............................................................................................................. 15 1.3.2 Objetivos específicos ...................................................................................................... 15

1.4 DELIMITACIÓN DEL PROYECTO ......................................................................................... 16 1.4.1 Alcances y Limitaciones .................................................................................................. 16 1.4.1.1 Alcances ................................................................................................................... 16 1.4.1.2 Limitaciones ................................................................................................................. 16

1.5 ESTADO DEL ARTE. ....................................................................................................... 17 1.5.1 Modificación parcial ......................................................................................................... 17 1.5.2 Modificación parcial ......................................................................................................... 19

1.6 MARCO METODOLÓGICO ................................................................................................... 26

2. SELECCIÓN DE SOFTWARE Y HARDWARE. .......................................................................... 28

2.1 INTELIGENCIA ARTÍFICIAL. ................................................................................................. 28 2.1.1 Software, librerías y plataformas ..................................................................................... 28 2.1.2. Herramientas potenciales ............................................................................................... 29 2.1.3 Comparación y selección del servicio ............................................................................. 30

2.2 RASPBERRY ......................................................................................................................... 33

2.3 CÁMARA ................................................................................................................................ 36

2.4 SENSORES ........................................................................................................................... 38 2.4.1 Sensor de luz TSL2561 ................................................................................................... 38 2.4.2 Sensor de humedad DHT22 ............................................................................................ 39

3. SIMULACIÓN Y LÓGICA DIFUSA. ............................................................................................. 41

3.1 SIMULACIÓN SYNCHRO 8. .................................................................................................. 42 3.1.1 Zona de estudio ............................................................................................................... 42 3.1.2 Parámetro viales ............................................................................................................. 43

6

3.1.3 Parámetro semafóricos ................................................................................................... 48 3.1.4 Reporte de simulación ..................................................................................................... 49

4. SISTEMA DIFUSO ....................................................................................................................... 52

4.1 VARIABLES DE ENTRADA Y SALIDA. ................................................................................. 53

4.2 REGLAS DIFUSAS. ............................................................................................................... 56

4.3 RESULTADOS DE LA LÓGICA DIFUSA. .............................................................................. 62

5. SISTEMA ELECTRÓNICO ......................................................................................................... 64

5.1 COMUNICACIÓN SERIAL. .................................................................................................... 65

5.2 FUENTES DE ALIMENTACIÓN. ............................................................................................ 67

5.3 BACK UP DE ENERGÍA. ....................................................................................................... 67 5.3.1 Sistema de carga de batería ........................................................................................... 68 5.3.2 Divisor de voltaje ............................................................................................................. 68 5.3.3 Sistema relé – transistor .................................................................................................. 69

5.4 LUCED LED ........................................................................................................................... 71

6. ARQUITECTURA DE SOFTWARE ......................................................................................... 73

6.1 PROTOCOLOS ...................................................................................................................... 73

6.2 FRAMEWORKS Y LIBRERÍAS .............................................................................................. 73 6.3.2 Rekognition Con Amazon Rekognition puede identificar objetos, personas, texto, escenas y actividades en imágenes y videos, además de detectar cualquier contenido inapropiado [34]. Este servicio es usado en el sistema para detectar y contar los vehículos de la vía. ........................................................................................................................................ 75

6.4 BASE DE DATOS .................................................................................................................. 76

6.5 VISION GENERAL DEL SISTEMA ........................................................................................ 77

7. PRUEBAS DE FUNCIONAMIENTO ........................................................................................ 81

7.1 PRIMERA ETAPA. ................................................................................................................. 81

7.2 SEGUNDA ETAPA ................................................................................................................. 87

8. CONCLUSIONES. ................................................................................................................... 90

REFERENCIAS BIBLIOGRÁFICAS ................................................................................................ 92

ANEXOS .......................................................................................................................................... 96

7

LISTA DE FIGURAS. Figura 1 Imágenes explicativas del tipo de zona de estudio y semáforo. .............. 17

Figura 2. Imágenes explicativas del tipo de zona de estudio y semáforo. ............. 18

Figura 3. Esquema para proyecto con sensor RFID ............................................. 19

Figura 4. Partes sensor loop. ................................................................................ 20

Figura 5. Ubicación y forma de detección del sensor infrarrojo. ............................ 21

Figura 6. Ubicación de sensores ........................................................................... 22

Figura 7. Identificación de bordes por el método de Canny. ................................. 23

Figura 8. Esquema de ubicación de cámara Traficam .......................................... 24

Figura 9. Funciones difusas .................................................................................. 26

Figura 10. Comparación de servicios en fiabilidad. ............................................... 31

Figura 11. Opciones del mercado ......................................................................... 34

Figura 12. Comparación de resoluciones (480p, 720p, 1080p) ............................. 36

Figura 13. Comparación de modelos de cámaras ................................................. 37

Figura 14. Módulo TSL2561. ................................................................................ 38

Figura 15. Módulo DHT22. .................................................................................... 39

Figura 16. Captura de pantalla obtenida del programa Synchro 8. ....................... 41

Figura 17. Fotografía de la zona en la que se basa el estudio. ............................. 42

Figura 18. Fotografía del cruce obtenida de google maps. ................................... 43

Figura 19. Medidas de un vehículo sedan. ........................................................... 49

Figura 20. Registro Fotográfico Toma de Datos de Agua Recolectada ................. 52

Figura 21. Entradas del sistema difuso. ................................................................ 54

Figura 22. Salidas del sistema difuso ................................................................... 56

Figura 23. Ingreso de las reglas definidas en MATLAB. ....................................... 62

Figura 24. Ejemplo del funcionamiento del sistema difuso. .................................. 63

Figura 25. Esquema de las tareas que realiza el circuito electrónico. ................... 64

Figura 26. Ejemplo del funcionamiento del sistema difuso. ................................... 65

Figura 27. Circuito conversor de 3.3 a 5v ............................................................. 66

Figura 28. Circuito conversor de 5 a 3.3v ............................................................. 66

Figura 29. Circuito fuente del sistema 9v y 6v respectivamente ............................ 67

Figura 30. Circuito TP4056 para carga de batería. ............................................... 68

Figura 31. Divisor de voltaje en la fuente de 6v. ................................................... 69

Figura 32. Sistema relé – transistor para cargador de la raspberry. ...................... 70

Figura 33. Sistema relé – transistor para batería de litio. ...................................... 71

Figura 34. Sistema relé – transistor para luces LED. ............................................ 72

Figura 35. Esquema completo del circuito desarrollado. ....................................... 72

Figura 36. Logo Django ........................................................................................ 74

Figura 37. Logo React .......................................................................................... 74

Figura 38. Logo EC2 ............................................................................................. 75

Figura 39. Logo rekognition .................................................................................. 75

Figura 40. Logo Amazon S3 ................................................................................. 76

Figura 41. Logo Lambda ....................................................................................... 76

Figura 42. Esquema y diagrama Raspberry Pi a server ........................................ 78

8

Figura 43. Esquema lógica difusa ......................................................................... 79

Figura 44. Esquema servidor a Raspberry ............................................................ 79

Figura 45. ID y nombre de los semáforos de la intersección ................................. 82

Figura 46. Servidor encargado del conteo de vehículos. ...................................... 83

Figura 47. Conteo vehicular por web .................................................................... 84

Figura 48. Flujo vehicular en la imagen 11 del registro fotográfico . ...................... 84

Figura 49. Registro de última lectura .................................................................... 84

Figura 50. Datos recibidos de los 3 semàforos ..................................................... 85

Figura 51. Respuesta de lamba con los tiempos del ciclo ..................................... 85

Figura 52. Rutinas establecidas en los semáforos ................................................ 86

Figura 53. Envío de rutinas hacia Raspberry ........................................................ 87

Figura 54. Iluminación de Bogotá a las 6 P.M. ...................................................... 87

Figura 55. Condición que limita el funcionamiento del sistema ............................. 88

Figura 56. Mensaje de activación de rutina pre establecida .................................. 88

Figura 57. Rutina pre establecida en semáforo CLL45 ......................................... 88

Figura 58. Delimitadores en código de Raspberry ................................................ 89

9

LISTA DE TABLAS

Tabla 1. Pruebas de detección con sensor loop ................................................... 20

Tabla 2. Comparación de servicios en sus características de API, capa gratuita y no entrenamiento robusto. .................................................................................... 29

Tabla 3. Comparación de fiabilidad. ...................................................................... 31

Tabla 4. Comparación de costos .......................................................................... 32

Tabla 5. Comparación en velocidad de respuesta ................................................ 32

Tabla 6. Comparación de sistemas ....................................................................... 34

Tabla 8. Comparación en calidad de cámaras ...................................................... 37

Tabla 9. Tabla con los flujos vehiculares para la zona. ......................................... 45

Tabla 10. Datos definidos para flujo vehicular en el simulador .............................. 47

Tabla 11. Datos definidos para flujo vehicular en el simulador .............................. 47

Tabla 12. Medidas de los vehículos en el simulador. ............................................ 48

Tabla 13. Tiempo de grabación para el simulador. ............................................... 49

Tabla 14. Datos del reporte de simulación. ........................................................... 50

Tabla 15. Siglas de las vías en el simulador. ........................................................ 51

Tabla 16. Casos de estudio para tiempos FN-FN. ................................................ 58

Tabla 17. Casos de estudio para tiempos FN-CONG. .......................................... 58

Tabla 18. Casos de estudio para tiempos FN-DESC. ........................................... 59

Tabla 19. Casos de estudio para tiempos DESC-FN. ........................................... 59

Tabla 20. Casos de estudio para tiempos DESC-CONG. ..................................... 60

Tabla 21. Casos de estudio para tiempos DESC-DESC. ..................................... 60

Tabla 22. Casos de estudio para tiempos CONG-FN. .......................................... 60

Tabla 23. Casos de estudio para tiempos CONG-CONG...................................... 61

Tabla 24. Casos de estudio para tiempos CONG-DESC. ..................................... 61

Tabla 25. Reglas difusas definidas para el sistema. ............................................. 62

10

LISTA DE ANEXOS Anexo 1. Circuito PCB del sistema. ...................................................................... 96

11

INTRODUCCIÓN

En algunas zonas de la ciudad de Bogotá, la problemática de los tiempos que invierten los ciudadanos en desplazarse a sus hogares, tiendas, supermercados, lugares de trabajo, etc. se ha vuelto bastante crítica y requiere de atención inmediata para lograr una solución en reducción de tiempos de movilidad A medida que aumenta la población y el parque automotor de la ciudad, se convierte en una necesidad realizar cambios y buscar alternativas en materia de movilidad. Una forma más efectiva de sobrellevar la situación vial sería conociendo los eventos que se presentan en cada una de las intersecciones para así poder contar con soluciones asertivas e instantáneas en cada cruce. El procesamiento de imágenes es una alternativa bastante viable para dar solución a esta problemática, ya que integra la posibilidad de poder captar los eventos que se presentan sobre la malla vial mediante fotografías o video y posteriormente someterlas a un análisis que desemboque en un cambio de la dinámica en los ciclos semafóricos. Por todo lo anterior, en el siguiente trabajo de grado se diseña un sistema de semaforización inteligente para controlar el flujo vehicular mediante procesamiento de imágenes y aplicación de lógica difusa, con el fin de interpretar la información captada y tomar decisiones que modifiquen los tiempos del ciclo para dar prioridad a situaciones de congestión.

12

RESUMEN

El presente trabajo de grado se llevó a cabo con el objetivo de diseñar un sistema de semaforización inteligente para controlar el flujo vehicular a partir del procesamiento de imágenes. Para comenzar con el diseño del sistema se procedió a realizar una identificación del tráfico vehicular de la zona en momentos de congestión, descongestión y flujo normal, esto mediante experiencia del grupo de trabajo sobre el lugar. Posterior a este análisis, se procede a investigar anteriores proyectos enfocados en la misma problemática para conocer sobre alternativas, falencias y soluciones que hayan propuesto los autores. Una vez definida la forma de análisis de las imágenes recolectadas en la vía, se estudian las posibles formas de interpretar la información para dar con un método capaz de interpretar las variables de entrada (tráfico), procesar la información y entregar salidas (tiempos) que se ajusten a la situación que se está presentando; este método fue la lógica difusa. Una vez establecidas estas herramientas se procedió con la elección y compra de sensores exteriores del semáforo para medición de condiciones climáticas del día, se calibraron e incluyeron al sistema. Con todas las partes integradas, se comenzó con las pruebas para corroborar la lectura, interpretación y entrega de datos desde la toma de fotografías hasta las salidas que da el sistema hacia las luces LED del semáforo. Finalmente, contando con todos estos componentes, se comienza con el diseño y las pruebas del sistema adicional de toda la estructura, el back up de energía, donde se construye el sistema relé – transistor que mantiene la energía circulando en casos de fallas eléctricas. En cuanto a las pruebas del sistema se destaca la importancia de: primero, el procesamiento de imágenes para lograr establecer tiempos dinámicos en las intersecciones viales y segundo, la gran ventaja de contar con un sistema pequeño pero muy efectivo para evitar caos vehicular y daños de componentes por bajones de electricidad como lo es el Back up de energía. Palabras Clave: procesamiento de imágenes, tiempos dinámicos, back up de energía, análisis de datos.

13

ABSTRACT

The following thesis was carried out with the aim of designing an intelligent traffic light system to control traffic flow using image processing. First of all, an identification of vehicular traffic in the area was implemented on a busy road to check for traffic conditions like normal vehicular flow, and traffic jams caused by congestion on the road, usually during peak hours. That information was acquired by the group member’s experience. Secondly, keeping in mind the earlier data interpretation obtained. Previously focused projects were reached out and examined to look for different alternatives, shortcomings and solutions their authors had proposed. Thirdly, once the images have been collected, analyzed and the road defined. Possible ways of reading the information are studied in order to discover a method capable of interpreting the input variables (traffic), processing the information and delivering outputs (times) that are adjusted to the situation that is being presented; this method is fuzzy logic. Finally, once tools were established, the next step was to proceed to choose and buy external sensors that fit best for traffic lights to measure daily weather conditions, they were calibrated and included in the system. All parts integrated, the tests began to corroborate the reading, interpretation and data delivery from the photographs taken to the outputs given by the system to the traffic light’s LED lights. Last but not least, with all these components in mind. The entire system structure gets designed and tested, as well as energy back-up, where the relay-transistor system is built keeping the energy circulating in cases of electrical failure. In regards to system testing, it’s key to highlight the importance of image processing to establish dynamic times in road intersections and the great advantage of having a small but quite an effective and productive structure to avoid heavy traffic and damage of components due to power outages such as the energy back up. Keywords: Image processing, dynamic times, power backup, analysis of data.

14

1. GENERALIDADES

1.1 PLANTEAMIENTO DEL PROBLEMA 1.1.1 Antecedentes del Problema. La ciudad de Bogotá a través de los años ha venido teniendo un crecimiento bastante considerable en la cantidad de personas que la habitan, el cual ha afectado necesidades básicas de los ciudadanos como lo es la movilidad vial. Desde hace tiempo, Bogotá no obtiene cambios considerables que logren reducir las horas que invierten los ciudadanos intentando movilizarse por las calles de la Capital, si bien es cierto, el gobierno ha intentado aliviar esta situación con medidas como la instauración del pico y placa, el aumento de flotas de transporte público TRANSMILENIO, restricciones del transporte pesado y de carga y la promoción de medios de transporte no motorizados, estas solo han significado un breve respiro en esta materia. Estudios de movilidad revelaron que la aplicación de pico y placa en la capital tuvo un buen impacto y se logró descongestionar un poco la malla vial durante cierto tiempo, tiempo después se presentó un aumento en el parque automotor de la ciudad ya que las personas empezaron a adquirir un segundo vehículo para poder movilizarse en días donde en uno de ellos tuviese pico y placa. Según un estudio de Movilidad en cifras [1], la ciudad pasó de tener 1.894.674 vehículos transitando a 2.042.890 en 2014, con este aumento la congestión volvió a ser protagonista en el día a día de los ciudadanos de Bogotá. Con el crecimiento de la flota de buses del sistema TRANSMILENIO no se sintió mayor cambio ya que, según sus mismos usuarios: “el sistema sigue siendo ineficiente e incapaz de transportar la cantidad de personas que demanda la ciudad”, por lo tanto, los represamientos de personas en las estaciones y troncales de transmilenio, además de las largas esperas por un bus siguieron siendo las mismas. Muchas personas han optado por los sistemas de transporte no motorizados, actualmente más de 300 mil habitantes utilizan bicicleta para movilizarse y así evitar largas esperas para llegar a sus destinos. Los ciudadanos Bogotanos exigen desde hace años una solución efectiva al tema Movilidad vial con acciones serias que logren un impacto positivo y permanente para la descongestión y reducción del tiempo que estos invierten en trancones, estaciones, paraderos de buses, etc. 1.1.2 Descripción del problema La ciudad de Bogotá cuenta con un sistema de semaforización vial obsoleto y que no se adapta a las necesidades actuales de la población con la que cuenta la capital Colombiana. Hoy en día, Bogotá es una ciudad que sigue en constante aumento de su población, las cantidades de automóviles que transitan por ella son muchos más y las rutinas presentes en cada una de las intersecciones no están en condiciones de agilizar el tráfico y evitar represamientos de vehículos en ellas. El problema nace en que dichas rutinas están pre establecidas, por lo tanto no están al margen de la situación vial que se esté presentando, sus tiempos no son dinámicos sino por el contrario, son fijos.

15

1.1.3 Formulación del problema. ¿Cómo contribuye la instalación de un sistema de enfriamiento de baja potencia en la eficiencia de captación de agua ambiente de un atrapa niebla? 1.1.4 Línea de investigación del programa. La línea de investigación del trabajo corresponde a la de Energías renovables.

1.2 JUSTIFICACIÓN El sistema de semaforización inteligente permite mantener un control constante del flujo vehicular en las vías de la ciudad. Dicho sistema recoge información mediante cámaras, la analiza e interpreta por medio de un software para aplicar cambios en el comportamiento de los tiempos de transición por intersección acorde a la situación vial que se esté presentando en cada uno de ellos, estableciendo un plan de acción en tiempo real. Bogotá es una ciudad que cuenta con una gran cantidad de habitantes, 7.181.569 según el último censo del DANE [17], los cuales manifiestan gran inconformidad en el aspecto de movilidad; las vías en mal estado y el sistema de semaforización obsoleto sumado con los poco eficientes servicios de movilidad empeoran la situación de la capital, por lo tanto la búsqueda de soluciones novedosas y que se ajusten a las necesidades de la sociedad son necesarias para la Ciudad. El desarrollo de este software inteligente busca la reducción del tiempo de movilización de los ciudadanos en la malla vial, reduciendo el embotellamiento y caos vehicular que se intensifica sobre ciertas horas del día. Con las nuevas rutinas acorde a la situación vial los represamientos vehiculares se reducirán considerablemente disminuyendo los tiempos de movilidad de los habitantes. 1.3 OBJETIVOS 1.3.1 Objetivo General.

Diseñar un sistema de monitoreo basado en procesamiento de imágenes para mejorar la temporización de los semáforos con el fin de mejorar el flujo vial.

1.3.2 Objetivos específicos

Establecer y caracterizar las variables necesarias para realizar el procesamiento de imágenes sobre tráfico vehicular en zonas de alto flujo.

16

Implementar el software de comunicación entre el sistema de monitoreo y los servidores centrales.

Establecer y caracterizar las variables necesarias para realizar el procesamiento de imágenes sobre tráfico vehicular en zonas de alto flujo.

Implementar el software de comunicación entre el sistema de monitoreo y los servidores centrales

Diseñar la estructura mecánica que se anexa al semáforo convencional

Diseñar el circuito electrónico del sistema de monitoreo y del semáforo

Validar el rendimiento del sistema.

1.4 DELIMITACIÓN DEL PROYECTO 1.4.1 Alcances y Limitaciones 1.4.1.1 Alcances. Los alcances de este proyecto son los siguientes:

Desarrollo de un software de semaforización inteligente aplicado a la ciudad de Bogotá.

Estudio de flujo vehicular en zonas críticas de la ciudad.

1.4.1.2 Limitaciones. Las limitaciones que presentan este proyecto son las siguientes:

El software solo procesará automóviles, camionetas y buses.

Se implementará un sistema de procesamiento de imágenes ya entrenado.

Funcionamiento solo durante horas diurnas debido a que la oscuridad afecta el procesamiento de imágenes

El proyecto está enfocado en la comunicación de los semáforos vehiculares y peatonales de una intersección de máximo 4 semáforos vehiculares y 8 peatonales, (ver figura 1).

17

El proyecto está enfocado en intersecciones que no tienen cruces vehiculares hacia izquierda y derecha.

No se diseñará la estructura de los semáforos, se utilizará alguna que esté en el mercado y se le agregará la parte adicional de la cámara (ver diagrama 2).

La comprobación de funcionamiento solo se realizará en simulación.

Figura 1 Imágenes explicativas del tipo de zona de estudio y semáforo.

Fuente: Elaboración propia. 1.5 ESTADO DEL ARTE. La congestión vial es un tema que afecta a ciudades en todo el mundo principalmente en capitales, por ende, han sido varios los grupos investigativos que se han concentrado en tratar de encontrar un sistema que pueda dar solución a esta problemática empleando distintas opciones de hardware y software que poco a poco van aportando experiencia, bases y conclusiones para futuros desarrollos. No todos los trabajos en esta área se fundamentan en la semaforización de calles o avenidas de una ciudad, existen proyectos basados en la mejora de procesos semafóricos en interiores donde se requieren (generalmente grandes plantas de producción). Es por ello que se pueden clasificar estos desarrollos en 2 ramas como la Modificación parcial y la Modificación completa. Estas dos categorías se explican a continuación. 1.5.1 Modificación parcial El termino modificación parcial hace referencia a que se realicen cambios en el funcionamiento de un semáforo para que actúe solo sobre una pequeña población dependiente del dispositivo para su rápido desplazamiento por la zona de aplicación. Una de las herramientas más empleadas para la lectura de vehículos en una intersección semafórica son los sensores pues, existe una extensa gama de ellos y, por consiguiente un sinfín de posibles aplicaciones. Entre

18

las propuestas que destacan en esta categoría, se encuentra el uso del sensor RFID para la identificación de vehículos y peatones que necesiten desplazarse por las vías, a continuación se estudia más a fondo la forma en que esta herramienta es beneficioso para el sistema inteligente.

1.5.1.1 Sensor RFID Los sensores RFID son herramientas empleadas en amplias ramas de la electrónica, este tipo de dispositivo “combina la funcionalidad de la etiqueta de identificación por radiofrecuencia y la funcionalidad del sensor” [18]. Una forma de integrar los RFID al mejoramiento del flujo vial lo proponen Laura Enciso y Alex Núñez en su proyecto de grado [2] donde consideran el uso de módulos interconectados por servicios web y sensores RFID implementados en ambulancias con la finalidad de trazar una ruta más corta y descongestionada que permita a los vehículos de emergencia encontrar una “Ola verde” a su paso, es decir, semáforo tras semáforo en luz verde, para que puedan acudir al lugar de destino de manera más rápida y con menor riesgo de accidente. De esta manera enfocan el estudio a la rama de vehículos de emergencia y buscan la reducción tanto en tiempos de movilización como en tasa de accidentalidad.

Figura 2. Imágenes explicativas del tipo de zona de estudio y semáforo.

FUENTE: ENCISO, L & Núñez, A. Sistema semafórico preferencial simulado para vehículos de emergencia usando enfoques de IoT E ITS: Caso de estudio ambulancias. [En línea]. Bogotá. [Citado el 14 mayo 2020]. Disponible en internet < http://polux.unipiloto.edu.co:8080/00004543.pdf> Otro proyecto investigativo que se basa en sensores RFID para hacer una modificación parcial al sistema de semaforización es el de la Universidad tecnológica de Israel [3] donde se sugiere el uso de esta tecnología para modificar tiempos de semaforización con el fin de darle prioridad a personas en condición de discapacidad. El autor explica que ya existe un sistema que supuestamente les da prioridad a los peatones en la intersección pero al parecer no cumple con su función,

19

por lo que es necesario un sistema más moderno para peatones que presentan dificultades en su desplazamiento como lo son las persona discapacitadas. 1.5.2 Modificación completa La modificación completa es la categoría constituida por proyectos de semaforización inteligente enfocados en la mejora de la movilidad vial de todos los medios de transporte que se desplazan por la zona de estudio. Para este tipo de modificación existen muchas propuestas de integración de sensores en la solución del tráfico vehicular, bien sean RFID, loop, ultrasónicos, entre otros. A continuación se estudian estas tecnologías.

1.5.2.1 Sensores para detección El estudiante Manuel Martínez [4] en su trabajo de grado diseña una propuesta basada en la implementación de sensores RFID en todo el parque automotor de las ciudades esto, con la finalidad de que una base de datos lea la cantidad de vehículos que hay en una intersección y pueda realizar cambios en los tiempos de ciclo semafórico en base a la congestión que se está presentando en el momento. La limitación que hace notar el propio autor que tiene su proyecto es la obligación de tener que implementar este tipo de sensores en todos los vehículos que transitan en la ciudad.

Figura 3. Esquema para proyecto con sensor RFID

FUENTE: ANOROZO, M. Semáforos inteligentes. [En línea]. Asunción. [Citado el 14 mayo 2020]. Disponible en internet < http://jeuazarru.com/wp-content/uploads/2014/10/semaforos_inteligentes.pdf> La tecnología avanza y prácticamente existen herramientas que pueden detectar cualquier tipo de fenómeno empleando diferentes metodologías, el electromagnetismo es otro de los fenómenos que pueden aprovecharse para la detección de movimiento, este es el principio del sensor loop. Este sensor es el más empleado en detección de tráfico, está compuesto como se indica en la figura 4 por el loop, cables y una unidad principal o detector.

20

Figura 4. Partes sensor loop.

FUENTE: LAMAS, J., CASTRO, P., DAPENA, A. Simple detection of inductive vehicle signatures with a multiplex resonant sensor. [En línea]. Coruña. [Citado el 15 Mayo 2020]. Disponible en internet <http://repositorio.unprg.edu.pe/bitstream/handle/UNPRG/6064/BC-3302%20MU%c3%91OZ%20ZAMBRANO.pdf?sequence=1&isAllowed=y> El proyecto “Implementación de un sistema de automatización para el control de semáforos inteligentes” [5] se plantea la opción de ubicar el sensor loop geométricamente de la manera más efectiva (realizando pruebas en la vía) para lograr una mejor detección de vehículos. Estas pruebas las plasma en la siguiente tabla: Tabla 1. Pruebas de detección con sensor loop

FUENTE: OSORIO, H. Implementación de un sistema de automatización para el control de semáforos inteligentes. [En línea]. Ibarra. [Citado el 15 mayo 2020]. Disponible en internet < http://repositorio.utn.edu.ec/bitstream/123456789/8200/1/04%20MEL%20034%20TRABAJO%20DE%20GRADO.pdf

21

Una vez cuenta con la posición ideal para la detección de vehículos, el sensor envía la información a una unidad principal encargada de interpretar la información y modificar los tiempos de los semáforos, de esta manera los tiempos van variando en función del tráfico de la zona. Otro de los sensores que se utilizan para la detección de vehículos en intersecciones es el sensor infrarrojo. Estos sensores son capaces de medir la radiación electromagnética de los cuerpos que atraviesan su campo de visión. La aplicación de esta herramienta electrónica es sugerida por Jesús Muñoz cuando en su proyecto de un sistema de semaforización inteligente [6] plantea la instalación de sensores en los postes de la intersección que permitan la lectura de los vehículos en horas pico. Figura 5. Ubicación y forma de detección del sensor infrarrojo.

FUENTE: MUÑOZ, A. Propuesta de implementación del sistema electrónico de semaforización inteligente en la avenida Luis Gonzales que conforma la zona del damero de Chiclayo. [En línea]. Lambayeque. [Citado el 15 mayo 2020]. Disponible en internet <http://repositorio.unprg.edu.pe/bitstream/handle/UNPRG/6064/BC-3302%20MU%c3%91OZ%20ZAMBRANO.pdf?sequence=1&isAllowed=y> Como se puede apreciar en la figura 5, el sensor lee la cantidad de vehículos que atraviesan y, junto a información que almacena sobre la zona donde se movilizan los automoviles puede establecer una nueva rutina para la intersección de estudio. Ya está claro que los sensores son aquellas herramientas empleadas para la detección del tráfico, ahora, una tecnología que complementa estas propuestas es la de los algoritmos de reconocimiento. En la revista INFOCIENCIA de la Universidad de las Fuerzas Armadas ESPE extensión Latacunga, los autores Fernando Mejía, German Torres y Eduardo Villa en su artículo Modelo de Semáforo inteligente empleando un algoritmo genético [7] proponen una forma novedosa de aplicar los avances tecnológicos más recientes a las situaciones cotidianas que aquejan una población como lo es el caos vehicular. Como lo explica Sergio Nesmachnow en su artículo Algoritmos genéticos paralelos y su aplicación al diseño

22

de redes de comunicaciones confiables [8]; los algoritmos genéticos constituyen una de las técnicas más evolutivas y difundidas de la actualidad, trabajan en base a soluciones potenciales de acuerdo a interacciones y transformaciones únicas. Volviendo al tema, el proyecto en el que basan su artículo roza con el bloque de identificación mediante sensores ya que el modelo para la detección de la cantidad de vehículos presentes en la vía se realiza mediante sensores de impacto o de presión ubicados a 3 distintas distancias respecto al semáforo (80mts, 40 mts y 2mts), sumado a un sensor de proximidad ubicado en la parte izquierda y otro en la derecha de la vía. Estas cadenas de sensores permiten la plena identificación del tráfico vehicular y así se crea la primera generación de tiempos de los ciclos del color verde y rojo fijando 2 segundos para el amarillo. Una vez establecidos estos tiempos y llevados a la práctica, la función de adaptación del sistema evalúa el impacto que tuvo el sistema en su tarea de descongestionar las vías, realizando una comparación del flujo vehicular y los tiempos de ciclo, dicha información queda almacenada para las próximas generaciones de este semáforo. Figura 6. Ubicación de sensores

FUENTE: MEJÍA, F., TORRES, G., VILLA, E. Modelo de semáforo inteligente empleando un algoritmo genético. [En línea]. Chimborazo. [Citado el 15 mayo 2020]. Disponible en internet < https://journal.espe.edu.ec/ojs/index.php/Infociencia/article/view/1177/pdf> Los autores al final de este articulo concluyen que si es posible lograr el control vehicular de una ciudad mediante la aplicación de algoritmos genéticos, eso sí, conociendo cuales son las mejores metodologías para la construcción de los algoritmos.

23

1.5.2.2. Procesamiento de imágenes. El procesamiento de imágenes para la identificación del tráfico vehicular es otra de las propuestas bastante sugeridas por los grupos investigativos de esta materia. Existen múltiples herramientas que pueden emplearse y pueden ir desde la más sencilla hasta el sistema más complejo y entrenado. Por ejemplo, el caso de la autora Carla Chávez en su trabajo “Sistema de semaforización inteligente para el control del flujo vehicular mediante el procesamiento digital de imágenes [9], propone el uso de Matlab. El autor Fernando Bianchi define Matlab como “Un lenguaje de alto nivel que permite hacer cálculos, visualizar resultados y desarrollar algoritmos utilizando noción matemática” [23]. Esta es la herramienta que se elige para realizar la identificación de la cantidad de vehículos que hay en fotografías tomadas por dos cámaras ubicadas en la intersección. El método que se emplea para identificar vehículos es el de Canny, que consiste en una segmentación de bordes. Una vez segmentados los bordes ya se puede realizar el conteo de vehículos en la imagen y enviar esta información para que sea interpretada y modifique los tiempos de ciclo. Figura 7. Identificación de bordes por el método de Canny.

FUENTE: CHAVEZ, C. Sistema de semaforización inteligente para el control de flujo vehicular mediante el Procesamiento Digital de Imágenes”. [En línea]. Ambato. [Citado el 15 mayo 2020]. Disponible en internet < https://repositorio.uta.edu.ec/bitstream/123456789/13061/1/Tesis_t1033ec.pdf > Esta es una herramienta bastante sencilla y puede que en aplicaciones a escala real, es decir, en una avenida principal, falle. Igualmente se tiene en cuenta para el estudio de nuevas herramientas pues presenta falencias que pueden ser evitadas por futuros grupos de trabajo, o, ilustrar a otros nuevos proyectos. Comenzando con unos sistemas un poco más complejos se encuentras las FPGA´s. La FPGA como lo afirman López Vallejo & Ayala Rodrigo en su escrito FPGA: Nociones básicas e implementación [24], consisten en una matriz bidimensional de bloques configurables que se pueden interconectar mediante recursos generales de interconexión. Los autores Félix Daniel Ochoa de la Cruz & Eduardo Joel Pariona Lozano en su trabajo de investigación “Diseño de un sistema electrónico basado en FPGA y visión artificial para el control de tráfico vehicular en la avenida Abancay”

24

[10] establecen un sistema de semaforización donde se emplean 4 cámaras para la obtención de fotografías de la vía las cuales son enviadas mediante protocolo Ethernet hacia el FPGA quien en primera fase ejecuta tareas pre-procesamiento. En la segunda fase el FPGA se encarga del cálculo de la densidad vehicular además de comparaciones con escenarios con la finalidad de representar el flujo vehicular y asignar nuevos tiempos en los semáforos. Debido al auge de la colaboración entre el procesamiento de imágenes y el control de tráfico vehicular, se comenzaron a desarrollar sistemas completos dedicados específicamente a esta tarea y que se pueden aplicar en diversos espacios sin necesidad de muchos componentes que le acompañen, este precisamente es el modelo de sistema embebido Traficam. La detección del tráfico vehicular mediante el sistema Traficam es una solución bastante innovadora, pues, se trata de una cámara pre entrenada para la identificación del flujo vehicular específicamente [25]. Los autores Luz David & John Mendigaña en su Artículo “Diseño de un sistema de semaforización electrónico” de la Universidad Distrital Francisco José de Caldas [11], plantean un proyecto dedicado al aumento de la seguridad dentro de empresas debido a los accidentes laborales presentados a causa de el desorden del tráfico en la línea de producción. El sistema Traficam permite soluciones en reducción de accidentes, mejoramiento del flujo vehicular y detección inteligente de problemas en la vía, es por ello que su decisión se inclina a la integración de esta herramienta a su proyecto. El sistema está constituido por 2 cámaras las cuales detectan vehículos día y noche, realiza conteo, detecta contraflujo vehicular y se adapta a cualquier tipo de superficie además de no demandar un alto consumo energético. Traficam cuenta con una interfaz la cual se encarga de enviarle los datos del estado actual vehicular en el semáforo para que un controlador reciba e interprete la información, de forma tal que se maneje acorde a ello el cambio de estado de los semáforos. Figura 8. Esquema de ubicación de cámara Traficam

Diseño de un sistema de semaforización electrónico. Luz, David y Mendigaña, John. 2013. 16, Bogotá : Ingeniería solidaria, 2013, Vol. 9.

25

González, Carlos. 2010. Escuela Superior de Informatica. [En línea] 2010. [Citado el: 15 de Junio de 2020.] https://www.esi.uclm.es/www/cglez/downloads/docencia/2011_Softcomputing/LogicaDifusa.pdf. Los resultados de aplicar este tipo de tecnología para los autores no solo se resumen en expresar la efectividad en la detección del tráfico en el semáforo, sino también de recalcar la gran utilidad en tareas importantes para la reducción de accidentes como por ejemplo el registrar vehículos en ‘contravía’. También, los autores hacen hincapié en la gran ventaja de interpretar cuando un vehículo está en estado de reposo durante bastante tiempo para no contarlo como un objeto en espera de cambio de señalización. 1.5.2.3 Lógica difusa La lógica difusa es una metodología empleada para obtener una conclusión a partir de información imprecisa, su creador el profesor Lofti A. Zaded se basó en su inconformidad con los conjuntos clásicos en los que un valor pertenece o no a un conjunto, para diseñar este método el cual permite que existan variables con valores intermedios[19]. La lógica difusa tiene una particularidad, aquella que menciona el mismo Zaded en su artículo “Quantitative Fuzzy Semantics” donde enuncia que: “La lógica difusa trata de copiar la forma en que los humanos toman decisiones” [12]. Analizando esta idea, en la cotidianidad las decisiones que tomamos se basan más que todo en valores cualitativos, muy pocas veces cuantitativos, y estos suelen ser imprecisos y dispersos. Un ejemplo que explica la forma en que a diario aplicamos la lógica difusa lo encontramos a la hora de tomar una ducha. Las duchas con calefacción en ocasiones emplean 2 perillas las cuales dependiendo de la cantidad de giro que se le dé permitirán el paso de agua a determinada temperatura. Si se desea dar la instrucción a una persona que usará la ducha por primera vez, estas se le dan de forma cualitativa y usando adjetivos imprecisos, por ejemplo: “un poco a la izquierda” o “un poquito a la derecha”. Estos adjetivos no tienen un valor numérico y la persona que abrirá las perillas debe basarse en su conocimiento para determinar qué tanto es “un poquito” y obtener el agua a la temperatura por la cual consultó. Por lo explicado anteriormente, se entiende que la lógica difusa de un suceso la determina una persona a la que se le puede denominar “experto”, el experto es quien conoce el tema y tiene las bases necesarias para otorgar valores y cantidades a las variables que componen al sistema y crear así los límites de los conjuntos.

26

Figura 9. Funciones difusas

FUENTE: FREEPNG.ES, [En línea]. < https://www.freepng.es/hd-png/%C3%A1lgebra-de-boole.html> Como se puede apreciar en la figura 9, se refleja el principio de la lógica difusa donde los conjuntos se cruzan y hay valores que abarcan tanto al conjunto “cold” como el conjunto “warm”. 1.6 MARCO METODOLÓGICO Se aplica una metodología mixta (cuantitativa y cualitativa), que parte de la recopilación de información documental sobre aspectos más relevantes de la investigación para la comprensión de conceptos y teoría. A continuación, se presentan las fases metodológicas consideradas para el desarrollo de la investigación.

Se realizó el reconocimiento de las variables viales de la zona de estudio a fin de identificar flujos, ciclos semafóricos, entre otras.

Se investigó sobre la estructura y diseño de un sistema difuso. Como establecer sus entradas, salidas y reglas difusas.

Se diseña el cruce vial en el software simulador de tráfico para recolectar datos del comportamiento de los vehículos a diferentes flujos y tiempos semafóricos.

Se identificaron los componentes electrónicos y elementos empleados para el sistema semafórico.

Se diseña el sistema electrónico para comprobar su funcionamiento mediante software simulador.

27

Se programa e implementa el circuito electrónico para corroborar su funcionamiento al momento de integrar todos los sistemas individuales.

Se realizan las pruebas con imágenes obtenidas de la malla vial.

28

2. SELECCIÓN DE SOFTWARE Y HARDWARE.

Existen muchas herramientas que se ofrecen para desempeñar las funciones que requieren este proyecto, es por ello por lo que es necesario realizar un análisis sobre las ventajas y desventajas que ofrece cada una de ellas en función a las necesidades del sistema. Los componentes principales para seleccionar en el sistema son:

1. El sistema de inteligencia artificial.

2. Sistema embebido.

3. Cámara.

4. Sensores. A continuación se realiza la explicación sobre las herramientas elegidas para el sistema. 2.1 INTELIGENCIA ARTÍFICIAL. La inteligencia artificial es la capacidad de las máquinas para usar algoritmos, aprender de los datos y utilizar lo aprendido en la toma de decisiones tal como lo haría un ser humano [13]. Existen múltiples plataformas digitales las cuales tienen la capacidad de analizar imágenes y dar una respuesta sobre la cantidad de objetos que se le solicita identificar. La elección de dicha herramienta se realiza en base a tres aspectos:

1. Investigación sobre software, librerías y plataformas orientadas al procesamiento de imágenes.

2. Selección de las herramientas que se ajusten de manera más fácil a los requerimientos del proyecto.

3. Comparación en base a las características de las herramientas seleccionadas en este punto.

2.1.1 Software, librerías y plataformas Existen diversas herramientas orientadas hacia el reconocimiento de imágenes las cuales brindan sus servicios de diferentes formas, bien sea por API (Interfaz para un servicio), SDK (Conjunto de herramientas) o servicio locales. Algunas de estas varias opciones son: OpenCV, Amazon Rekognition, Microsoft Computer Vision API, SimpleCV, Google Cloud Vision API, Scikit-image, Clarifai, IBM Watson Visual Recognition, Microsoft Video API, Azure, Face API, DeepPy, Microsoft Emotion API, Deepdream.

29

2.1.2. Herramientas potenciales De las 13 opciones mencionadas en el apartado anterior, se realiza un filtro el cual nos permita extraer un grupo reducido de aplicaciones el cual nos permita llegar a la más adecuada. Los filtros establecidos son:

Servicio API: con este filtro se busca consumir un servicio que desarrolla la labor de identificación de objetos mediante los servidores de la herramienta a contratar.

Capa gratuita: gracias a la variedad de sistemas para el procesamiento de imágenes, se cuenta con una buena cantidad de ofertas las cuales permiten el ahorro en costos, pues comprenden un periodo donde la herramienta presta el servicio sin ningún tipo de recargo, esto sumado a un buen servicio puede ser clave para cualquier proyecto.

Evitar entrenamiento robusto: Evitar un entrenamiento basado en una gran cantidad de información, además de poder aprovechar los servidores brindados por la compañía desarrolladora.

Tabla 2. Comparación de servicios en sus características de API, capa gratuita y no entrenamiento robusto.

Aplicación API Capa gratuita

No tiene entrenamiento

robusto OpenCV ✔

Amazon rekognition ✔ ✔ ✔ Microsoft visión API ✔ ✔ ✔

SimpleCV ✔

Google cloud visión API ✔ ✔ ✔ Scikit-image ✔

Clarifai ✔ ✔

IBM Watson Visual Recognition

✔ ✔ ✔

Microsoft video API ✔ ✔

Azure face API ✔ ✔

DeepPy ✔

Microsoft Emotion API ✔ ✔

DeepDream ✔

30

Una vez considerados los filtros mencionados las mejores opciones son: Amazon Rekognition, Microsoft computer vision API, Google cloud visial API & IBM Watson visual recognition. 2.1.3 Comparación y selección del servicio Una vez analizadas las herramientas para el procesamiento de imágenes y aplicados los filtros API, capa y robustez, la tabla 2 nos deja como las 4 opciones más destacadas: Amazon Rekognition, Microsoft Company Vision API, IBM Watson Visual Recognition y Google Cloud Visual API. En base a dicha elección se realiza una comparación de las características más relevantes de cada herramienta teniendo en cuenta aspectos como:

Fiabilidad.

Costo.

Velocidad de respuesta. 2.1.3.1 Fiabilidad Para estudios de fiabilidad de cada uno de los sistemas se cuenta con una base de fotografías de la malla vial donde algunas presentan muy poca congestión, mediana congestión y vías congestionadas. La forma de obtener la fiabilidad fue mediante la siguiente ecuación:

𝐹𝑖𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = (𝑣𝑒ℎ𝑖𝑐𝑢𝑙𝑜𝑠𝐷𝑒𝑡𝑒𝑐𝑡𝑎𝑑𝑜𝑠

𝑉𝑒ℎ𝑖𝑐𝑢𝑙𝑜𝑠𝐸𝑥𝑖𝑠𝑡𝑒𝑛𝑡𝑒𝑠) ∗ 100 (1)

A continuación se presentan 4 fotografías en forma de collage donde se pueden apreciar recuadros que encierran a los vehículos que pasan por la avenida en horas de baja congestión, las detecciones corresponden a las herramientas ya mencionadas (AWS, google, IBM cloud y Microsoft):

31

Figura 10. Comparación de servicios en fiabilidad.

FUENTE: Fotografía tomada por los autores. Para hablar de fiabilidad se evalúa entre los 4 sistemas cual es el que tiene una mejor detección de la cantidad de vehículos que se encuentran en la calzada. En la tabla 3 se reflejan los resultados obtenidos por cada software, dividiéndola en columnas por la cantidad de vehículos detectados, vehículos existentes en la imagen (valor dado por el conteo de una persona) y el porcentaje de acierto que haya tenido cada software: Tabla 3. Comparación de fiabilidad.

Plataforma Vehículos Detectados

Vehículos Existentes

%

AWS 11 11 100% Google Cloud 4 11 36.36%

IBM cloud 6 11 54.54% Microsoft 4 11 36.36%

Fuente: Elaboración propia. Una vez considerados los filtros mencionados las mejores opciones son: Amazon Rekognition, Microsoft computer vision API, Google cloud visial API & IBM Watson visual recognition.

32

2.1.3.2 Costo La comparación de costos de las 4 opciones consideradas se realiza en base a la cantidad de imágenes por mes que ofrecen sus capas gratuitas y el precio que cobra cada software por cada 1000 imágenes adicionales de las que ofrece la capa gratuita. En la tabla 4 se contemplan los costos de cada plataforma: Tabla 4. Comparación de costos

AWS IBM Microsoft Google

Capa gratuita de imágenes por mes

5000 1000 5000 1000

precio por 1000 imágenes adicionales

1,30 USD 2,30 USD 1,00 USD 1,50 USD

Fuente: Elaboración propia. AWS y Microsoft son los software´s que ofrecen mayor cantidad de imágenes en sus capas gratuitas por mes aunque es eta última aquella que destaca por ofrecer el precio más bajo por cada 1000 imágenes adicionales.

2.1.3.3 Velocidad de respuesta El ítem velocidad de respuesta fundamenta su comparación en el tiempo en que tarda en llegar la respuesta desde el momento en que se envía la imagen para que se le realice el análisis vehicular. Se llevaron a cabo pruebas de velocidad de respuesta en cada una de las 4 herramientas pre – seleccionadas y los resultados fueron los siguientes: Tabla 5. Comparación en velocidad de respuesta

# AWS IBM Microsoft Google

1 2,01 3,2 7,32 3,31

2 2,05 3,03 8,83 5,65

3 2,46 2,38 4,6 3,02

4 2,41 3,78 6,32 3,29

5 2,05 2,83 8,33 2,75

6 2,12 2,52 9,56 3,08

7 2,06 2,54 7,78 3,14

8 2,12 2,97 5,17 3,24 9 2,17 2,39 7,11 3,38

10 2,74 2,71 5,89 3,55

Promedio 2,219 s 2,835 s 7,091 s 3,441 s Fuente: Elaboración propia.

33

Por tiempo de respuesta es la herramienta AWS aquella con el mejor tiempo de respuesta promedio de los 4 software´s. Finalmente, al analizar todas las ventajas y desventajas de las 4 herramientas sometidas a comparación se concluye que AWS es el software que ofrece mayor fiabilidad en el análisis de imágenes, más rápida velocidad de respuesta y, a pesar de que en costo la mejor opción es Microsoft, AWS no dista mucho de este precio y su superioridad en los ítems anteriormente mencionados hacen que la inversión valga realmente la pena. Es por ello que Amazon Rekognition es el software elegido para el presente proyecto. 2.2 RASPBERRY Un sistema embebido o empotrado (integrado, incrustado) es una estructura de computación diseñada para realizar una o algunas pocas funciones dedicadas, frecuentemente en un sistema de computación en tiempo real [28]. Para este proyecto se necesita que el sistema embebido cumpla los siguientes requerimientos:

Conexión a internet: El sistema estará en continua comunicación con el

servidor central usando protocolos HTTP y MQTT (ver capitulo 6)

Que permita conexión de cámara web: Para la obtención de las imágenes de

la vía.

Protocolo UART: Para la comunicación con el microcontrolador encargado

del control de las luces.

Capacidad de almacenar mucha información: debe tener la capacidad de

almacenar las imágenes tomadas, para luego ser enviadas al servidor.

Que se pueda programar con algún lenguaje de alto nivel: Los lenguajes de

programación de alto nivel expresan los algoritmos de una manera adecuada

a la capacidad cognitiva humana, esto hace más fácil su continuo desarrollo

y mejora, además, este lenguaje preferiblemente debe ser interpretado, para

que no se necesite compilar cada vez que se hace un cambio en el código.

En el mercado se destacan las siguientes opciones:

34

Fuente: Rodrigo, A. Hz hard zone. [En línea] 08 de Julio de 2020. [Citado el 02 de

Agosto de 2020]. [<https://hardzone.es/reportajes/listas/alternativas-raspberry-pi-

4/>]

Cabe destacar que, aunque la placa Arduino no se considere un sistema embebido,

debido a sus especificaciones técnicas y físicas se decide incluirla en este análisis.

Tabla 6. Comparación de sistemas

Raspberry pi 3

Raspberry pi zero

Arduino Mega

ASUS tinkerboard

Banana Pi BPI M3

NanoPi M4

Conexión a internet

10/100 Ethernet, 2.4GHz 802.11n wireless

802.11 b/g/n wireless LAN

Hay placas Arduino homologadas con modulos Wifi integrados, o se puede conectar por módulo wifi ESP8266 externo

802.11 b/g/n wireless LAN

802.11 b/g/n wireless LAN

802.11 a/b/g/n wireless LAN

Figura 11. Opciones del mercado

35

Tabla 6. (Continuación)

Cámara Web Camera Serial Interface (CSI) o con cámara web USB

Camera Serial Interface (CSI)

únicamente Con modulo, por ejemplo Ov7670

Con módulo de cámara o cámara web USB

Con módulo de cámara o cámara web USB

Con módulo de cámara o cámara web USB

Protocolo UART

Si por puertos GPIO

Si, por puertos GPIO

Si, por puertos digital

Si, por puertos GPIO

Si, por puertos GPIO

Si, por puertos GPIO

Almacenamiento

máximo 256GB por Micro SD

máximo 256GB por Micro SD

Se necesita un módulo adicional de micro SD

máximo 256GB por Micro SD

8GB de memoria eMMC en la placa, o slot para expansión Micro SD máximo de 256GB

Slot para expansión Micro SD máximo de 256GB

Lenguaje alto nivel

Si, Python

Si, Python

No, es una variación de C

Si, Python

Si, Python

Si, Python

Costo COP $310.000

COP $113.000

COP $113000

COP $354000

COP $230000

COP $385000

Teniendo en cuentas estas opciones de decide escoger la Raspberry pi 3 modelo B, debido a que cumple con todos los requisitos técnicos, su precio, además, es el 3 más bajo, sin embargo, las dos primeras opciones con precios más bajos hace obligatorio el uso de módulos o expansores que implican más conexiones y más espacio físico necesario para todos los elementos, finalmente la Raspberry pi es un tarjeta más fácil de encontrar en el mercado local y ya se tiene experiencia en su utilización.

36

2.3 CÁMARA La cámara es un elemento importante en el sistema debido a que está involucrada en el proceso de conteo de vehículos, asegurando una buena definición de la imagen se puede asegurar que el procesamiento y detección de vehículos sea lo más fiable posible. Teniendo en cuenta que el sistema embebido seleccionado es la Raspberry pi 3, en el análisis entran las cámaras web convencionales y los módulos de cámara web compatibles con Raspberry. Primero se desea comprobar hasta qué punto la resolución de la fotografía afecta la detección de vehículos, para esto se analizan las resoluciones 480p, 720p y 1080p [29], resoluciones más grandes implicarían también imágenes con tamaño de archivo más grande y puede afectar los tiempos en los que se envía la imagen al servidor (ver capitulo 6). Para la prueba se utiliza la misma imagen redimensionada a las 3 resoluciones y se determina si afecta en el procesamiento en AWS Rekognition. Figura 12. Comparación de resoluciones (480p, 720p, 1080p)

Como se puede evidenciar en la figura 12, en la resolución 480p (izquierda) se dejan de detectar algunos elementos, en las resoluciones 720p y 1080p (centro y derecha respectivamente) no se pierde ningún elemento permitiendo un mejor conteo de vehículos al procesar cualquier imagen, por lo tanto, se determina que la resolución óptima es de 720p que implica una imagen de buena definición, pero de poco peso. Una vez se define esto se analizan las siguientes opciones de cámara:

37

Figura 13. Comparación de modelos de cámaras

Fuente: Desconocido. [En línea] 03 de agosto de 2020. [<https://www.raspberrypi.org/homepage-9df4b/static/621b26de7977c5b8d765b3003b341a49/ae23f/68fe7e4cb53767ad6c033bf3b46da3452188a24a_pi-camera-front-1-1426x1080.jpg>] Tabla 7. Comparación en calidad de cámaras

Raspberry pi Camera V2

ELP 1MP USB Camera

Logitech C270 SAT C270

Resolución 1080p 720p 720p 1080p

USB No, por interfaz

CSI dedicada SI Si Si

Exteriores No Si No No

Observaciones

Recomendada para elementos

fijos

Cable de 5m, luz diurna y

nocturna

Web Cam, ángulo

ajustable

Web Cam, ángulo

ajustable

Precio COP $82000 COP $160000 COP $171000 COP $89000 La cámara ELP cumple con los requisitos técnicos; tiene soporte para Linux (Sistema operativo de la Raspberry), la resolución es óptima para el sistema y además, cuenta con 2 particularidades bastante útiles para esta aplicación, es una cámara ideal para exteriores, por lo tanto está protegida de la filtración de agua, y tiene un soporte ajustable que solo necesita atornillarse, esto ahorra espacio porque ya no es necesario construir una estructura adicional en la cámara. Aunque la cámara ELP es la segunda más costosa entre estas opciones, las particularidades de este modelo la hacen ideal en esta aplicación.

38

2.4 SENSORES Existen variables que el sistema debe conocer como son las condiciones meteorológicas del día, para esto se deben emplear dos tipos de sensores uno que mida la cantidad de luz y otro la humedad del ambiente. Esto debido a que este no funciona en horarios nocturnos ni cuando se encuentre lloviendo en la ciudad. 2.4.1 Sensor de luz TSL2561 Figura 14. Módulo TSL2561.

FUENTE: THAOYU ELECTRONICS. [En línea]. [Disponible en internet < https://www.hotmcu.com/luminosity-sensor-tsl2561-p-187.html > Para comprender la forma de reconocimiento de la intensidad lumínica de este sensor, es necesario primeramente definir la unidad de medida de luz en la que trabaja, esta es el LUX. Un lux es la medida de la luminancia en el sistema internacional y corresponde a 1 lumen/m2. A continuación se enuncian las ventajas de emplear este sensor para comprender un poco su funcionamiento y el ¿Por qué elegirlo? [20]:

Rango muy similar al ojo humano.

Medición precisa en diferentes ambientes lumínicos.

Tiene una temperatura de funcionamiento entre los -30 a 80°C.

Rango de 0.1 a 40000 lux.

39

Alimentación de 2.7 a 3.6 V

Interfaz I2C.

Consumo de energía de tan solo 15mA.

Tiene la capacidad de medir intensidad de luz visible, infrarroja y ultravioleta.

Bajo costo.

Como se puede observar en la lista de especificaciones de este sensor, cuenta con un buen rango de medición, además de requerir muy poco voltaje, consumir una cantidad baja de corriente, etc. Pero la cualidad que más llama la atención de este dispositivo es que puede medir intensidades de luz con diferentes longitudes de onda a la que tiene la luz visible, por lo tanto se considera que este sensor ofrece las características que se requieren en este proyecto. 2.4.2 Sensor de humedad DHT22 El valor de la humedad en el ambiente es importante en el desarrollo de este proyecto ya que, en condiciones de lluvia se puede afectar la visibilidad de la cámara y afectar los cálculos de flujo vehicular del sistema ocasionando posiblemente que las rutinas no se ajusten al tráfico que se está presentando, es por ello que es necesario implementar un sensor de humedad al sistema, en este caso, el DHT22. Figura 15. Módulo DHT22.

FUENTE: COMPONENTES 101. [En línea]. [Disponible en internet < https://components101.com/sensors/dht22-pinout-specs-datasheet > A continuación se presentan las características que tiene este pequeño dispositivo [21]:

40

Voltaje de operación: 3.5 - 5.5 V.

Corriente de funcionamiento: 0.3Ma.

Rango de temperatura: -40 a 80°C.

Rango de humedad: 0 - 100%.

Vale resaltar que este sensor también tiene la capacidad de medir temperatura. El sensor DHT22 tiene un “reemplazo” por llamarlo de alguna manera y se trata del DHT11, se diferencia de este en que maneja rangos de medición de temperatura y de humedad mucho más amplios, y es por esta cualidad precisamente que el elegido es el 22 ya que para la identificación de los niveles de humedad se necesitarán medidas superiores a 80% y el DHT11 no las puede detectar.

41

3. SIMULACIÓN Y LÓGICA DIFUSA.

La simulación de la intersección es uno de los pasos más importantes en el proyecto, por lo tanto es importante elegir un software que brinda las herramientas que se requieren para construir de la manera más real posible. Synchro es una herramienta bastante potente para el desarrollo y simulación de escenarios viales además de ofrecer una interfaz gráfica bastante fácil de entender y manejar cuando se es primerizo con ella. Figura 16. Captura de pantalla obtenida del programa Synchro 8.

FUENTE: Programa de simulación Synchro 8. Como se puede observar en la figura 16, el espacio de diseño del programa Synchro 8 presenta sus herramientas en la misma ventana, en la parte superior se encuentra la barra con las que se puede realizar tareas como:

Definir las propiedades de las vías, es decir, cantidad de carriles, medidas, velocidad, inclinación, factores de giro, dirección, entre otras propiedades de las vías.

Definir las propiedades del volumen vehicular, es decir, determinar la cantidad de vehículos que pasan, presencia de peatones, presencia de ciclistas, bloqueos por buses, porcentaje de aparición de vehículos pesados, etc.

Definir las propiedades de los ciclos semafóricos, es decir, los tiempos de verde, rojo y ámbar, el orden en que cambian las fases, definir las cantidades de vehículos que giran o toman otras direcciones, etc.

42

Este programa en especial ofrece una herramienta llamada “Detector”, con ella se pueden emplear detectores de vehículos en las vías los cuales pueden identificar cuando hay un automóvil sobre él y avisar a semáforos para dar prioridad a este carril, algo muy semejante a la función del sensor loop en aplicaciones de semaforización.

Las herramientas mencionadas hacen parte del ambiente de desarrollo de synchro 8, pero, en esta misma barra se encuentra una pequeña herramienta que es una extensión del programa y permite simular todo el diseño que se ha realizado, esta es Simtrafic, al ejecutarla nos redirección a la simulación creada en Synchro. 3.1 SIMULACIÓN SYNCHRO 8. El software ya mencionado, Synchro 8 permite, además, ajustar parámetros que logran simular de una manera muy similar a la que se presenta el tráfico en la malla vial. El primer parámetro que se establece en el simulador es el del flujo de vehículos por hora (vph), este valor se definió teniendo en cuenta la cantidad de vehículos que atraviesan cada semáforo dependiendo la vía y la congestión de la misma, se calcularon de la siguiente forma: 3.1.1 Zona de estudio

La intersección modelo que se emplea para el estudio en cuestión es la de Carrera 7ma con Calle 45 de la ciudad de Bogotá D.C, Colombia. Figura 17. Fotografía de la zona en la que se basa el estudio.

FUENTE: Google earth. (s.f.). [Mapa de Bogotá, Colombia en Google maps]. Citado el 12 de Agosto 2020. [Disponible en internet https://www.google.com/intl/es/earth/] Esta intersección consta de una carrera la cual posee 3 carriles tanto en sentido Norte - Sur como otros 3 en sentido Sur -Norte, una calle la cual posee 2 carriles en

43

sentido Oriente - Occidente como 2 en sentido Occidente - Oriente, y por último un angosto carril al atravesar la carrera séptima en sentido occidente - oriente. Además, en el cruce se ubican 3 semáforos repartidos de la siguiente manera: dos sobre la carrera séptima y uno sobre la 45. Figura 18. Fotografía del cruce obtenida de google maps.

FUENTE: Google maps. (s.f.). [Mapa de Bogotá, Colombia en Google maps]. Citado el 12 de Agosto 2020. [Disponible en internet https://www.google.com/maps/?hl=es] En este cruce se permiten giros de la siguiente manera:

Carrera séptima sentido sur - norte puede girar hacia el oriente.

Carrera séptima sentido norte - sur puede girar hacia el occidente.

Calle 45 sentido Occidente - Oriente puede girar hacia el Sur y hacia el Norte.

La intersección, además, cuenta con 8 semáforos peatonales que para efectos de este estudio no se tienen en cuenta.

3.1.2 Parámetro viales Los parámetros viales son aquellos que establecen el flujo que tendrá cada calzada al momento de realizar la simulación, en el programa Synchro 8 los flujos se establecen por hora, dato a tener en cuenta al momento de querer simular una situación vial. A continuación se presenta la manera en que se convierten datos de cantidad de vehículos por segundo a flujos por hora:

Para la carrera séptima: Se establece como medida de tráfico vehicular descongestionado cuando pasan por el semáforo 1 vehículo cada 2 segundos, flujo normal cuando pasan 1 vehículo por segundo y congestionado 2 vehículos por segundo.

44

Para la calle 45: Se establece como medida de tráfico vehicular descongestionado cuando pasan 1 vehículo cada 6 segundos, flujo normal cuando pasan 1 vehículo cada 4 segundos y congestionada 1 vehículo cada segundo.

Estos datos son asumidos por los integrantes del grupo basándose en la experiencia.

Al medir los tiempos en el cruce se observa que un ciclo actual de los semáforos consta de 50 segundos de verde en los de la carrera séptima y 27 en los de la calle 45 además de incluir 3 segundos de ámbar en cada uno, lo cual suma 83 segundos de ciclo semafórico. Teniendo en cuenta que en 1 hora hay 3600 segundos se realiza el cálculo de la cantidad de ciclos que hay en una hora:

3600 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠

83 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠= 43 𝑐𝑖𝑐𝑙𝑜𝑠 (2)

Ahora para el cálculo del flujo de vehículos por la carrera séptima se hace lo siguiente: Si en 83 segundos existen 50 segundos de verde + 3 segundos de ámbar, se hace el cálculo para un flujo congestionado (2 veh/s):

53 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠 ∗ 2 = 106 𝑣𝑒ℎ𝑖𝑐𝑢𝑙𝑜𝑠 (3)

Ahora estos 106 vehículos se multiplican por los 43 ciclos que hay en 1 hora:

106 𝑣𝑒ℎí𝑐𝑢𝑙𝑜𝑠 ∗ 43 = 4558 𝑣𝑒ℎ/ℎ (4) Para un flujo normal: Pasa 1veh/s lo que significa que pasan 53 vehículos por ciclo:

53 𝑣𝑒ℎí𝑐𝑢𝑙𝑜𝑠 ∗ 43 = 2279 𝑣𝑒ℎ/ℎ (5) Para un flujo descongestionado: Pasan 1 veh/2s lo que significa que pasan 27 vehículos por ciclo:

45

27 𝑣𝑒ℎí𝑐𝑢𝑙𝑜𝑠 ∗ 43 = 1160 𝑣𝑒ℎ/ℎ (6)

Ahora para el cálculo del flujo de vehículos por la calle 45 se hace lo siguiente: Si en 83 segundos existen 27 segundos de verde + 3 segundos de ámbar, se hace el cálculo para un flujo congestionado (1veh/2s):

30 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠/2 = 15 𝑣𝑒ℎí𝑐𝑢𝑙𝑜𝑠 (7) Ahora estos 15 vehículos en 43 ciclos equivalen a:

15 𝑣𝑒ℎí𝑐𝑢𝑙𝑜𝑠 ∗ 43 = 645 𝑣𝑒ℎ𝑖𝑐𝑢𝑙𝑜𝑠/ℎ (8) Para un flujo normal: Pasa 1veh/4s lo que significa que pasan 7 vehículos por ciclo:

7 𝑣𝑒ℎ ∗ 43 = 301 𝑣𝑒ℎ𝑖𝑐𝑢𝑙𝑜𝑠/ℎ (9) Para un flujo descongestionado: Pasa 1veh/6s lo que significa que pasan 5 vehículos por ciclo:

5 𝑣𝑒ℎ ∗ 43 = 215𝑣𝑒ℎ𝑖𝑐𝑢𝑙𝑜𝑠

ℎ (10)

En la tabla 8 podremos observar los flujos vehiculares por hora como quedaron calculados en los 43 ciclos resultantes: Tabla 8. Tabla con los flujos vehiculares para la zona.

FLUJOS VEHÍCULARES POR HORA.

VIA CONGESTIONADO FLUJO NORMAL DESCONGESTIONADO

CRA 7MA

4558 veh/h 2279 veh/h 1160 veh/h

CLL 45 645 veh/h 301 veh/h 215 veh/h

Fuente: Elaboración propia.

Teniendo en cuenta que estas vías tienen la opción de hacer giros, se debe establecer la cantidad de vehículos que giran o siguen de largo por la carretera, según la actividad de la vía se asumen unos porcentajes de giro: Para la carrera

46

séptima del 80-85% siguen de largo y del 10-15% gira, para la Calle 45 del 65 al 70% giran hacia el hacia el sur, del 8 al 12% siguen de largo y del 18 al 23% giran hacia el norte, de esta manera se obtiene:

Carrera 7ma en flujo normal: 2279 vehículos, 1954 siguen de largo y 325 giran.

Carrera 7ma en flujo congestionado: 4558 vehículos, 3908 siguen de largo, 650 giran.

Carrera 7ma en flujo descongestionado: 1160 vehículos, 960 siguen de largo, 200 giran.

Calle 45 en flujo normal: 645 vehículos, 429 giran hacia el sur, 68 siguen de largo y 148 giran hacia el norte.

Calle 45 en flujo congestionado: 301 vehículos, 211 giran hacia el sur, 25 siguen de largo y 65 giran hacia el norte.

Calle 45 en flujo descongestionado: 215 vehículos, 150 giran hacia el sur, 25 siguen de largo y 40 giran hacia el norte.

47

Tabla 9. Datos definidos para flujo vehicular en el simulador

FUENTE: Elaboración propia.

En la tabla 9 se observa cómo se establecen los valores de flujo según la vía y el rumbo de la misma. En ella misma se definen otros parámetros que se pueden ingresar de manera manual y otros los calcula el simulador. Link speed corresponde a la velocidad que van a tener los vehículos durante la simulación, este valor se define como 50km/h ya que este es el máximo permitido para transitar en vía urbana según la ley Colombiana. Otro factor que se define también es el del Lane Width el cual tienen que tener una medida mínima de 3.25m [14], en este caso los carriles tienen una medida de 3,6m. La carrera séptima es conocida por ser un corredor vial donde se movilizan considerables porcentajes de vehículos de transporte público, por lo tanto es importante resaltar esta característica en el simulador, además de considerar también los bloqueos que pueden causar los mismos. Tabla 10. Datos definidos para flujo vehicular en el simulador

Fuente: Captura de pantalla obtenida por el autor del simulador Synchro 8.

48

3.1.3 Parámetro semafóricos El software ofrece las opciones para definir los tiempos de verde de cada semáforo, establecer los giros permitidos y la forma en que cambian los semáforos, es decir, en un escenario donde existan más de 2 semáforos debería definirse cual cambia primero, a este valor Synchro 8 le llama Phase. Tabla 11. Medidas de los vehículos en el simulador.

Fuente: Captura de pantalla obtenida por el autor del simulador Synchro 8. En la simulación solo se presentan vehículos del tipo “Car 1” y “Car 2” y en cuanto a transporte público del tipo “Bus”. Las medidas de los automóviles se ajustan maso menos a la de un vehículo de la marca Sedan, una marca recurrente en la ciudad y de dimensiones generales respecto a otras marcas y modelos. Es importante definir esta medida ya que el simulador trae una por defecto que puede ser diferente a las de los vehículos recurrentes en la ciudad, situación que afecta en materia de espacio que ocupan en la fila del semáforo.

49

Figura 19. Medidas de un vehículo sedan.

FUENTE: MOTOR.ES. [En línea] [Citado el: 21 de Agosto de 2020.] https://www.motor.es/chevrolet/aveo/medidas. El resultado de todo este ajuste de parámetros para simulación se ve reflejado en un informe que nos genera el software SimTrafic, este informe se da en respuesta a un tiempo de grabación que se le establece al programa, durante este tiempo el informe recoge datos sobre todo lo que ocurre en la vía, el tiempo lo establece la persona según su necesidad. En esta ocasión el tiempo de grabación fue de 15 minutos. Tabla 12. Tiempo de grabación para el simulador.

FUENTE: Captura de pantalla tomada por el autor del simulador Synchro 8. Una vez definido el tiempo de grabación, se procede a grabar y generar el informe con lo que sucedió en estos 15 minutos. 3.1.4 Reporte de simulación Los reportes de simulación que genera SimTrafic son bastante completos ya que ofrece una larga lista de datos que puede generar en un ciclo de simulación para que el usuario elija que información quiere que sea relevante a la hora de generar su reporte.

50

En esta ocasión, el reporte que se genera para el análisis del flujo vehicular durante la grabación contiene los datos de los vehículos que cruzaron la intersección rotulados bajo el nombre de “vehicles exited”. Tabla 13. Datos del reporte de simulación.

FUENTE: Captura de pantalla obtenida por el autor del simulador Synchro 8. En la tabla 14 se puede apreciar de qué forma se abrevian las vías en el software Synchro.

51

Tabla 14. Siglas de las vías en el simulador.

Siglas Vía

EBT Cra 7 hacia el sur

EBR Cra 7 con giro hacia el Oriente

WBT Cra 7 hacia el norte

WBR Cra 7 con giro hacia el occidente

NBL Calle 45 con giro hacia el sur

NBT Calle 45 con giro hacia el Oriente

NBR Calle 45 con giro hacia el Norte

Fuente: Elaboración propia.

52

4. SISTEMA DIFUSO

La clave de la lógica difusa es la posibilidad de dar valores a variables lingüísticas acostumbradas (mucho, moderado, poco, alto, bajo, etc.) a la hora de tratar de explicar un evento. Llevando esto al caso de aplicación, las variables que normalmente se emplean para referirse a la situación vial que se está presentando en un cruce son: “Congestionado”, “descongestionado” o “normal” y se dan a partir de la percepción que tiene la persona que está observando, basándose en la experiencia que tiene sobre el tráfico cotidiano que hay en el cruce. Las variables toman valores que no necesariamente tienen que ser 0 o 1, sino que pueden abarcar un conjunto de valores y, si se desea, compartir valores con otros conjuntos. Se le llama función a la figura que forman los valores “limites” de cada variable, estas pueden ser: triangulares, trapezoidales, campana, pi, etc. En la figura 20 se observan algunas de las más famosas. Figura 20. Registro Fotográfico Toma de Datos de Agua Recolectada

Fuente: Descripción general de las técnicas de lógica difusa. [En linea]. [Citado el 24 de Agosto de 2020] [Disponible en internet http://www.tdx.cat/bitstream/handle/10803/6887/04Rpp04de11.pdf ] Volviendo al tema de los conjuntos, las funciones de la lógica pueden estar totalmente separadas o como ya se mencionó, solaparse entre sí, esto sería una afirmación más del principio de la lógica difusa.

53

4.1 VARIABLES DE ENTRADA Y SALIDA. Las variables lingüísticas con las que se diseñan las funciones del sistema corresponden a las mencionadas anteriormente, es decir:

Congestionado: Que corresponde a una situación de mucho tráfico vehicular y poco movimiento.

Descongestionado: Que corresponde a una situación de poco tráfico vehicular.

Flujo Normal: Que corresponde a una situación donde el tráfico no es exagerado pero tampoco es escaso y la movilidad no está limitada.

Estas variables tienen unos valores que le dan una forma triangular a la función, además, estas comparten ciertas cantidades de vehículos en la vía casi al final de los conjuntos, lo que significa que se solapan. Las entradas sobre su eje X poseen un rango el cual indica los valores de componen cada conjunto lingüístico, estos valores obedecen a las cifras que se le dieron a la situación vial congestionada, descongestionada y normal. El valor máximo del rango se elige considerando que muy difícilmente la cámara podrá fotografiar toda la vía, por ende se define como tope del rango 35 vehículos. Teniendo en cuenta la limitación de la cámara, los rangos de conjuntos son los siguientes: Sobre FLUJO7 como se le nombra a la variable de entrada del tráfico por la Cra 7ma.

Una situación de congestión obedece a 106 vehículos pasando por el semáforo en un ciclo. Si la cámara capta entre 19 y 35 vehículos en la vía mientras el semáforo se encuentra en rojo, le dará un status de congestionado a la situación vial.

Una situación de flujo normal obedece a 53 vehículos pasando por el semáforo en un ciclo. Si la cámara capta entre 13 y 20 vehículos en la vía mientras el semáforo se encuentra en rojo, le dará un status de flujo normal a la situación vial.

Una situación de descongestión obedece a 27 vehículos pasando por el semáforo en un ciclo. Si la cámara capta entre 0 y 14 vehículos en la vía mientras el semáforo se encuentra en rojo, le dará un status de descongestionado a la situación vial.

54

Sobre FLUJO45A como se le nombra a la variable de entrada del tráfico por la Cll 45.

Una situación de congestión obedece a 15 vehículos pasando por el semáforo en un ciclo. Si la cámara capta entre 11 y 35 vehículos en la vía mientras el semáforo se encuentra en rojo, le dará un status de congestión a la situación vial.

Una situación de flujo normal obedece a 7 vehículos pasando por el semáforo en un ciclo. Si la cámara capta entre 6 y 12 vehículos en la vía mientras el semáforo se encuentra en rojo, le dará un status de flujo normal a la situación vial.

Una situación de descongestión obedece a 5 vehículos pasando por el semáforo en un ciclo. Si la cámara capta entre 0 y 7 vehículos en la vía mientras el semáforo se encuentra en rojo, le dará un status de descongestión a la situación vial.

Cabe destacar que para este estudio no se tienen en cuenta los peatones ni las variaciones que puede tomar el sistema debido a su comportamiento.

A continuación se aprecia cómo quedan diseñadas las funciones de entrada y sus respectivos rangos:

Figura 21. Entradas del sistema difuso.

Fuente: Elaboración propia.

Para el caso de las salidas del sistema, las variables lingüísticas con las que se denominan los conjuntos siguen siendo las mismas pero sus rangos claramente se modifican ya que ahora no estarán en función de cantidad de vehículos detectados

55

sino de segundos que debe otorgar el semáforo a cada vía. Las salidas reciben los nombres de S1S2 y S3 y corresponden a:

S1S2 es el tiempo para los semáforos sobre la cra 7ma, si bien cierto que existen 2 flujos diferentes se deben comparar los 2 para conocer qué sentido de la vía está teniendo el mayor y otorgarle ese estado a toda la vía.

S3 es el tiempo para el semáforo ubicado sobre la Cll45.

Al igual que en las entradas la función de los conjuntos de salida es triangular y sus rangos son los siguientes:

Para S1S2.

Un tiempo “congestionado” según la cantidad de vehículos tendrá un rango entre los 60 y 75 segundos de verde.

Un tiempo “flujo normal” según la cantidad de vehículos tendrá un rango entre los 45 y 65 segundos de verde.

Un tiempo “descongestionado” según la cantidad de vehículos tendrá un rango entre los 40 y 50 segundos de verde.

PARA S3.

Un tiempo “congestionado” según la cantidad de vehículos tendrá un rango entre los 28 y 47 segundos de verde.

Un tiempo “flujo normal” según la cantidad de vehículos tendrá un rango entre los 18 y 29 segundos de verde.

Un tiempo “descongestionado” según la cantidad de vehículos tendrá un rango entre los 15 y 19 segundos de verde.

56

Figura 22. Salidas del sistema difuso

Fuente: Elaboración propia.

4.2 REGLAS DIFUSAS. La relación que se establece entre los conjuntos de entrada y salida del sistema se llama “regla” [22] y son definidas por el experto a partir de su conocimiento de la intersección, es decir, el experto modela las reglas buscando que cada una maneje el tráfico de la manera correcta para que en la vía no se presenten tiempos de rojo excesivos. Existen variadas formas de construir las reglas difusas como lo explica el autor Carlos Morcillo en su artículo Lógica difusa una introducción práctica [15], es el modelo TSK el que se emplea para este desarrollo ya que se compone de la forma:

𝑖𝑓 𝑥 𝑒𝑠 𝐴 𝑎𝑛𝑑 𝑦 𝑒𝑠 𝐵 𝑒𝑛𝑡𝑜𝑛𝑐𝑒𝑠 𝑧 𝑒𝑠 𝑘 (11) Para el diseño de las reglas se realizó un análisis de las posibles situaciones vehiculares que se pueden presentar en la malla vial con diferentes tiempos rotulados bajo los nombres de: Tiempo para flujo descongestionado, normal y congestionado. Los tiempos para flujo normal son los que se encuentran ahora mismo en la intersección, es decir, un flujo normal significan 50 segundos de verde en el semáforo de la cra séptima y 27 en el de la cll 45, un flujo congestionado requiere un aumento en el tiempo del ciclo de la vía que se encuentre con esta situación, para realizar este aumento se debe tener en cuenta también que debe ser proporcional a la dinámica de la intersección para no generar una congestión peor, es por ello que el tiempo en la cra 7ma se aumenta en 20 segundos y en la Cll 45, 10. Con los aumentos definidos para una situación de congestión tendremos 70 segundos en la 7ma y 37 en la 45, por lo tanto procedemos ahora a realizar los cambios para descongestión en esta via. Un escenario de descongestión en la carrera en ocasiones puede tratarse del mismo flujo vehicular que el de la 45 cuando esta se encuentra en “flujo normal”, por ende la reducción en el tiempo de esta vía

57

puede ser igual al de la calle para que ambos no signifiquen un cambio desmedido que empeore la situación vial, de esta forma se define como reducción de tiempo de verde para la séptima y la 45 un total de 10 segundos. Establecidos los rangos de congestión y los tiempos para cada escenario ahora sí se puede proceder a construir las reglas difusas. Para este ejercicio se combinó un análisis a partir del conocimiento vial de la zona y simulaciones realizadas y documentadas en un archivo de Excel donde se tienen en cuenta cada una de los flujos vehiculares y tiempos de ciclo semafórico, el proceso se explica de la siguiente manera:

Existen 3 posibles situaciones en cada una de las vías, es decir, congestionado, flujo normal y descongestionado, por lo tanto habrán 9 posibles escenarios que se puedan presentar en la intersección, estos son: C - FN, C - C, C- D, FN - C, FN - FN, FN - D, D - C, D - FN, D - D.

La misma explicación anterior aplica para la situación de los tiempos donde se presentan los mismos 9 casos. Ahora bien, el análisis se realiza modificando los flujos vehiculares en las 9 situaciones planteadas manteniendo 1 escenario de ciclo semafórico por conjunto de prueba, es decir, los casos C - FN, C - C, C- D, FN - C, FN - FN, FN - D, D - C, D - FN, D - D todos con tiempos C - FN, luego los mismos 9 casos con tiempos C - C y así sucesivamente hasta cubrir las 81 pruebas.

El objetivo de estas pruebas es documentar cuantos vehículos pasan por los semáforos en cada una de las situaciones de flujo con el fin de determinar en todos los escenarios de congestión cual es el tiempo que permite que pasen más vehículos por la intersección.

C: Congestionado. FN: Flujo Normal. D: Descongestionado.

A continuación, se presentan las tablas que ayudaron a establecer algunas de las reglas de la lógica difusa: El caso de estudio es para cuando el tráfico en la cra 7ma es CONGESTIONADO y en la 45 DESONGESTIONADO. Los tiempos del ciclo semafórico se irán variando para encontrar el que permita el mayor paso de vehículos en la intersección.

En la primera tabla se observan los resultados para la simulación con tiempos 27 y 50 de verde en la intersección, es decir, flujo normal en ambos

58

semáforos.

En la segunda tabla se observan los resultados para la simulación con tiempos 47 y 50 de verde en la intersección, es decir, congestionado y flujo normal en ambos semáforos.

Tabla 15. Casos de estudio para tiempos FN-FN.

Fuente: Elaboración propia.

Tabla 16. Casos de estudio para tiempos FN-CONG.

Fuente: Elaboración propia.

En la tercera tabla se observan los resultados para la simulación con tiempos 17 y 50 de verde en la intersección, es decir, descongestionado y flujo normal.

En la cuarta tabla se observan los resultados para la simulación con tiempos 27 y 40 de verde en la intersección, es decir, flujo normal y descongestionado.

N° VIA FLUJO DIRECCIONCANTIDAD DE

VEHICULOS

TIEMPO

ROJO

TIEMPO

AMBAR

TIEMPO

VERDE

ABREVIATURA

SYNCHRO 8

VEHICULOS

QUE PASAN

norte 3908 WBT 266

oriente 650 WBR 52

sur 3908 EBT 262

occidente 650 EBR 48 628

sur 150 NBL 9

oriente 25 NBT 3

norte 40 NBR 15 27

655

50

3. Cll 45 1 VEH/6s 50 27

TRÁFICO CONGESTIONADO 7MA Y SUAVE 45

TIEMPO DE PRUEBA 7 MINUTOS.

1. Cra 7ma hacia el norte

2 VEH/s27

3

50

2. Cra 7ma hacia el sur 27

N° VIA FLUJO DIRECCION

CANTIDAD

DE

VEHICULOS

TIEMPO

ROJO

TIEMPO

AMBAR

TIEMPO

VERDE

ABREVIATUR

A SYNCHRO

8

VEHICULOS

QUE PASAN

norte 3908 WBT 237

oriente 650 WBR 45

sur 3908 EBT 237

occidente 650 EBR 43 562

sur 150 NBL 8

oriente 25 NBT 3

norte 40 NBR 12 23

585

47 50

3. Cll 45 1 VEH/6s 50 47

TRÁFICO CONGESTIONADO 7MA Y SUAVE 45

TIEMPO DE PRUEBA 7 MINUTOS.

1. Cra 7ma hacia el norte

2 VEH/s47

3

50

2. Cra 7ma hacia el sur

59

Tabla 17. Casos de estudio para tiempos FN-DESC.

Fuente: Elaboración propia.

Tabla 18. Casos de estudio para tiempos DESC-FN.

Fuente: Elaboración propia.

En la quinta tabla se observan los resultados para la simulación con tiempos 47 y 40 de verde en la intersección, es decir, descongestionado y congestionado.

En la sexta tabla se observan los resultados para la simulación con tiempos 17 y 40 de verde en la intersección, es decir, descongestionado en ambos.

60

Tabla 19. Casos de estudio para tiempos DESC-CONG.

Tabla 20. Casos de estudio para tiempos DESC-DESC.

Fuente: Elaboración propia.

En la séptima tabla se observan los resultados para la simulación con tiempos 27 y 70 de verde en la intersección, es decir, flujo normal y congestionado.

En la octava tabla se observan los resultados para la simulación con tiempos 47 y 70 de verde en la intersección, es decir, congestionado en ambos.

Tabla 21. Casos de estudio para tiempos CONG-FN.

Fuente: Elaboración propia.

61

Tabla 22. Casos de estudio para tiempos CONG-CONG.

Fuente: Elaboración propia.

En la novena y última tabla se observan los resultados para la simulación con tiempos 17 y 70 de verde en la intersección, es decir, descongestionado y congestionado.

Tabla 23. Casos de estudio para tiempos CONG-DESC.

Fuente: Elaboración propia.

Una vez se recolecta toda la información de las simulaciones, se procede a calcular la cantidad de automóviles que pudieron avanzar por la intersección en cada ciclo semafórico, este digito corresponde a la suma de vehículos que avanzaron por la calle 45 hacia el sur, oriente y norte y de los que avanzaron por la 7ma hacia el norte, sur, oriente y occidente. Esta suma se registra en la parte inferior derecha de la tabla. Para este caso de estudio se observa que de las 9 simulaciones realizadas, es en la última en la que se encuentra el mayor número de vehículos que pudieron pasar por los semáforos. De acuerdo a la información de la tabla número 9 se puede establecer la primera regla difusa para el caso en que se encuentre congestión en la carrera séptima y descongestión en la calle 45, esta regla tendría la siguiente forma:

𝑖𝑓 𝐹𝐿𝑈𝐽𝑂7 𝑖𝑠 𝐶𝑜𝑛𝑔𝑒𝑠𝑡𝑖𝑜𝑛𝑎𝑑𝑜 𝑎𝑛𝑑 𝐹𝐿𝑈𝐽𝑂45𝐴 𝑖𝑠 𝐷𝑒𝑠𝑐𝑜𝑛𝑔𝑒𝑠𝑡𝑖𝑜𝑛𝑎𝑑𝑜 𝑒𝑛𝑡𝑜𝑛𝑐𝑒𝑠 𝑆1𝑆2 𝑒𝑠 𝐶𝑜𝑛𝑔𝑒𝑠𝑡𝑖𝑜𝑛𝑎𝑑𝑜 𝑆3 𝑒𝑠 𝐷𝑒𝑠𝑐𝑜𝑛𝑔𝑒𝑠𝑡𝑖𝑜𝑛𝑎𝑑𝑜 (11)

Esta regla quiere decir que:

62

Cuando el flujo de la carrera séptima está congestionado y el de la Cll45 está descongestionado, entonces, el semáforo de la séptima tendrá tiempo congestionado y el de la 45 descongestionado.

A continuación se presenta la tabla con el resto de las reglas difusas definidas para el sistema: Tabla 24. Reglas difusas definidas para el sistema.

Flujo 7ma

45A

Cong FlujoNorm Descong

Cong S1S2=cong S3= Normal

S1S2=Normal S3= Cong

S1S2=Normal S3= Cong

FlujoNorm S1S2=cong S3= Normal

S1S2=Normal S3= Normal

S1S2=Descong S3= Normal

Descong S1S2=cong S3= Descong

S1S2=Normal S3= Descong

S1S2=Normal S3= Descong

Una vez definidas las reglas difusas, procedemos a ingresarlas en el software de MATLAB para poder comenzar a simular situaciones de tráfico y obtener respuesta a situaciones reales. Figura 23. Ingreso de las reglas definidas en MATLAB.

Fuente: Captura de pantalla tomada por el autor del software MATLAB.

4.3 RESULTADOS DE LA LÓGICA DIFUSA. Una vez se cuenta con las entradas definidas, los resultados que se esperan a la salida y las reglas que debe seguir la lógica difusa, se procede a observar como la lógica a partir de reglas lingüísticas interpreta unas cantidades y es capaz de entregar un resultado numérico que determina los tiempos del ciclo semafórico.

63

Caso de ejemplo: se le entrega a la función Fuzzy diseñada en MATLAB un valor de 6 vehículos en el semáforo de la carrera séptima segundos antes de cambiar a verde y 28 vehículos sobre la calle 45, entonces: Figura 24. Ejemplo del funcionamiento del sistema difuso.

Fuente: Elaboración propia.

En la figura 24, se observa como la barra roja vertical establece los parámetros de entrada para el flujo en la carrera 7ma donde se ubican tan solo 6 vehículos y en la 45 un total de 28, siguiendo las reglas difusas que se le ajustaron los tiempos que arroja para los semáforos son: 55 segundos para la carrera séptima y 38 segundos para la Calle 45, aumentando en 11 al de la calle 45 a fin de descongestionarla sin reducir mucho el tiempo de la Cra Séptima pues, al ser una vía principal y mucho más importante que la 45 , reducir su tiempo podría significar acumular tráfico en el semáforo. Este proceso recibe datos ingresado manualmente ya que son las bases construidas en MATLAB, más adelante se explicará la forma en que llega a convertirse en parte de un sistema autónomo.

64

5. SISTEMA ELECTRÓNICO

El circuito electrónico del sistema cuenta con componentes para realizar tareas de:

1. Comunicación serial.

2. Medición de condiciones climatológicas.

3. Alimentación.

4. Respaldo energético.

5. Encendido de luces LED.

En la figura 25 se muestran las tareas a realizar.

Figura 25. Esquema de las tareas que realiza el circuito electrónico.

A continuación se explican cada uno de los componentes que hacen parte del sistema.

65

5.1 COMUNICACIÓN SERIAL. Una UART como la define Borja Díaz en su trabajo de fin de grado titulado “Universal Asynchronous receiver-transmiter [16],” es un dispositivo hardware capaz de traducir datos con formato paralelo a formato serie. El UART se compone de una entrada y una salida denominadas RX y TX las cuales significan receptor y transmisor respectivamente. Su forma de conexión es muy sencilla: El extremo receptor de uno de los dispositivos se conecta al transmisor del otro y el transmisor del primero al receptor del segundo, de esta manera se garantiza el envío y recepción de datos bilateral. Una última conexión corresponde a las tierras, pues estas deben ser comunes. En la figura 26 se ilustra la forma de conexión. Figura 26. Ejemplo del funcionamiento del sistema difuso.

Fuente: Dieguez, Loli. 2019. Kolwidi. [En línea] 27 de mayo de 2019. [Citado el: 25 de agosto de 2020.] https://kolwidi.com/blogs/blog-kolwidi/comunicaciones-serie-en-arduino-uart-i2c-y-spi. La comunicación serial en este proyecto se realiza entre una tarjeta Raspberry Pi 3 y un PIC 18F4550, estos elementos electrónicos manejan voltajes de salida diferentes en sus puertos UART, de llegar a realizarse una conexión directa entre estos se ocasionarían daños en los pines de la Raspberry pi 3, condición que obliga a añadir 2 circuitos que se encarguen de elevar y disminuir el voltaje entre estos 2 componentes. El primero se trata de un sistema con 2 transistores 2n2222 y 4 resistencias de 1k,. Lo que hacen simplemente es saturar el primero con el voltaje de salida del TX de la raspberry para que puedan fluir 5v hacia el RX del PIC18F4550, de esta manera se garantiza una señal de 5V a partir de una de 3.3V. En la siguiente figura se observa el circuito.

66

Figura 27. Circuito conversor de 3.3 a 5v

Fuente: Elaboración propia. Ahora hay que garantizar que la raspberry obtenga una señal de entrada no mayor a 3.3V para evitar daños en su pin, para ello se emplean 2 resistencias en serie. Estas resistencias dividen el voltaje de entrada proveniente del PIC18F, tomando del nodo que une a las resistencias la señal hacia la raspberry. La conexión se evidencia en la figura 28. Figura 28. Circuito conversor de 5 a 3.3v

Fuente: Elaboración propia.

67

5.2 FUENTES DE ALIMENTACIÓN. El sistema del semáforo inteligente cuenta con 2 fuentes de alimentación que derivan de una entrada AC de 110v. Un transformador se encarga de convertir a 9 y 6 voltios la señal, destinando los 9v rectificados y regulados para el uso del PIC18F y relés del sistema y los 6v para las luces del semáforo y un divisor de voltaje que indica a la raspberry cuando se corta la electricidad para activar el back up de energía que mantiene al sistema funcionando en caso de fallos eléctricos. Cabe resaltar que la fuente de 9v cuenta además con 3 condensadores en paralelo a su salida con el fin de evitar un apagón súbito cuando se corta la energía. Los circuitos de las fuentes se muestran en la figura 29. Figura 29. Circuito fuente del sistema 9v y 6v respectivamente

5.3 BACK UP DE ENERGÍA. El back up de energía es un elemento bastante importante en el diseño electrónico, consiste en un sistema de relés activados por transistores, una batería de litio alimentada por energía solar y un grupo de condensadores que se encarga de mantener voltaje en el sistema cuando se corta el suministro de energía de las fuentes. Para comprender el funcionamiento del back up se realiza el siguiente análisis parte por parte.

68

5.3.1 Sistema de carga de batería Una batería de litio de 10V y 2200mAh es la fuente principal de este back up de energía, la batería se encontrará en proceso de carga mientras las fuentes de voltaje se encuentren funcionando normalmente. Este proceso de carga lo lleva a cabo mediante un panel solar que se encuentra conectado a un pequeño módulo TP4056 (Figura 30), este módulo tiene la capacidad de alimentar la batería hasta que se encuentre totalmente cargada y detener el paso de energía. Además, cuenta con una protección capaz de evitar que la batería se sobre descargue y pueda dañarse. La carga del módulo puede darse mediante puerto micro USB o por sus 2 pines de 5v y GND. La mencionada protección que tiene este tipo de módulo permite que mientras se carga la batería a su vez esta pueda estar entregando energía a los dispositivos que tenga conectados. Figura 30. Circuito TP4056 para carga de batería.

Fuente: WAVGAT. 2019. https://es.aliexpress.com/i/32982737893.html. [En línea] ALIEXPRESS, 2019. [Citado el: 30 de Agosto de 2020.] https://es.aliexpress.com/items/reviews-32982737893p1.html?spm=a219c.12057483.0.0.44c888c96RSaMz. 5.3.2 Divisor de voltaje El sistema necesita reconocer el momento en que las fuentes se apagan para dar paso a la activación del back up, es por ello que un divisor de voltaje conectado a la salida de la fuente de 6V se ocupa de bajar la tensión a un valor manejable por los pines GPIO de la raspberry PI. Este valor debe

69

oscilar entre los 1.5 y 3.3 V para que sea interpretado como un 1 lógico. En el instante en que se apagan las fuentes, el divisor deja de recibir voltaje e inmediatamente llega un 0 lógico al GPIO, este 0 básicamente es la señal que alerta del apagón.

Figura 31. Divisor de voltaje en la fuente de 6v.

Fuente: Elaboración propia. En el apartado “Fuentes de alimentación” se explicó que la fuente de 9v cuenta con condensadores en paralelo quienes se encargan de mantener el suministro energético en el circuito, es por ello que el divisor se aplica a la salida de la fuente de 6V, pues si se conecta a la de 9 no se reconocerá instantáneamente la falla eléctrica, este divisor de aprecia en la figura 31. 5.3.3 Sistema relé – transistor El sistema relé-transistor es la base más importante del back up de energía, pues, se encarga de dar paso o de cortar el suministro de corriente hacia la raspberry. El sistema tiene como entrada principal la energía proveniente del cargador que alimenta la tarjeta, esta fuente se conecta directamente al pin común del relé para garantizar que no haya caídas de voltaje ni corriente por otros dispositivos. El VCC de la raspberry PI va conectado hacia la terminal NA (normalmente abierta) por lo que es necesario activar la bobina para que el pin común conmute. Esta activación de bobina se logra al conectar una de sus terminales a la fuente de 9v y la otra hacia GND. La conexión a GND no es directa ya que el relé necesita activarse mediante transistor, entonces, el 2n2222 tendrá una resistencia de base directa hacia la fuente de 9V para que sature mientras haya energía, su pin colector a la bobina y el emisor a tierra. Así se garantiza la activación.

70

Figura 32. Sistema relé – transistor para cargador de la raspberry.

Fuente: Elaboración propia. En las siguientes ecuaciones se presenta la forma en que se calculó la resistencia de base para el primer transistor:

−𝑉𝑖𝑛 + 𝐼𝑏𝑅𝑏 + 𝑉𝑏𝑒 = 0

𝑅𝑏 =𝑉𝑖𝑛 − 𝑉𝑏𝑒

𝐼𝑏

𝐼𝑏 =𝐼𝑐

𝐵=

0.8

269= 2.97𝑚𝐴

𝑅𝑏 = (((𝑉𝑖𝑛 − 0.7) ∗ 𝐵)/𝐼𝑏) 𝑅𝑏 = ((5 − 0.7) ∗ 263/71.4𝑚𝐴)

𝑅𝑏 = 16𝑘𝑂ℎ𝑚

La segunda parte de este sistema es aquella que se acciona en el momento en que existe una falla eléctrica y la fuente principal ya no proporciona el voltaje para alimentar a la raspberry. Debido al almacenamiento de energía que ocurre en los condensadores de la fuente, el sistema se mantiene encendido por unos segundos cuando ocurre el apagón, tiempo suficiente para que una señal GPIO enviada desde la raspberry llegue al transistor 2n2222 quien entra en saturación y permite que la bobina excitada por el voltaje de una batería de litio tenga contacto con tierra y conmute el pin común al NA, esta acción hace que la corriente de la batería sea ahora quien alimenta la raspberry y esta no tenga tiempo de apagarse.

71

Figura 33. Sistema relé – transistor para batería de litio.

Fuente: Elaboración propia. A continuación se presenta el cálculo de la resistencia de base para el segundo transistor, se emplea el mismo método del primer Rb:

𝑅𝑏 = ((3.3 − 0.7) ∗ 283/71.4𝑚𝐴)

𝑅𝑏 = 10𝑘𝑂ℎ𝑚 Ahora, en el momento en que el divisor de voltaje de la fuente de 6v avisa sobre el apagón, la raspberry hace un apagado por software para que la batería no se descargue rápidamente por entregar los entre 500 y 800 mA que requiere la placa. 5.4 LUCED LED El sistema de luces emplea el mismo método de activación que el back up de energía, es decir, los diodos LED en su pin positivo se encuentran inicialmente alimentados por la fuente de 6V. En caso de ocurrir un apagón, un transistor 2n2222 se satura por medio de un puerto GPIO, la bobina se activa gracias a la batería de Litio y su pin común lleva la corriente de la batería hacia el normalmente abierto de un relé que va conectado al positivo de los bombillos, alimentándolos mientras se soluciona el problema energético, así las luces nunca estarán apagadas y no habrá caos vehicular. El circuito se presenta en la figura 34.

72

Figura 34. Sistema relé – transistor para luces LED.

Fuente: Elaboración propia. Cabe resaltar que las luces leds también se activan mediante transistores 2n2222, estas están dispuestas en paralelo para reducir el consumo de voltaje y, el voltaje de activación de los transistores proviene de los puertos del PIC18F. En la siguiente figura se observa una aproximación final al circuito definitivo del sistema. Figura 35. Esquema completo del circuito desarrollado.

Fuente: Elaboración propia.

73

6. ARQUITECTURA DE SOFTWARE

El software en el sistema se divide principalmente en 3 frentes, el software del sistema embebido, el Frontend y Backend del sistema, teniendo como punto en común, la base de datos, a continuación, se explican los protocolos de comunicación que se utilizan entre las partes del sistema y cómo funciona uno por uno estos frentes incluyendo las razones por las que se escogieron las tecnologías seleccionadas. 6.1 PROTOCOLOS En informática, un protocolo se refiere al conjunto de reglas y estándares que controlan la secuencia de mensajes que ocurren durante una comunicación entre entidades que forman una red. En el sistema propuesto se emplean 2 protocolos: el http principalmente para el envío de imágenes al servidor y el MQTT para envío y recepción de información de tiempo real. 6.1.1 Protocolo HTTP HTTP, de sus siglas en inglés: "Hypertext Transfer Protocol", es el nombre de un protocolo el cual nos permite realizar una petición de datos y recursos como pueden ser documentos HTML [26]. Esta herramienta es la base de cualquier intercambio de datos en la Web, y un protocolo de estructura cliente-servidor, esto quiere decir que una petición de datos es iniciada por el elemento que recibirá los datos (el cliente), normalmente un navegador Web. 6.1.1 Protocolo MQTT MQTT (Message Queue Telemetry Transport) es un protocolo de transporte de mensajes Cliente/Servidor basado en publicaciones y suscripciones a los denominados “tópicos”[27]. Cada vez que un mensaje es publicado será recibido por el resto de dispositivos adheridos a un tópico del protocolo. El protocolo MQTT es idóneo para aplicaciones de Internet de las Cosas en las cuales se envían cantidades pequeñas de información y por tanto no se necesita un gran ancho de banda. 6.2 FRAMEWORKS Y LIBRERÍAS

Un framework es un esquema o estructura que se establece y que se aprovecha para desarrollar y organizar un software determinado, por su parte las librerías son un conjunto de implementaciones de código que facilitan algunas funciones. Para el sistema desarrollado se empleó un framework en el backend y una librería en el FrontEnd, a continuación se presentan estas dos herramientas:

74

6.2.1 Django Django es un framework de desarrollo web de código abierto, escrito en Python, es el framework utilizado en el servidor y por lo tanto, es el encargado de toda la lógica de tratamiento de datos del sistema [30].

Figura 36. Logo Django

Fuente: AEPI. [En línea] [Citado el: 25 de Agosto de 2020.] https://asociacionaepi.es/los-modelos-de-django/.

6.2.2 React (también llamada React.js o ReactJS) es una biblioteca Javascript de código

abierto diseñada para crear interfaces de usuario, es la librería utilizada en el Frontend, por

tanto, se encarga de toda interacción entre el usuario y el sistema, priorizando la usabilidad (UX), seguridad y diseño [31].

Figura 37. Logo React

Fuente: WIKIPEDIA [En línea] [Citado el: 25 de Agosto de 2020.] https://es.wikipedia.org/wiki/React.

6.3 SERVICIOS AWS. AWS es una plataforma de computación en la nube, pionera en su campo, que ofrece una colección de servicios escalables con la particularidad de que se paga únicamente por lo que se usa sin necesidad de una suscripción por tiempo, AWS facilita la integración entre sus servicios [32], por lo que es común tener toda la infraestructura de software de un sistema con servicios AWS, a continuación se presentan los servicios AWS que se utilizan en este sistema. 6.3.1 EC2 Elastic Cloud Computing, es un servicio web que proporciona capacidad informática en la nube segura y de tamaño modificable [33], en este servicio se almacena y se ejecuta el servidor de backend.

75

Figura 38. Logo EC2

Fuente: KUENDIG, M. Copebit. [En línea] [Citado el: 25 de Agosto de 2020.] https://www.copebit.ch/amazon-ec2-debuts-5-bare-metal-instances/

6.3.2 Rekognition Con Amazon Rekognition puede identificar objetos, personas, texto, escenas y actividades en imágenes y videos, además de detectar cualquier contenido inapropiado [34]. Este servicio es usado en el sistema para detectar y contar los vehículos de la vía.

Figura 39. Logo rekognition

Fuente: AMAZON WEB SERVICES [En línea] [Citado el: 25 de Agosto de 2020.] https://amazonwebservices.hackster.io/products/aws-rekognition

6.3.3 S3 Amazon Simple Storage Service (Amazon S3) es un servicio de almacenamiento de objetos que ofrece escalabilidad, disponibilidad de datos, seguridad y rendimiento líderes en el sector. Este servicio es utilizado para almacenar las imágenes tomadas en todos los semáforos [35].

76

Figura 40. Logo Amazon S3

Fuente: APRENDER BIG DATA [En línea] [Citado el: 25 de Agosto de 2020.] https://aprenderbigdata.com/amazon-s3/

6.3.4 Lambda AWS Lambda es un servicio de informática sin servidor que ejecuta código en respuesta a eventos y administra automáticamente los recursos informáticos subyacentes [36]. Este servicio se utiliza para ejecutar el código de la lógica difusa. Figura 41. Logo Lambda

Fuente: WORLD VECTOR LOGO [En línea] [Citado el: 25 de Agosto de 2020.] https://worldvectorlogo.com/logo/aws-lambda 6.4 BASE DE DATOS Para este sistema es obligatorio que exista persistencia, es decir que los datos se guarden y persistan a través del tiempo, para esto se utiliza la base de datos, aunque hay soluciones de BD locales (en el mismo computador o servidor) lo ideal es que esté alojada en la nube, porque por lo general el acceso es más seguro, confiable y rápido. Debido a que este sistema tiene funcionalidades en tiempo real, una base de datos NoSQL o no Relacional es la mejor opción debido a que la lectura

77

y escritura de información es más dinámica, y entre este tipo de base de datos la mejor es MongoDB, su núcleo está hecho con el lenguaje de programación JavaScript, sin embargo, esta BD tiene una particularidad y es que no es recomendable para guardar grandes cantidades de registros, por ejemplo, los registros históricos de detecciones, por lo tanto se hace obligatorio también, hacer respaldos de las tablas cada cierto tiempo. 6.4.1 Mongo DB Es un sistema de base de datos NoSQL, orientado a documentos y de código abierto [37]. En lugar de guardar los datos en tablas, tal y como se hace en las bases de datos relacionales, MongoDB guarda estructuras de datos BSON (una especificación similar a JSON) con un esquema dinámico, haciendo que la integración de los datos en ciertas aplicaciones sea más fácil y rápida. Esta base de datos es utilizada para guardar los datos de los semáforos, usuarios, configuración de la lógica difusa por intersección, y un histórico de datos recolectados de las imágenes de un pequeño rango de tiempo. 6.5 VISION GENERAL DEL SISTEMA El proceso del sistema se puede resumir en 3 pasos, que conforman un ciclo repetitivo, desde la raspberry se toma una imagen que se envía al servidor y se cuentan los vehículos, luego se utiliza lógica difusa para determinar el tiempo necesario en el semáforo para que pasen esos vehículos y luego esos tiempos llegan nuevamente a la raspberry para que sean modificados, a continuación se explica con más detalles estos 3 pasos y los elementos de software y hardware involucrados. 6.5.1 Raspberry PI a servidor La raspberry Pi, mediante python obtiene la imagen de la vía conectándose al puerto en que está conectada la cámara web, esta imagen es guardada en una carpeta temporal del sistema de archivos para respaldo, una vez hecho esto se envía la imagen al servidor mediante protocolo HTTP con una petición tipo POST, el servidor recibe esta imagen y la guarda en un bucket de S3 (carpeta de archivos en la nube), luego solicita al servicio AWS rekognition que detecte los objetos en ella, cuando se recibe la respuesta se filtra y se cuenta los objetos de interés (carros, buses, camiones), este número de vehículos se guarda en la base de datos MongoDB como la última detección del dispositivo “lastDetection”, finalmente esta es la respuesta de la petición HTTP hecha por la Raspberry.

78

Figura 42. Esquema y diagrama Raspberry Pi a server

Fuente: Elaboración propia. 6.5.2 Lógica difusa El Algoritmo que determina los tiempos de los semáforos utilizando

lógica difusa está escrito en python con librerías escritas específicamente para el tratamiento de datos, este algoritmo no es recomendable que esté corriendo en la misma infraestructura del servidor por 2 razones, la primera es que es un proceso repetitivo que se ejecuta en intervalos definidos de tiempo pero que pueden variar en algún momento, si este código estuviere corriendo en el servidor habría que reiniciarlo cada vez que se quiera cambiar este intervalo, la segunda razón es que dependiendo de la cantidad de intersecciones y de dispositivos del sistema el proceso puede requerir más o menos recursos físicos (Procesador, RAM, etc), y podría “colgar” el servidor, repercutiendo en los tiempos de respuesta de todos los otros procesos. Debido a estas razones este código corre en el servicio AWS Lambda, que permite ejecución de código sin servidor y escalable a las necesidades únicas de las funciones escritas, además permite configurar el desencadenante fácilmente, por ejemplo, se puede especificar que se ejecute el código cada 15 minutos todos los días de 6:00 am a 6:00 pm. El código se conecta a la base de datos para obtener la información de configuración específica de la lógica difusa de esa intersección, una vez ejecutada la lógica difusa se conecta al servidor por protocolo MQTT enviando los ID’s de los dispositivos a los que se les acaba de actualizar los tiempos, para que el servidor también por protocolo MQTT le envíe los tiempos actualizados a cada uno de los dispositivos de la intersección analizada en tiempo real.

79

Figura 43. Esquema lógica difusa

Fuente: Elaboración propia.

6.5.3 Servidor a Raspberry Para enviarle los tiempos del semáforo actualizados, el servidor se conecta a cada una de las raspberry utilizando el protocolo MQTT, esto funciona utilizando publicaciones/suscripciones a los grupos, un grupo está formado por el nombre de la intersección y el nombre único del semáforo, por ejemplo “/CLL45CRA7/CLL45CRA7_W/”, el servidor entonces publica los tiempos en el grupo y la raspberry suscrita a este grupo recibe la información, esto asegura que nunca se repita un grupo y que la raspberry reciba siempre y en tiempo real la información específica del semáforo. Figura 44. Esquema servidor a Raspberry

Fuente: Elaboración propia.

80

81

7. PRUEBAS DE FUNCIONAMIENTO

El funcionamiento del ciclo semafórico inteligente es un proceso totalmente autónomo, es decir, no requiere de ninguna persona que se tenga que ocupar de intervenir en la toma de decisiones o asignación de tiempos rojo, verde o ámbar. Por esta razón, con fines de documentar las pruebas de funcionamiento se demuestran ejecutando de manera manual etapa por etapa cada uno de los procesos que se llevan a cabo en el sistema hasta llegar a la modificación de la dinámica de la intersección. El sistema desarrolla los siguientes procesos:

1. Reconocimiento de la fotografía obtenida identificando la cantidad de vehículos que se encuentran en la vía.

2. Envío de la información y recepción en la base de datos.

3. Procesamiento de la lógica difusa para determinación de tiempos.

4. Asignación de los tiempos en cada uno de los dispositivos del cruce.

5. Lectura de condiciones climatológicas.

6. Lectura del status energético del sistema.

7. Envío de rutinas hacia PIC18F.

Todo el proceso se demuestra mediante un caso de aplicación y se divide en 2 etapas: Una primera etapa que consta del proceso de la información antes de llegar a la Raspberry PI y una segunda que consta del envío de datos de la Raspberry hacia el PIC18F. 7.1 PRIMERA ETAPA. Como se mencionó en el capítulo 3 “Simulación y lógica difusa” el cruce consta de 3 semáforos, estos semáforos cuentan cada uno con un nombre de dispositivo y una ID para su identificación como se puede observar en la figura 45.

82

Figura 45. ID y nombre de los semáforos de la intersección

Fuente: Elaboración propia. Como se puede observar los semáforos están rotulados bajo los nombres de “CLL45CRA7_W”, “CRA7CLL45_S” y “CRA7CLL45_N”, los 3 nombres se componen por la calle o carrera donde están ubicados, la calle o carrera con la que hacen intersección y la orientación desde la que proviene el flujo vehicular, es decir:

Si el semáforo se ubica en la calle 45 la primera parte de su nombre iniciará con CLL45.

La vía con la que hace intersección es la CRA7.

La orientación del flujo por la cll 45 es de Occidente a Oriente, por ende la última letra del nombre del dispositivo será la inicial de Occidente en inglés (West), es decir, W.

El proceso comienza con la obtención del material fotográfico de la intersección durante cada uno de los ciclos semafóricos. Las imágenes se captan por medio de software, programa el cual abre la cámara del sistema, capta los vehículos que se encuentran en ese momento y lo envía para que AWS realice el reconocimiento de vehículos y entregue una respuesta. Para observar la efectividad del sistema en el conteo de vehículos se emplea el siguiente servicio web diseñado.

83

Figura 46. Servidor encargado del conteo de vehículos.

Fuente: Elaboración propia. En la figura 46 se observa el servidor web dispuesto para una demostración manual de la identificación vehicular de la intersección. En él se encuentra un botón “choose file” con el que se puede elegir una imagen específica, una barra llamada “Devicename” en la que se ingresa el nombre del semáforo al que se le va a enviar

84

la información y una barra llamada “ID” donde se ingresa la identificación de cada uno (véase figura 45). A continuación se realiza el proceso de conteo vehicular para la imagen número 11 del registro fotográfico obtenido para la comprobación. Figura 47. Conteo vehicular por web

Fuente: Elaboración propia. Figura 48. Flujo vehicular en la imagen 11 del registro fotográfico .

Fuente: Imagen captada por el autor. Como se observa, el software capta los 20 vehículos presentes en la foto y envía esta información hacia el dispositivo especificado. En la base de datos se refleja inmediatamente en el apartado “HistoricDetections” la lectura que hizo el sistema. Figura 49. Registro de última lectura

85

Fuente: Elaboración propia. El mismo procedimiento se realiza para los otros 2 semáforos de la intersección con 2 fotografías que registran 8 vehículos sobre la CLL 45 y 21 sobre la CRA 7 Norte, obteniendo así los siguientes datos en los Devices: Figura 50. Datos recibidos de los 3 semàforos

Fuente: Elaboración propia. Una vez la base de datos tiene las cantidades de vehículos, comienza con el análisis del sistema difuso, las variables de entrada y salida definidas junto a las reglas se encargan de dar los tiempos a cada uno de los semáforos. Esta demostración manual se realiza mediante el servicio LAMBDA de AWS el cual tiene la información de la lógica difusa. Figura 51. Respuesta de lamba con los tiempos del ciclo

Fuente: Elaboración propia.

86

En la figura 51 se observa como Lambda indica que con los datos de entrada obtenidos, los tiempos de verde para el sistema son de 24 segundos para la CLL 45 y de 65 segundos para la CRA 7. Es necesario aclarar que los flujos vehiculares de la CRA7 son 2 datos distintos, es en este punto donde el software realiza una comparación de ambos para darle a la vía completa el valor del flujo mayor (en este caso es de 21 vehículos). Ahora lo realmente importante es que esta información se encuentre en la base de datos para que posteriormente sea enviada al PIC18F4550, en la figura 52 se observa como los semáforos ya cuentan con las rutinas que el sistema difuso ha establecido. Figura 52. Rutinas establecidas en los semáforos

Fuente: Elaboración propia. Finalmente en esta primera etapa dicha información debe pasar de la base de datos hacia la raspberry para que esta se encargue de enviarla al PIC y este le dé el encendido a las luces LED acorde a las rutinas. En la figura 53 se aprecia como se ve en la consola la forma en que viajan los datos hacia el sistema embebido.

87

Figura 53. Envío de rutinas hacia Raspberry

Fuente: Elaboración propia. En este punto la Raspberry ya conoce las rutinas que debe enviar hacia el PIC. 7.2 SEGUNDA ETAPA La segunda etapa del funcionamiento del sistema corresponde a las lecturas externas que realizan los sensores y los pines GPIO sobre las condiciones del clima y energéticas. El sensor de luz TSL2561 mide la cantidad de “Lux” que hay en el momento para reconocer cuando el día cuenta con la suficiente iluminación para captar imágenes claras que puedan ser correctamente analizadas por AWS, es por ello que se debe determinar una cifra de Lux mínima para que el sistema pueda seguir modificando los ciclos semafóricos. Se determina que sobre las 6 P.M. del día en la ciudad de Bogotá la iluminación comienza a tomar valores iguales y menores a 200 lux lo cual provoca que la visibilidad para el sistema sea muy regular (Ver figura 54). Figura 54. Iluminación de Bogotá a las 6 P.M.

Fuente: Elaboración propia.

88

Otra de las condiciones evaluadas por el sistema es el nivel de humedad que se encuentra en el ambiente. Esta medición es realizada por el sensor DHT22 al mismo tiempo que el de luz para recopilar al instante los dos datos, en momentos de lluvia la humedad tiene valores muy altos entre el 90 y 100%, de esta manera se establecen los siguientes rangos como limitante de funcionamiento: Figura 55. Condición que limita el funcionamiento del sistema

Fuente: Elaboración propia. La condición mostrada en la figura 55 da inicio a un bucle que activará una rutina pre establecida que será la que dirigirá el tráfico en la intersección al menos hasta que el valor de luminosidad sea mayor a 200 lux y la humedad se encuentre por debajo del 90%. A continuación se presenta un ejemplo del mensaje de consola que se presenta en el momento en que el sistema entra en el bucle de la figura 56. Figura 56. Mensaje de activación de rutina pre establecida

Fuente: Elaboración propia. La rutina pre establecida del sistema tendrá los valores de un ciclo semafórico en el que se presenta “Flujo normal” en cada una de las vías, es decir, los tiempos serán de 50 segundos de verde para la CRA7 y 27 para la CLL45. En la base de datos se puede observar cómo se encuentra almacenado este valor en una variable llamada “DefaultValue”. Figura 57. Rutina pre establecida en semáforo CLL45

Fuente: Elaboración propia.

89

Finalmente se ejecutan por software los scripts que permiten enviar hacia el PIC18F las rutinas definidas por la lógica difusa o en caso de que se presenten las limitantes de condiciones climáticas o bajones de energía, las rutinas pre establecidas. Una vez llega la información por comunicación serie, el PIC 18F lee la cadena enviada por la raspberry, separa los tiempos por medio de una cadena delimitadora y asigna los tiempos de HIGH a los ports del micro controlador que se encargan de encender las luces LED. Figura 58. Delimitadores en código de Raspberry

Fuente: Elaboración propia.

90

8. CONCLUSIONES.

En la investigación realizada en este proyecto, se encontró que existen sistemas dedicados al monitoreo del flujo vehicular mediante video. El sistema propuesto aprovecha la condición de intersección semaforizada para captar imágenes de la cantidad de vehículos que se presentan en la vía mientras estos se encuentran detenidos. Esta forma de recolección de información permite el envío de fotografías mediante API al servidor donde se procesa la imagen evitando así realizar el procesamiento en la misma Raspberry que estaría limitada por especificaciones técnicas. La raspberry pi es una pequeña pero muy potente herramienta electrónica, la posibilidad que corra un sistema operativo de escritorio como Raspbian y con este un lenguaje de alto nivel como Python, permite desarrollar código más comprensible para el humano de forma rápida a diferencia de tarjetas que ejecutan lenguajes C o Ensamblador por ejemplo. La posibilidad de replicar la dinámica vehicular de la zona de estudio con una muy completa herramienta como el programa Synchro 8 permitió tener bastante detalle de situaciones de congestión vehicular para así mediante la modificación de parámetros encontrar soluciones efectivas en materia de movilidad. AWS como herramienta de infraestructura en la nube provee un servicio casi para cualquier necesidad del sistema. La posibilidad de que todas las funcionalidades estén ejecutándose con estos servicios cloud permite escalabilidad y flexibilidad, es decir que una vez vaya creciendo el sistema tanto en funcionalidades como en número de dispositivos, se puede ir aumentando la capacidad. Si el sistema corriera en entornos locales, como computadores de mesa o redes LAN el sistema estaría limitado por las especificaciones técnicas de los mismos En el proceso de detección y conteo de vehículos en la imagen, es decir, en la vía, se evidencia que es mejor realizar este proceso en un servidor externo y consumirlo mediante API, esto implica menos consumo de recursos informáticos en la raspberry (CPU, GPU, RAM) y además, si fuese necesario un reentrenamiento del modelo, solo habría que hacerlo una vez en el servidor y no en cada una de las raspberries. Se evidencia la utilidad del protocolo MQTT para aplicaciones de dispositivos en tiempo real, una vez el servidor envía la información se demora menos de 1 segundo en llegar al dispositivo, con la información específica de este y sin pérdida de paquetes. Sin embargo lo más importante es que el servidor no necesita una petición o desencadenante enviada desde la raspberry, como sucede con el protocolo HTTP, únicamente que se configure el grupo.

91

Contar con un sistema de power back up integrado permite que el sistema no falle en situaciones donde se puedan presentar fallas eléctricas en la intersección evitando posible caos vehicular. Además, este sistema tiene la capacidad de alimentarse por medio de energías renovables significando un beneficio para el medio ambiente y en materia económica.

92

REFERENCIAS BIBLIOGRÁFICAS

[1]. Movilidad en cifras. 2018. Prudencia Bogotá. [En línea] Alcaldía mayor de Bogotá, 2018. [Citado el: 20 de Febrero de 2020.] https://www.simur.gov.co/portal-simur/datos-del-sector/movilidad-en-cifras/. [2]. ENCISO, L & Núñez, A. 2008. Sistema semafórico preferencial simulado para vehículos de emergencia usando enfoques de IoT E ITS: Caso de estudio ambulancias. [En línea]. Bogotá. [Citado el 14 mayo 2020]. Disponible en internet < http://polux.unipiloto.edu.co:8080/00004543.pdf> [3]. Bolivar, Freddy. 2017. ucuenca. [En línea] 06 de Febrero de 2017. [Citado el: 16 de Marzo de 2020.] http://157.100.241.244/bitstream/47000/1363/1/UISRAEL-EC-ELDT-378.242-2017-008.pdf. [4]. Martinez, Manuel. 2014. jeuazarru. [En línea] Octubre de 2014. [Citado el: 16 de Marzo de 2020.] http://jeuazarru.com/wp-content/uploads/2014/10/semaforos_inteligentes.pdf. [5]. Osorio, Hernán. 2018. Repositorio digital Universidad Técnica del Norte. [En línea] 16 de Mayo de 2018. [Citado el: 24 de Marzo de 2020.] http://repositorio.utn.edu.ec/handle/123456789/8200. [6]. Muñoz, Jesus. 2008. Repositorio Universidad Nacional Pedro Ruiz Gallo. [En línea] 15 de Febrero de 2008. [Citado el: 28 de Marzo de 2020.] http://repositorio.unprg.edu.pe/bitstream/handle/UNPRG/6064/BC-3302%20MU%c3%91OZ%20ZAMBRANO.pdf?sequence=1&isAllowed=y. [7]. Mejia, Fernando, Torres, German y Villa, Eduardo. 2016. 1, Chimborazo : Infociencia, 2016, Vol. 10. [8]. Nermachnow, Sergio. 2014. Universidad de la República de Uruguay. [En línea] Julio de 2014. [Citado el: 02 de Abril de 2020.] https://www.colibri.udelar.edu.uy/jspui/bitstream/20.500.12008/2932/1/tesis-nesmachnow.pdf. [9]. Chávez, Carla. 2015. Universidad técnica de Ámbato. [En línea] Julio de 2015. [Citado el: 02 de Abril de 2020.] https://repositorio.uta.edu.ec/bitstream/123456789/13061/1/Tesis_t1033ec.pdf.

93

[10]. Ochoa, Félix y Pariona, Eduardo. 2019. Universidad Técnologica del Perú. [En línea] Agosto de 2019. [Citado el: 10 de Abril de 2020.] http://repositorio.utp.edu.pe/bitstream/UTP/2343/1/Felix%20Ochoa_Eduardo%20Pariona_Trabajo%20de%20Investigacion_Bachiller_2019.pdf. [12]. Introducción al razonamiento aproximado: lógica difusa. D'Negri, Carlos y De Vito, Eduardo. 2006. 3, Córdoba : Revista Américana de Medicina Respiratoria, 2006, Vol. 6. [13]. Inteligencia artíficial 101 cosas que debes saber hoy sobre nuestro futuro. Rouhiainen, Lasse. 2018. Barcelona : Alienta, 2018. [15]. González, Carlos. 2010. Escuela Superior de Informatica. [En línea] 2010. [Citado el: 15 de Junio de 2020.] https://www.esi.uclm.es/www/cglez/downloads/docencia/2011_Softcomputing/LogicaDifusa.pdf. [16]. Díaz, Borja. 2015. Universidad Carlos III de Madrid. [En línea] 2015. [Citado el: 10 de Agosto de 2020.] https://e-archivo.uc3m.es/bitstream/handle/10016/23730/TFG_Borja_Diaz_Mulas.pdf?sequence=1&isAllowed=y. [17]. CityNoticias. 2019. Hay más de 7 millones de habitantes en Bogotá, según cifras del DANE. EL TIEMPO. 2019. [18]. Bandy, William y Peeters, John. 2006. Radio frequency identification (RFID) based sensor networks. US7148803B2 Estados Unidos, 12 de Diciembre de 2006. [19]. Lazzari, Luisa, Machado, Emilio y Perez, Rodolfo. 2000. Universidad de Buenos Aires. [En línea] 2000. [Citado el: 28 de Junio de 2020.] http://bibliotecadigital-old.econ.uba.ar/download/cuadcimbage/cuadcimbage_n2_01.pdf. [20]. Ada, L. 2018. TSL2561 Luminosity sensor. Adafruit. [En linea] 2018. [Citado el 13 de Septiembre de 2020.] https://cdn-learn.adafruit.com/downloads/pdf/tsl2561.pdf [21]. Liu, Thomas. Sparkfun. [En línea] [Citado el: 12 de Septiembre de 2020.] https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf. [22]. Desconocido. 2015. Aprende en linea. [En línea] 22 de Noviembre de 2015. [Citado el: 15 de Septiembre de 2020.] http://aprendeenlinea.udea.edu.co/lms/investigacion/mod/page/view.php?id=9137#:~:text=Las%20reglas%20difusas%20permiten%20crear,se%20tienen%20los%20

94

siguientes%20ejemplos%3A&text=Si%20x%20es%20largo%20entonces%20y%20es%20peque%C3%B1o.&text=Si%20el%20nivel%. [23]. Bianchi, Fernando. 2001. Universidad Nacional de La Plata. [En línea] 2001. [Citado el: 18 de Septiembre de 2020.] https://catedra.ing.unlp.edu.ar/electrotecnia/senysis/files/apuntes/ResumenMatlab2.pdf. [24] Lopez, M y Ayala, J. 2004. Ing. Miguel Ojeda y Asociados. [En línea] Febrero de 2004. [Citado el: 21 de Septiembr de 2020.] http://www.miky.com.ar/fpga_2004.pdf. [25]. Desconocido. 2019. Flir. [En línea] 2019. [Citado el: 25 de Mayo de 2020.] https://www.flir.com.mx/products/traficam/. [26] Desconocido. MDN web docs. [En línea] 7 de Agosto de 2020. [Citado el: 25 de Agosto de 2020.] https://developer.mozilla.org/es/docs/Web/HTTP/Overview [27] Desconocido. TST-sistemas. [En línea]. [Citado el: 25 de Agosto de 2020.] http://www.tst-sistemas.es/mqtt/#:~:text=MQTT%20(Message%20Queue%20Telemetry%20Transport,a%20un%20t%C3%B3pico%20del%20protocolo. [28] Desconocido. Semantic web builder. [En línea]. [Citado el: 25 de Agosto de 2020.] http://www.semanticwebbuilder.org.mx/es_mx/swb/Sistemas_Embebidos_Innovando_hacia_los_Sistemas_Inteligentes_ [29] Desconocido. Xataca. [En línea]. [Citado el: 25 de Agosto de 2020.] https://www.xataka.com/basics/resoluciones-pantalla-que-guia-tipos-sus-nomenclaturas [30] Desconocido. Django project. [En línea]. [Citado el: 25 de Agosto de 2020.] https://www.djangoproject.com/ [31] Desconocido. ReactJS org. [En línea]. [Citado el: 25 de Agosto de 2020.] https://www.djangoproject.com/ [32] Desconocido. AWS. [En línea]. [Citado el: 25 de Agosto de 2020.] https://aws.amazon.com/es/what-is-cloud-computing/?nc2=h_ql_le_int_cc [33] Desconocido. AWS. [En línea]. [Citado el: 25 de Agosto de 2020.] https://aws.amazon.com/es/ec2/

95

[34] Desconocido. AWS. [En línea]. [Citado el: 25 de Agosto de 2020.] https://aws.amazon.com/es/rekognition/?blog-cards.sort-by=item.additionalFields.createdDate&blog-cards.sort-order=desc [35] Desconocido. AWS. [En línea]. [Citado el: 25 de Agosto de 2020.] https://aws.amazon.com/es/s3/ [36] Desconocido. AWS. [En línea]. [Citado el: 25 de Agosto de 2020.] https://aws.amazon.com/es/lambda/ [37] Desconocido. Genbeta. [En línea]. [Citado el: 25 de Agosto de 2020.] https://www.genbeta.com/desarrollo/mongodb-que-es-como-funciona-y-cuando-podemos-usarlo-o-no

96

ANEXOS

Anexo 1. Circuito PCB del sistema.