Proyecto seytrma2526g09 · URJC

Autores

Sergio Montañés Díaz

Alejandra Uzquiano Naranjo

Raúl Mojío López

1. INTRODUCCIÓN

En este proyecto de la asignatura de Sistemas Empotrados y de Tiempo Real nos hemos propuesto llevar a cabo el diseño y creación de un simulador  de desactivación de artefactos explosivos, como se le suele llamar un “juego de desactivar la bomba”. La idea nació en intentar recrear estas salas de “escape room” o las típicas películas donde el protagonista en el último segundo salva el mundo, donde aquí el usuario tiene que enfrentarse a un cronómetro en tiempo real mientras resuelve acertijos y prueba su suerte.

Hemos elegido esta temática de “a contra reloj”, ya que al a parte de ser un juego divertido, tenso y visualmente atractivo, supone un verdadero reto en esta asignatura, donde el sistema gestiona:

• Sistemas en tiempo real, ya que el cronómetro no puede detenerse ni retrasarse permitiendo al usuario la capacidad de respuesta inmediata con feedback
• Complejidad Hardware teniendo tanto periféricos como puede ser el LCD, LDR y vistos en clase, y periféricos fuera de lo común como son los registros de desplazamiento 74HC595, Teclados Matriciales o controles inalámbricos con bluetooth, lo que nos ha permitido expandir mucho las capacidades del Arduino.
• Interacciones intermodales, al combinar digital, con analógico como puede ser el teclado o detectar luces ambientales con el LDR

2. FUNCIONAMIENTO Y CASOS DE USO

Como bien hemos dicho antes, nuestro proyecto consiste en un sistema que simula el funcionamiento del juego de desactivar una bomba antes de que explote, hemos integrado una arquitectura avanzada para poder gestionar todos los periféricos con recursos limitados.

Lógica del sistema:

El sistema responde de manera distinta actuando de diferentes formas según el estado o la fase del juego en la que se encuentre:

1. Estado de bloqueo: El sistema permanece inactivo(es decir, con la bomba desactivada y el tiempo sin correr), hasta recibir una señal de activación vía bluetooth(HC-05), lo que simula una activación remota del artefacto(o al malo de la película activandola).
2. Configuración de la dificultad: Mediante un switcher, el sistema es capaz de leer y cambiar la configuración deseada respecto al nivel de dificultad de la “bomba” en cuestión(Facil Medio, Dificil). Dependiendo de la dificultad la variables del tiempo que se posee para desactivar la bomba es mayor o menor.
3. Fase de Armado: Una vez se ha seleccionado la dificultad, el juego no comienza(o la bomba no se activa) hasta que el sensor de luz LDR detecta que la caja se ha abierto. En este momento el sistema o la bomba se activa, inicializa el LCD y comienza la cuenta atrás.
4. Desactivación por código. El usuario debe introducir una clave secreta en el teclado Matricial 4×4. El usuario en todo momento recibe feedback para que tenga conocimiento de como de cerca esta de la cifra obtenida, esto es posible mediante LEDs RGB(donde si acierta el digito en su posición es verde, si acierta el digito pero no en su posición es amarillo, y si no acierta el digito es rojo). Para todo esto el usuario tiene un número limitado de intentos, si obviamente no lo consigue en los intentos la bomba explota y el juego termina sin avanzar a la siguiente fase.
5. Desactivación por cables. Una vez superado el código, el sistema pasa a la fase de “cortar el cable”, donde el usuario debe desactivar el cable correcto para desactivar, o en un caso pésimo, cortar el cable que hace explotar la bomba. El usuario también recibe feedback para poder desconectar el cable correcto, mediante pistas de “caliente/frío” según la proximidad.
6. Resolución. Si en algún momento el usuario llega al límite de intentos sin acertar el código secreto o corta el cable equivocado, el juego termina y la “bomba explota” junto a un sonido horroroso y un mensaje de “boom!” que le hace saber que ha perdido. Si consigue superar los dos retos la bomba queda desactivada.

