<style>body {text-align: justify}</style>

# <p style="text-align:center;">**Producción Multimedia II: Proyecto Final**</p>
<p style="text-align:center;"><img src="https://hackmd.io/_uploads/ryXKOjUbA.png" width="600" height="200"/></p>

<p style="text-align:center;"> Esta documentación ha sido creado por:

Alejandra Díaz, Alex Collado, Guillem Roselló, Marina Ortega, Laura Pascual i Albert Tomàs</p>

<hr/>

[toc]

<hr />

### Video demo del proyecto

{%youtube AtvqF7fnZ5U %}

### Cartel grafico información

<hr />

# 1. Motivaciones e Intereses:
## 1.1 Motivaciones Generales

Lo primero que hicimos para elegir nuestra propuesta de proyecto final fue realizar una lluvia de ideas. Consideramos varias opciones, como crear un dron o coche teledirigido con funciones preprogramadas, un detector de mentiras con sensores en la mano, un juego de realidad aumentada para encontrar elementos virtuales en un espacio físico, y finalmente, un juego de pistolas láser.

En cuanto a esta última idea, pensamos en dos enfoques: el láser tag, que nos permitiría detectar los disparos y su posición en el chaleco del jugador, y un juego de disparos a objetivos móviles con pistolas láser. Después de evaluar estas opciones, optamos por el láser tag por su potencial para ofrecer una experiencia de juego emocionante y participativa. Es un juego popular y atractivo para personas de todas las edades. Al desarrollar nuestro propio sistema de láser tag, no solo creamos una experiencia divertida para nosotros, sino también para otros que puedan disfrutar del juego.

Otra razón para elegir esta idea fue el reto que nos motiva a todo el equipo en participar activamente en el proyecto. El desafío técnico de crear un sistema de detección y disparo mediante láser es muy estimulante, y nos permite resolver problemas y superar obstáculos durante el desarrollo. Además, la elección del proyecto de láser tag no solo se basa en su potencial de entretenimiento o reto personal, sino también en la complejidad del proyecto y la necesidad de coordinación entre un equipo de seis personas. Cada miembro tiene una parte importante del proyecto y es crucial entender las contribuciones de los demás para el éxito general. Nos enseñamos y aprendemos mutuamente, fortaleciendo nuestra colaboración y abordando desafíos técnicos de manera más efectiva. La integración de hardware y software requiere una coordinación y comunicación constantes entre nosotros para alcanzar nuestros objetivos.

Resumiendo, crear un láser tag desde cero nos brinda la oportunidad de aplicar y expandir nuestros conocimientos en múltiples disciplinas. La idea de diseñar todo, escoger los componentes electrónicos que más se adaptan a nuestras necesidades, hasta la programación del software, nos motiva a aprender y perfeccionar habilidades que serán cruciales en nuestra futura carrera profesional. Este proyecto nos permite ser innovadores, experimentar con tecnologías de gran alcance y desarrollar un producto completo que podemos sentir como verdaderamente nuestro. La satisfacción de ver un producto terminado, que hemos creado desde sus cimientos, nos impulsa a dar lo mejor de nosotros mismos en cada etapa del desarrollo.

## 1.2 Motivaciones Individuales
Alejandra Díaz: Este proyecto era perfecto para hacer algo que realmente nos motivara. A lo largo de la carrera, hemos tenido que hacer proyectos que no nos agradan mucho, pero en este caso, podíamos decidir como grupo. Esto ha sido mi mayor motivación: poder crear un juego que disfruté mucho en mi adolescencia y que me trae muy buenos recuerdos. Tener la oportunidad de diseñarlo, prototiparlo y codificarlo nosotros mismos me hacía mucha ilusión. Aunque mi participación en este proyecto no fue como esperaba y me hubiera gustado involucrarme más en algunas áreas, estoy muy contenta con el resultado de mi equipo.

Alex Collado: Mi principal motivación ha sido poder trabajar en un proyecto interesante y divertido sin tener que preocuparse por tener que hacerlo "vendible" o tener que explicarlo desde una perspectiva de negocio. Además, también me ha gustado mucho poder trabajar en un proyecto con tantas partes distintas, en el que cada persona se podía dedicar a una parte muy concreta y luego trabajar en como juntarlo todo de manera satisfactoria.

Guillem Roselló: Personalmente me apasiona crear sistemas con diferentes componentes que reaccionan o comunican entre si. Este proyecto es entonces la oportunidad perfecta para crear componentes de hardware y software y combinarlos de manera lógica para formar un sistema medianamente complejo. Un Laser tag me ha parecido un proyecto con una complejidad suficiente elevada como para suponer un reto pero no uno imposible.

Marina Ortega: Mi motivación principal era realizar un proyecto que realmente me interesara. En la universidad, a menudo trabajamos en proyectos que nos vienen dados y que nos resultan aburridos porque no los hemos elegido. Quería tener la oportunidad de seleccionar un proyecto que me apasionara y me desafiara. Además, quería aprender a trabajar en grupo, planificar y comunicarnos efectivamente entre todos. Estas habilidades no son fáciles de desarrollar, pero son esenciales tanto en el mundo laboral como en el personal. Quería experimentar la satisfacción de superar retos junto a mis compañeros y enriquecerme con sus conocimientos y habilidades, creando un proyecto del que todos nos sintiéramos orgullosos.

Laura Pascual: Personalmente, estaba muy interesada en tema hardware ya que en multimedia casi no habíamos tocado nada. Tenía muchas ganas de hacer este proyecto porqué pensé que seria una forma de aprender muy divertida, implementando un prototipo que podría llegar a ser funcional. En mi caso y creo que en el de todos, nos encantó la idea de hacer un Láser Tag, por lo que ayudó mucho a la motivación tanto individual como grupal. Al principio tenía mis dudas sobre el rol que tuve, ya que al final me quedó como planificadora. Sin embargo, estuve muy contenta porque toqué varias cosas del proyecto. Al final, casi todos se centraron más en su rol pero a mi me encantó participar en todo un poco, hice tanto programación, pruebas con el hardware y prototipado (chaleco y pistola).

Albert Tomàs: Mi mayor motivación ha sido pensar que con este proyecto podemos ayudar a todas aquellas personas que les apasiona el mundo de la electrónica a realizar un Laser Tag casero con el que podrán disfrutar y divertirse indefinidamente!
A parte de eso, también me ha motivado mucho el pensar que la finalidad de nuestro proyecto era el entretenimiento, cosa que ha hecho que el proceso haya sido planificado con el fin de buscar la mayor diversión para el consumidor.

<hr/>

# 2. Descripción General del Proyecto:
El proyecto “Slayser Tag” se centra en el desarrollo de un sistema de juego tipo láser tag, donde las pistolas y chalecos de los jugadores estarán conectados entre sí para ofrecer una experiencia de juego interactiva. En este juego, los jugadores utilizarán pistolas para disparar pulsaciones de láser que deberán impactar contra el chaleco de sus contrincantes para eliminarlos del juego.

Los participantes tendrán la opción de seleccionar entre diversas modalidades de juego, incluyendo opciones individuales o por equipos, con variaciones basadas en tiempo (time out) o supervivencia (last survivor). Para facilitar esta selección, el sistema contará con una interfaz web que permitirá a los jugadores crear partidas y ver las puntuaciones en tiempo real. Antes de comenzar una nueva partida, los jugadores podrán elegir el modo de juego deseado a través de un sistema de "click and play", aunque siempre tendrán la opción de iniciar una partida con la configuración predeterminada con tan solo presionar un botón.

En cuanto al diseño de los dispositivos, las pistolas estarán equipadas con microprocesadores ESP32, baterías recargables extraíbles, módulos de carga, láseres, tiras LED, elementos sonoros y pantallas para mostrar información relevante. Por su parte, los chalecos contarán con placas solares, tiras LED, elementos sonoros y conexión mediante cables. Cabe destacar que las pistolas actuarán como el "cerebro" del sistema y se conectarán a los chalecos a través de cables ocultos en el brazo del jugador. Además, las pistolas se comunicarán mediante el protocolo MQTT.

La utilización de una Raspberry Pi como servidor central permitirá alojar el servidor web y un node-red con la lógica de la partida. Sin embargo, se deberá tener en cuenta el consumo de batería para la Raspberry Pi y el tamaño de esta para poder añadirla a los dispositivos.

