UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Sistema para conversión de semáforosconvencionales en semáforos para no

videntes

Autor:Ing. Sebastián Alejandro Suárez

Director:Esp. Ing. Sergio Renato de Jesús Meleán (FIUBA)

Jurados:Esp. Ing. Franco Bucafusco (FIUBA)Esp. Ing. Diego Fernandez (FIUBA)

Esp. Ing. Marcelo E. Romeo (UNSAM, UTN-FRBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entreoctubre 2018 y diciembre de 2019.

III

Resumen

En esta memoria se presenta el diseño e implementación de un dispositivo parala inclusión de personas no videntes. El sistema desarrollado advierte a los no

videntes los cambios de luces de un semáforo vehicular por medio devibraciones de su smartphone. Este dispositivo fue desarrollado para la empresa

Adox. El código y el hardware están disponibles libremente en Internet.

Para la elaboración del trabajo se aplicaron los conocimientos adquiridos a lolargo de la carrera tales como la programación de microcontroladores, conceptos

de sistemas operativos de tiempo real, procesamiento de eventos asíncronos,protocolos de comunicación y diseño de circuitos impresos.

V

Agradecimientos

A mi esposa Mary por su compañía, paciencia, consejo y apoyo incondicional alo largo de toda la especialización.

A mis padres José y Graciela que me forjaron como la persona que soy y mealentaron en el estudio.

A mi director Sergio por su tiempo y sabiduría en todo momento.

A Roberto Zelarayán por facilitarme la EDU-CIAA.

A los profesores y compañeros de la Carrera de Especialización en Sistemas Em-bebidos que me acompañaron en esta formación profesional.

VII

Índice general

Resumen III

1. Introducción General 11.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Semáforos para no videntes . . . . . . . . . . . . . . . . . . . . . . . 21.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Introducción Específica 52.1. Semáforos viales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Evolución de los semáforos . . . . . . . . . . . . . . . . . . . 52.1.2. Componentes de los semáforos . . . . . . . . . . . . . . . . . 52.1.3. Clasificación de semáforos . . . . . . . . . . . . . . . . . . . . 62.1.4. Variaciones de secuencia en los semáforos . . . . . . . . . . 7

2.2. Tecnología de comunicación empleada en este trabajo . . . . . . . . 72.2.1. WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2. Protocolo UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3. FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Esquema general del sistema . . . . . . . . . . . . . . . . . . . . . . 92.3.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Diseño e Implementación 113.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1. Plataforma de desarrollo . . . . . . . . . . . . . . . . . . . . . 123.2.2. Subsistema de Sensado de red eléctrica . . . . . . . . . . . . 123.2.3. Subsistema de toma de ruido ambiental . . . . . . . . . . . . 133.2.4. Módulo generador de sonido . . . . . . . . . . . . . . . . . . 153.2.5. Subsistema de comunicación . . . . . . . . . . . . . . . . . . 15

Módulo WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.6. Arquitectura general del sistema . . . . . . . . . . . . . . . . 16

3.3. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2. Principio de funcionamiento . . . . . . . . . . . . . . . . . . 183.3.3. Diseño del firmware . . . . . . . . . . . . . . . . . . . . . . . 19

Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Aprendizaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Corriendo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4. Aplicación Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5. Poncho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6. Gabinete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4. Ensayos y Resultados 27

VIII

4.1. Test unitarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.1. Módulo estado del dispositivo . . . . . . . . . . . . . . . . . 274.1.2. Módulo de aprendizaje . . . . . . . . . . . . . . . . . . . . . 274.1.3. Módulo encolar eventos . . . . . . . . . . . . . . . . . . . . . 284.1.4. Módulo detector de anomalías . . . . . . . . . . . . . . . . . 284.1.5. Módulo configuración de dispositivos . . . . . . . . . . . . . 28

4.2. Test funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2.1. Módulo sensado de tensión . . . . . . . . . . . . . . . . . . . 294.2.2. Módulo detección de ruido ambiente . . . . . . . . . . . . . 294.2.3. Prueba de sonido . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3. Pruebas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.1. Pruebas en el dispositivo . . . . . . . . . . . . . . . . . . . . 31

5. Conclusiones 335.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Bibliografía 35

IX

Índice de figuras

1.1. Botón pulsador que acciona la generación de sonido . . . . . . . . . 21.2. Visión general del sistema funcionando . . . . . . . . . . . . . . . . 3

2.1. Fotografía de una semáforo led en la vía pública. . . . . . . . . . . . 62.2. Esquema emisor-receptor de paquetes UDP. . . . . . . . . . . . . . . 82.3. Esquema general del sistema. . . . . . . . . . . . . . . . . . . . . . . 9

3.1. Subsistemas del dispositivo. . . . . . . . . . . . . . . . . . . . . . . . 113.2. La EDU-CIAA posee un microcontrolador LPC4337 (dual core ARM

Cortex-M4 y Cortex-M0). . . . . . . . . . . . . . . . . . . . . . . . . . 123.3. Módulo con optoacopladores para Sensado de tensión alterna. . . . 123.4. Conexionado de los módulos de sensado de tensión. Se observa

que el pin GPIO1 corresponde a la línea del foco rojo, GPIO3 a ladel amarillo y GPIO5 al verde . . . . . . . . . . . . . . . . . . . . . . 13

3.5. Módulo para la detección de sonido . . . . . . . . . . . . . . . . . . 133.6. Conexionado del módulo de detección de sonido a la EDU-CIAA.

La conexión se hace por medio del pin Out del módulo y el PIN 13(ADC1) de la EDU-CIAA . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.7. En azul la señal de entrada, en verde la señal con el primer filtro,en rojo la señal con el segundo filtro. . . . . . . . . . . . . . . . . . . 14

3.8. Módulo amplificador HXJ8002. . . . . . . . . . . . . . . . . . . . . . 153.9. Conexionado del módulo de generación de sonido a la EDU-CIAA.

La conexión se hace por medio del pin Out del módulo y el PIN 13(ADC1) de la EDU-CIAA . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.10. Módulo inalámbrico ESP01. . . . . . . . . . . . . . . . . . . . . . . . 163.11. Conexion de la ESP01 al puerto RS232 de la placa EDU-CIAA. . . . 163.12. Diagrama general del hardware. . . . . . . . . . . . . . . . . . . . . 173.13. Estructura de capas para el firmware. . . . . . . . . . . . . . . . . . . 173.14. Diagrama general de funcionamiento. . . . . . . . . . . . . . . . . . 183.15. Máquina de estado finito del sistema. . . . . . . . . . . . . . . . . . 203.16. Máquina de estado finito del sistema. . . . . . . . . . . . . . . . . . 223.17. Interfase gráfica de la aplicación Android desarrollada . . . . . . . 233.18. Pantallas de la aplicación según el estado del semáforo. (a) No debe

cruzar la calle. (b) Puede cruzar la calle. (c) Se aproxima el cambiode luces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.19. Poncho desarrollado para el dispositivo. . . . . . . . . . . . . . . . . 243.20. Vista del modelo en programa online tinkercad. . . . . . . . . . . . 253.21. Impresión de gabinete finalizada. . . . . . . . . . . . . . . . . . . . . 26

4.1. Respuesta del detector de ruido ambiente. . . . . . . . . . . . . . . . 304.2. Semáforo realizado con Arduino UNO para testeo. . . . . . . . . . . 304.3. Dispositivo Soniforo en funcionamiento. . . . . . . . . . . . . . . . . 31

XI

Índice de Tablas

3.1. Relación estado semáforo - vibraciones smartphone . . . . . . . . . 233.2. Configuración Kicad . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3. Configuración impresora 3D . . . . . . . . . . . . . . . . . . . . . . . 25

4.1. Test estado dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2. Test aprendizaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3. Test encolar eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4. Test detector de anomalías . . . . . . . . . . . . . . . . . . . . . . . . 284.5. Test configuración de dispositivos . . . . . . . . . . . . . . . . . . . 284.6. Test sensado de tensión . . . . . . . . . . . . . . . . . . . . . . . . . . 294.7. Test ruido ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.8. Test sonido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.9. Pruebas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1

Capítulo 1

Introducción General

Este capítulo introduce al lector en el presente trabajo, la motivación a la queresponde, definición de discapacidad, historia de los semáforos para personasno videntes, funcionamiento básico de estos aparatos, objetivos y alcances deltrabajo.

1.1. Motivación

En Argentina una de cada diez personas poseen algún tipo de discapacidad, sien-do la que más prevalece la discapacidad motora, seguida por la visual, la auditivay la mental [1].

Según la OMS [2] (Organización mundial de la salud), la discapacidad es un tér-mino general que abarca las deficiencias, las limitaciones de la actividad y las res-tricciones de la participación. Las deficiencias son problemas que afectan a unaestructura o función corporal; las limitaciones de la actividad son dificultades pa-ra ejecutar acciones o tareas, y las restricciones de la participación son problemaspara participar en situaciones vitales.

Por consiguiente, la discapacidad es un fenómeno complejo que refleja una inter-acción entre las características del organismo humano y las de la sociedad en laque vive.

En este marco el enfoque del trabajo está dirigido a aquellas personas con disca-pacidad visual, las cuales se enfrentan diariamente con el desafío de calcular dis-tancias en un lugar determinado, y de evitar accidentes al realizarlo. Para abordardicha problemática se utiliza el bastón como principal elemento a la hora de des-plazarse. Ésto supone un mayor inconveniente al circular por la vía pública yaque no existen señales adecuadas que indiquen cuándo es posible cruzar la calle,si la misma está libre de autos circulando o si se produjo un cambio en las lucesdel semáforo. En este tipo de situaciones el bastón no es de completa utilidad, yaque no brinda la información necesaria. Si bien en algunas oportunidades puedenvalerse de la buena predisposición de algún transeúnte, es importante para todapersona poder valerse por sí misma y no depender de un tercero.

Hoy en día con la gran masividad de los teléfonos inteligentes (conocidos po-pularmente como smartphones) y sus diferentes aplicaciones, resulta fácil realizartareas básicas como hacer una suma, tomar una foto o buscar el camino ópti-mo hacia algún destino. La tecnología usada como un puente hacia la inclusiónpuede lograr que personas con discapacidad sean independientes en su vida coti-diana, ya sea revisando su correo electrónico, escuchando música y/o navegando

2 Capítulo 1. Introducción General

por internet. Esa autonomía es el derecho de toda persona, ya que, permite dig-nificarla como tal. El presente trabajo busca la inclusión e independencia de laspersonas no videntes para cruzar la calle.

1.2. Semáforos para no videntes

Según el Instituto Nacional de la Propiedad Industrial (INPI) en el año 1990 elSr. Mario Dávila presento una solicitud de patente sobre ”Un semáforo para cie-gos y discapacitados”. Esa solicitud fue tratada bajo la ley de patentes 111 (envigor en ese momento) la cual establecía que el trámite era secreto hasta su con-cesión. La misma fue abandonada en el año 1993. El funcionamiento del aparatoera muy sencillo, cuando el semáforo de vehículos estaba en verde, el semáforopeatonal emitía una señal sonora entrecortada. Cuando marcaba el rojo, el sonidoera más fuerte y la señal continua. El aporte de Dávila era muy valioso, ya queuna persona no vidente era capaz de valerse de sus propios medios para cruzaruna intersección, sin depender de la ayuda de los transeúntes [3].

Pero existían algunas limitaciones en su uso. En primer lugar el costo que implica-ba su instalación hizo que no sean muy populares y sólo se instalaron en lugaresestratégicos, cercanos a escuelas y otras instituciones de personas no videntes.

Por otra parte, la señal que emitía el semáforo partía de la vereda en la que seencontraba la persona al cruzar, lo que no daba referencia de la dirección en quedebía cruzar la calle ni la ubicación de la acera de enfrente.

Modelos posteriores se diseñaron en función del mismo principio que el originalde Dávila, pero con señales provenientes de la vereda de enfrente. Sin embargo,mantenían un problema, la polución sonora producida por la señal sonora devolumen elevado. A ésto se sumaba la necesaria distancia que debe haber entreestos semáforos para impedir que las señales se superpongan.

Actualmente en el mercado existen estos tipos de aparatos los cuales generan se-ñales audibles que permiten el cruce seguro a las personas con discapacidadesvisuales en las intersecciones semaforizadas. Sobre la columna del semáforo pea-tonal se ubica un pulsador como se observa en la figura 1.1 con una señal auditivade presencia, que permite al no vidente ubicar el pulsador. Cuando se presionael pulsador, se activa un generador de señal auditiva, el cual deberá emitir el tipode sonido correspondiente según cual sea el encendido el semáforo peatonal. Siel cruce peatonal está habilitado el sistema genera una señal sonora aguda y enforma secuencial su par del cruce peatonal opuesto emitirá un tono grave, gene-rando un ping pong sonoro que formará una guía direccional sonora inequívocaentre ambas aceras, garantizando el cruce seguro de la persona no vidente.

FIGURA 1.1: Botón pulsador que acciona la generación de sonido

1.3. Objetivos 3

1.3. Objetivos

El objetivo de este trabajo fue desarrollar un prototipo funcional, abierto, autó-nomo y económico, que permita ser conectado a cualquier semáforo vehicularconvencional. Para ello, debe aprender el comportamiento de las secuencia de lasluces y advertir a las personas no videntes cuándo pueden o no cruzar la calle.Esta advertencia se realiza por medio de una señal sonora y/o vibraciones de susmartphone el cual se conecta a una red WiFi [4] provista por el dispositivo desa-rrollado como muestra la figura 1.2. Este trabajo también incluyó el desarrollo dela aplicación para smartphone.

FIGURA 1.2: Visión general del sistema funcionando

El dispositivo está disponible de manera abierta, es decir, que su código y hard-ware están disponibles para todas las personas que lo deseen.

Este trabajo espera motivar a la comunidad y a todos los interesados en la temá-tica a brindar su aporte.

1.4. Alcance

El desarrollo del presente trabajo incluyó:

Desarrollo de un prototipo funcional.

Desarrollo de una aplicación en Android.

Desarrollo de un protocolo para lograr la escalabilidad en las formas decomunicación con dispositivos de advertencia.

Ajuste de nivel de sonido automáticamente según ruido ambiente.

El presente trabajo no incluyó:

Compatibilidad con otro sistema operativos distintos de Android.

5

Capítulo 2

Introducción Específica

Este capítulo presenta al lector una explicación del funcionamiento de los semá-foros, una vista general del sistema, sus requerimientos y una explicación de lastecnologías involucradas en el desarrollo realizado.

2.1. Semáforos viales

2.1.1. Evolución de los semáforos

La palabra semáforo proviene del griego sema, que significa señal, y foros quesignifica portador, es decir, un semáforo es lo que ”lleva las señales” [5].

En castellano, hace siglos, se llamaba semáforos a las torres de señales, que seextendían por todo el territorio, desde las que por medio de señales ópticas (lucesde noche, banderas de colores de día) se comunicaban las noticias importantes,más deprisa que con un caballo al galope. También se llamaba así a las estacionesdesde las que se transmitían las señales del telégrafo óptico establecido en lascostas y en los puertos, cuyo objeto era dar a conocer las llegadas y las maniobrasde los buques que venían de alta mar o navegaban a la vista o bien, dar a conoceravisos urgentes por medio de bolas y/o de banderas o recibirlos de ellos.

Actualmente, el término semáforo se refiere a un dispositivo mecánico o eléctricoque regula el tráfico de vehículos y peatones en las intersecciones de caminos.

Los semáforos han ido evolucionando con el paso del tiempo. Actualmente seestán utilizando lámparas led para la señalización luminosa, puesto que éstasutilizan sólo 10 % de la energía consumida por las lámparas incandescentes. Ade-más tienen una vida estimada superior, y por tanto generan importantes ahorrosde energía y de mantenimiento, y satisfacen el objetivo de conseguir una mayorfiabilidad y seguridad pública.

2.1.2. Componentes de los semáforos

El semáforo (figura 2.1) está formado por los siguientes componentes:

Cabeza: armadura que contiene las partes visibles del semáforo. Cada ca-beza contiene un número determinado de caras orientadas en diferentesdirecciones.

Soportes: estructuras que se utilizan para sujetar la cabeza de los semáforosde forma que les permitan algunos ajustes angulares, verticales y horizon-tales.

6 Capítulo 2. Introducción Específica

Cara: distintas luces de las cuales están formados los semáforos. En cadacara puede haber desde dos luces hasta más de tres, siendo la de tres luceslas caras más usuales.

Lente: parte de la unidad óptica que por refracción dirige la luz provenien-te de la lámpara y de su reflector en la dirección deseada. Este elementodesaparece en los nuevos semáforos de led.

Visera: elemento que se coloca encima o alrededor de cada una de las unida-des ópticas, para evitar que, a determinadas horas, los rayos del sol incidensobre éstas y den la impresión de estar iluminadas, así como también paraimpedir que la señal emitida por el semáforo sea vista desde otros lugaresdistintos hacia el cual está enfocado.

FIGURA 2.1: Fotografía de una semáforo led en la vía pública.

2.1.3. Clasificación de semáforos

Los semáforos pueden clasificarse en cuatro clases, que se mencionan a continua-ción:

Vehicular: tiene por objeto regular el tránsito de vehículos en las intersec-ciones. Está compuesto esencialmente por tres faros programados para queproyecten durante un tiempo determinado una luz roja, amarilla o verde.

Peatonal: se hallan instalados en combinación con los vehiculares y tienenpor objeto regular el paso de los peatones en intersecciones con alto volú-men de tráfico.

Direccional: tiene como fin informar mediante flechas, el momento adecua-do para girar.

Sonoro: tiene como finalidad informar por medio de una señal sonora cuán-do una persona puede cruzar la calle.

2.2. Tecnología de comunicación empleada en este trabajo 7

En cuanto al funcionamiento del semáforo vehicular se puede decir que, cuandola luz es verde, significa que hay vía libre y se puede pasar. La luz amarilla ad-vierte al conductor que se aproxima un cambio de luz. Al ver la luz roja se debedetener el auto, pues otro flujo de vehículos se interceptará en la dirección de sumarcha.

En los semáforos peatonales, la silueta roja indica que el peatón no debe cruzar lacalle, mientras que la silueta verde o blanca lo permite.

En los semáforos direccionales, la flecha roja prohíbe el giro, y la verde autorizael cruce en ese sentido.

En cuanto al funcionamiento de los semáforos sonoros, emiten una señal audiblecon un tono definido con distintas frecuencias de intermitencia. Éstos funcionanen simultáneo con los semáforos peatonales e indican, el derecho de paso y losintervalos de despeje peatonal. Es decir, orientan al peatón mediante una señalsonora dirigida, el sentido de cruce habilitado de la intersección.

2.1.4. Variaciones de secuencia en los semáforos

En base a la observación del funcionamiento de los semáforos vehiculares en dis-tintas provincias de la República Argentina como ser Córdoba, Catamarca y Tu-cumán se detectaron las siguientes secuencias:

Rojo, rojo-amarillo , verde, amarillo y rojo

Rojo, amarillo, verde, amarillo y rojo

Rojo, amarillo, verde y rojo

Este trabajo contempla las variaciones previamente listadas, las cuales se utiliza-ron como base para las pruebas de funcionamiento.

2.2. Tecnología de comunicación empleada en este trabajo

2.2.1. WiFi

Es una tecnología que permite la interconexión inalámbrica de dispositivos elec-trónicos. Los equipos habilitados con WiFi (tales como computadoras personales,teléfonos, televisores, videoconsolas, reproductores de música, etc) pueden co-nectarse entre sí o a internet a través de un punto de acceso de red inalámbrica.

WiFi es una marca de la Alianza WiFi, la organización comercial que cumple conlos estándares 802.11 [6] relacionados con redes inalámbricas de área local. Suprimera denominación fue, en inglés, Wireless Ethernet Compatibility Alliance.

Existen diversos tipos de WiFi, basados cada uno de ellos en un estándar IEEE802.11.

Los estándares IEEE [7] 802.11b, IEEE 802.11g e IEEE 802.11n disfrutan de unaaceptación internacional debido a que la banda de 2,4 GHz está disponible casiuniversalmente, con una velocidad de hasta 11 Mbit/s, 54 Mbit/s y 300 Mbit/s,respectivamente.

La norma IEEE 802.11 fue diseñada para sustituir el equivalente a las capas físicasy MAC [8] de la norma 802.3 (Ethernet [9]). Ésto quiere decir que en lo único

8 Capítulo 2. Introducción Específica

que se diferencia una red WiFi de una red Ethernet es en cómo se transmitenlas tramas o paquetes de datos. Por tanto, una red local inalámbrica 802.11 escompletamente compatible con todos los servicios de las redes locales (LAN) decable 802.3 (Ethernet).

2.2.2. Protocolo UDP

El protocolo de datagramas de usuario (User Datagram Protocol o UDP) es un pro-tocolo del nivel de transporte basado en el intercambio de datagramas (Encapsu-lado de capa 4 o de Transporte del Modelo OSI [10]). Permite el envío de datagra-mas a través de la red sin que se haya establecido previamente una conexión, yaque el propio datagrama incorpora suficiente información de direccionamientoen su cabecera. Tampoco tiene confirmación ni control de flujo como muestra lafigura 2.2, por lo que los paquetes pueden adelantarse unos a otros y tampocohay confirmación de entrega o recepción.

ReceptorEmisor

Envío Paquete 1

Envío Paquete 2

Envío Paquete 3

FIGURA 2.2: Esquema emisor-receptor de paquetes UDP.

Su uso principal es para protocolos como DHCP, BOOTP, DNS y demás, en losque el intercambio de paquetes de la conexión/desconexión son mayores, o lasobrecarga por la encapsulación del protocolo sea mayor a la información trans-mitida, así como para la transmisión de audio y vídeo en tiempo real, donde noes posible realizar retransmisiones por los estrictos requisitos de retardo que setiene en estos casos.

2.2.3. FreeRTOS

Es un sistema operativo de tiempo real para dispositivos embebidos. Está distri-buido bajo la licencia MIT.

El tipo de sistema operativo se define por cómo el planificador decide cuándodebe ejecutar un determinado programa. El planificador en un sistema operativo

2.3. Esquema general del sistema 9

en tiempo real (RTOS -Real Time Operating System) está diseñado para proporcio-nar un patrón de ejecución predecible (normalmente descrito como determinista).Ésto es particularmente interesante para los sistemas embebidos, ya que estos amenudo tienen requisitos de tiempo real.

Un requisito de tiempo real es aquel que especifica que el sistema embebido deberesponder a un evento determinado dentro de un tiempo estrictamente definido.Sólo se puede garantizar que se cumplan los requisitos si se puede predecir elcomportamiento del planificador del sistema operativo.

Los planificadores tradicionales en tiempo real, como él utilizado en FreeRTOS,logran determinismo al permitir que el usuario asigne una prioridad a cada sub-proceso de ejecución. El planificador luego usa la prioridad para saber qué hilode ejecución realiza a continuación. En FreeRTOS, un hilo de ejecución se llamatarea [11] [12].

2.3. Esquema general del sistema

En la figura 2.3 se presenta un esquema general del sistema implementado.

Entradas Prototipo Salidas

FIGURA 2.3: Esquema general del sistema.

El sistema toma como entradas las luces del semáforo, que se encuentran conec-tadas al prototipo a través de interfaces que detectan la tensión presente en losfocos. Esta información se procesa y según el caso se envían las señales corres-pondientes.

El sistema puede advertir a una persona con discapacidad visual de dos manerasdiferentes:

1. Por un módulo WiFi a través de mensajes UDP hacia una aplicación insta-lada previamente en su smartphone.

2. Mediante una bocina que emite una señal sonora. Para ésto el prototipotoma el ruido ambiente y limita la intensidad de esta señal de manera di-rectamente proporcional al ruido presente.

10 Capítulo 2. Introducción Específica

2.3.1. Requerimientos

De acuerdo a la necesidad que se precisa satisfacer y a lo expuesto, se encontraronlos siguientes requerimientos:

R1. Hardware:

R1.1. Operar con cargas de entradas de 220 V, 50 Hz y 5 A.

R1.2. El hardware involucrado en la detección del cambio de luces debe estartotalmente aislado del módulo principal.

R2. Comunicación:

R2.1. El sistema debe proveer un red WiFi que cumpla con las normas IEEE802.11n.

R2.2. Se debe proveer una señal sonora, su intensidad debe poder variar au-tomáticamente dependiendo del ruido ambiente presente.

R3. Software embebido:

R3.1. El sistema debe ser capaz de aprender la secuencia de cambio de luces.

R3.2. El sistema debe ser capaz de detectar el semáforo fuera de servicio.

R3.3. Se debe implementar un protocolo para la fácil escalabilidad de losdistintos módulos de comunicación.

R3.4. Se debe implementar un sistema operativo de tiempo real.

R4. Metodología de desarrollo:

R4.1. Se deberá utilizar GIT como herramienta de control de versiones.

R4.2. Se deberá utilizar Doxygen como herramienta para generar la docu-mentación.

R4.3. Se deberá desarrollar pruebas unitarias para cada módulo.

R5. Aplicación móvil:

R5.1. Se deberá conectar automáticamente a la red WiFi que provee el siste-ma.

R5.2. Se deberá definir un protocolo de vibraciones según los mensajes delsistema.

11

Capítulo 3

Diseño e Implementación

En este capítulo se presenta la arquitectura del firmware y el patrón de diseñousado para los módulos del sistema. Asimismo, se detallan aspectos funcionalesde cada módulo y se fundamentan las elecciones de los distintos componentes dehardware utilizados.

3.1. Hardware

3.2. Diseño

Como se detalló en la sección 2.3 se pueden distinguir los siguientes subsistemas:

Plataforma dedesarrollo

(EDU-CIAA)

Subsistema decomunicación

Subsistema degeneración de sonido

Subsistema desensado de ruido

ambiental

Subsistema desensado de red

eléctrica

FIGURA 3.1: Subsistemas del dispositivo.

Función de cada subsistema:

Sensado de red eléctrica: se encarga de generar una señal hacia la platafor-ma de desarrollo cuando detecte la tensión en la lámpara del semáforo.

Sensado de ruido ambiental: modula la intensidad de las señales sonoras enfunción del ruido presente en el ambiente.

Plataforma de desarrollo: es el cerebro del dispositivo, ya que se encarga deprocesar y analizar las entradas provenientes de los subsistemas de sensadode red eléctrica y ruido ambiental. Una vez finalizada las etapas anterioresse encarga de mostrar los resultados por medio del subsistema de comuni-cación y generación de sonido.

Comunicación: se encarga de enviar los mensajes por las distintas interfacesa los dispositivos conectados.

Generación de sonido: se encarga de generar una señal sonora audible porlos peatones.

12 Capítulo 3. Diseño e Implementación

3.2.1. Plataforma de desarrollo

Se optó por la EDU-CIAA (figura 3.2) como base para el desarrollo del trabajopor ser una plataforma ya conocida, de amplia disponibilidad, económica y dehardware abierto. Dicha placa posee un microcontrolador LPC4337 de la empresaNXP, el cual cuenta con dos núcleos ARM Cortex-M; un Cortex-M4 y un Cortex-M0.

FIGURA 3.2: La EDU-CIAA posee un microcontrolador LPC4337(dual core ARM Cortex-M4 y Cortex-M0).

3.2.2. Subsistema de Sensado de red eléctrica

Para censar si hay tensión presente en el foco del semáforo vehicular, se utilizaronmódulos con optoacopladores para tensión alterna 220 V (figura 3.3) en cada foco.

FIGURA 3.3: Módulo con optoacopladores para Sensado de ten-sión alterna.

Este módulo se conecta en paralelo con el foco y se obtiene una salida en BAJO sise detecta tensión en los focos y en ALTO si no hay tensión aplicada. Esta salidase conecta a un puerto GPIO de la EDU-CIAA.

Para el trabajo se utilizan tres puertos GPIO1, GPIO3 y GPIO5 correspondientesa los pines 72, 74 y 76, respectivamente. Se muestra en la figura 3.4 la conexióncon la EDU-CIAA.

3.2. Diseño 13

FIGURA 3.4: Conexionado de los módulos de sensado de tensión.Se observa que el pin GPIO1 corresponde a la línea del foco rojo,

GPIO3 a la del amarillo y GPIO5 al verde

3.2.3. Subsistema de toma de ruido ambiental

Para la detección del nivel de ruido ambiente presente se utilizó un módulo queposee un micrófono y un circuito amplificador MAX9814 como se muestra en lafigura 3.6. Este sensor cuenta con un filtro de ruido proveniente de la alimenta-ción, y además un control automático de ganancia.

FIGURA 3.5: Módulo para la detección de sonido

Este módulo posee una serie de opciones configurables de ganancia, por defectoel nivel máximo es de 60 dB, pero puede variar, uniendo los pines Gain a VCC seobtiene una ganancia de 40 db, si se conecta Gain a GND se obtiene una gananciade 50 db. La salida desde el amplificador está alrededor de 2 Vpp max. sobre unabase de 1,25V DC, por lo que puede ser conectado fácilmente a la entrada ADCde la EDU-CIAA.

El LPC4737 presente en la EDU-CIAA posee un ADC de 10 bits con una tasa demuestreo máxima de 400 kmuestras por segundo.

En la figura 3.6 se observa el conexionado del módulo a la EDU-CIAA.

14 Capítulo 3. Diseño e Implementación

FIGURA 3.6: Conexionado del módulo de detección de sonido a laEDU-CIAA. La conexión se hace por medio del pin Out del mó-

dulo y el PIN 13 (ADC1) de la EDU-CIAA

Según el nivel de intensidad del ruido ambiente presente se definieron tres tiposde niveles de salida de acuerdo a la entrada. Como se tiene un conversor analó-gico digital de 10 bits, la entrada puede estar comprendida entre un valor de 0 a1024, con ésto se definió los niveles posibles en función de la entrada.

Nivel bajo: 0 a 600

Nivel medio: 600 a 700

Nivel alto: 700 a 1024

La intensidad del sonido es medida aplicando dos filtros a la señal de entrada. Elprimer filtro se realiza en un periodo de 2 s, tomando un total de diez muestrasde las cuales, se detecta el máximo y mínimo valor de intensidad en ese período,almacenando la diferencia en un arreglo.

El segundo filtro calcula el promedio de las muestras del arreglo de forma diná-mica a través de una ventana móvil.

En la siguiente figura se observa en azul la señal de entrada, en verde la señalcuando se aplica el primer filtro y en rojo la señal final con el último filtro.

FIGURA 3.7: En azul la señal de entrada, en verde la señal con elprimer filtro, en rojo la señal con el segundo filtro.

3.2. Diseño 15

3.2.4. Módulo generador de sonido

Para generar las señales sonoras se utilizó un módulo amplificador HXJ8002 desonido (figura 3.8), se alimenta con 5 V. Este amplificador se conecta a un par-lante de 8 Ω el cual puede entregar una potencia máxima de 1,5 W con 5 V dealimentación.

FIGURA 3.8: Módulo amplificador HXJ8002.

Este módulo posee tres entradas IN, VCC, GND y dos salidas L y R correspon-dientes a derecha e izquierda de un sonido stereo. El módulo es conectado comose muestra en la figura 3.9 a la salida DAC de la EDU-CIAA.

FIGURA 3.9: Conexionado del módulo de generación de sonidoa la EDU-CIAA. La conexión se hace por medio del pin Out del

módulo y el PIN 13 (ADC1) de la EDU-CIAA

3.2.5. Subsistema de comunicación

Módulo WiFi

El ESP01 [13] es un módulo que contiene un microcontrolador ESP8266 [14] debajo coste con WiFi integrado fabricado por la empresa Espressif [15] (figura 3.10).Este módulo tiene comunicación integrada 802.11 b/g/n, incluidos modos WiFiDirect (P2P) [16] y softAp [17]. Incluye una pila de TCP/IP completa, lo que liberade la mayor parte del trabajo de comunicación al procesador.

16 Capítulo 3. Diseño e Implementación

FIGURA 3.10: Módulo inalámbrico ESP01.

En la figura 3.11 se observa el conexionado entre la ESP01 y la EDU-CIAA. Laprogramación del módulo se hace a través de comandos AT. También conoci-dos como comandos Hayes, es un lenguaje desarrollado por la compañía HayesCommunications que prácticamente se convirtió en estándar abierto de coman-dos para configurar modems. Se envían los comandos a través de la interfaseRS232 presente en la EDU-CIAA.

FIGURA 3.11: Conexion de la ESP01 al puerto RS232 de la placaEDU-CIAA.

3.2.6. Arquitectura general del sistema

En la figura 3.12 se muestra el dispositivo junto a su ecosistema. Los módulosson utilizados para capturar eventos y reaccionar en consecuencia, se puedenobservar éstos y su tipo de conexión a la placa principal EDU-CIAA.

A la izquierda de la figura 3.12 se encuentran las luces del semáforo conectadasa la EDU-CIAA a través de las entradas GPIO. El ruido ambiente, es captado porel sensor de ruido, el cual está conectado a la interfase ADC. Tanto el semáforocomo el ruido ambiente conforman las entradas del dispositivo. Como salidas seencuentran un módulo de WiFi y un amplificador de sonido que está conecta-do a un parlante. Por último, a la derecha de la figura, se muestra la aplicaciónAndroid instalada en el smartphone.

3.3. Firmware 17

ENTRADAS DISPOSITIVO USUARIO FINAL

SEMÁFORO

RUIDOAMBIENTE

RS232

DAC Amplificador

Sensor ruido ADC CI//\

Detector tensión

Detector tensión

Detector tensión

GPIO

GPIO

GPIO

WiFi

FIGURA 3.12: Diagrama general del hardware.

3.3. Firmware

3.3.1. Arquitectura

Al trabajo se le dio el nombre de Soniforo, de la conjunción da las palabras sonidoy semáforo.

Se optó por un modelo de capas jerárquico para organizar el código en los distin-tos niveles de abstracción.

En la figura 3.13 se observa como se planteó este trabajo.

LPC OPEN

HARDWARE

BOARD DRIVERS

FREE RTOS sAPI

SONIFORO

PERIPHERALDRIVER

EVENTFRAMEWORK

RTOS TASKS

RTOS SERVICE

FIGURA 3.13: Estructura de capas para el firmware.

18 Capítulo 3. Diseño e Implementación

La primera capa constituye el hardware de la plataforma EDU-CIAA. La segundacapa, Hardware Abstraction Layer (HAL), permite desacoplar las capas superioresdel hardware. Aquí se encuentran los drivers del fabricante del microcontrolador,en el bloque funcional LPC Open. La capa Hardware Independent Layer (HIL) in-cluye los módulos del RTOS (no está asociada a ningún hardware en particular)y sAPI que permite el manejo de los periféricos de la placa con mayor facilidad.

Sobre esta base hay capas orientadas a servicios que procesa la información delsistema, estas son:

RTOS Service: creación de tareas, temporizadores, semáforos binarios.

Peripheral Driver: configuración de los periféricos, interrupciones, UART,etc.

Event Framework: definición y creación de todos los eventos del sistema.

Por encima de las capas de servicios se ubican todas las tareas que corren y sonpropias del sistema, a ésta se la llama RTOS Task. Finalmente, la última capacontiene la aplicación Soniforo, que inicia la aplicación y los módulos que corres-ponden.

3.3.2. Principio de funcionamiento

El firmware fue diseñado en base a distintos patrones de software vistos a lo largode la carrera, principalmente se basa en el diseño ”Observar y reaccionar”, estepatrón permite reaccionar a distintos eventos de una manera predefinida. En con-junto con este patrón el sistema implementa ”Lazos de eventos”. Las reaccionesproducen mensajes y según el estado en el cual se encuentre el sistema se disparauna acción.

En la figura 3.14 se muestra el flujo de trabajo del sistema. Los cambios de lucesson eventos que produce el semáforo, éstos se envían a una cola, que, según eltipo y el estado del sistema reacciona de una manera predefinida.

DAC

CONTROL DE VOLUMEN

RS232

INTERRUPCIONES

ENTRADAS

GPIO0_IRQHandler() GPIO GPIO1_IRQHandler() GPIO

GPIO2_IRQHandler() GPIO

CI/\\

ADC

SEMAFORO

eventQueueCOLA DE MENSAJES

rs232RxQueue

COLA DE MENSAJES

rs232TxQueue

ESP8266

COLA DE MENSAJES

TAREAS PARA ENVIO DE ESTADO

esp01ConfigurationTask()

sendStatusCrossToEsp01Task()

sendStatusCautionToEsp01Task()esp01ExpectedResponseTask()

TEMPORIZADORES

redLightTimerHandle

yellowLightTimerHandle

greenLightTimerHandle

initConfigurationTimerHandle

FUNCIONES DE CALLBACK

redLightCallback()

greenLightCallback()yellowLightCallback()

MANEJADORES DE EVENTOS

lightsHandler(event_t)lightsTimeHandler(event_t)statusHandler(event_t) learningHandler(event_t)

configurationHandler(event_t) broadcastHandler(event_t)

taskProcessNoise() AMPLIFICADOR

SENSOR DE SONIDO

FIGURA 3.14: Diagrama general de funcionamiento.

3.3. Firmware 19

Se define un tipo de dato especial, event_t que contiene la información necesa-ria para manejar los eventos.

1 s t r u c t event_t 2 module_t ∗ r e c e p t o r ;3 i n t s i g n a l ;4 led_name_t ledName ;5 ;

Los estados de las luces pueden ser:

Luz encendida

Luz apagada

Podemos ejemplificar este flujo, para el caso en el cual se enciende la luz roja:

1. Se produce una interrupción de la luz roja.

2. Esta interrupción es manejada por su función.

3. Se envía un evento a la cola eventQueue.

4. La tarea encargada de recibir los eventos, lee el mensaje y ejecuta el mane-jador correspondiente.

5. Se ejecuta la acción.

3.3.3. Diseño del firmware

Para modelar la solución se utilizó una máquina de estado finito, también cono-cidas como MEF, ésta se puede definir como un modelo que realiza cómputos enforma automática sobre una entrada para producir una salida.

Este modelo está conformado por un alfabeto, un conjunto de estados finito, unafunción de transición, un estado inicial y un conjunto de estados finales.

De esta manera se observa en la figura 3.15 la máquina de estado finito pertene-ciente al sistema, por simplicidad algunos estados y transiciones fueron elimina-dos.

Al energizarse el sistema o luego de un reinicio, el dispositivo se encuentra enestado INIT donde inicia un temporizador llamado initConfigurationTimerHandle,su función principal es estabilizar las entradas y tensiones involucradas, una vezexpirado este temporizador se envía un mensaje para iniciar el sistema, llevandoal dispositivo al estado CONFIGUING_INIT.

De una manera simplificada el sistema puede encontrarse en tres estados genera-les:

Configuración: donde se inicializan todos los módulos para la comunica-ción con dispositivos externos.

Aprendizaje: el sistema usa el prendido y apagado de las luces del semáforoy con ello aprende su funcionamiento tomando los tiempos de las luces.

20 Capítulo 3. Diseño e Implementación

Corriendo: el sistema funcionando de manera autónoma, siempre y cuandono detecte anomalías en los cambios de las luces del semáforo.

initConfigurationTimerHandle

INIT

SIG_CONFIGURING_FINISH

CONFIGURINGINIT

GREEN_LIGHT_ON

LIGHT WATCH DOG

WAITINGGREENLIGHT

GREEN_LIGHT_ON

LIGHT WATCHDOG

WAITINGAGAING GREENLIGHT

RED_LIGHT_ON

LIGHT WATCHDOG

WAITING RED

LIGHT

RED_LIGHT_ON

WAIT

GREEN_LIGHT_ON

yellowLightTimerHandle

CAUTION

redLightTimerHandle

CROSS

LEARNING INIT

LIGHT BLINKERS

APRENDIZAJE

CONFIGURACION

CORRIENDO

SIG_FAIL_CONFIG

FIGURA 3.15: Máquina de estado finito del sistema.

Configuración

Cuando el dispositivo se encuentra en el estado CONFIGUING_INIT configuratodos los dispositivos de comunicación.

La ESP01 se configura a través de comandos AT. Se envían los correspondientescomandos para que iniciar un punto de acceso inalámbrico de nombre ”SoniforoCIAA”, de tal forma que, cualquier smartphone pueda conectarse a la red inalám-brica propiamente dicha.

Una vez configurado correctamente el punto de acceso, se inicia un servidor UDPen el puerto 4096 para enviar mensajes broadcast por dicho puerto.

A continuación se enumeran los comando que debe enviar la EDU-CIAA a travésdel puerto RS232 hacia la ESP01 para configurar de manera correcta, el punto deacceso y el servidor UDP:

1. AT

2. AT+RST

3. AT+CWMODE=2

4. AT+CWSAP=“Soniforo_CIAA”,“”,8,0

3.3. Firmware 21

5. AT+CWDHCP=0,1

6. AT+CWDHCP=1,1

7. AT+CIPSTART=3,“UDP”,“0”,0,4096,2

8. AT+CIPSEND=3,8,“192.168.4.255”,4096

9. AT+CIPMUX=1

10. AT+CIPDINFO=1

11. AT+CWAUTOCONN=0

Para más detalle sobre la funcionalidad de cada comando, el lector puede recurrira la documentación que provee el fabricante [18].

Cada comando posee una respuesta conocida es por ésto que por cada uno se es-pera la respuesta previamente definida, si ésto no sucede después de tres intentosse envía la señal SIG_FAIL_CONFIG de manera que el sistema regrese al estadoINIT.

Aprendizaje

La solución abstracta a la problemática radica en el momento adecuado para in-dicar el cruce de la calle, es decir, cuándo un peatón puede o no cruzar la calle.

En Argentina no existe un protocolo único de cambios de luces, por ello para serindependiente de ésto se necesita conocer el tiempo de los autos en espera unavez producido el cambio de luz.

Lo que busca el sistema es el tiempo que necesita el peatón para cruzar la callecuando se dispara la luz roja.

Como no se sabe a priori el momento del ciclo del semáforo que el dispositivoinicia su funcionamiento, el proceso de aprendizaje se hace a través del encendidoy apagado de las luces roja y verde.

Una vez finalizado el estado de configuración correctamente el dispositivo pa-sa al estado LEARNING_INIT. Donde se espera el encendido de la luz verde,por ésto envía al dispositivo al estado WAITING_GREEN_LIGHT de manera talque, si se detecta el encendido de la luz tome su tiempo, lo guarde en la variablegreenLightTimerHandle y espere por el encendido de la luz roja, para ésto se poneal dispositivo en el estado WAITING_RED_LIGHT. Cuando llega la luz roja sedetiene el tiempo de la luz verde e inicializa el tiempo para la luz roja mientrasespera nuevamente la luz verde, es por ésto, que se pasa al dispositivo al estadoWAITING_AGAIN_GREEN_LIGHT.

Podemos ejemplificar la secuencia en la figura 3.16 para el caso donde la secuen-cia de las luces son rojo, rojo-amarillo, verde, amarillo, rojo.

Si por alguna razón se detecta alguna anomalía, como ser un semáforo fuera deservicio el sistema regresa al estado LEARNING_INIT.

22 Capítulo 3. Diseño e Implementación

Estados t [s]WAITING

GREENLIGHT

WAITING RED

LIGHT

WAITINGAGAING GREENLIGHT

WAIT

Acciones Iniciotemporizador

luz verdeFin

temporizadorluz verde

YInicio

temporizadorluz roja

Fintemporizador

luz roja

AUTOS DETENIDOS AUTOS EN MARCHA AUTOS DETENIDOS AUTOS EN MARCHA

Tiempo verde Tiempo Rojo

FIGURA 3.16: Máquina de estado finito del sistema.

Corriendo

Una vez finalizado correctamente el aprendizaje de los tiempos, el sistema calculael tiempo límite para indicar a la persona que puede cruzar la calle, esto se hacecon el tiempo de la luz roja a través de la siguiente fórmula 3.1:

redLightT imerHandle = tiempoLuzRojo ∗ 0,65 (3.1)

De igual manera se hace el cálculo para el tiempo en el cual está próximo uncambio de luz a través de la siguiente fórmula 3.2:

yellowLightT imerHandle = tiempoLuzRojo ∗ 0,35 (3.2)

Estos porcentajes fueron calculados de manera empírica. Y pueden modificarsesegún cada problemática. Estos temporizadores son gestionados por el FreeRTOSde manera tal que cuando expiren llamen a funciones predefinidas.

El sistema posee tres temporizadores los cuales son iniciados cuando se detectauna luz encendida.

redLightTimerHandle: tiempo de la luz roja encendida.

yellowLightTimerHandle: tiempo para cruzar la calle con precaución.

greenLightTimerHandle: tiempo de la luz verde.

Una vez configurados los temporizadores, se esperan las interrupción de las lucesdel semáforo. La luz roja desbloquea la tarea que envía el estado CROSS a laESP01, además inicia el temporizador redLightTimerHandle, cuando este expirese bloquea la tarea que envia el estado de CAUTION hacia la ESP01. La luz verdedesbloquea la tarea de enviar el estado WAIT, cabe recordar que los mensajesbroadcast UDP se envían a través del puerto 4096.

3.4. Aplicación Android 23

3.4. Aplicación Android

Para recibir los estados del semáforo correctamente se diseñó una aplicación deprueba simple para la plataforma móvil Android, ésta corre desde la versión 4.0.0(Ice Cream Sandwich) [19], dicha aplicación es capaz de vibrar según el tipo decomando que reciba desde el prototipo.

Se observa en la figura 3.17 la pantalla principal de la aplicación. La misma constade dos botones, uno para inicial la escucha de mensajes UDP provenientes delpuerto 4096 y la otra para obtener información acerca de la aplicación.

Iniciar la conexión

Información de laaplicación

FIGURA 3.17: Interfase gráfica de la aplicación Android desarro-llada

En la tabla 3.1 se muestra la relación entre los estados enviados y el tipo de vibra-ción que produce.

TABLA 3.1: Relación entre el estado del semáforo y las vibracionesemitidas

Estado enviado Tipo de vibraciones

Esperar Sin vibracionesCruzar Vibraciones 2 segundos con 2 segundos de esperaPrecaución Vibraciones de 1 segundos con 1 segundos de espera

Una vez iniciada la escucha de los mensajes, la aplicación además de vibrar enintervalos muestra diferentes colores en la pantalla. Roja si no se puede cruzarla calle, verde si se puede cruzar la calle y amarilla si está próximo el cambio deluces (figura 3.18).

24 Capítulo 3. Diseño e Implementación

(a) ESPERAR (b) CRUZAR (c) PRECAUCIÓN

FIGURA 3.18: Pantallas de la aplicación según el estado del semá-foro. (a) No debe cruzar la calle. (b) Puede cruzar la calle. (c) Se

aproxima el cambio de luces.

3.5. Poncho

Para conectar los módulos externos principal EDU-CIAA se utilizó la aplicaciónEeschema del KiCAD 5. El diseño se llevó a cabo conectando los puertos de laEDU-CIAA a los diferentes módulos externos, también adicionalmente se agre-garon puertos para conectar una fuente externa de manera tal que la placa prin-cipal no tenga exigencia de corrientes. La placa fue hecha en doble capa, con elmétodo de plancha y cloruro férrico.

Se observa en la figura 3.19 el poncho terminado.

FIGURA 3.19: Poncho desarrollado para el dispositivo.

3.6. Gabinete 25

Los parámetros que se utilizaron para el diseño de la placa se listan en la tabla3.2.

TABLA 3.2: Configuración para el diseño en Kicad.

Parámetros de diseño

Grillas 1 mm, 0,5 mm, 0,25 mmVias 2 mm / 0,8 mmMargen 0,2 mmPistas 1 mm

3.6. Gabinete

Para el diseño del gabinete se utilizó el programa de modelado 3D en línea Tin-kercad 1 (figura 3.20) por ser simple y de fácil uso. El gabinete fue impreso en unaimpresora 3D MDF (Modelado por deposición fundida) en el material PLA, unpolímero biodegradable derivado del ácido láctico, se fabrica a partir de recursosrenovables como el maíz, trigo, remolacha y otros productos ricos en almidón. Esun materiales fácil de tratar, barato y apto para realizar prototipos.

FIGURA 3.20: Vista del modelo en programa online tinkercad.

En la figura 3.21 se muestra el resultado de la impresión 3D, la misma tardo 9 h.Las medidas del gabinete son 20x20x6 cm.

Se muestra en la tabla 3.3 la configuración utilizada para la impresión.

TABLA 3.3: Configuración básica para la impresión 3D

Configuración

Modelo impresora Anet A6Ancho boquilla 0,8 mmAltura de capa 0,5 mmTemperatura material 210 CVelocidad impresión 30 mm/s

1https://www.tinkercad.com/

26 Capítulo 3. Diseño e Implementación

FIGURA 3.21: Impresión de gabinete finalizada.

27

Capítulo 4

Ensayos y Resultados

En este capítulo se detalla el testing que se realizó al dispositivo y se documentanlos ensayos realizados a nivel funcional, módular y de sistema.

4.1. Test unitarios

Para realizar pruebas unitarias al código se utilizó el framework Ceedling que sedistribuye como una gema del lenguaje de programación ruby. Ceedling integratres herramientas, Unity, Cmock y CException y se encarga de compilar y ejecu-tar los test sobre el código. A continuación se presentan los casos de prueba quese definieron para ensayar con test unitarios, las funciones de los cuatro módulosdesarrollados. En cada subsección se muestra una tabla donde se recopilan loscasos de prueba para el módulo. En la primer columna se incluye un código deidentificación único del test que permite realizar la trazabilidad con los requeri-mientos.

4.1.1. Módulo estado del dispositivo

El objetivo de estos test, es verificar que el sistema realice los cambios de estadosdefinidos según los estímulos, como se puede apreciar en la tabla 4.1.

TABLA 4.1: Listado de test realizados al módulo estado del dispo-sitivo.

Test ID Nombre del test Estado

SFR_001 test_el_sistema_pasar_estado_init OKSFR_002 test_el_sistema_pasar_estado_config_init OKSFR_003 test_el_sistema_pasar_estado_waiting_green_light OKSFR_004 test_el_sistema_pasar_estado_waiting_red_light OKSFR_005 test_el_sistema_pasar_estado_waiting_again_green_light OKSFR_006 test_el_sistema_pasar_estado_learning_finish OKSFR_007 test_el_sistema_pasar_estado_running OKSFR_008 test_el_sistema_no_debe_cambiar_estado OK

4.1.2. Módulo de aprendizaje

El objetivo de estos test, es enviar los mensajes de eventos correctos hacia los dis-positivos de comunicación según se enciendan o apaguen las luces del semáforo,como se puede apreciar en la tabla 4.2.

28 Capítulo 4. Ensayos y Resultados

TABLA 4.2: Listado de test realizados al módulo de aprendizaje.

Test ID Nombre del test Estado

SFR_009 test_puede_cruzar_la_calle OKSFR_010 test_tiene_que_apurar_el_paso OKSFR_011 test_culquier_estado_debe_esperar OK

4.1.3. Módulo encolar eventos

El objetivo de estos test es enviar los mensajes correctos según los estímulos defi-nidos, como se puede apreciar en la tabla 4.3.

TABLA 4.3: Listado de test realizados al módulo encolar eventos.

Test ID Nombre del test Estado

SFR_012 test_debe_encolar_cuando_se_encienda_la_luz_verde OKSFR_013 test_debe_encolar_cuando_se_apaga_la_luz_verde OKSFR_014 test_debe_encolar_cuando_se_encienda_la_luz_roja OKSFR_015 test_debe_encolar_cuando_se_apaga_la_luz_roja OKSFR_016 test_debe_encolar_cuando_se_encienda_la_luz_amarilla OKSFR_017 test_debe_encolar_cuando_se_apaga_la_luz_amarilla OK

4.1.4. Módulo detector de anomalías

El objetivo de estos test es detectar posibles anomalías en el funcionamiento desemáforo vehicular y tomar las acciones definidas, como se puede apreciar en latabla 4.4.

TABLA 4.4: Listado de test realizados al módulo detector de ano-malías.

Test ID Nombre del test Estado

SFR_018 test_el_sistema_debe_funcionar_correctamente OKSFR_019 test_el_sistema_debe_detectar_anomalia_luz_intermitente OKSFR_020 test_el_sistema_debe_detectar_anomalia_luces_se_apagan OK

4.1.5. Módulo configuración de dispositivos

El objetivo de estos test es verificar que la ESP01 se configure correctamente, delo contrario debe detectar la falla y tomar las acciones definidas, como se puedeapreciar en la tabla 4.5.

TABLA 4.5: Listado de test realizados al módulo de configuraciónde dispositivos.

Test ID Nombre test Estado

SFR_021 test_configuracion_esp_correcta OKSFR_022 test_configuracion_esp_incorrecta OK

4.2. Test funcionales 29

4.2. Test funcionales

Para este tipo de pruebas se verificó que cada módulo funcione correctamente,independiente del resto. En algunos casos se programaron pequeños bloques decódigos para tener un testing más limpio.

4.2.1. Módulo sensado de tensión

Este módulo está conformado por tres módulos de detección de tensión con oc-toacopladores, es por ésto que se realizó el mismo test para los tres módulos. Setesteó tanto el correcto funcionamiento del módulo físico así como la detecciónde la interrupción en el dispositivo, tanto para flanco ascendente cómo flancodescendente, como se puede apreciar en la tabla 4.6.

TABLA 4.6: Listado de test realizados al módulo de sensado detensión.

Test ID Nombre test Estado

SFR_023 funcional_debe_detectar_tension_foco_rojo OKSFR_024 funcional_debe_detectar_apagado_foco_rojo OKSFR_025 funcional_debe_detectar_interrupcion_foco_rojo OKSFR_026 funcional_debe_detectar_tension_foco_verde OKSFR_027 funcional_debe_detectar_apagado_foco_verde OKSFR_028 funcional_debe_detectar_interrupcion_foco_verde OKSFR_029 funcional_debe_detectar_tension_foco_amarillo OKSFR_030 funcional_debe_detectar_apagado_foco_amarillo OKSFR_032 funcional_debe_detectar_interrupcion_foco_amarillo OK

4.2.2. Módulo detección de ruido ambiente

Para el testeo de este módulo se utilizó la aplicación Android Sonómetro dispo-nible en Google Play. Con ella se tuvo referencia de la intensidad del sonido a lacual el dispositivo está siendo sometido, como se puede apreciar en la tabla 4.7

TABLA 4.7: Listado de test realizados al módulo de ruido ambien-te.

Test ID Nombre test Estado

SFR_033 funcional_detectar_ruido_bajo OKSFR_034 funcional_detectar_ruido_medio OKSFR_035 funcional_detectar_ruido_alto OK

4.2.3. Prueba de sonido

Para el testeo de este módulo se utilizó ruido blanco de distintas intensidades, yaque es una señal que contienen todas las frecuencias deseadas (200 - 2000 Hz) ytodas con la misma potencia. Los distintos test se puede apreciar en la tabla 4.8.En la figura 4.1 se observa la respuesta del filtro aplicado en el sensado de ruidoambiental.

30 Capítulo 4. Ensayos y Resultados

TABLA 4.8: Listado de test realizados al módulo de sonido.

Test ID Nombre test Estado

SFR_036 funcional_debe_generar_sonido_bajo OKSFR_037 funcional_debe_generar_sonido_medio OKSFR_038 funcional_debe_generar_sonido_alto OK

Zona 1

Zona 2

Zona 3

FIGURA 4.1: Respuesta del detector de ruido ambiente.

4.3. Pruebas de sistema

Estas pruebas se basaron en el dispositivo funcionando de manera integral, simu-lando el funcionamiento real al que podría ser sometido. Para ello se fabricó unsemáforo de pruebas, con una placa Arduino UNO conectada a tres módulos conrelés.

El programa cargado en la placa Arduino UNO (figura 4.2) posee distintos per-files de secuencias para las luces, como se menciona en la sección 2.1.4. Ademáscuenta con un botón que simula un semáforo fuera de servicio.

FIGURA 4.2: Semáforo realizado con Arduino UNO para testeo.

4.3. Pruebas de sistema 31

Los perfiles cargados en el semáforo de prueba fueron:

Perfil 1: Rojo, rojo-amarillo , verde, amarillo y rojo

Perfil 2: Rojo, amarillo, verde, amarillo y rojo

Perfil 3: Rojo, amarillo, verde y rojo

Se muestra en la figura 4.3 el dispositivo en funcionamiento:

FIGURA 4.3: Dispositivo Soniforo en funcionamiento.

4.3.1. Pruebas en el dispositivo

Para este tipo de pruebas se utilizó el semáforo de pruebas, el dispositivo realiza-do y un teléfono Android con la aplicación instalada, como se puede apreciar enla tabla 4.9.

TABLA 4.9: Listado de test realizados al dispositivo.

Test ID Nombre test Estado

SFR_039 sistema_debe_iniciar_correctamente_modo_uno OKSFR_040 sistema_debe_iniciar_correctamente_modo_dos OKSFR_041 sistema_debe_iniciar_correctamente_modo_tres OKSFR_042 sistema_debe_detectar_fuera_de_servicio_modo_configuracion FAILSFR_043 sistema_debe_detectar_fuera_de_servicio_modo_corriendo OKSFR_044 sistema_debe_detectar_apagado_semaforo_configuracion FAILSFR_045 sistema_debe_detectar_apagado_semaforo_corriendo OKSFR_046 sistema_debe_indicar_cruzar_calle OKSFR_047 sistema_debe_indicar_cambio_luz OKSFR_048 sistema_debe_indicar_no_cruzar_calle OK

Los test SFR_042 y SFR_044 fallaron ya que el requerimiento para detectar unaanomalía en el modo CONFIGURING no se tuvo en cuenta en la etapa inicial derecolección de requerimientos funcionales. El firmware fué diseñado para detec-tar las anomalías en el estado RUNNING. Si bien en los dos casos no se detectó la

32 Capítulo 4. Ensayos y Resultados

anomalía, el dispositivo inició el modo LEARNING pero nunca lo finalizó, es de-cir, el dispositivo nunca inició el proceso de advertir los cambios de luces (modoRUNNING). La seguridad de la persona no está comprometida con este fallo.

33

Capítulo 5

Conclusiones

En esta sección se detallan cuáles fueron los conceptos utilizados para el desa-rrollo del trabajo, los principales aportes del trabajo realizado y cómo se podríacontinuar.

5.1. Conclusiones generales

Se logró poner en marcha un dispositivo capaz de aprender las secuencias máscomunes de funcionamiento en semáforos vehiculares observados. Se utilizaronherramientas libres y gratuitas. Se aplicaron buenas prácticas de programación ydiseño, de manera tal que cualquier interesado sea capaz de comprender, apren-der y aportar fácilmente al desarrollo.

En cuanto a los resultados obtenidos, se puede mencionar que se cumplieron conlos requerimientos planteados en el inicio del trabajo. Si bien los tiempos pro-gramados al inicio para algunas tareas fueron insuficientes debido a obligacionesparticulares, se finalizó con éxito el trabajo.

A lo largo del trabajo se han abarcado y llevado a la práctica diferentes conceptosadquiridos durante la carrera. Si bien cada una de las asignaturas cursadas aportóconocimiento y experiencia para el desarrollo del trabajo, se pueden mencionaraquellas de mayor relevancia:

El diseño de circuitos impresos, tanto en el manejo de herramientas de soft-ware como de distintas metodologías de fabricación.

Desarrollo de software, arquitecturas y modelos de programación.

Manejo y programación de sistemas operativos de tiempo real.

Criterios de diseño sobre protocolos de comunicación.

Manejo de periféricos e interfaces de comunicaciones en microcontrolado-res.

Herramientas para el control de versiones y repositorios.

Planificación de proyectos, tanto estructurados como con metodologías ági-les.

34 Capítulo 5. Conclusiones

5.2. Próximos pasos

En base al testing realizado en el capítulo 4 y las decisiones de diseño tomadaspara el desarrollo del dispositivo, se obtuvieron las siguientes recomendacionesy mejoras futuras, tanto de hardware como de firmware.

Con respecto al hardware:

Una alternativa al módulo de censado de tensión podría ser relés de estadosólido ya que aísla totalmente al dispositivo de la linea de tensión alterna.

El diseño de gabinete debería ser impermeable al agua.

Proveer otros medios de comunicación como Bluetooth.

El poncho debería tener su fuente de alimentación incorporada.

Según lo investigado algunos equipos de similares características poseenhardware redundante en caso de fallas.

El mecanismo que detecta anomalías podría ser un hardware externo.

En el firmware se recomienda:

Ampliar la aplicación para smartphone a otras plataformas como iOS.

Mejorar el filtro de sensado de ruido ambiental.

Agregar logs para mejorar la depuración.

Optimizar el sistemas de colas.

Implementar algoritmos de machine learning.

Agregar más controles de fallas para otros escenarios.

Agregar la detección de una anómala cuando el dispositivo está configu-rando los módulos de comunicación.

El trabajo fue concebido con un enfoque de hardware y software abierto a la co-munidad, por lo que se recomienda que el próximo paso referente a ésto, sea crearun plan para organizar el proyecto donde se lideren y organicen los aportes de lacomunidad.

35

Bibliografía

[1] Indec. Estudio Nacional sobre el Perfil de las Personas con Discapacidad.Disponible: 2019-07-13. URL: https://www.indec.gob.ar/ftp/cuadros/poblacion/estudio_discapacidad_12_18.pdf.

[2] OMS. Discapacidad. Disponible: 2019-11-06. URL:https://www.who.int/topics/disabilities/es/.

[3] Eugenia Sacerdote de Lustig. Inventos argentinos. Disponible: 2019-11-30.URL: https://bibliotecavirtual.unl.edu.ar/publicaciones//index.php/ConCiencia/article/download/2240/3260/.

[4] Real academia española. Definicion de wifi. Disponible: 2019-07-13. URL:https://dle.rae.es/?id=c6ehZd8.

[5] Wikipedia. Semáforo. Disponible: 2019-07-11. URL:https://es.wikipedia.org/wiki/Sem%C3%A1foro.

[6] Wikipedia. IEEE 802.11. Disponible: 2019-11-06. URL:https://es.wikipedia.org/wiki/IEEE_802.11.

[7] Wikipedia. IEEE. Disponible: 2019-11-06. URL: https://es.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers.

[8] Wikipedia. Dirección MAC. Disponible: 2019-11-11. URL:https://es.wikipedia.org/wiki/Direcci%C3%B3n_MAC.

[9] Wikipedia. Ethernet. Disponible: 2019-11-11. URL:https://es.wikipedia.org/wiki/Ethernet.

[10] Wikipedia. Modelo OSI. Disponible: 2019-11-06. URL:https://es.wikipedia.org/wiki/Modelo_OSI.

[11] Wikipedia. Inventos argentinos. Disponible: 2019-11-30. URL:https://es.wikipedia.org/wiki/FreeRTOS.

[12] Amazon. FreeRTOS. Disponible: 2019-11-30. URL:https://www.freertos.org/.

[13] Esp01. Hoja de datos Esp01. Disponible: 2019-07-31. URL:http://www.microchip.ua/wireless/esp01.pdf.

[14] Espressif. Hoja de datos ESP8266. Disponible: 2019-07-31. URL:https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf.

[15] Espressif. Espressif Systems. Disponible: 2019-07-31. URL:https://www.espressif.com/.

[16] Wikipedia. Wi-Fi Direct. Disponible: 2019-07-31. URL:https://es.wikipedia.org/wiki/Wi-Fi_Direct.

[17] Wikipedia. SoftAP. Disponible: 2019-07-31. URL:https://es.wikipedia.org/wiki/SoftAP.

[18] Espressif. Hoja de comandos ESP8266. Disponible: 2019-08-07. URL:https://www.espressif.com/sites/default/files/documentation/4a-esp8266_at_instruction_set_en.pdf.

[19] Wikipedia. Android Ice Cream Sandwich. Disponible: 2019-08-08. URL:https://es.wikipedia.org/wiki/Android_Ice_Cream_Sandwich.