2.1. ORGANIZACIÓN

Para garantizar que el proyecto salga adelante y con una metodología de cualquier proyecto de ingeniería, hemos seguido estos pasos:

1. Creación del concepto y la lluvia de ideas: Tras haber hecho investigación de otros proyectos, estuvimos buscando ideas para el nuestro. Pasamos por varios modelos rechazados y varios modelos que nosotros mismos decidimos no hacer hasta llegar a este.
2. Investigación y adquisición de Hardware: Aunque fuimos construyendo prototipos con los materiales que teníamos según el momento, al principio se determinó que componentes eran necesarios, los cuales estuvieron muy claros desde el principio.
3. Prototipado modular: Fuimos probando y conectando partes día tras día, construyendo el modelo paso por paso, teniendo que cambiar código y entradas en el Arduino según se iban añadiendo más cosas. Aunque lo veremos después, se empezó con el LDR y el zumbador ya que partíamos de la base de la práctica obligatoria, siguiendo de los LEDs RGB y el primer 74HC595, continuamos al switcher, teclado matricial y el LCD junto al segundo 74HC595 y por último el juego de los cables con la palanca.
4. Desarrollo de Software: Fue surgiendo a la vez que la construcción del modelo, ya que según se añadían más cosas había que ir haciendo grandes modificaciones en el código. Así como veremos a continuación, fuimos probando periférico por periférico y solucionando los problemas que estos acarreaban en el momento.
5. Ensamblaje final. Diseño de la carcasa y optimización del espacio ocupado en esta.

2.2. REPARTO DE TAREAS

Aunque el trabajo ha sido en conjunto y mayoritariamente todos en físico juntos, donde todos los miembros estábamos colaborando y ayudándonos entre nosotros, establecimos unos roles principales por cada integrante

• Sergio (Arquitectura y Hardware): Encargado del diseño del esquema eléctrico y físico, gestión de los chips 74HC595 y la gestión para que los sistemas no chocaran entre sí. Respecto al software fue ayudando con la asociación entre chips, el teclado y el LCD.
• Alejandra (Lógica del Software y Tiempo Real): Encargada de la mayor parte de la base del software, programando la máquina de estados, y la gestión del cronómetro y tiempo real junto al Bluetooth. Comprobando junto a Raúl que el software fuera funcionando.
• Raúl(Ensamblaje, Pruebas y optimización): Encargado de la calibración de los sistemas básicos en el hardware y software, el diseño del prototipo final. En el software fue responsable de optimizar el código.

3. MATERIALES

A continuación, se muestra la tabla con los materiales que han sido utilizados en el proyecto, a pesar de que la mayoría venían en la caja proporcionada por el profesorado hemos adquirido materiales extra para complementar el proyecto.

MATERIALES Y COSTES
FOTO	NOMBRE	CANTIDAD	PRECIO
	lcd 16×2	1	Venía en la caja
	Potenciómetro	1	Venía en la caja
	Switcher con tres palancas	1	Venía en la caja
	Leds rgb	3	Venía en la caja
	Resistencias 200 ohm	6	Venía en la caja
	Resistencia 1k	1	Venía en la caja
	Resistencia de 2k	1	Venía en la caja
	Resistencia para el LDR	1	Venía en la caja
	LDR	1	Venía en la caja
	Zumbador	1	Venía en la caja
	Driver de Salida ULN2003AN	1	Venía en la caja
	Cables jumper		Venía en la caja
	Placas de prueba	3	Venía en la caja
	Arduino UNO	1	Venía en la caja
	Cables jumper macho macho	130	3€
	Cables jumper hembra-macho		3€
	Teclado matricial 4×4 usado	1	2€
	Teclado matricial 4×4 no usado y devuelto	1	6,65€
	Módulo bluetooth HC-05	1	10€
	Interruptores palanca de dos posiciones	6	6 x 0,9 = 5,4€
	Registros de desplazamiento 74HC595, uno comprado y otro que ya había en la caja	2 1 comprado1 venía en la caja	0,7€
	Condensador electrolítico 100 uF	4	0,2€

