PROYECTO II A 2025 » Grupo 6A 2025

table{width:100%;background:#0cc0df}.

|_. [[Wiki|⌂]] |_. [[Descripción general]] |_. [[Organización y planificación del proyecto]] |_. [[Poster]] |

---

_

_

h1=. Organización del proyecto

_

_

h2=. +Personal y entidades externas+

p=. *Jefe del proyecto:* Renato Almeyda

*Programador(es):* Renato Almeyda, Jeany Aravena

*Diseñador:* Bastián Cruz

*Ensamblador:* Josue Sucso

*Documentador:* Bastián Cruz

_

_

h2=. +Roles y responsabilidades+

* *Jefe del proyecto:* Encargado de coordinar y supervisar el correcto avance de todos los procesos que componen el desarrollo del proyecto. Es representante del equipo de trabajo ante los profesores encargados del ramo y el resto de los equipos.

* *Diseñador:* Se encarga de diseñar la interfaz de usuario y la experiencia de usuario de la aplicación móvil de alerta. Es responsable de crear el flujo de notificaciones que recibe el propietario.

* *Programador(es):* Encargados de escribir el código que se ejecuta en el Raspberry Pi 4. Su trabajo es asegurar que el dispositivo pueda leer correctamente la información de los sensores, tomar las decisiones de seguridad (como verificar la velocidad y el código QR), y coordinar todas las partes del sistema para que funcionen de manera sincronizada.

* *Ensamblador:* Encargado de la preparación física y el montaje del sistema. Sus responsabilidades incluyen: ensamblar el Raspberry Pi 4 con sus componentes (caja o chasis), cablear y conectar correctamente todos los sensores (velocidad, cámara) y periféricos al microcontrolador, y asegurar que la instalación del hardware sea funcional dentro del vehículo.

* *Documentador:* Responsable de la gestión integral de la información del proyecto. Esto incluye la elaboración de informes de avance y bitácoras, así como la creación y mantenimiento de la Wiki para documentación técnica. Es el encargado de administrar la Carta Gantt dentro de la plataforma Redmine para el seguimiento y control del proyecto.

_

_

___

_

_

h2=. +Mecanismos de Comunicación+

p=. *Canales internos:* Correo institucional, grupo de WhatsApp, Discord.

*Documentación compartida:* Google Drive y GitHub (repositorio del proyecto).

_

_

h2=. +Comunicaciones y Estándares Técnicos+

* *Lenguajes de Programación:*

** *Python:* Para la lógica del sistema en la Raspberry Pi 4 y el procesamiento de datos del acelerómetro y la cámara.

** *Kotlin:* Para el desarrollo de la aplicación móvil nativa (Android).

* *Lenguajes de Interfaz y Datos:*

** *JSON (JavaScript Object Notation):* Como estándar de intercambio de datos para la comunicación entre el dispositivo IoT (Raspberry Pi) y la aplicación móvil.

* *Comunicaciones para XR (Realidad Extendida):*

** *C#:* Utilizado en el motor Unity para la creación de una maqueta virtual del proyecto, la cual será desplegada en un dispositivo Meta Quest 3.

_

_

---

_

_

h1=. Planificación de los procesos de gestión

h2=. +Planificación inicial del proyecto+

_

_

h3=. Planificación de estimaciones

table{margin-left:auto;margin-right:auto}.

{background:#0cc0df}. |_. Producto |_. Cantidad |_. Costo por unidad |_. Costo Total |

|=. Notebook (Uso) |=. 4 |=. $50.000 |=. $200.000 |

|=. Raspberry PI 4 |=. 1 |=. $90.000 |=. $90.000 |

|=. Sensor Cámara |=. 1 |=. $5.000 |=. $5.000 |

|=. Sensor Acelerómetro |=. 1 |=. $5.000 |=. $5.000 |

|=. Grove LCD RGB Backlight |=. 1 |=. $15.000 |=. $15.000 |

|=. Tarjeta SD |=. 1 |=. $13.000 |=. $13.000 |

|||| *Total: $328.000* |

_

_

h3=. Planificación de Recursos Humanos

table{margin-left:auto;margin-right:auto}.

{background:#0cc0df}. |_. Roles |_. Tarifa x Hora |

|=. Jefe de proyecto |=. $12.000 |

|=. Programador |=. $10.000 |

|=. Diseñador |=. $8.500 |

|=. Documentador |=. $5.000 |

|=. Ensamblador |=. $6.000 |

_

_

h3=. Tabla de Planificación de recursos totales

table{margin-left:auto;margin-right:auto}.

{background:#0cc0df}. |_. Miembro |_. Rol |_. Hora x mes |_. Meses de utilidad |_. Resultado |_. Pago Final |

|=. Renato Almeyda |=. Jefe de proyecto |=. 40 |=. 4 |=. $1.920.000 |/2=. $3.520.000 |

|=. Renato Almeyda |=. Programador |=. 40 |=. 4 |=. $1.600.000 |

|=. Bastián Cruz |=. Diseñador |=. 40 |=. 2 |=. $680.000 |/2=. $1.480.000 |

|=. Bastián Cruz |=. Documentador |=. 40 |=. 4 |=. $800.000 |

|=. Josue Sucso |=. Documentador |=. 40 |=. 4 |=. $800.000 |/2=. $1.280.000 |

|=. Josue Sucso |=. Ensamblador |=. 40 |=. 2 |=. $480.000 |

|=. Jeany Aravena |=. Programador |=. 40 |=. 4 |=. $1.600.000 |=. $1.600.000 |

|||||=. *Total* |=. *$7.880.000* |

p=. *Costo total del proyecto: $8.208.000*

_

_

_

_

---

_

_

h2=. Lista de actividades (Carta Gantt)

_

_

h1=. !cartaGantt.png!

_

_

---

_

_

h2=.  Planificación de la gestión de riesgos

p=. *Niveles de impacto:* 1. Despreciable | 2. Marginal | 3. Crítico | 4. Catastrófico

table{margin-left:auto;margin-right:auto}.

{background:#0cc0df}. |_. Riesgo |_. Probabilidad |_. Impacto |_. Acción Remedial |

|=. Retraso en la entrega de componentes (sensores, cámara, cables). |=. 70% |=. 2 |=. Reasignar tareas de software mientras se espera el hardware. Avanzar en simulación y documentación. |

|=. Fallo en la compatibilidad de librerías entre sensores Grove y Raspberry Pi 4. |=. 60% |=. 2 |=. Buscar alternativas compatibles o adaptar código con librerías Python (ej. smbus, OpenCV, grovepi). |

|=. Error en la lectura del QR por condiciones de luz o enfoque. |=. 30% |=. 2 |=. Implementar prueba de iluminación adicional con LED blanco o ajustar contraste por software. |

|=. Fallas en la conexión Wi-Fi durante las pruebas. |=. 15% |=. 4 |=. Utilizar red local o conexión directa entre Raspberry y smartphone. |

|=. Problemas de programación en la app móvil o en la comunicación con Raspberry. |=. 50% |=. 2 |=. Realizar pruebas modulares (API y comunicación). Dividir tareas por submódulos. |

|=. Dificultad del equipo para coordinar horarios o tareas. |=. 20% |=. 3 |=. Planificar reuniones semanales y utilizar Google Drive y WhatsApp para actualizaciones rápidas. |

|=. Sobrecarga académica o ausencia de un integrante clave. |=. 20% |=. 3 |=. Reasignar tareas temporalmente y mantener documentación actualizada para continuidad del trabajo. |

|=. Problemas de Raspberry y sensores por motivos accidentales. |=. 20% |=. 1 |=. Manejar con cuidado el dispositivo Raspberry y cuidar que los sensores no se quemen. |

|=. Deriva o calibración incorrecta del acelerómetro. |=. 50% |=. 3 |=. Establecer una rutina de calibración inicial del sensor y aplicar filtros digitales (ej. Filtro Complementario o Kalman). |

|=. Problemas de seguridad en la transmisión de datos (IoT). |=. 40% |=. 4 |=. Implementar cifrado (SSL/TLS) en la comunicación entre el dispositivo (Raspberry Pi) y la aplicación móvil. |

_

_

---

_

_

h1=. Planificación de procesos técnicos

h2=. Tabla de requerimientos funcionales

table{margin-left:auto;margin-right:auto;width:100%}.

{background:#0cc0df}. |_. ID |_. Descripción |

|=. RF 1 |=. El sistema debe generar un código QR dinámico que cambie periódicamente para permitir la autenticación del propietario del vehículo. |

|=. RF 2 |=. El sistema debe capturar el QR mediante la cámara de la Raspberry Pi para validar al usuario autorizado. |

|=. RF 3 |=. El sistema debe verificar el QR escaneado contra el código generado y determinar si es válido o no. |

|=. RF 4 |=. El sistema debe permitir al usuario autenticado desactivar la alerta desde la aplicación móvil con el código QR. |

|=. RF 5 |=. El sistema debe leer los valores del acelerómetro (GY-6500/9250) para detectar la aceleración del vehículo, permitiendo identificar que hubo arranque y que está en movimiento. |

|=. RF 6 |=. El sistema debe enviar una notificación en tiempo real a la aplicación móvil del propietario cuando se detecte movimiento no autorizado al no escanear el QR. |

|=. RF 7 |=. El sistema debe permitir al usuario, tras confirmar un evento, enviar los datos a carabineros indicando fecha, hora, modelo del vehículo y una imagen de la persona arribada en el vehículo. |

|=. RF 8 |=. El sistema debe almacenar las alertas confirmadas en un registro histórico accesible desde la app. |

|=. RF 9 |=. El sistema debe activar un display LCD dependiendo del estado en que se encuentre. |

|=. RF 10 |=. El sistema debe permitir registrar información del vehículo (modelo, patente, color, detalles adicionales). |

_

_

h2=. Tabla de requerimientos no funcionales

table{margin-left:auto;margin-right:auto;width:100%}.

{background:#0cc0df}. |_. ID |_. Descripción |

|=. RNF 1 |=. El sistema debe utilizar cifrado para todas las comunicaciones entre la Raspberry Pi y la aplicación móvil para proteger el código QR y la información sensible. |

|=. RNF 2 |=. El tiempo de respuesta desde la captura del QR (RF 2) hasta la validación y determinación de si es válido (RF 3) no debe exceder los 2 segundos. |

|=. RNF 3 |=. El sistema debe ser capaz de mantener un registro histórico (RF 8) de al menos 6 meses de alertas. |

|=. RNF 4 |=. El código del sistema debe ser modular y estar bien documentado para permitir que un nuevo desarrollador pueda entender y modificar la lógica. |

|=. RNF 5 |=. El sistema debe ser actualizable de forma remota (OTA - Over-The-Air) para el software de la Raspberry Pi sin requerir acceso físico al vehículo. |

|=. RNF 6 |=. El consumo de energía del sistema, cuando está en modo de espera (monitoreando el acelerómetro), debe ser mínimo para no descargar la batería del vehículo. |

|=. RNF 7 |=. El tiempo de envío de la notificación de movimiento no autorizado a la aplicación móvil no debe superar los 5 segundos desde que se detecta el movimiento. |

|=. RNF 8 |=. La interfaz de usuario (UI) de la aplicación móvil debe ser intuitiva y de fácil navegación. |

_

_

---

_

_

h1=. Diagramas y descripción de arquitectura

_

_

h2=. Diagrama de caso de uso general

!CasoGeneral.png!

_

_

h2=. Descripción de la arquitectura

!contexto.png!

_

_

h2=. Diagrama de clases

!DiagramaClases.png!

_

_

h2=. Diagrama de secuencias

!diagramaSecuencias.png!

_

_

_

_

h2=. Descripción de la arquitectura con respecto a los modelos

* *Modelo de caso de uso general:* El diagrama de caso de uso general demuestra cómo la arquitectura del sistema integra los distintos componentes físicos y lógicos. Se representan los sensores y actuadores del vehículo (acelerómetro, cámara y pantalla LCD), los cuales interactúan directamente con la Raspberry Pi como sistema central. Por otro lado, se ubican los actores externos: la aplicación móvil y el Sistema de la Autoridad.

* *Modelo de diagrama de clases:* Representa la estructura interna del sistema. La clase Raspberry aparece como el centro de la arquitectura, administrando la cámara (SensorQR), el acelerómetro y el display LCD. La Aplicación Móvil sirve como puente entre el dueño y la Raspberry Pi.

* *Modelo de diagrama de secuencia:* Representa cómo la arquitectura funciona en los dos escenarios principales:

** *Ingreso normal:* El acelerómetro detecta movimiento, el usuario muestra el QR, la Raspberry valida y desactiva la alerta.

** *Intrusión:* El acelerómetro detecta movimiento sin QR válido, la cámara captura imagen del sospechoso y notifica a la app. Si el usuario confirma, se envía reporte a la autoridad.

_

_

---

_

_

h2=. Herramientas y técnicas

_

_

h3=. Herramientas

p=. *Visual Studio Code:* Editor principal para la programación.

*Redmine:* Gestión de tareas y seguimiento del proyecto.

*Google Docs:* Elaboración de documentos y bitácoras.

*Draw.io:* Creación de diagramas.

*Canva:* Diseño de interfaz de usuario y presentaciones.

*Raspberry Pi OS:* Sistema operativo de la plataforma central.

_

_

h3=. Técnicas utilizadas

p=. *Dividir para conquistar:* Separación de módulos para facilitar el desarrollo.

*Iteración incremental:* Avance en etapas con revisión previa.

*Validación por escenarios:* Análisis de flujos de dueño e intruso.

*Prototipado temprano:* Diseño de modelos antes de la implementación real.

*Modularización:* Componentes independientes (sensores, cámara, app).

*Pruebas por componente:* Validación individual antes de la integración.

_

_

---

_

_

h2=. Plan de integración

p=. Este plan describe cómo se unificarán los distintos componentes físicos y lógicos:

p=. *Integración de Sensores con Raspberry Pi 4:* Conexión física del acelerómetro y configuración de librerías Python (smbus, grovepi).

*Integración de la Cámara QR:* Implementación del lector QR mediante Python + OpenCV y validación contra el QR dinámico de Telegram.

*Integración del Display LCD:* Comunicación vía I2C para mostrar mensajes de estado.

*Integración del Módulo Acelerómetro:* Registro continuo de valores para identificar el inicio de movimiento.

*Integración del Bot de Telegram:* Configuración del bot para envío de alertas, generación de QR dinámico y recepción de comandos del usuario.

_

_

---

_

_

h2=. Descripción de la Arquitectura (vista desde los módulos del caso de uso)

p=. La arquitectura se organiza en torno a la Raspberry Pi 4 como unidad central que coordina:

p=. *Módulo de Detección de Movimiento (Acelerómetro):* Detecta cambios de aceleración y activa el flujo de validación.

*Módulo de Validación del Usuario (Cámara y QR):* Captura imágenes en tiempo real y decodifica el QR para compararlo con el generado por el bot.

*Módulo de Display LCD:* Entrega retroalimentación visual ("Autorizado", "Denegado").

*Módulo de Comunicación (Bot de Telegram):* Interfaz principal con el dueño para alertas y confirmaciones.

*Módulo de Generación y Gestión de Alertas:* Se activa ante fallos de validación, captura imagen del sospechoso y genera reportes.

*Módulo Central:* Coordina todos los sensores y lógica de estados.

_

_

---

_

_

h2=. Modelo de Implementación

p=. La solución se estructura en Python con una arquitectura modular:

p=. *main.py:* Coordinación general.

*accelerometer.py:* Manejo del sensor.

*qr_reader.py:* Lectura y decodificación de QR.

*telegram_bot.py:* Comunicación con el usuario.

*lcd_display.py:* Controlador del display.

*alerts.py:* Gestión de alertas y registros.

_

_

h2=. Módulos Implementados

p=. Durante el desarrollo se implementaron los siguientes módulos independientes:

p=. *Módulo de Acelerómetro:* Lectura del sensor GY-6500/9250.

*Módulo de Cámara y Lectura de QR:* Uso de OpenCV para validación.

*Módulo Bot de Telegram:* Uso de librerías `telegram` y `telethon` para comunicación bidireccional.

*Módulo Display LCD:* Visualización de estados.

*Módulo de Alertas:* Captura de fotos y notificaciones.

*Módulo Central:* Coordinación del flujo completo (detección -> validación -> acción).

_

_

---

_

_

h1=. Reporte de Revisión

Durante el desarrollo del proyecto, se realizaron diversas pruebas evaluando partes específicas del sistema. A continuación se detallan los resultados:

h3. Prueba de Integración de Hardware y Software

* *Objetivo:* Validar el ciclo completo de operación visualizando la ejecución en el monitor.

* *Resultados:*

** La generación del código QR mediante el módulo "bot-funatron" operó correctamente.

** *Fallo Detectado:* Durante la validación de escaneo, el sistema no reconoció la cámara, resultando en ausencia de señal.

** *Diagnóstico:* Tras el desmontaje, se identificó una conexión deficiente del módulo de la cámara.

** *Solución Aplicada:* Se restableció la conexión física y se reforzó la sujeción del componente para prevenir desconexiones por vibraciones[cite: 512, 513, 514, 515, 516].

h3.  Segunda Prueba: Validación de Sensores y Lógica de Estado

* *Objetivo:* Validar el escaneo QR y el algoritmo de detección de estado (encendido/apagado) mediante el acelerómetro.

* *Resultados:*

** El escaneo QR funcionó correctamente.

** *Fallo Detectado:* La variable de sensibilidad del acelerómetro (programada para aumentar cada 4 segundos) se estancaba en el valor 1 y no acumulaba valor ni se reiniciaba.

** *Diagnóstico:* Error de sintaxis en el código. Se implementó una asignación directa (@v=+1@) en lugar de un incremento (@v+=1@).

** *Solución Aplicada:* Corrección de sintaxis. Se verificó que la variable incrementara y se restableciera correctamente tras el ajuste[cite: 519, 520, 521, 522, 523, 524].

_

_

---

_

_

h1=. Problemas encontrados y soluciones propuestas

A continuación se describen los obstáculos técnicos y de diseño enfrentados y sus respectivas soluciones.

h3. Tamaño insuficiente de la carcasa Raspberry

* *Problema Identificado:* Se detectó un error de medición en el diseño para la impresión 3D, resultando en una carcasa donde la Raspberry Pi no encajaba en ciertas esquinas por falta de holgura[cite: 527, 529, 530].

* *Solución Propuesta:* Ajuste manual utilizando un cúter y un encendedor para fundir y remover el material plástico excedente en las secciones conflictivas.

* *Resultado:* El dispositivo logró encajar de manera funcional, aunque se considera una medida temporal[cite: 532, 533, 537].

h3. Aplicación innecesaria

* *Problema Identificado:* Se evaluó que el desarrollo de una aplicación móvil nativa era innecesario dada la simplicidad de las funciones requeridas (generar QR y emitir reportes)[cite: 540].

* *Solución Propuesta:* Cambio de estrategia tecnológica hacia un *Bot de Telegram* (recomendación docente).

* *Justificación:*

** Permite ejecutar funciones de manera más directa.

** Reduce significativamente la complejidad y tiempo de desarrollo.

** Ofrece una experiencia fluida sin obligar al usuario a instalar apps adicionales[cite: 541, 542, 544, 546, 547].