En resumen, el proyecto busca ofrecer una experiencia de juego interactiva y dinámica, con opciones de juego variadas y una integración tecnológica eficiente. El objetivo final es permitir que cualquier persona en casa pueda crear su propio equipo de “Slayser Tag” y organizar sus propias partidas con facilidad.

<hr/>

# 3. Relación con el Usuario:
La relación del usuario con el sistema está separada en dos partes bien diferenciadas, la de juego y la de configuración.

Para empezar, antes de poder jugar hay que configurar las diferentes opciones de la partida, o como mínimo, hay que poder iniciar el juego. Cuando pensamos en cómo diseñar esto, la prioridad era hacerlo lo más accesible posible para la gente que quisiera tanto jugar al juego como replicar este proyecto, así que optamos por hacer que todo el proceso se pudiera llevar a cabo en cualquier dispositivo que sea capaz de conectarse a internet. Ya que nuestro diseño del juego ya incluía generar una red wifi propia, decidimos utilizarla como punto de acceso para la interfaz, y que así cualquier jugador con un dispositivo inteligente (un ordenador, un móvil, una Smart TV, etc…) fuese capaz de operarla.

Esta interfaz es una página web a la que se puede acceder tras conectarse a la red wifi generada por el juego. Al entrar a esta web, se muestran los dispositivos de juego que están listos para empezar a jugar, junto con dos botones, una para cada modo de juego. Estos dos modos son: en equipo y todos contra todos. Al pulsar cualquiera de estos dos botones, se te mostrarán los dispositivos que van a estar en la partida, y se te permitiría elegir si quieres iniciar la partida con la configuración predeterminada, o si prefieres configurar el tiempo que dura la partida.

En las opciones, hay un botón para seleccionar entre un modo de juego en el que la partida se acaba al pasar cierto tiempo y otro en el que cada jugador tiene un número de vidas y la partida se acaba cuando solo queda un jugador con vidas, pero por problemas de tiempo este último no está completamente implementado. A esta interfaz puede acceder cualquier jugador en cualquier momento, siempre y cuando esté conectado al wifi; no tiene por qué haber nadie usándola para que el juego esté en funcionamiento, puede usarse para iniciar la partida y volver a tocarse hasta el final de esta.

Durante la partida, el juego tiene dos partes fundamentales, el chaleco y la pistola. La pistola tiene una pequeña pantalla LED que, durante el proceso de encendido, te indica el estado de la pistola y te deja saber cuando está conectada a la red y lista para jugar. Además de la indicación visual, el buzzer de la pistola te indicará con diferentes sonidos los cambios de estado. Cuando la partida haya empezado, la pantalla te mostrará la cantidad de munición de tu pistola con un gráfico que imita al velocímetro de un coche, y en el centro de la pantalla indica tu puntuación: cuanta gente has eliminado, y cuantas veces te han eliminado. El buzzer también te indica esta información de manera sonora, con sonidos para cada vez que disparas, eliminas a alguien, te eliminan, te quedas sin munición o se termina la partida.

Para interactuar con la pistola, tenemos dos botones. El gatillo, que aunque sea un botón normal, está colocado donde esperarías ver un gatillo en cualquier pistola, y que al pulsarlo consumirá una unidad de munición y causa que el láser de la pistola se active durante un periodo de tiempo de aproximadamente un segundo parpadeando a una frecuencia concreta. El botón de recarga hace lo que su nombre indica: rellena tu indicador de munición al máximo, un total de diez disparos.


Respecto al chaleco, este tiene cosida una tira de LEDs que cambian de color según el equipo al que pertenezca el jugador. Cada chaleco cuenta con cinco paneles solares capaces de detectar los láseres del resto de jugadores, y saber a qué frecuencia está siendo disparado, para así poder llevar una cuenta de puntuación de cada jugador.

<hr/>

## 3.3 ¿Porqué una interfaz web?

En el desarrollo de "Slayser Tag", la interacción con el usuario es un componente esencial para asegurar una experiencia de juego inmersiva y eficiente. Una interfaz web proporciona una plataforma intuitiva y accesible para gestionar esta interacción, mejorando significativamente la usabilidad y la gestión del juego. A continuación, se explicaran la necesidad de implementar una interfaz web para nuestro proyecto.
- Las interfaces web son accesibles desde cualquier dispositivo con navegador web, incluyendo smartphones, tablets, laptops y PCs. Esto permite a los usuarios acceder a la plataforma de gestión del juego sin restricciones de hardware.

- La creación de interfaces de usuario amigables e intuitivas. Mediante el uso de HTML5, CSS3 y JavaScript, se pueden diseñar interfaces que sean fáciles de navegar, con una curva de aprendizaje mínima para los usuarios.

- Una interfaz web centraliza la configuración y personalización de las partidas de láser tag. Los usuarios pueden seleccionar el número de jugadores, los modos de juego, los equipos, los tiempos y otros parámetros, todo desde una única plataforma.

- Si el usuario prefiere empezar una partida rápidamente, también damos la opción de crear una "QUICK PLAY", una partida rápida que dividirá a los jugadores en dos equipos y jugaran en modo tiempo.

- La interfaz web puede proporcionar una vista en tiempo real del estado del juego, incluyendo el tiempo restante, el marcador de puntos y el estado de los jugadores. Esto es crucial para mantener a los usuarios informados.

- La interfaz web puede ser fácilmente adaptada para incorporar nuevas funcionalidades y modos de juego, respondiendo rápidamente a las demandas y preferencias de los usuarios.

En resumen, la implementación de una interfaz web para interactuar con los usuarios en "Slayser Tag" no solo mejora la accesibilidad y usabilidad, sino que también optimiza la gestión del juego y la experiencia del usuario. Mediante una plataforma centralizada y dinámica, se facilita la configuración y monitoreo del juego. En un entorno de juego competitivo y en constante evolución, la interfaz web se presenta como una herramienta indispensable para el éxito y la sostenibilidad del juego de láser tag.

### Capturas de la web







# 4. Componentes de software y flujo de datos
## 4.1 Descripción componentes software
### Servidor (Rapsberry Pi)
:::info
Para este proyecto hemos utilizado una Raspberry Pi 4, el modelo de 4GB de RAM. Tanto una Raspberry Pi 3, como una Raspberry Pi Zero W también habrían funcionado perfectamente.
:::

En la Raspberry Pi que actúa como nodo central y servidor en este proyecto, hay tres piezas de software esenciales:

La primera, Mosquitto, que permite al dispositivo actuar como broker MQTT para que todos los dispositivos involucrados puedan comunicarse entre ellos utilizando una variedad de tópicos.

La siguiente es RaspAP, que facilita mucho el proceso de crear un punto de acceso Wifi desde la Raspberry, al que acceden tanto los diferentes ESP32 para comunicarse con el servidor, como el jugador para configurar y visualizar el estado de la partida.

Por último, el software con el que hemos creado el cliente web ha sido Node.js, que nos ha permitido tener una mayor flexibilidad a la hora de crear este servicio utilizando una arquitectura más similar a la de una aplicación que a la de una página web, y que además tiene una integración con MQTT muy cómoda y fácil de usar.