4. IMPLEMENTACIÓN HARDWARE

4.1. IMPLEMENTACIÓN DEL CIRCUITO

Antes de realizar el circuito en modelo real, se realizó una simulación del circuito en TinkerCad: A falta de la conexión bluetooth HC-05, que estaría conectada de tal forma:

• Conector 5V: A los 5V del arduino
• Conector GND: A GND del arduino
• Conector TX: Entrada 0 del arduino
• Conector RX: Está conectado a un punto al que llamaremos“Nudo Señal”. Desde este punto se conecta una resistencia de 2kOhm a GND del arduino y otra resistencia de 1kOhm que va hasta el Pin 1 del arduino. 

4.2.IMPLEMENTACIÓN EN PRUEBA

Previo al empotrado final, se realizaron pruebas componente a componente y paso a paso que veremos después para comprobar que el funcionamiento tanto del código como de los componentes era correcto. 

Se siguió la estructura complementada en el apartado anterior de implementación hardware en circuito de prueba, pero sin la estructuración final. No se compactó tanto ya que era la fase de experimentación y prueba de todos y cada uno de los componentes.

4.3.IMPLEMENTACIÓN FINAL POR MÓDULOS

Para la realización física del prototipo final, hemos empleado un soporte o carcasa firme con forma de maletín, donde hemos colocado todos los componentes de forma que mantienen su portabilidad y previenen, en la medida de lo posible, las desconexiones no intencionadas. 

La instalación se organiza en cuatro secciones distintas, parecidas a las secciones de los periféricos:

1. Sección interna de procesamiento(Arriba izquierda): El Arduino Uno, aunque esté en una esquina, funciona como el centro del sistema. Se han empleado cintas aislantes, silicona y soldaduras para sujetar los grupos de cables y garantizar que los elementos no interfieran entre ellos.
2. Sección interna y placa base(En el centro): Se han utilizado dos protoboard independientes para poder soportar todo el cableado de los dos registros de desplazamiento, el buzzer con el controlador ULN2003, el módulo bluetooth. Y aunque lo veremos en la siguiente sección también se ve todo el cableado correspondiente al LCD, los LEDs RGB y las palancas.
3. Sección superior e interior de la caja(Cables hacia arriba): Podemos observar como tanto de la protoboard como del propio arduino, salen cables a esa superficie de juego, donde podemos encontrar los periféricos como el LCD, El teclado matricial, los LEDs RGB y las palancas que simulan los cables cortados. Todos los cables están cubiertos en sus uniones con cinta aislante y silicona, para que no haya interferencias entre ellas, además de las uniones entre cables soldadas entre ellas.
4. Sección externa(Fuera de la caja): Utilizamos el Switcher de tres posiciones por fuera, para poder elegir la dificultad antes de que se active la bomba y empiece el juego y la cuenta atrás.

5. IMPLEMENTACIÓN SOFTWARE

El software del proyecto en un proyecto empotrado con un  Arduino UNO como este, es la pieza más importante, teniendo que programar varias funciones para cada uno de los componentes y controles diferentes. Buscamos un proyecto ordenado por fases, por lo que tenemos un proyecto .ino donde se encuentran las siguientes funciones organizadas

Este código ha sido iterativo, por lo que donde empezó con un simple control de LDR y de Buzzer ha terminado siendo un código de más de 350 líneas repartidas en funciones, la estructura del código gira en torno a varias funciones, que gestionan desde la comunicación de bajo nivel hasta la lógica del juego:

