Sistema antirrobo para mochila – Grupo 13
Índice
1.Introducción
2.Funcionamiento
3.Caso de uso
4.Material usado y costes
5.Diseño
6.Implementación
7.Construcción
8.Problemas y soluciones encontradas
9.Posibles mejoras
10.Demostración
11.Autores
Introducción
Este proyecto consiste en el diseño y construcción de un sistema de seguridad para una mochila. La finalidad principal es detectar si la mochila se abre o si alguien se acerca o la manipula, avisando al usuario mediante una alarma física y mediante una aplicación móvil conectada por Bluetooth.
El sistema combina varios elementos de detección y aviso: un sensor magnético para detectar la apertura de la mochila, un sensor PIR para detectar movimiento, un buzzer para emitir una alarma sonora, un motor vibrador para generar una alerta física y un módulo Bluetooth HC-05 para comunicar el Arduino con la aplicación Android.
Funcionamiento
El funcionamiento general del sistema se basa en la comunicación entre una aplicación Android y un Arduino mediante el módulo Bluetooth HC-05. La aplicación actúa como panel de control del usuario, mientras que el Arduino se encarga de leer los sensores y activar los elementos físicos de aviso. Desde la app se envían comandos simples al Arduino para activar o desactivar la alarma, y el Arduino responde enviando mensajes de estado para que la aplicación actualice la pantalla.
La comunicación desde la aplicación hacia el Arduino se realiza mediante tres señales principales: el comando «1», el comando «2» y el comando «0». Cuando la app envía «1», el Arduino activa la alarma en modo normal. Cuando envía «2», activa la alarma en modo movimiento. Cuando envía «0», desactiva completamente la alarma. De esta forma, el usuario puede controlar el sistema desde el móvil sin tocar directamente el circuito.
En el modo normal, el sistema utiliza tanto el sensor magnético como el sensor PIR. El sensor magnético detecta si la mochila se abre, mientras que el sensor PIR detecta movimiento cerca de la mochila. Por tanto, en este modo la alarma se dispara si se abre la mochila o si se detecta movimiento alrededor. Este modo está pensado para cuando la mochila está quieta y se quiere vigilar cualquier intento de manipulación.
Cuando la app envía el comando «1», el Arduino cambia la variable interna de la alarma a activada y pone el sistema en modo normal. Después envía a la aplicación el mensaje «MODO_NORMAL», para que Android cambie visualmente el estado de la interfaz y muestre que la alarma está funcionando en modo normal. Si al activar este modo ya hay una intrusión detectada, el Arduino envía también el mensaje «PELIGRO». Si no detecta nada extraño, envía el mensaje «SEGURO».
En el modo movimiento, el sistema ignora el sensor PIR y solo tiene en cuenta el sensor magnético. Esto se hace para evitar falsas alarmas cuando la mochila se está moviendo o transportando, ya que el PIR podría detectar movimiento constantemente. En este modo, la alarma solo se dispara si el sensor magnético detecta que la mochila se abre.
Cuando la app envía el comando «2», el Arduino activa la alarma en modo movimiento. A continuación, envía a la aplicación el mensaje «MODO_MOVIMIENTO», para que Android actualice la interfaz y muestre que está activo ese modo. Igual que en el modo normal, si en ese momento el sensor magnético detecta apertura, el Arduino envía «PELIGRO»; si no hay apertura, envía «SEGURO».
El estado «SEGURO» significa que la alarma está activa, pero no se ha detectado ninguna intrusión. En este caso, la aplicación Android muestra que la mochila está segura y detiene la vibración del móvil si estuviera activa. Este estado permite diferenciar entre una alarma activada sin peligro y una alarma activada con intrusión detectada.
La alarma solo se considera activa cuando el usuario la activa expresamente desde la aplicación móvil. Es decir, el sistema no dispara la alarma si el usuario no ha seleccionado previamente el modo normal o el modo movimiento. Mientras la alarma está desactivada, el Arduino puede seguir leyendo los sensores, pero no activa ni el buzzer ni el motor vibrador ante una posible detección.
Cuando el Arduino detecta una intrusión, cambia el estado interno de la alarma a disparada. En ese momento activa el buzzer y el motor vibrador. El buzzer emite una alarma sonora intermitente y el motor vibrador genera una alerta física. Al mismo tiempo, el Arduino envía por Bluetooth el mensaje «PELIGRO» a la aplicación Android.
Una vez que la alarma se dispara, permanece activa hasta que el usuario la desactiva manualmente desde la aplicación. Esto significa que, aunque el sensor deje de detectar movimiento o aunque la mochila vuelva a cerrarse, el buzzer sigue sonando, el motor sigue vibrando y la aplicación sigue mostrando el estado de “PELIGRO”. La alarma no se reinicia sola, sino que necesita que el usuario pulse el botón de desactivar alarma en la app.
Cuando la aplicación recibe el mensaje «PELIGRO», cambia su interfaz para mostrar una alerta visual. En la pantalla aparece el estado de peligro, se muestra un mensaje de intrusión detectada y el teléfono comienza a vibrar. Por tanto, el móvil no decide por sí solo si hay peligro, sino que cambia su pantalla en función de las señales que recibe del Arduino.
Si el usuario quiere apagar la alarma, pulsa el botón de desactivar en la aplicación. En ese momento la app envía al Arduino el comando «0». Al recibirlo, el Arduino desactiva el sistema, apaga el buzzer, detiene el motor vibrador, borra el estado de alarma disparada y sale de cualquier modo activo.
Después de recibir el comando «0», el Arduino envía a la aplicación los mensajes «DESACTIVA» y «SEGURO». El mensaje «DESACTIVA» indica que la alarma ya no está armada, por lo que la aplicación cambia el modo activo a apagado. El mensaje «SEGURO» indica que ya no hay peligro activo, por lo que la app vuelve a un estado tranquilo y detiene la vibración del teléfono.
Además de esos mensajes, el Arduino también puede enviar «ACTIVA» en el estado inicial si el sistema estuviera armado. La aplicación interpreta «ACTIVA» como un estado de alarma activada en modo normal.
Caso de uso
Como ejemplo de uso del modo normal, se puede pensar en una mochila guardada en una taquilla del gimnasio, en una biblioteca o en un lugar donde permanece quieta durante un tiempo. En ese caso interesa detectar cualquier intento de manipulación, tanto si alguien abre la mochila como si alguien se acerca o se mueve cerca de ella. Por eso se utilizaría el modo normal, ya que en este modo están activos tanto el sensor magnético como el sensor PIR.
Como ejemplo de uso del modo movimiento, se puede pensar en una situación en la que el usuario lleva la mochila puesta o se desplaza con ella, por ejemplo caminando por la calle. En este caso no sería útil que el sensor PIR activara la alarma, porque al estar en movimiento podría detectar personas alrededor constantemente y generar falsas alarmas. Por eso se utilizaría el modo movimiento, en el que el PIR se ignora y la alarma solo se dispara si alguien abre la mochila y salta el sensor magnético.
Materiales usados y costes
| Componentes | Coste |
| Arduino UNO | 17,99€ |
| Protoboard | 2,41€ |
| Bluetooth BT-05 | 9,99€ |
| Sensor Magnético | 1,39€ |
| Sensor PIR | 2,80€ |
| Vibrador DC | 1,82€ |
| Buzzer | 2,39€ |
| Otros(pila, cables, resistencias…) | ≃3€ |
El total de nuestro producto es:41,79€
Diseño
El diseño del proyecto se divide en dos partes principales: el diseño del circuito electrónico y el diseño de la aplicación móvil. El circuito se ha organizado alrededor de una placa Arduino UNO, que actúa como unidad central de control. A esta placa se conectan los sensores encargados de detectar una posible intrusión y los elementos de aviso que se activan cuando se detecta peligro.
En el circuito se incluye un sensor magnético conectado al pin 3 del Arduino, que permite detectar la apertura de la mochila. También se utiliza un sensor PIR conectado al pin 4, encargado de detectar movimiento cerca de la mochila. Como elementos de salida, se ha conectado un buzzer al pin 8 para emitir una señal sonora y un motor vibrador al pin 7 para generar una alerta física.
La comunicación entre el Arduino y la aplicación Android se realiza mediante un módulo Bluetooth HC-05. Este módulo permite que la aplicación envíe órdenes al Arduino, como activar la alarma en modo normal, activar el modo movimiento o desactivar el sistema. También permite que el Arduino envíe mensajes de estado a la aplicación, como “PELIGRO”, “SEGURO”, “MODO_NORMAL”, “MODO_MOVIMIENTO” o “DESACTIVA”.
En el diseño del circuito se han incluido resistencias en la conexión del Bluetooth para proteger el módulo HC-05. Esto se debe a que el Arduino trabaja con señales de 5 V, mientras que el Bluetooth trabaja con lógica de aproximadamente 3,3 V. Por tanto, las resistencias actúan como divisor de tensión y reducen la señal que llega al pin RX del Bluetooth.
También se ha añadido un transistor para controlar el motor vibrador. El motivo es que el Arduino no debe alimentar directamente un motor desde uno de sus pines digitales, ya que el vibrador puede necesitar más corriente de la que el pin puede entregar con seguridad. El transistor funciona como un interruptor electrónico: el Arduino solo envía una señal de control y el transistor permite o corta el paso de corriente hacia el vibrador.
El diseño de la aplicación Android se ha planteado como una interfaz sencilla para el usuario. La pantalla permite conectarse al Bluetooth, activar el modo normal, activar el modo movimiento y desactivar la alarma. Además, cambia visualmente según los mensajes que recibe del Arduino, mostrando si la mochila está segura, si hay peligro o si la alarma está desactivada.
Implementación
Código de arduino:
#include <SoftwareSerial.h>
SoftwareSerial BT(10, 11); // RX, TX
const int buzzerPin = 8;
const int vibradorPin = 7;
const int magneticoPin = 3;
const int pirPin = 4;
bool sistemaArmadoApp = false;
bool ultimoEstadoPeligro = false;
bool ultimoEstadoArmado = false;
bool alarmaDisparada = false;
bool modoMovimiento = false;
unsigned long ultimoCambioAlarma = 0;
bool estadoBuzzer = false;
void setup() {
configurarPines();
iniciarComunicacion();
mostrarInicio();
enviarEstadoInicial();
}
void loop() {
leerBluetooth();
revisarEstadoArmado();
revisarPeligro();
}
bool hayIntrusion() {
bool magneticoAbierto = digitalRead(magneticoPin) == HIGH;
bool movimientoDetectado = digitalRead(pirPin) == HIGH;
if (modoMovimiento) {
return magneticoAbierto;
} else {
return magneticoAbierto || movimientoDetectado;
}
}
void configurarPines() {
pinMode(buzzerPin, OUTPUT);
pinMode(vibradorPin, OUTPUT);
pinMode(magneticoPin, INPUT_PULLUP);
pinMode(pirPin, INPUT);
desactivarAlarma();
}
void iniciarComunicacion() {
Serial.begin(9600);
BT.begin(9600);
}
void mostrarInicio() {
Serial.println("=================================");
Serial.println(" SISTEMA DE ALARMA INICIADO");
Serial.println("=================================");
Serial.println();
}
void enviarEstadoInicial() {
bool armado = sistemaActivo();
if (armado) {
Serial.println("[ESTADO] Estado inicial: ALARMA ACTIVADA");
BT.println("ACTIVA");
} else {
Serial.println("[ESTADO] Estado inicial: ALARMA DESACTIVADA");
BT.println("DESACTIVA");
}
ultimoEstadoArmado = armado;
}
void revisarEstadoArmado() {
bool armado = sistemaActivo();
if (armado != ultimoEstadoArmado) {
if (armado) {
Serial.println("[ESTADO] Alarma ACTIVADA");
if (modoMovimiento) {
BT.println("MODO_MOVIMIENTO");
} else {
BT.println("MODO_NORMAL");
}
} else {
Serial.println("[ESTADO] Alarma DESACTIVADA");
BT.println("DESACTIVA");
}
ultimoEstadoArmado = armado;
}
}
void revisarPeligro() {
bool armado = sistemaActivo();
bool intrusion = hayIntrusion();
if (armado) {
if (intrusion && !alarmaDisparada) {
alarmaDisparada = true;
Serial.println("[ALERTA] INTRUSION DETECTADA");
mostrarSensores();
BT.println("PELIGRO");
ultimoEstadoPeligro = true;
}
if (alarmaDisparada) {
activarAlarmaSinDelay();
}
} else {
desactivarAlarma();
if (ultimoEstadoPeligro) {
Serial.println("[INFO] Alarma apagada por la app");
BT.println("SEGURO");
ultimoEstadoPeligro = false;
}
alarmaDisparada = false;
}
}
void leerBluetooth() {
while (BT.available()) {
char dato = BT.read();
Serial.print("[BT] Comando recibido: ");
Serial.println(dato);
procesarComandoBluetooth(dato);
}
}
void procesarComandoBluetooth(char dato) {
if (dato == '1') {
sistemaArmadoApp = true;
modoMovimiento = false;
Serial.println("[BT] La app ha ACTIVADO la alarma en MODO NORMAL");
BT.println("MODO_NORMAL");
if (hayIntrusion()) {
alarmaDisparada = true;
ultimoEstadoPeligro = true;
}
if (alarmaDisparada) {
BT.println("PELIGRO");
} else {
BT.println("SEGURO");
}
}
else if (dato == '2') {
sistemaArmadoApp = true;
modoMovimiento = true;
Serial.println("[BT] La app ha ACTIVADO la alarma en MODO MOVIMIENTO");
Serial.println("[BT] En este modo se ignora el PIR");
BT.println("MODO_MOVIMIENTO");
if (hayIntrusion()) {
alarmaDisparada = true;
ultimoEstadoPeligro = true;
}
if (alarmaDisparada) {
BT.println("PELIGRO");
} else {
BT.println("SEGURO");
}
}
else if (dato == '0') {
sistemaArmadoApp = false;
modoMovimiento = false;
ultimoEstadoPeligro = false;
alarmaDisparada = false;
desactivarAlarma();
Serial.println("[BT] La app ha DESACTIVADO la alarma");
BT.println("DESACTIVA");
BT.println("SEGURO");
}
else if (dato == '\n' || dato == '\r') {
// Ignorar saltos de linea
}
else {
Serial.println("[BT] Comando no reconocido");
}
}
bool sistemaActivo() {
return sistemaArmadoApp;
}
void mostrarSensores() {
Serial.print("[SENSORES] Magnetico: ");
Serial.print(digitalRead(magneticoPin));
Serial.print(" | PIR: ");
Serial.println(digitalRead(pirPin));
}
void activarAlarmaSinDelay() {
digitalWrite(vibradorPin, HIGH);
unsigned long ahora = millis();
if (ahora - ultimoCambioAlarma >= 200) {
ultimoCambioAlarma = ahora;
estadoBuzzer = !estadoBuzzer;
if (estadoBuzzer) {
tone(buzzerPin, 1000);
} else {
noTone(buzzerPin);
}
}
}
void desactivarAlarma() {
noTone(buzzerPin);
digitalWrite(vibradorPin, LOW);
estadoBuzzer = false;
}Código de la aplicación Android:
La aplicación Android se ha desarrollado en Kotlin. En esta memoria no se incluye el código completo de la interfaz, ya que la mayor parte corresponde al diseño visual de la pantalla. Se recogen únicamente los fragmentos relacionados con la comunicación Bluetooth, por ser los más relevantes para el funcionamiento del sistema empotrado.
Esta comunicación permite que la app envíe al Arduino los comandos de control y procese los mensajes que recibe como respuesta. De este modo, la aplicación puede activar el modo normal, activar el modo movimiento, desactivar la alarma y actualizar visualmente el estado del sistema.
private fun sendCommand(command: Char) {
if (!_isConnected.value || outputStream == null) {
return
}
scope.launch {
try {
outputStream?.write(command.code)
outputStream?.flush()
withContext(Dispatchers.Main) {
_statusMessage.value = "Comando enviado: $command"
}
} catch (e: IOException) {
withContext(Dispatchers.Main) {
_isConnected.value = false
_statusMessage.value = "Error al enviar"
}
cerrarConexion()
}
}
}La función sendCommand() se utiliza desde los botones principales de la aplicación. Según el botón pulsado por el usuario, se envía un carácter diferente al Arduino:
De esta forma, el usuario no interactúa directamente con el circuito, sino que controla el sistema desde la aplicación móvil. El Arduino recibe el comando, lo interpreta y activa o desactiva la alarma según corresponda.
onActivate = { sendCommand('1') }
onMoveMode = { sendCommand('2') }
onDeactivate = { sendCommand('0') }private fun processMessage(message: String) {
val msg = message.trim().uppercase()
when {
msg.contains("DESACTIVA") -> {
_alarmMode.value = AlarmMode.OFF
_dangerStatus.value = "ESPERANDO"
_statusMessage.value = "Alarma desactivada"
vibratePeligro(false)
}
msg.contains("PELIGRO") -> {
_dangerStatus.value = "PELIGRO"
_statusMessage.value = "Alerta — Intrusión detectada"
vibratePeligro(true)
}
msg.contains("SEGURO") -> {
_dangerStatus.value = "SEGURO"
_statusMessage.value = "Mochila segura"
vibratePeligro(false)
}
msg.contains("MODO_MOVIMIENTO") -> {
_alarmMode.value = AlarmMode.MOVIMIENTO
_statusMessage.value = "Modo Movimiento activo"
}
msg.contains("MODO_NORMAL") || msg == "ACTIVA" -> {
_alarmMode.value = AlarmMode.NORMAL
_statusMessage.value = "Modo Normal activo"
}
else -> {
_statusMessage.value = "Mensaje: $msg"
}
}
}La función processMessage() es la encargada de interpretar los mensajes recibidos desde el Arduino. Primero limpia el texto recibido y lo convierte a mayúsculas para evitar errores por espacios o diferencias de formato. Después, mediante una estructura when, comprueba qué mensaje ha llegado y actualiza los distintos atributos de la interfaz.
Por ejemplo, si recibe "PELIGRO", la aplicación cambia el estado de seguridad a peligro, muestra un mensaje de intrusión detectada y activa la vibración del teléfono. Si recibe "SEGURO", muestra que la mochila está segura y detiene la vibración. Si recibe "DESACTIVA", cambia el modo de alarma a apagado y vuelve al estado de espera.
Esta función se ejecuta cada vez que llega un nuevo mensaje por Bluetooth desde el Arduino. Por tanto, la aplicación va cambiando dinámicamente según las señales recibidas: muestra el modo activo, el estado de seguridad, los mensajes informativos y la vibración del móvil. De esta manera, la app actúa como panel de control y visualización del sistema de alarma.
Costrucción
La construcción del prototipo se realizó de forma progresiva, siguiendo estos pasos:
- Diseño del circuito en Fritzing: primero se realizó el esquema del circuito, colocando el Arduino, el módulo Bluetooth HC-05, el sensor magnético, el sensor PIR, el buzzer, el motor vibrador, las resistencias y el transistor.
- Prueba individual de componentes: después se probaron los componentes uno a uno en la protoboard, comprobando el funcionamiento del buzzer, el vibrador, el sensor magnético, el PIR y el módulo Bluetooth.
- Desarrollo de la aplicación móvil: una vez comprobados los componentes, se desarrolló la app Android. Antes de conectarla al Arduino, se simularon mensajes como “PELIGRO”, “SEGURO”, “MODO_NORMAL”, “MODO_MOVIMIENTO” y “DESACTIVA” para comprobar que la interfaz cambiaba correctamente.
- Integración entre Arduino y aplicación: posteriormente se conectó la app con el circuito real. Se comprobó que la aplicación enviaba correctamente los comandos “1”, “2” y “0”, y que el Arduino respondía activando el modo normal, el modo movimiento o desactivando la alarma.
- Montaje de la maqueta: por último, se colocaron los componentes en la mochila. El sensor magnético se situó en la zona de apertura, el sensor PIR se orientó hacia el exterior y se integraron el buzzer y el motor vibrador como elementos de aviso.
- Pruebas finales: finalmente se realizaron pruebas del sistema completo, comprobando que al detectar una intrusión se activaban el buzzer y el vibrador, y que la aplicación mostraba correctamente el estado de peligro.
Problemas y soluciones encontradas
1.Falsos positivos en el sensor PIR:
Durante las primeras pruebas del sistema, el sensor de movimiento PIR detectaba actividad de forma constante, incluso cuando no había movimiento real cerca de la mochila. Esto provocaba que la alarma se disparase de forma continua, haciendo que el modo normal no fuese fiable.
Causa: El sensor PIR tenía la distancia de detección y la sensibilidad configuradas demasiado altas. Este sensor dispone de potenciómetros de ajuste que permiten modificar la distancia de detección y el tiempo de activación de la señal. Al estar configurado con valores demasiado elevados, detectaba pequeñas variaciones del entorno como si fueran movimiento real.
Solución: Se calibró manualmente el sensor PIR, reduciendo la distancia de detección y ajustando su sensibilidad a un valor más adecuado para el proyecto. Tras este ajuste, el sensor dejó de detectar movimientos irrelevantes y pasó a activarse únicamente cuando había una presencia real cerca de la mochila.
2.Limitaciones de MIT App Inventor
En la fase inicial del proyecto, la aplicación móvil se intentó desarrollar con MIT App Inventor, una herramienta visual sencilla para crear aplicaciones Android. Sin embargo, durante las pruebas se comprobó que no era suficiente para el funcionamiento que necesitaba nuestro sistema.
Causa:La aplicación necesitaba gestionar comunicación Bluetooth en tiempo real, recibir mensajes de forma continua desde el Arduino y actualizar la interfaz de manera inmediata cuando llegaran señales como “PELIGRO”, “SEGURO” o “DESACTIVA”. MIT App Inventor presentaba limitaciones para gestionar esta recepción continua de datos de forma fiable.
Solución: Se decidió descartar MIT App Inventor y desarrollar la aplicación desde cero en Kotlin utilizando Android Studio. Aunque esta opción aumentó la complejidad del desarrollo, permitió controlar mejor la conexión Bluetooth, procesar los mensajes recibidos correctamente y actualizar la interfaz de forma más estable.
Problemas con el divisor de tensión del Bluetooth
Durante el montaje del módulo Bluetooth HC-05, surgieron problemas de comunicación entre el Arduino y la aplicación móvil. En un primer momento parecía que el fallo podía estar en el código o en la conexión Bluetooth, pero finalmente se comprobó que el problema estaba en el divisor de tensión utilizado para proteger el pin RX del HC-05.
Causa: El Arduino trabaja con señales de 5 V, mientras que el pin RX del módulo HC-05 debe recibir una señal de aproximadamente 3,3 V. Para ello era necesario montar un divisor de tensión con resistencias. Necesitábamos una resistencia de 2 kΩ y otra de 1 kΩ, pero al no tener una resistencia de 2 kΩ utilizamos dos resistencias de 1 kΩ en serie para obtener el valor equivalente. El problema fue que inicialmente las resistencias se colocaron de forma incorrecta, por lo que la señal no llegaba bien al módulo Bluetooth.
Solución: Se revisó el esquema del divisor de tensión y se corrigió la posición de las resistencias. Finalmente, se colocaron dos resistencias de 1 kΩ en serie para formar la resistencia equivalente de 2 kΩ, junto con otra resistencia de 1 kΩ, consiguiendo reducir la señal del Arduino a un valor seguro para el HC-05. Tras corregir la conexión, la comunicación Bluetooth empezó a funcionar correctamente.
Recepción de mensajes Bluetooth incompletos
Durante las pruebas de integración entre el Arduino y la app, se detectó que en ocasiones los mensajes enviados por el Arduino (por ejemplo, «PELIGRO») llegaban a la aplicación de forma parcial, procesándose como cadenas incompletas como «PELI» o «GRO» que no eran reconocidas por la lógica de la app.
Causa: La lectura del stream Bluetooth se realizaba byte a byte, sin esperar a que llegara el mensaje completo. Dado que el protocolo SPP no garantiza que los datos lleguen en un único paquete, es posible que un mensaje se fragmente en varias lecturas.Solución: Se implementó un BufferedReader sobre el InputStream Bluetooth, utilizando el método readLine() que espera hasta recibir el carácter de fin de línea (\n) antes de devolver el mensaje completo. El Arduino ya enviaba los mensajes con BT.println(), que añade automáticamente el \n al final. Con este cambio, la app siempre recibe mensajes íntegros.
Posibles mejoras
Una posible mejora del proyecto sería sustituir el sensor PIR de movimiento por un acelerómetro. El PIR detecta movimiento en el entorno, pero puede generar falsas alarmas si hay personas cerca o si la mochila se encuentra en una zona con mucho movimiento. En cambio, un acelerómetro permitiría detectar directamente vibraciones, golpes o desplazamientos de la propia mochila, por lo que la detección sería más precisa y estaría más relacionada con una manipulación real del objeto protegido.
Otra mejora sería sustituir la placa Arduino UNO por una placa ESP32. Esta opción permitiría reducir el coste total del sistema, ya que el ESP32 es una placa económica y además incorpora conectividad Bluetooth integrada. De esta manera, no sería necesario utilizar un módulo Bluetooth HC-05 externo, simplificando el circuito y reduciendo tanto el número de componentes como el espacio ocupado dentro de la mochila.
También sería recomendable sustituir la protoboard y el cableado provisional por una PCB personalizada. Aunque fabricar una PCB para una única unidad puede resultar más caro que montar el circuito en una protoboard, esta solución sería mucho más adecuada si el proyecto se quisiera escalar o fabricar en varias unidades. Una PCB permitiría reducir el tamaño del montaje, mejorar la resistencia de las conexiones, evitar cables sueltos y conseguir un acabado más profesional.
Además, se podría mejorar la alimentación del sistema utilizando una batería recargable integrada. Esto permitiría que la mochila funcionara de forma autónoma sin depender de una conexión USB o de una fuente externa de alimentación. Junto con esto, podría añadirse un sistema de carga y un indicador del nivel de batería en la aplicación móvil.
Por último, la aplicación Android podría ampliarse incorporando un registro de eventos. De esta forma, el usuario podría consultar cuándo se activó la alarma, cuándo se detectó peligro y cuándo se desactivó el sistema. Esto haría que la aplicación no solo sirviera como panel de control, sino también como herramienta de seguimiento del estado de seguridad de la mochila.
Demostración
Autores
Hecho por:
Borja González Rebollo, David Ingunza Romero, Gonzalo Valverde Manso, Diego Quinzaños Díaz