El código del cliente web se puede encontrar en [este](https://github.com/a-collado/pmm2-lasertag-servidor) repositorio de GitHub. Este código puede ejecutarse en cualquier dispositivo en el que Node.js esté disponible (Linux, FreeBSD, Mac y Windows).

Además de todo esto, durante el desarrollo, hemos utilizado Node Red para hacer más cómodo el proceso de crear e ir probando la web. Lo hemos configurado para que imite el comportamiento de los ESP32, haciendo que envíe mensajes MQTT para simular varios jugadores conectados a la partida. Sin esto, comprobar como funciona la web con varios jugadores conectados al mismo tiempo habría sido mucho más difícil y tedioso.


### ESP32

Para las pistolas y los chalecos necessitamos un microcontrolador capaz de conectarse a una red Wifi y de tamaño sufficientemente reducido como para caber dentro de una pistola. El ESP32 es el componente ideal para la ocasion. Usando el framework de Arduino es facil de programar y tiene soporte para muchas librerias que nos van a ser utiles en el proyecto.

Para programar el Esp32 hemos decidido usar PlatformIO como IDE en lugar de ArduinoIDE.

Cada ESP32 sera responsable de controlar todos los compomentes de un chaleco y una pistola.
También tendrá que responder a la lógica de la partida programada.

En este siguiente diagrama podemos ver esta lógica.

st=>start: Encendido
ini=>operation: Inicializacion
conn=>operation: Conectandose a la red
cond_conn=>condition: Conectado?
cond_brok=>condition: Conectado?
brok=>operation: Conectandose al broker MQTT
ready=>operation: Listo para jugar
isReady=>subroutine: Esperando mensaje de inicio
start=>operation: Empieza el juego
updateSensor=>operation: Obteniendo valores sensores
updateShoot=>operation: Comprobando gatillo
updateReload=>operation: Comprobando recarga
updateDead=>operation: Comprobando si estas muerto
updateAmmo=>operation: Comprobando munición 
updateKill=>operation: Sumar kill
shoot=>subroutine: Disparar
reload=>subroutine: Recargar
end=>subroutine: Esperando final partida
kill=>subroutine: Esperando kill 
dead=>operation: Morir
cond_shoot=>condition: Gatillo presionado?
cond_reload=>condition: Recarga presionada?
cond_dead=>condition: Estas muerto?
cond_ammo=>condition: Tienes municion?
cond_hit=>condition: Disparo detectado?
cond_kill=>condition: Kill recibida?
cond_end=>condition: Partida terminada?

st->ini->conn->cond_conn
cond_conn(yes)->brok->cond_brok
cond_conn(no)->conn
cond_brok(yes)->ready->isReady->start->cond_dead
cond_brok(no)->brok
cond_dead(no)->cond_shoot
cond_shoot(yes)->cond_ammo
cond_shoot(no)->cond_reload
cond_ammo(yes)->shoot->cond_reload
cond_ammo(no)->cond_reload
cond_reload(no)->updateSensor
cond_reload(yes)->reload->updateSensor
updateSensor->cond_hit
cond_hit(yes)->dead
cond_hit(no)->kill
cond_dead(yes)->kill
dead(right)->kill
kill->cond_kill
cond_kill(yes)->updateKill->end
cond_kill(no)->end
end->cond_end(no)->cond_dead
cond_end(yes,left)->ready

st@>ini({"stroke":"Red"})@>conn({"stroke":"Red"})@>cond_conn({"stroke":"Red"})@>brok({"stroke":"Red"})@>cond_brok({"stroke":"Red"})@>ready({"stroke":"Red"})@>isReady({"stroke":"Red"})@>start({"stroke":"Red"})@>cond_dead({"stroke":"Red"})@>kill({"stroke":"Red"})@>cond_kill({"stroke":"Red"})@>updateKill({"stroke":"Red"})@>end({"stroke":"Red"})@>cond_end({"stroke":"Red"})
cond_dead@>cond_shoot({"stroke":"Blue"})@>cond_ammo({"stroke":"Blue"})@>shoot({"stroke":"Blue"})@>cond_reload({"stroke":"Blue"})@>reload({"stroke":"Blue"})@>updateSensor({"stroke":"Blue"})@>cond_hit({"stroke":"Blue"})@>dead({"stroke":"Blue"})
cond_hit@>kill({"stroke":"Green"})
dead@>kill({"stroke":"Green"})
cond_end@>cond_dead({"stroke":"Green"})
cond_end@>ready({"stroke":"Green"})

Para la programación del ESP32 hemos decidido estructurar el codigo en clases, una para cada componente. De esta manera tenemos las siguientes clases:
- Buzzer
- Button
- RGBLights
- Laser
- Receiver
- LCD
- GameManager
- MqttClient

Entonces, desde el main.cpp llamamos a los diferentes componentes respondiendo a la lógica mencionada anteriormente.
Esta es la estructura del main.cpp:

Laser laser(LASER_PIN);
Button shootButton(BUTTON_SHOOT_PIN);
Button reloadButton(BUTTON_RELOAD_PIN);
Lcd lcd;
RGBLights rgbLights(R_PIN, G_PIN, B_PIN, 300);
Buzzer buzzer(BUZZER_PISTOLA_PIN);
Receiver receiver1(RECEIVER2_PIN); //Set corrects pins later
Receiver receiver2(RECEIVER2_PIN);
Receiver receiver3(RECEIVER2_PIN);
Receiver receiver4(RECEIVER2_PIN);
MqttClient mqttClient;
GameManager* gm;

State state = POWER_ON;

void setup(void) {

  //Inicializamos los diferentes componentes
  gm = &GameManager::getInstance();

  lcd.start();
  
  rgbLights.start();
  rgbLights.setColor(0, 0, 0);

  receiver1.start();
  receiver2.start();
  receiver3.start();
  receiver4.start();

  laser.start();
}

//Loop principal, usamos diferentes estados para cambiar el momento del proceso en el que nos encontramos
void loop() {

  switch (state){
    case POWER_ON:{ //1 - Secuencia de inicio
      ...
    }
    case CONNECTING:{ //2 - Conectado al router
      ...
    }
    case READY:{ //3 - Listo para jugar, nos conectamos al mqtt y recibimos info de la partida
     ...
    }
    case PRE_GAME: { //4 - Esperamos a recibir los datos necesarios y que empieze la partida
      ...
    }
    case GAME: { //5 - Juego en curso
      //Toda la logica de la partida
      ...
    }
    case END_GAME:{ //6 - Fin del juego
     ...
    }
  }
}

Como podemos ver el codigo se ejecuta en un solo bucle, al tener tantos componentes que dependen entre si, es importante no usar ningun `delay()` para evitar pausar el funcionamiento del resto de componentes. Para esto, cada componente tiene su metodo `start()` para inicializar algunas variables y el metodo `update()` para actualizar el estado. De esta manera, usando el `update()`, desde el main.cpp no tenemos que preocuparnos por la lógica del componente, sabemos que ya esta programada internamente para su correcto funcionamiento. En caso de necessitar un `delay()` se estará haciendo usando `millis()` y comprobando si el tiempo esperado se ha superado.

Aunque, hay algun componente que hemos tenido problemas para usar este sistema. Necessitábamos usar el delay() y no conseguiamos hacerlo usando `millis()`. Para solucionar esto hemos decidido usar `tasks`. Tasks son los threads de Arduino y vienen ya integrados en el framework de ESP32.

Por ejemplo lo hemos usado para disparar con el laser:

//main.cpp

laser.shoot();

void Laser::shoot(){
    LaserData *laserData = new LaserData;
    laserData->period = _period;
    laserData->pin = _pin;
    Serial.println(_pin);
    Serial.println(_period);
    xTaskCreate(
        shootTask,    // Function that should be called
        "Shoot Task", // Name of the task (for debugging)
        2048,         // Stack size (bytes)
        laserData,         // Parameter to pass to the function
        1,            // Task priority (0 is the lowest, higher values are higher priority)
        NULL          // Task handle (optional, we don't need it here)
    );
}

void Laser::shootTask(void * parameter) {
    LaserData* laserData = (LaserData*) parameter;
    int pin = laserData->pin;
    int period = laserData->period;
    int i = 0;
    Serial.println("LASERANDO");
    Serial.println(pin);
    Serial.println(period);
    while (i<10) {
      digitalWrite(pin, HIGH);
      delay(period);
      digitalWrite(pin, LOW);
      delay(period);
      i++;
    }
    digitalWrite(pin, HIGH);
    vTaskDelete(NULL);
    
}

Usando `xTaskCreate()` nos permite correr el codigo en paralelo sin preocuparnos por pausar la ejecucion de los otros componentes.

Para debugar el codigo, usamos diferentes herramientas, desde simples Serial.print() y usando el Serial monitor de platform IO a enviar automaticamente cierta telemetria desde el ESP32 conectado a la wifi a la Raspberry en la cual tenemos un servidor que recibe toda la informacion y dibuja gráficos de los diferentes componentes en directo.

#### Usando Teleplot

Teleplot: https://github.com/nesnes/teleplot

Teleplot es una solucion Open Source para la recopilacion de telemetria.

VS Code tiene una extension de Teleplot que sirve para recibir datos desde un puerto. Pero tambien se puede envior datos a un servidor propio.

Desde el ESP32 tenemos que añadir manualmente el fichero `Teleplot.h`. Se puede encontrar en el repositorio.

Para usar teleplot desde la raspberry nos descargamos el respositorio y accedemos a la carpeta `server`

cd server
npm i
node main.js

entonces ya tenemos el server activo.

Desde el ESP32 tenemos que enviar la información a este servidor

El primer paso es modificar el fichero `Teleplot.h` para especificar la direccion IP:

static Teleplot &localhost() {static Teleplot teleplot("10.3.141.1"); return teleplot;}

En este caso estamos usando la ip `10.3.141.1`.

Entonces para enviar telemetria lo hacemos de la siguiente manera:

#include "Teleplot.h"

_light = analogRead(_pin);
char* str = "Receiver";
str+=_pin; 
Teleplot::localhost().update(str , _light);

Accediendo a la web: http://10.3.141.1:8080
Podemos ver la siguiente telemetria (ejemplo):

Todo el código se puede comprobar en [este](https://github.com/guillemroch/SLayser-Tag) repositorio de Github.
## 4.2 Descripción flujo de datos

#### Mensajes MQTT

Toda la lógica, tanto de la configuración como de la partida, se hace intercambiando mensajes en ciertos tópicos MQTT. Cada ESP32 envía mensajes a tópicos a los que la aplicación de Node.js está suscrita, y esta envía mensajes a tópicos a los que cada dispositivo está suscrito.

Para el siguiente ejemplo, tenemos dos dispositivos ESP32, llamados Charlie y Tango. Estos nombres se los asignamos cuando compilamos el código, y tenemos que cambiarlo manualmente para por cada dispositivo. El siguiente esquema representa el transcurso de una partida normal, aunque para poder entenderlo vamos a aclarar que información se envía en el mensaje de cada tópico.

- Connections/Connect: Simplemente se envía la palabra 'connect'.
- Connections/Reconnect: Se envía el nombre del ESP32 (Charlie, Tango, etc).
- Connections/Team/Nombre: Se enviá un número indicando el equipo (1,2,3).
- Connections/Period/Nombre: Se envía el periodo en ms al que se dispara el láser.
- Game/Start: Simplemente se envía la palabra "start".
- Game/ReceiveHit: Se envía un JSON con el nombre del ESP32 que lo envía, y el periodo del disparo que ha sido detectado por el chaleco.
- Game/Kill/Nombre: Simplemente se envía la para "kill".
- Game/End: Simplemente se envía la para "end".

Title: Conexión Servidor  - ESP32
Servidor->Charlie: Connections/Connect
Servidor->Tango: Connections/Connect
Charlie->Servidor: Connections/Reconnect
Tango->Servidor: Connections/Reconnect
Note over Servidor, Charlie: Se repite cada 10 segundos\n hasta que empieza la config 
Note over  Servidor: Iniciamos config
Note right of Servidor: Seleccion equipo
Servidor->Charlie: Connections/Team/Charlie
Servidor->Charlie: Connections/Period/Charlie
Servidor->Tango: Connections/Team/Tango
Servidor->Tango: Connections/Period/Tango
Note over Servidor, Charlie: Empieza la partida
Servidor->Charlie: Game/Start
Servidor->Tango: Game/Start
Note over Charlie: Recibe un disparo de Tango
Note left of Charlie: +1 death
Charlie->Servidor: Game/ReceiveHit
Servidor->Tango: Game/Kill/Tango
Note left of Tango: +1 kill
Note over Servidor: Pasa el tiempo
Servidor->Charlie: Game/End
Servidor->Tango: Game/End
Note over Servidor, Charlie: Volvemos al inicio

#### Servidor Node.js

La web que hemos creado utiliza un sistema de máquina de estados en el que la página solo puede estar en un estado al mismo tiempo. Este estado decidirá que se muestra a todos los clientes conectados, y dependiendo del input de cualquiera de estos usuarios, se actualizara el estado y forzara a todos los usuarios a recargar la web. Así nos aseguramos de que, en caso de que haya varias personas conectadas al mismo tiempo, todas estarán viendo la misma información, y si varias intentan hacer una acción al mismo tiempo solo se llevará a cabo la primera que detecte el servidor.

Por esto mismo, toda la lógica de la partida, y el manejo de cualquier tipo de información se ejecuta vía JavaScript desde el servidor, y solo se le envía al cliente la información que ha de mostrar, evitando así que se pueda editar información de la partida desde el cliente. Para poder actualizar la información en tiempo real, toda la comunicación servidor - cliente se hace a través del protocolo WebSocket.

En el siguiente gráfico se muestra como se comunican el cliente y el servidor, siendo cada flecha un mensaje enviado por WebSocket.

Title: Comunicación Servidor - Cliente
Participant Servidor
Participant Cliente
Note left of Servidor: Estado: Conectando
Servidor->Cliente: Lista de dispositivos conectados
Note over Servidor, Cliente: Cada 10 segundos se vuelve\n a enviar la vista
Note over Cliente: Pulsa en\n"Select Teams"
Cliente->Servidor: Teams
Note left of Servidor: Estado: Teams
Servidor->Cliente: Recargar página
Note over Cliente: Recarga la página
Note over Cliente: Selecciona los \nequipos
Cliente->Servidor: Información de equipos
Note over Cliente: Pulsa en "Play"
Cliente->Servidor: Play
Note left of Servidor: Estado: Scoreboard
Servidor->Cliente: Recargar página
Note over Cliente: Recarga la página
Note over Servidor: Recibe informacion de\nla partida via MQTT
Servidor->Cliente: Información actualizada
Note over Cliente: Actualiza la información\n en la vista
Note over Servidor: Pasa el tiempo y \nacaba la partida
Note left of Servidor: Estado: End
Servidor->Cliente: End
Servidor->Cliente: Recargar página
Note over Cliente: Recarga la página
Note over Cliente, Servidor: Si el cliente le da al\n botón de volver a jugar,\nse repite este proceso.

## 4.3 Gráficos:
### Grafico del flujo de datos entre el ESP32 y la Raspberry PI durante una partida

---

:::info
Nuestros repositorios:
**Servidor Node**: [https://github.com/a-collado/pmm2-lasertag-servidor](https://github.com/a-collado/pmm2-lasertag-servidor)
**ESP 32**: [https://github.com/guillemroch/SLayser-Tag](https://github.com/guillemroch/SLayser-Tag)
:::

<hr/>

# 5. Inputs, Outputs y Comunicaciones:

## 5.1 Sensores y actuadores usados

### 5.1.1 Inputs
- **2 Botones**
- Botón de disparo: Se decidió poner un botón para disparar para activar fácilmente el láser
- Botón de recarga: También decidimos que fuera un botón para facilitar rapidez a la hora de recargar
- **Placas solares**
Las placas solares las hemos utilizado como sensores para detectar los láseres. Hemos considerado que las placas son ideales ya que tienen una superficie con la que es más fácil acertar que solamente a un punto en concreto.
Además, vimos que independientemente de dónde recibiese el impacto del láser, detectava una subida muy recta, perfecta para el código de detección de la frecuencia enviada.

_Para decidir si usar placas solares, se hicieron un seguido de pruebas explicado en el apartado de pruebas previas (5.3), y en pruebas en el desarrollo (5.4)._
### 5.1.2 Outputs
- **Láser**
Decidimos hacer el disparo con un láser ya que pensamos que sería muy interesante tener un juego de láser tag con láseres de verdad, ya que hoy en día, los láser tags se suelen hacer con infrarrojos.
Nuestra idea fue que sería más interesante ya que se trataría más de un juego de puntería. Con Infrarrojos, se podría detectar que se ha recibido el disparo aunque no se disparara justo en el objetivo.

_Sin embargo, hicimos una primera investigación sobre los distintos modos que podríamos usar para disparar, explicado en el apartado de "investigaciones previas" (5.2)_

- **Tiras led**
Las tiras led las escogimos por su facilidad de cambiar el color, para así, que cada chaleco brillase de un color distinto.
Gracias a esto, podemos conseguir indicar con colores los equipos, además de parpadear cuando se recibiese un disparo.

- **Buzzer**
El buzzer se encuentra para indicar mediante sonidos cuando se dispara, cuando no queda munición y cuando se recibe un disparo. Al principio teníamos pensado usar dos buzzers, uno dentro de la pistola y otro en el chaleco, ya que no tendría más sentido que sonase el sonido de que te han matado en el mismo chaleco.

Al final, se tuvo que poner solo uno, ya que algunos pines que teníamos para las placas solares no funcionaban el usar la wifi, por lo que tuvimos que moverlas y nos quedamos sin pines.

- **Pantalla**
Finalmente, la pantalla ayuda al usuario a tener información durante la partida, y a la conexión con el servidor. Ayudando así a la usabilidad del producto

### 5.1.3 Otro hardware
- **step up**
Para conseguir llegar a 5V para el láser y la tira leds, ya que el ESP32 no puede suministrar tanto voltaje.

_Nos encontramos varios problemas a la hora de conseguir suministrar el voltaje y el flujo necesario para el láser y los leds, explicado en el apartado de pruebas en el desarrollo (5.4)_

- **batería**
Se decidió usar una batería de litio para así no promover las pilas desechables. Siempre es una mejor opción si se puede evitar la gran generación de residuos.

- **switch encendido/apagado**
Componente para suministrar o no la energía de la batería al ESP32

- **Módulo de carga**
Permite cargar la batería he indicar con una luz si ya está cargada o no

## 5.2 Investigaciones previas
En este apartado se describen algunas investigaciones que hicimos para tomar algunas decisiones sobre que componentes usar. En concreto, el método de disparo.

### 5.2.1 Opciones de emitir y recibir
Para este proyecto, es fundamental encontrar un método de disparar (emitir) y de recibir disparos. Por este motivo, lo primero que hicimos fue investigar algunas opciones con las cuales pudiéramos realizarlo:

- **Infrarrojos:**
Opción más utilizada hoy en día para hacer el láser tag de verdad. En general, emite en una dirección en concreto y se puede diferenciar quién ha disparado mediante un código o por pulsaciones.

- **Láser visible:**
Opción muy interesante ya que es completamente direccional, permitiendo conseguir hacer un juego de puntería real. Puede llegar a grandes distancias, pero es bastante más dañino para los ojos.

- **Radiofrecuencia:**
Opción posible pero no muy factible al ser omnidireccional. Podría llevarnos muchos problemas el hecho de calcular la dirección. Aun así, podría llevar información y fácilmente podríamos detectar quién ha disparado.

- **Ultrasonido:**
Opción direccional, pero, por lo que entendimos, no puede llegar a tanta distancia.

De esta investigación optamos más por los infrarrojos y por el láser ya que eran las opciones que nos convencían más. Por este motivo realizamos pruebas de estos dos para ver cuál encaja más con lo que estábamos buscando, y si era factible implementar nuestro juego de ese modo.
_Explicado en el apartado de Pruebas previas (5.3)_

### 5.2.2 Baterías necesarias

Nuestro prototipo contiene varios componentes. Las pantallas como los buzzers o otros similares consumen poca bateria. Lo que consume mas bateria son los leds. Estimamos que con alrededor de 20 Leds por chaleco, nuestro prototipo consume alrededor de 1000mAh. Estimamos entonces necessario tener baterias con al menos 15000mAh para poder disfrutar de una partida sin problemas. También es importante que las baterias sean de 3.3V ya que es lo que soporta el ESP32.

## 5.3 Pruebas previas
Estas pruebas se hicieron en la primera mitad del proyecto. Nos ayudaron para decidir si escojer láser o Infrarrojos.

### 5.3.1 Sistema de Infrarrojos
Para emitir y recibir infrarrojos necesitamos un Sensor IR y un Emisor IR. Probando con un circuito podemos ver que el sensor recibe la emisión de IR. Uno de los problemas que vemos principalmente es que apenas es necesario apuntar para que el sensor reciba IR. Esto es un problema ya que nosotros lo que queremos es que se tenga que apuntar al objetivo para que se reciba el disparo según su trayectoria.

#### Diodo y fotoresistor infrarrojos:

**_Objetivo:_**
Comprobar el funcionamiento y la viabilidad de usar luz infrarroja como proyectil en nuestras pistolas.

**_Experimentación:_**
El primer paso fue investigar cómo leer los datos provenientes del fotorresistor; acabamos utilizando la librería IRremote, que contiene funciones para leer y enviar códigos hexadecimales utilizando infrarrojos y es compatible con Arduino y ESP32.

Para hacer pruebas con el fotodiodo utilizamos un mando de televisión, y comprobamos si el sensor era capaz de leer los códigos enviados, y hasta qué distancias los diferenciaba.
Después, conectamos el diodo led y con la misma librería hicimos que emitiera diferentes códigos mientras los leíamos con el sensor para comprobar si se estaban transmitiendo correctamente.

<p style="text-align:center;"><img style="text-align:center;" src="https://hackmd.io/_uploads/By8e7BKZC.jpg" width="400" height="380"/>

**_Observaciones y conclusiones:_**
Las pruebas del receptor nos mostraron que era capaz de recibir perfectamente los códigos enviados por el mando. La distancia máxima que probamos fueron unos 7 metros, y los resultados han sido prometedores, si se apunta el mando correctamente, el sensor no tiene problemas para detectar el código enviado.

En cuanto al led, solo pudimos probar el led a una distancia muy cercana al sensor, en la cual no tenía ningún problema para transmitir los códigos. Eso mismo fue lo que nos dio problemas a la hora de plantearnos usarlo como disparos: en distancias cortas, la manera de propagarse de la luz infrarroja hace que sea demasiado fácil que esta llegue al sensor, haciendo que los disparos no sean lo suficiente unidireccionales, generando así falsos positivos en el sensor.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/r15SfSKb0.png" width="600" height="250"/></p>

Tras investigar más profundamente hemos descubierto que existen unas lentes que permiten enfocar la emisión hacia una dirección y que esto ayudaría a tener que apuntar a un receptor. El problema que le hemos encontrado es que si queremos tener bastante alcance se necesitan buenos lentes y estos pueden llegar a ser bastante caros.

### 5.3.2 Sistema Láser:
Un láser en resumen es un haz de luz polarizada con mucha potencia. Un láser tiene mucho alcance y nos permitirá dar este efecto de disparo que buscamos.
Hemos investigado entonces si es posible emitir información y recibirla correctamente con suficiente fiabilidad.

Las pruebas están ordenadas cronológicamente (aunque algunas se hicieron en paralelo).

Problemas a los que enfocamos las pruebas:
- Detectar la información de qué pistola ha disparado.
- El haz de un láser tiene un diámetro muy pequeño, dificultando o haciendo imposible acertar en cierto objetivo.

#### Primera prueba: Detección de pulsos (Láser + LDR)
**_Objetivo:_**
Esta prueba se centró en averiguar si era posible detectar quién había disparado mediante un láser.

**_Experimentación:_**
Mediante un Arduino UNO, un láser y un LDR, hicimos que el láser emitiera en una frecuencia concreta y graficamos lo que recibía el LDR.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/H1SFMHY-A.jpg" width="450" height="350"/></p>

**_Observaciones y conclusiones:_**
Gracias a esta prueba, pudimos observar que el LDR captaba perfectamente cuando el láser lo apuntaba o no. De este modo, también vimos los distintos pulsos que enviaba el láser. Gracias al sistema de pulsos, si cada pistola envía a frecuencias distintas, mediante un código, deberíamos poder detectarlas y discernir quién ha disparado.

El principal problema de esta solución es que si queremos disparar a alguien el objetivo al que hay que apuntar es muy pequeño y difícil de acertar.
No obstante, es posible la transmisión de información.

#### Segunda prueba: LDR en série
**_Objetivo:_**

Para esta prueba, fuimos con la premisa de que, si conectamos varios LDR en serie, independientemente de quien recibiera el láser, detectaríamos los pulsos.

**_Experimentación:_**

Pusimos 5 LDR en serie, graficamos su resultado y apuntamos a cada uno de ellos por separado con el láser.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/HkBQQrKbR.jpg" width="500" height="350"/></p>

**_Observaciones y conclusiones:_**
Vimos que sí que independientemente a cuál enfocáramos, se detectaba un pico de luz. Sin embargo, vimos que, por cada LDR, cuanto más alejado estaba, el pico de luz disminuía.

Al ver este resultado, decidimos comprobar con solo un LDR y vimos una gran diferencia del valor máximo (amplitud) al que podía llegar. Así que vimos que no sería una buena opción.

Miramos entonces si podría ser factible en paralelo, pero si por cada LDR necesitamos un pin, nos quedaríamos sin espacio en el ESP32.
Finalmente pensamos en hacer una combinación de los dos, tener en serie y en paralelo, pero, aunque pusiéramos 4 en serie en cada rama, seguiríamos necesitando muchos pines, el voltaje disminuiría bastante, y no abarcaríamos el espacio que necesitamos.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/Hky9AW_-0.png" width="500" height="210"/></p>

#### Tercera prueba: Ampliar el diámetro del haz del láser
**_Objetivo:_**

Mediante materiales externos al láser, intentar aumentar el diámetro del haz del láser. Teniendo como primera idea una especie de difusor.
En este caso, la idea es sencilla, si el haz es mayor, más probabilidad hay que le dé a un sensor, aunque este sea más pequeño.

**_Experimentación:_**

Por ello, cogimos distintos materiales que tenía por casa para ver el láser a través de esos materiales.
En esta documentación no aparecen todos los materiales que usamos ya que algunos, simplemente no se veía nada o daban resultados muy parecidos a otros que no nos interesaban tanto.

* **Envoltorio típico fino tipo espuma cuando compras alguna cosa**
En este caso, aunque esta prueba fue la que aumentó más el diámetro del haz, se descartó rápidamente por el hecho de que la potencia del láser disminuyó mucho. El detector lumínico podría detectarlo como un cambio de luz ambiental.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/ByJ8HrtZA.jpg" width="500" height="300"/></p>

* **Plástico 1**
Respecto a los plásticos, algunos sí que incrementaron un poco el haz, pero en general, se hacía más en formato línea, no uniformemente. Por lo tanto, no nos serviría tampoco.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/H1NKBBKWC.jpg" width="500" height="270"/></p>

* **Plástico 2**
Otros plásticos vimos que hacían formas extrañas y cambiantes si lo movíamos. Este hecho nos hizo pensar de que sería por la suciedad del plástico, haciendo que fuera aleatorio y a una opción no viable.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/B1qiHBYbA.png" width="500" height="270"/></p>

* **Lente gafas miopía**
Posteriormente, se probó con las gafas de Laura (miopía) y en este caso, sí que vimos un aumento interesante sin reducción de potencia, aunque no tenía forma redonda, no era lineal como el plástico y era lo que más se acercaba por el momento. Lamentablemente, no es una opción viable ya que unas lentes de gafas son costosas y solo se pueden pedir por prescripción médica.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/HyKaSBY-0.jpg" width="500" height="370"/></p>

* **Lupa**
Finalmente, al ver el resultado de las gafas, se intentó con una lupa. Ésta tuvo el mejor resultado con diferencia y el que optamos ya que es más sencillo encontrar lupas.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/BJ8k8BKWC.jpg" width="500" height="250"/></p>

* **Lente para led 20º**
Al ver que las lentes eran la mejor opción, encontramos que había lentes para led. Decidimos comprar una para probar, pero dispersó demasiado el láser. Posiblemente, con otro ángulo, nos podría ayudar. Pero es una idea interesante por el reducido tamaño que tiene.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/HJ0MIrFbC.jpg" width="500" height="300"/></p>

**_Observaciones y conclusiones:_**
Hemos visto que usando una lente convergente es la mejor opción para conseguir lo que buscábamos. Dependiendo del ángulo de éste, dispersará demasiado la luz y perderá potencia. La prueba que más ha resultado ha sido con la lupa.

Aun así, las lentes son más caras y quizá, algún plástico podría servir, de este modo reutilizaremos un plástico que seguramente sería desechado.
Queremos destacar que, en las fotos, la luz se ve bastante distinta a la vida real.

#### Cuarta prueba: Espacio curvado que refleja la luz al centro
**_Objetivo:_**
Conseguir una superficie que, independientemente de dónde toque el láser, este sea redirigido al centro. Disminuyendo así la necesidad de tener muchos LDR.

**_Experimentación:_**
Ésta prueba la hicimos un poco teóricamente con una aplicación de gráficas matemáticas. Sí que pudimos encontrar el punto dónde interseccionaría cualquier disparo.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/SyEeDrFbC.png" width="500" height="350"/></p>

Posteriormente, cogimos un cucharón de cocina y disparamos el rayo al interior en distintos lugares.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/HkNXDHYZR.jpg" width="500" height="350"/></p>

**_Observaciones y conclusiones:_**
Aunque sería posible teóricamente, reconstruirlo en la vida real podría resultar siendo muy muy complejo. Además de que las funciones que hicimos fueron en 2D.
Finalmente, tampoco sería una buena opción ya que, aunque le de al LDR, el rayo también podría llegar a más zonas, haciendo más fácil el daño en los ojos.

#### Quinta prueba: Placa solar como receptor
**_Objetivo:_**
En este caso, vamos también con la premisa de poder detectar las variaciones de luz en cualquier punto de una placa solar. Ésta nos daría la superficie que necesitamos y que en las pruebas anteriores no hemos conseguido.

**_Experimentación:_**
Conexión de una placa solar al ESP-32 el cual graficará lo que recibe. Con un láser fuimos enfocando a la placa solar.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/r1Wx_SKZ0.png" width="300" height="370"/></p>

Efectivamente podemos observar la variación del voltaje producido por una placa solar en una habitación medianamente iluminada cuando se enfoca y desenfoca el láser en cualquier punto.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/HkF7drY-0.png" width="500" height="230"/></p>

Nos dimos cuenta de que, si hay mucha iluminación ambiental, genera el máximo de su voltaje y por mucho que se ilumine más no se pueden observar los picos/ pulsos de variación de luz.</

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/S1AUuBtZA.png" width="500" height="230"/></p>

Este problema podría disminuirse usando diferentes tipos de placas solares, como por ejemplo algunas que generen más voltaje, pero habría que probarlo igualmente.

**_Observaciones y conclusiones:_**
Estas primeras pruebas con las placas solares son bastante satisfactorias ya que significa que tenemos una superficie de tamaño variable (dependiendo de qué placa solar se use). Es bueno ver que las placas solares son bastante sensibles al láser. Tenemos que probar ahora si es posible detectar pulsos en ella.

#### Sexta prueba: Detección de pulsos con placa solar
**_Objetivo:_**
Enviar al láser una frecuencia que en la placa solar se detecten.

**_Experimentación:_**
Conexión de una placa solar al ESP-32 el cual hará una gráfica de lo que recibe. Otro ESP32 enciende y apaga el láser a cierta frecuencia.
El láser lo aguantamos con un alambre para que no se moviera. Cuando lo cogíamos nosotros, lo movíamos y se los desconectaba.

Realizamos las pruebas en una habitación medianamente iluminada.
Detectamos esta gráfica con una frecuencia de 10 Hz.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/r1qN5rF-0.png" width="500" height="370"/></p>

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/ryOD5St-A.png" width="500" height="240"/></p>

**_Observaciones y conclusiones:_**
Se pueden observar claramente los pulsos recibidos por la placa solar incluso si la luz ambiente varía.

También vimos que con los 3,3 V del ESP-32 no eran suficientes para el correcto funcionamiento del láser, los pulsos tenían muy poca amplitud con 10 cm de distancia.

Usamos el Arduino y vimos un resultado marcado y prometedor. Una solución para esto es usar un step-up para convertir el voltaje de 3,3 V a 5 V.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/H13s5SK-R.png" width="500" height="230"/></p>

## 5.4 Pruebas en el desarrollo
### 5.4.1 Detección LDR con superficie
**_Objetivo:_**
Aunque las placas solares parecían la mejor solución, nos dimos cuenta de que las placas solares resultaban mucho más caras que la detección con el LDR. En este momento ya habíamos comprobado que la detección de frecuencia directamente al LDR funcionaba bien al igual que con las placas solares.
El objetivo entonces era conseguir poder disparar en una superficie y que el LDR lo detectase.

*Experimentación:*
Conexión de un Arduino o ESP32 con un LDR apuntando a una superficie reflectante. Hicimos la prueba con varios materiales.

- **Metacrilato transparente:**
Compramos este material al pensar que sería como los cristales de algunas lámparas donde rebota la luz por todos lados, pero al ser tan transparente, en vez de rebotar, atravesó el láser.

- **Superficie blanca (pared y mesa):**
En este caso vimos que aunque no le diesemos directamente al LDR, si que recibía una subida de iluminación. Además, vimos que los picos tenian una distancia bastante similar entre unos i otros, por lo pensamos que podría funcionar correctamente la detección de la frecuencia.

- **Papel reflectante:**
Con el papel reflectante nos dió un resultado semejante a la superficie blanca

**_Observaciones y conclusiones:_**
Según los resultados, parece factible el hecho de poderlo hacer con LDR's ya que hemos visto que en una superficie reflectante, se detectan las subidas de luz.

Por este motivo diseñamos como debería ser los receptores para que el LDR pudiese detectar en una superficie.
Tal i como se ve en los dibujos, el LDR se encontraría enganchado en la tapa mas alta. Una tapa transparente de color rojo que serviría como filtro. La altura de LDR permitiria que se detectase cambios de luz en las distintas zonas de abajo, de una superficie reflectante blanca o con el papel metálico.

### 5.4.2 LDR con tupper 1
En este apartado quisimos comprovar si funcionaria el diseño que pensamos para que el LDR detectase en una superficie. Por ello recorrimos algunas tiendas y logramos encontrar algunos elementos que podrían funcionar para probarlo.
Una jabonera bastante transparente, y un tupper con tapa blanca y más opaco

**_Objetivo:_**
Comprovar si nuestro diseño era funcional:
- mirar si el LDR detectaba subida en todas las zonas blancas de la tapa del tupper
- Comprovar si puede detectar las frecuencias.

Se decidió hacer la primera prueba con el tupper, ya que pensamos que sería el que tendría más posibilidades: Ya tenía la tapa blanca, y al ser un poco opaco, pensamos que haría como en las pruebas que hicimos para incrementar el diametro de luz del láser. Gracias a eso, sería más facil que el LDR detectase la luz independientemente de si se encuentra en una esquina o en otra

**_Experimentación:_**
Enganchamos el LDR en la parte transparente del tupper para que se encuentre elevado. Hacemos agujeros en las esquinas de la tapa del tupper para pasar el cable positivo y el de massa y así, poder cerrar la tapa.
Finalmente, conectamos el LDR del tupper en el ESP32 y ejecutamos el código de detección de luz y frecuéncia.

- _Comprovación de subida de luz en cualquier lugar del tupper_
Desplazamos el láser por todos los rincones del tupper i vimos que efectivamente detectaba una subida de luz en cualquier punto del tupper. Pero claramente, en las esquinas del tupper detectava menos subida que en las zonas centrales
Gráfica de lo que detecta el LDR siendo la parte isquierda zonas más centrales y la derecha una equina del tupper

- _Comprovación de detección de frecuencia_
En las comprovaciones vimos que no detectava correctament las frecuencias. Probamos con distintos thresholds y cons distintas frecuencias, pero no lo conseguía.

Estuvimos mirando que le pasaba durante un buen rato y vimos que lo que detectava el LDR en el tupper era bastante distinto a si lo recibía la placa solar o el láser directamente en el LDR
En la izquierda está la detección dentro del tupper, y la derecha la que detecta bien la frecuencia

Vemos que las subidas de el del tupper són de menor valor y que suben algunas por tramos. Eso explicaría el porqué no detecta bien la frecuencia con el código que hicimos.

En nuestro código calcula el periodo detectando los tiempos de las subidas, pero solo cogiendo una subida de diferencia superior a un threshold. El threshold usado era de 100 pero probamos con otros. Sin embargo, no podíamos usar un threshold menor a 60 ya que con luz ambiental, muchas veces detectaba diferencias de entre 40-60. El hecho de que los picos subieran por partes, hacía que no llegara al threshold y por ello no funcionaba.

Entonces pensamos que quizá el filtro rojo funcionaría. Hicimos entonces las pruebas completamente a oscuras para evitar todo el ruido de luz ambiental para ver como resultaba.
En este caso vimos una mejora, había menos picos que se partían pero no lo suficiente como para que funcionase correctamente.

**_Observaciones y conclusiones_**
La detección lumínica se recibe independientemente de la zona del tupper aunque la zona central recibe mucho más. Lo que podría indicar que si se dispara en algún lateral podría ser más dificil la detección por si algún momento no llega a superar el threshold

Respecto a la detección de la frecuencia, no la detecta pero podemos apreciar que cada pico se encuentra a distancias parecidas por lo que parece que podría ser factible llegar a dectectar correctamente la frecuencia.

### 5.4.3 LDR con tupper 2
**_Objetivo_**
Una vez vistos los resultados del primer tupper, el objetivo era de que el hecho de que este segundo tupper era más transparente, que no hiciera tanta dispersión y que los pulsos se recibieran con menos pasos. Intentando buscar algo más parecido a lo que teníamos con el láser apuntando directamente al LDR.

**_Experimentación_**
La misma conexión que en la prueba anterior pero con el segundo tupper. Esta vez encima de una mesa blanca.

En este caso, vemos que el LDR también detecta las subidas con algunos picos por partes. Pero, nos fijamos que también había más pulsos que lo hacían de una sola subida. Con la ayuda de los prints que teníamos en todas estas pruebas, también detectamos que detectaba una mayor cantidad de pulsos que en las pruebas del anterior tupper.
Y finalmente, vimos que la cantidad de luz recibida también era mayor.

Miramos de editar el código para hacer algún procesado de la señal, aún así, no lo conseguíamos.

**_Observaciones y conclusiones_**
Éste tupper se veía mucho más prometedor. Aún así seguíamos teniendo problemas que parecían que no se solucionaban. Estuvimos bastantes días con esto y se acercaba la fecha de entrega.
Nos dimos cuenta de que era factible realizarlo pero no con el tiempo que nos quedaba. Por ello, decidimos volver a las placas solares para así, mirar de tener un prototipo funcional.

## 5.5 Incorporacion de los diferentes elementos de hardware
### Laser
Para hacer que funcionase el laser dependiendo del output de un pin GPIO de un ESP32 no fue tan fácil como habíamos imaginado.
El problema es que el laser funciona con 5V, menos voltaje significa menos intensidad de luz y entonces mucho mas dificil su detección. Es por esto que es un paso crucial para el proyecto.

El problema del ESP32 esque funciona con 3,3V. Al conectarlo de la siguiente manera, no es sufficiente para hacer funcionar el Laser. Solo circulan 3,3V.

Entonces hemos aprendido sobre un componente que sirve para aumentar el voltage: el Step-Up.
Tras adquirir este componente hemos probado conectarlo de la siguiente manera:


En este caso, el problema es que el step up no se activaba, creemos que la razon es porque no circulaba sufficientemente corriente en el.

Otra solucion que probamos es usando un MOSFET. Un MOSFET es un componente que permite dejar pasar la corriente a partir de un cierto voltage. Es como un transistor.

Siguiendo [esta](https://www.electronics-tutorials.ws/transistor/tran_7.html) guia nos hemos ayudado para montar el circuito.


Este circuito tampoco nos funcionó.

No obstante, acabamos encontrando una solucion:

de esta manera, siempre estamos alimentando el Laser con 5v. Activando el pin, hacemos que el voltaje disminuya a 2V haciendo que el laser sea apenas visible.

---

# 6. Desarrollo del prototipo
## 6.1 Diseño e ideas principales
Después de planear cómo nos gustaría que fuese el prototipo de Slayer Wars, llegamos a diferentes conclusiones. Primero hicimos unos bocetos con nuestra idea principal, cosa que posteriormente mejoramos tras algunas sesiones de clase donde cambiamos ciertas ideas por otras que parecían más adecuadas y óptimas.

Las primeras ideas del prototipo fueron las siguientes:</p>

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/BJ4m0iUbR.png" width="300" height="240"/><img src="https://hackmd.io/_uploads/Bk3XRiUZR.png" width="270" height="270"/></p>
<p style="text-align:center;"><img src="https://hackmd.io/_uploads/S1l4CjUWA.png" width="270" height="250"/></p>

Como se puede observar en los bocetos, encontramos algunas anotaciones que hicimos para discutir en grupo cómo podríamos mejorarlo. El principal inconveniente que nos encontramos fue que, finalmente, decidimos que las conexiones de chaleco-pistola, serían por cable, cosa que cambiaría un poco la distribución y el diseño de lo que habíamos planeado en un principio.
Después de pensar cómo adaptar el diseño, teniendo en cuenta que no queríamos que los cables se engancharan con cualquier cosa si el usuario que los lleva va corriendo por algún sitio estrecho, decidimos este nuevo prototipo que, por ahora es el definitivo:

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/SkOjRoUZR.png" width="300" height="240"/><img src="https://hackmd.io/_uploads/SJii0oUWC.png" width="300" height="300"/></p>

En este prototipo podemos observar algunos cambios con respecto al primero. El cambio más notorio, es el de usar una manga en el chaleco, la cual tendrá una función de protección de los cables (que pasarán por dentro de ella) a parte que creemos que dará un toque estético futurista adecuado para nuestro proyecto.
Con respecto a la pistola, no hay muchos cambios, solo que esta vez realizamos un boceto donde se pudiera ver cómo irían más o menos distribuidos los componentes por dentro de ella.

## 6.2 Prototipado cartón pistola:
Finalmente, hemos realizado un pequeño prototipo a tamaño real de cartón, solo para ver los tamaños que serían necesarios para que quepa todo sin problemas. Cabe recalcar que este prototipo no está hecho a modo de diseño, ya que al prototipo final se le añadirán muchas más “florituras” y formas para que estéticamente llame más la atención, como decíamos, es solo un prototipo para ver tamaños y distribuciones de componentes.

A continuación, las imágenes y medidas del prototipo:

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/Bkplk3LZ0.png" width="600" height="300"/></p>

## 6.3 Diseño 3D pistola
Para el diseño y prototipado de la pistola 3D, utilicé el programa Blender. El diseño consistía en cuatro partes principales: el cañón izquierdo, el cañón derecho, el mango izquierdo y el mango derecho. Cada una de estas partes fue modelada cuidadosamente para garantizar un ajuste preciso y una apariencia cohesiva.

A continuación se pueden observar capturas de pantalla de los modelos

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/HJobkXiER.jpg"/><img src="https://hackmd.io/_uploads/SysW1QoVR.png" /><img src="https://hackmd.io/_uploads/BksWy7sVR.png" /></p>

Uno de los mayores desafíos que enfrenté fue la planificación del diseño. Inicialmente, no anticipé adecuadamente el tiempo y los recursos necesarios para completar cada etapa del proceso. Este aprendizaje me enseñó la importancia de adelantar tareas siempre que sea posible, lo que permite una mayor flexibilidad y tiempo para resolver problemas inesperados.

Para la impresión de las piezas, utilizamos inicialmente una impresora Ender Creality. Sin embargo, esta impresora falló en varias ocasiones, lo que nos obligó a reconsiderar nuestra estrategia. Finalmente, optamos por imprimir solo una pieza utilizando la impresora de la universidad, una Bambulab X1 Carbon. Esta impresora resultó ser mucho más fiable y precisa, lo que nos permitió obtener una pieza de alta calidad que cumplió con nuestras expectativas.

En resumen, el proceso de prototipado fue una experiencia de aprendizaje significativa. La importancia de una planificación cuidadosa y la flexibilidad para adaptarse a los problemas técnicos fueron lecciones clave que, sin duda, aplicaré en futuros proyectos.

## 6.4 Prototipado chaleco
Una vez realizados los primeros bocetos del chaleco, pasamos a construir el primer prototipo físico, el cual teníamos claro que iba a estar compuesto de tela cosida de manera que resultase cómodo para el usuario.

La idea principal era que los chalecos tuviesen 6 placas solares (3 por delante y 3 por detrás), de manera que se pudiese abarcar el máximo rango posible sin hacer una diana "demasiado fácil".

Compramos una "tote bag" en el bazar y la descosimos para tenerla por partes. A continuación nos pusimos manos a la obra con la máquina de coser para crear la estructura que se había diseñado en primer lugar:

>Después de muchas horas de coser, ya que uno de los chalecos se tuvo que coser a mano por falta de máquina de coser, conseguimos tener los dos chalecos terminados (solo la forma de estos), y faltaba enganchar las placas solares y los cables que posteriormente irían conectados a nuestra pistola.

Para enganchar las placas solares decidimos coser velcro para poder crear compartimentos que se pudieran abrir y cerrar fácilmente, en caso de que se tuviese que reponer alguna pieza:

<div style="display:flex">
<img src="https://hackmd.io/_uploads/BkOZQA34C.jpg" width="370" height="650"/>

<img src="https://hackmd.io/_uploads/HytvE0hER.jpg" width="370" height="650"/>
</div>

Una vez finalizado cada uno de los chalecos por delante y por detrás, solo quedaba crear la estructura de cables, los cuales viajaron por la manga especial que se diseñó tambien, con el fin de evitar enredarse con algun objeto del lugar donde se juegue la partida.

El resultado final de los chalecos fue un éxito, y siguió los diseños principales, por eso estamos muy orgullosos de como quedaron.

<p style="text-align:center;"><img src="https://hackmd.io/_uploads/SyBEHA34C.jpg" width="630" height="350"/></p>

## 6.5 Plan B pistola
La fecha de entrega cada vez se acercaba más, aún nos quedaba aproximadamente un mes para la entrega pero algún miembro del grupo se dió cuenta de que el prototipo 3D de la pistola se estaba alargando bastante más de lo que habíamos pensado.

Por ello, lo comentó a los compañeros y se decidió comprar unas pistolas de agua por si acaso. La idea era terminar el modelo 3D imprimirlo y usar ese.

<div style="display:flex">
<p>Sé compraron las pistolas por Aliexpress, se buscaron entre varios modelos, modelos con una forma realista, pero muchos de ellos eran muy pequeños ya que estaban pensados para niños.</p>
<img src="https://hackmd.io/_uploads/BJb79X7B0.png" width="100"/></p>

</div>

Finalmente nos encontramos este modelo, parecía un poco más grande que los otros y nos dió la sensación de que podría funcionar. Este modelo, además, nos permitiría tener la pantalla detrás.

Una vez nos llegó, vimos que era más pequeña de lo que pensabamos. Aunque habíamos comprovado las medidas antes de comprarla.

1. **Primero, nos dispusimos a abrirla.**
Fue una tarea no muy sencilla. No tenía tornillos, estaba enganchada a presión y tuvimos que hacer muchos esfuerzos para abrirla. Incluso llegó a tal momento que, en el lugar donde va la mano, tuvimos que desacer el plástico con el soldador para terminar de abrirla.

2. Una vez abierto, hicimos alguna que otra **remodelación fundiendo el plástico**. Quitando algunas paredes y añadiendo alguna otra para aguantar bien los componentes. Se consiguió poner algunos elementos con paredes para que fueran de quita y pon. Pero para conseguir todo eso, requirrió mucho tiempo.

Algunos de los cambios que se hicieron fue:
- Se quitó el deposito de agua, y la zona se aprovechó para crear paredes, y un puente para agauntar la batería. Al lado vereis una forma más cuadrada, se hizo para aguantar un botón que al apretar el gatillo, apretaría el botón. Lo del botón se consiguió que aguantara y se presionara al apretar el gatillo. Sin embargo, una vez estaba todo montado, al cerrar la pistola, el gatillo se giraba y se encallaba. Finalmente tocó poner un botón grande en vez del gatillo con el botón pequeño.

- Se hicieron agujeros para poder cargar, para poner los botones, el switch y para pasar los cables.

- Se hizo un agujero muy grande para la pantalla. Como la placa sobreralía y se veia todo con bultos, se construyeron paredes para solo ver la pantalla.

BEFORE
<div>
<img src="https://hackmd.io/_uploads/rJLeRNmBC.png" width="200"/>
<img src="https://hackmd.io/_uploads/HyYs047BR.png" width="270"/>
<img src="https://hackmd.io/_uploads/rJH0ANQBR.png" width="170"/>
</div>
Lamentamos que las fotos no se vean demasiado bien. No se hicieron del objeto en concreto y han sido recortadas de imagenes más grandes. La primera de ellas era antes de hacer el agujero. Las otras dos son con el agujero antes de ponerlo más bonito

AFTER
La primera foto tiene unas linias que indican un poco la forma anterior del objeto.

- Se hicieron más cambios pero masomenos queda bastante claro.

## 6.6 Adición de Hardware a los prototipos
Finalmente, se añadió el hardware en los protitipos. Tanto en la pistola como en el chaleco.

Se intentó hacer de la manera más limpia posible. Soldando con plásticos termorretráctiles para evitar que las soldaduras se tocasen y pudiesen generar problemas o cortocircuitos

Un problema que tuvimos con la pistola fue al cerrar la pistola. Se apretó mucho y se rompió. Por lo que se tuvo que desoldar y soldar una nueva. Para luego, finalmente cerrar con mucho cuidado.
<img src="https://hackmd.io/_uploads/S1OSYSXHA.jpg" width="170"/>

Cerrar la pistola también trajo problemas, al final se hizo un agujero mayor en el lateral para que entrasen bien los cables, y se hizo más grande los laterales para que los cables en el ESP32 no estuvieran tant apretados.

---

Para el chaleco, para conectar correctamente los elementos y que los cables no quedasen colgando, se cosieron en varios puntos. La tira leds también se despegaban, así que también se cosieron.