• Funciones del sistema y de control de hardware:
  • setup(): Es la función de inicialización de todo el código. Configura la comunicación con el serial a 9600 baudios, inicializa LCD, pone los números de la secuencia aleatoria a adivinar, y configura todos los pines físicos de entrada y salida.
  • loop(): Actúa como el motor de ejecución que está en constante ejecución. Es el encargado de que el cronómetro esté a tiempo real, escanea el teclado y lo más importante, gestiona la máquina de estados, donde están la configuración, el juego, los cables y los finales.
  • actualizarResgistro(): Es la función principal de salida. Que quiere decir esto, se encarga de realizar todo el volcado físico de la variable hacia los dos chips 74HC595 en cascada, utilizando comunicación con ellos por reloj.
• Funciones de gestión de la interfaz o LCD:
  • lcdInit(): Como queríamos que el LCD arrancara en un momento determinado del estado del juego, esta función es el arranque del controlador del LCD, configurando el modo de 4 bits para ahorrar pines y estableciendo parámetros como el cursor o el número de líneas
  • lcdEnvio(): Es la función principal de la pantalla LCD, divide cada byte de info en dos nibbles, gestiona los bits de control RS y E, y también es importante que asegura que los datos se sincronicen correctamente con el hardware.
  • lcdPrint,lcdClear,lcdSetCursor, lcdWrite,lcdCommand: Son funciones que encapsulan comandos más complejos para luego facilitar el uso en otras funciones la escritura de texto, el borrado de pantalla, el posicionamiento, etc.
• Función de lectura de entrada:
  • leerTeclado(): Debido a la dificultad que era leer el teclado, creamos una función solo para leer este, por lo que implementamos el escaneo de la matriz 4×4. Este utiliza el segundo registro de desplazamiento para poner a nivel bajo cada columna, mientras el arduino lee las filas. Incluye lógica de espera controlada para poder estabilizar voltajes y un sistema que evita lecturas duplicadas solo pulsando una vez.
• Lógica del juego y seguimiento de los estados:
  • actualizarPantallaJuego() y actualizarPantallaCables(): Funciones que como bien dicen sus nombres, actualizan el feedback de la información que aparece en el LCD según la fase. La primera muestra el tiempo restante y los intentos, ocultando el código con asteriscos y la segunda da instrucciones según el cable que cortes y muestra a su vez el cronómetro.
  • procesarIntento(): Esta función contiene la lógica principal de la promesa fase del jeugo. Compara lo que ha introducido el usuario en el teclado con el código secreto generado antes, y manda a los LEDs RGB cómo deben encenderse, y si gana esta parte, inicializa los cables de forma aleatoria.
• Funciones de feedback y periféricos:
  • actualizarHardwareLed(): Traduce los estados del teclado de acierto o fallo(verce,amarillo,rojo) a combinaciones de bits para el primer 74HC595 para controlar el encendido de los LEDs RGB
  • activarBuzzer() y gestionarSonido(): Las dos funciones controlan todo el feedback acústico, activan el zumbador , y controlan el tiempo que dura.

6. PASOS DADOS, PROBLEMAS Y SOLUCIONES

Surgieron muchos problemas durante la construcción e implementación en prueba del prototipo. Ya que aunque nos basamos en la implementación del circuito que hicimos en TinkerCad, fuimos probando sensor por sensor y no de la forma final. Con esto nos referimos a que cada vez que añadimos un controlador o un elemento del hardware, teníamos que cambiar tanto el software como el hardware de la parte anterior, lo que a veces llevaba a confusiones. Vamos a ver todos los problemas que fueron surgiendo según los pasos dados:

1. LDR y Zumbador con ULN2003

PROBLEMAS ENCONTRADOS EN ESTE PASO:

En este momento del circuito el único problema que tuvimos era que no conseguimos conectar bien y de forma fija el ULN2003 ya que la primera pata del módulo no era el conector out1 que realmente necesitábamos lo que llevó a confusiones. Mucho más adelante en el proyecto, nos dimos cuenta que lo que estábamos conectado no era directamente el ULN2003 si no el módulo de este, para lo cual cuando nos dimos cuenta, solucionó bastante este problema.

