Challenge #1 - G-Corzo/DetectorNivelAgua GitHub Wiki

Para acceder a la pagina del Challenge #2, haz click aqui

Monitoreo IoT para la Gestión del Agua en Sabana Centro (Challenge #1)

Asignatura: Internet de las Cosas | Universidad de La Sabana
Integrantes: Samuel Borda Munevar, Juan Jose Gomez Saavedra, Gabriel Alejandro Corzo Fernandez
Video Demostrativo: Video Demostrativo

Resumen Ejecutivo

Este documento describe un prototipo funcional de un sistema IoT de bajo costo diseñado para monitorear la disponibilidad y escasez de agua en puntos críticos de suministro y almacenamiento en la región Sabana Centro, Cundinamarca. El sistema busca alertar rápidamente a la comunidad y autoridades locales ante niveles de desabastecimiento o sequía peligrosos provocados por el Fenómeno de El Niño.

🌎 1. Contextualización y Motivación 🌎

Contexto Climático

  • La confirmación oficial del inicio anticipado del Fenómeno de El Niño ha extremado drásticamente las vulnerabilidades ambientales y climaticas de todas las regiones del mundo, generando varias sequias y desbordamiendo de cuerpos de agua por nuevos rangos extremos de rocio; aunque Colombia aun no ha declarado oficialmente de estar debajo de los efectos de El Niño, el concenso general de la poblacion es que se encuentra en efecto, incluso si es un efecto leve.

Justificación

  • Existe una falta de herramientas comunicantes de informacion tanto de un cuerpo de agua como el entorno alrededor de este; no solo esto, pero existe una necesidad de un despliegue rapido, sencillo y economico para las comunidades involucradas, que funcione en varios entornos no estables / caoticos o que no se pueden evaluar en un tiempo razonable.

Pregunta Guía

  • ¿Cómo diseñar un sistema IoT que mida y analice en tiempo real el nivel del agua, la evaporación potencial y variables meteorológicas locales en la región Sabana Centro (Cundinamarca), que combine múltiples señales ambientales críticas mediante lógica de fusión para generar alertas válidas y emita alertas tempranas In-Site a las autoridades locales de manera efectiva, sin el uso de redes de comunicación convencionales?

🏁 2. Requisitos y Restricciones de Diseño 🏁

Restricciones de Hardware

  • La unica restriccion presente para el proyecto es la utilizacion de un microcontrolador embebido en el dispositivo final desarrollado, inmediatamente descartando el uso de un Raspberry Pi, debido a su precio por unidad individual.

Notificación In-Site

  • Debe incluir una alarma física configurada para notificar sobre metricas fuera de sus valores de rango normales / esperados. La comunicacion de esta puede ser por cualquier medio (visual, auditiva, etc), pero no puede utilizar redes de comunicaciones externas a las conexiones de sensores y accionadores presentes en el dispositivo, es decir, nada digital.

Matriz de Diseño

  • Las restricciones por las cuales se genera la matriz de diseño del proyecto dependen de:
  • Tecnicas: El codigo final del dispositivo debe ser facil de desplegar, ligero para correr eficientemente en el dispositivo elegido, y facil de modificar para establecer nuevos niveles de alerta o nueva informacion a ser comunicada.
  • Economicas: Se debe tener los costos de desarrollo y despliegue como la segunda prioridad debajo de funcionalidad, ya que el dispositivo debe funcionar en partes remotas y en pueblos con presupuestos pequeños, junto a considerar el tamaño del equipo de desarrollo. Junto a esto, se debe tener en cuenta para la escalabidad de el sistema, como tener varios puntos de despliegue en el mismo cuerpo de agua, o monitoreos de multiples cuerpos simultaneos.

🏗️ 3. Arquitectura del Sistema y Diseño Teórico 🏗️

Diagrama de Arquitectura

Imagen de Diagrama de Arquitectura

Diseño Teórico Modular

Criterios de Diseño:

  • Funcional: El modelo debe cumplir con todos los requerimientos de funcionalidad propuestos, no se debe omitir ninguna parte para el beneficio de todos los involucrados.
  • Compacto: El modelo debe ser compacto para obtener los mejores beneficios de utilizar un microcontrolador embedido.
  • Economico: El modelo debe ser facil de financiar y producir en masa, tanto para el beneficio del equipo de desarrollo como para el beneficio de las entidades buscando implementar el modelo a su funcionamiento diario.
  • Los diagramas de la solucion propuesta se encuentran en la carpeta de "DOCUMENTACION", accesible por este hipervinculo

Estándares y Viabilidad

  • No se aplicaron ningun estandard normalmente implementado para estos proyectos (IEEE), debido a la naturaleza del problema resuelto y el equipo de trabajo; el problema es altamente variable, y el equipo esta desarrollando el proyecto con tiempo y recursos altamente limitados, limitando los estandares a seguir
  • La viabilidad del diseño propuesto es alta, su fabicracion compone de componentes baratos y faciles de conectar, no sacrifica funcionalidad y es extremadamente compacto.

⚙️ 4. Simulación y Configuración Experimental (Wokwi) ⚙️

Plataforma de Simulación

  • Se utilizo la plataforma Wokwi para la fase de simulaciones y validacion del funcionamiento teorico del circuito, otorgando una plataforma de seguridad para empezar con el desarrollo fisico del dispositivo. Las simulaciones, junto al codigo del proyecto, queda en la carpeta de "CODIGO Y SIMULACIONES"

Configuración

  • Se configuro mediante el codigo dentro del ESP32, donde automaticamente hace toda la traduccion de voltajes, procesamiento de datos obtenidos, y activaciones de actuadores externos, en nuestro caso, alarmas fisicas. Los valores de activacion del dispositivo actualmente son placeholders, y modificables solo por codigo.

📋 5. Resultados, Análisis y Protocolo de Pruebas 📋

Resultados y Análisis

  • Integracion: La integracion de los componentes del dispositivo resultaron faciles, con la mayoria de los componentes requiriendo modificacion / configuracion minima, y funcionando correctamente durante la primera prueba. El unico problema presentado fue la falla de la pantalla LCD integrada, requeriendo la integracion de un LCD externo para mostrar la informacion relevante.
  • Precision: Todos los componentes presentaron precision en la toma y envio de datos; tanto la precision de las metricas medidas, como el tiempo de respuesta y variabilidad.
  • Comportamiento: El sistema se comporta igual a como fue diseñado, sin ninguna irregularidad de comportamiento detectada durante las pruebas.

Protocolo de Pruebas

  • Para la realizacion de pruebas, se acerco gradualmente al cuerpo de agua simulado, viendo la respuesta del sistema supuesta contra la respuesta del sistema en practica.

👤 6. Gestión del Proyecto y Roles del Equipo 👤

Herramienta de Gestión

  • No se utilizo ninguna herramienta dedicada de gestion; solo se utilizo WhatsApp para la toma de decisiones del equipo de desarrollo.

Roles y Contribuciones

  • Samuel Borda: Asamblaje y testing del prototipo inicial
  • Juan Jose Saavedra: Desarollo del codigo de simulacion y codigo del prototipo inicial
  • Gabriel Corzo: Ideacion inicial, compra de materiales del prototipado y documentacion del dispositi

🤖 7. Uso de Inteligencia Artificial 🤖

  1. IA Consultada: Google Gemini Pro 3.1
  2. Registro de Prompts: "Este es un diagrama de un dispositivo detector del nivel del agua y otras variables ambientales, necesito que generes un diagrama de arquitectura en formato de codigo para ser pegado en LucidChart" -> "Ahora, necesito lo mismo para un diagrama en formato UML"
  3. Validación: Se verifico que todas las conexiones de los componentes coincidieran con las conexiones de la simulacion; ya que no se proporciono el codigo del programa a la IA, se reemplazo el nombre de las funciones y variables manualmente dentro del diagrama de UML.

🔜 8. Conclusiones y Trabajo Futuro 🔜

Conclusiones

  • El prototipo trajo resultados satisfactorios que cumplieron con los criterios de los objetivos establecidos de manera econommica, eficiente y facil para los involucrados, sin gran cantidad de errores o comportamientos inesperados. Es decir, el prototipo funciono bien, y como se esperaba. El equipo demostro capacidad organizacional y independiente al desarollar su rol asignado sin problema o complicacion mayor.

Retos Presentados

  • El mayor reto de los dos presentados durante el desarrollo fue la compra y entrega de componentes. Debido a que la mayoria de tiendas electronicas y mayoria de integrantes de grupo quedan extremadamente lejos uno del otro, se tuvo que hacer varios tiempos de reunion establecidos para poder entregar los materiales necesitados al resto de los integrantes.

Trabajo Futuro

  • Se tiene como trabajo futuro planteado la conectividad del dispositivo por fuera de su entorno fisico, con la conexion de un servidor en la nube y usuarios que puedan configurar el dispositivo remotamente.

📜 9. Anexos y Enlaces 📜

  • Código Fuente: Carpeta "CODIGO Y SIMULACIONES", ver guia de descarga para ejecutar el dispositivo
  • Esquemáticos y Material Extra: Carpeta "DOCUMENTACION", todos los componentes tienen sus esquematicos presentes, y se tiene una guia de asambleaje para el dispositivo
  • Video Demostrativo: Video demostrativo del sistema en funcionamiento
  • Acceso a la Wiki: Esta Wiki está alojada en GitHub y se encuentra en estado de acceso publico.