2. LED RGB conectado

PROBLEMAS ENCONTRADOS EN ESTE PASO:

Aquí hicimos la prueba de que el LED RGB funcionara correctamente según el número introducido (hasta que no conectamos el teclado, hacíamos la prueba de los números introducidos por el Serial). Y probando el LED nos dimos cuenta de que si solo queríamos sacar colores rojo, amarillo y verde la pata para el color azul del LED lo únicp que hacia era estorbar y ocupar sitio que sabíamos que ibamos a necesitar en un futuro, por lo que la desconectamos.

3. Tres LEDs RGB y primer  registro de desplazamiento 74HC595

PROBLEMAS ENCONTRADOS EN ESTE PASO:

Aquí ya conectamos el primer registro de desplazamiento junto a los tres LEDs RGB para comprobar que los tres números introducidos corresponden con los colores correctos. Ya solo seis Pines del Arduino para 3 LEDs pintaba mal la cosa, aunque contábamos con ellos. así que pusimos el primero de los dos registros, y hay que admitir que fue un resto bastante largo y tedioso conseguir hacerlo en software, ya que fue el primero que conectamos todos los miembros. Y como bien hemos dicho antes, solo tres patas de las cuatro de los LEDs RGB están conectadas.

4. LCD, Segundo 74HC595, switcher y primer Teclado matricial

PROBLEMAS ENCONTRADOS EN ESTE PASO:

En esta parte obviamente es en la que más problemas nos encontramos, al conectar todo la mayoría fallo y fuimos resolviendo los problemas uno a uno:

• El switcher ya no contaba con más entradas y tampoco lo podíamos conectar al 74HC595, ya que este registro es para salida y el switcher es de entrada. Por lo que la situación temporal que encontramos fue conectarlo a los Pines 0 y 1 del arduino, pero como bien sabemos son los canales principales del arduino de comunicación con el ordenador a través del puerto USB y utilizados para cargar datos. Esto hacía que si los tenemos conectados a la hora de lanzar y hacer Upload del código, todo el sistema empezaba a dar error ya que las señales del ordenador y la del módulo chocaban. Nuestra solución fue subir el código primero, y una vez que estaba subido conectar el switcher, de esta forma después de haber subido el código por USB los pines quedan libres de carga de datos y se dedicaban exclusivamente a la comunicación.
• Obviamente para poder conectar el teclado, el LCD y el potenciómetro para el LCD, tuvimos que conectar un segundo 74HC595, aunque todavía había algunas conexiones del LCD y del teclado que iban directamente al arduino sin pasar por el 74HC595.
• Tuvimos muchos problemas con este teclado, ya que al ser de botones físicos, lo primero de todo tenía 10 agujeros, donde entendimos que el primero y el último no se conectaban y los 8 de el medio eran para filas y columnas. Probamos de mil maneras y de ninguna forma posible conseguimos que el teclado funcionará, acudiendo a muchos recursos externos. Optamos por la opción de comprar un Teclado Matricial de membrana hecho por Arduino y por fin conseguimos que funcionara.

5. Palancas para simular cables

PROBLEMAS ENCONTRADOS EN ESTE PASO:

• Conectamos todas las palancas para simular estos cables cortados, y como bien hemos comentado antes, estas palancas son módulos de entrada, esto significa que no pueden ir al registro de desplazamiento, así que sí, estáis intuyendo bien lo que viene a continuación:
  • Nos tocó volver a cambiar casi todos los cables del LCD y del Teclado matricial que estaban conectados al Arduino, a su correspondiente sitio en el registro de desplazamiento para poder dejar hueco a las palancas. Estos supuso un gran cambio no solo en el hardware si no también en el software, pero como las señales RS y E del LCD seguían estando en el Arduino, la mayoría de funciones del LCD seguían intactas con comandos simples.
• Al probar en este momento del prototipo suponíamos que la mayoría o prácticamente todo funcionaría correctamente, pero nos equivocamos estrepitosamente. Creemos que entre la sensibilidad que tenía ahora el LCD de estar conectado al 74HC595 y seguir jugando con los Pines 0 y 1 del Arduino con el switcher, el proyecto entero empezó a fallar, nada de los datos cargaba correctamente. Decidimos mover el switcher a los Pines 11 y 12 del Arduino, donde antes estos Pines estaban ocupados por las señales RS y E del LCD, por lo que tuvimos que mudarlos al segundo registro de desplazamiento. 

Esto fue costoso no solo a nivel de hardware, sobre todo a nivel de software, ya que el LCD y el Teclado pasaban de estar conectados al Arduino con comandos simples como hemos dicho antes, a gestionar todo el estado del LCD bit a bit dentro de una variable, lo que supuso un cambio drástico en la mayoría de funciones del LCD escritas en el código.

Después de cambiar el control del LCD al registro de desplazamiento, el sistema empezó a mostrar por este caracteres aleatorios o basura, es decir que no salía nada correctamente, ya que recibía comandos incompletos.

En este momento tuvimos que ajustar con verdadera precisión los pulsos de reloj de los datos en el registro, puesto que no enviábamos una señal directamente al LCD. Al pasar por el 74HC595 vimos que esto pasaba porque se añadía como una latencia extra lo que hacía que el controlador se volviera loco. Y con muchas pruebas y con algo de ayuda conseguimos añadir retardos que aseguraban que el voltaje y la información fueran limpios y constantes. 

• Al tener todo montado y funcional, fuimos conscientes de que la primera columna del teclado matricial que teníamos no funcionaba. Probamos distintos métodos para comprobar su correcto funcionamiento y como bien teníamos planetario, debía ser un problema interno del teclado, así que nos tocó tener que cambiarlo por uno nuevo. Por eso en la foto aparecen las conexiones del teclado en una almohadilla con los números correspondientes a las entradas del teclado, en ese momento inexistente.

6. MONTAJE FINAL

PROBLEMAS ENCONTRADOS EN ESTE PASO:

• Un problema que al final no ha tenido solución, o mejor dicho la solución está pero no es la óptima, es la conexión del módulo bluetooth. Como bien hemos comentado antes, estábamos justos de Pines, bien pues en este momento no teníamos Pines restantes, solo los Pines 0 (RX) y 1 (TX) del Arduino, los cuales vamos a utilizar para nuestro módulo bluetooth. 

Pero el problema está en que si tenemos estos conectados a la hora de cargar el código al Arduino presenta conflicto de hardware con el USB durante la carga del dispositivo, lo que nos obliga a desconectar el módulo físicamente cada vez que actualizamos o lanzamos el código para probar el sistema, y tener que volver a conectarlo una vez el código esté cargado.

Como bien hemos dicho, este problema ya tiene su propia solución, lo cual ahora que está todo montado en una caja compacta, tener que abrir todo para conectar el módulo bluetooth es algo molesto y tedioso.

• El último problema que mencionamos, ha sido sin duda el peor de todos y que más quebraderos de cabeza ha llevado. Como hemos visto en esta práctica se hizo un montaje de prueba para comprobar que todo funcionaba y un montaje final en el producto, y como bien todos sabemos, conectar todo un cableado y volver a desconectarlo tiene sus riesgos, así que vamos a verlos.

Una vez tuvimos todo montado en la caja, cada cosa en su sitio y todo con orden, obviamente había que comprobar que todo funcionase correctamente otra vez, aquí es donde todo el mundo tiene miedo, y como bien suele ser el caso, el nuestro no fue diferente, el LCD no funcionaba como debía.

Sin embargo, todo estaba conectado en su sitio y correctamente, así que no sabíamos a qué se podía deber, así que hicimos pruebas, investigamos cuales suelen ser los sucesos cuando hay muchos periféricos, con cables tan largos y en un sitio tan compacto, y ahí tienes el propio problema y la propia solución.

Valoramos muchas causas posibles y todas sus posibles soluciones:

• Conflictos entre el Hardware y los datos que recibía, usando los Pines 0 y 1 podíamos llegar a pensar que el módulo generaba colisiones. Así que lo desconectamos e hicimos las pruebas sin él.
• Problemas con la conectividad, ya que al compactar tantos componentes, algunos cables se soltaban y no hacían contacto bien. Así pues, soldamos los cables, y aseguramos las uniones con cinta aislante o silicona derretida.
• La temporización del Timing entre periféricos, asumimos que algunos errores que daba era porque no tenía tiempo para pensar, así que añadimos algo de tiempo entre los sensores para que dejara de soltar basura.

Ahora vienen los que creemos y sabemos que causaban tantos problemas:

• Ruido y problemas en la integridad: Al necesitar cables más largos para que todo fuera a su sitio correctamente y ordenado, estos cables empezaron a captar interferencias entre ellos, a qué nos referimos con esto, mandaban señales o basura entre ellos rompiendo los datos que de verdad tenían que llegar bien y rápido al LCD. A parte de que obviamente al ser tan largos tarda más en llegar la información y hacía que el LCD parpadeara bastante a la hora de funcionar. Así que acortamos todos los cables de conexión entre el LCD y el registro de desplazamiento, y acortamos los cables también entre los registros de desplazamiento y el arduino.

Así conseguimos solucionar bastantes problemas, el LCD dejaba de parpadear y se veía la información como había que verla, y aunque mayoritariamente siempre sacaba la información correcta, había veces que todavía no. Así pasamos a la siguiente causa probable.

• Problemas en la alimentación y el voltaje. Como teníamos periféricos como el zumbador o los LEDs que tenían picos de consumo, pudimos llegar a la conclusión de que estos al encenderse provocan caídas o subidas de voltaje que desestabilizaban el LCD.

Nuestra única solución ante esto, fue comprar condensadores, así conseguimos que estas pequeñas ondas que hacían que todo se volviera loco, las tendríamos controladas. Pusimos uno entre la mayoría de puntos entre la GND y los 5V, es decir, pusimos condensadores en los registros de desplazamiento, en el LCD y en la alimentación directa del arduino a la placa base. Esto también consiguió que el porcentaje que saliera bien aumentara, pero a su vez, fue la gota que colma el vaso.

• Por mucho que aumentamos el ratio de mejora y del LCD funcionando bien, esto no fue suficiente, a veces seguía fallando y ya no teniamos mas posibles causas, así que hicimos lo que toda persona sensata menos nosotros tres hubiera hecho desde el principio, cambiar de LCD

Y como no, después de cambiar el LCD a otro, funcionaba el cien por ciento de las veces.

7.BIBLIOGRAFÍA

• Arduino Forum:

https://forum.arduino.cc/?_gl=1*ed80ck*_up*MQ..*_ga*NjE2MzUwMTM2LjE3NjU2NTkzNzA.*_ga_NEXN8H46L5*czE3NjU2NTkzNjkkbzEkZzAkdDE3NjU2NTkzNjkkajYwJGwwJGgxNjM5OTE2MDA4

• Más específicamente en este lugar, de aquí sacamos ideas para implementar en nuestro juego y ayuda con el código, de un zip que hay subido:

https://forum.arduino.cc/t/construccion-maleta-bomba-airsoft/402906

• Página de juego parecido en Arduino:

Cómo hacer tu propia bomba Arduino con contador regresivo para tu Escape Room Educativo de forma fácil y barata.

FIN

VIDEO

MEMORIA