Saltar al contenido
Guardian EyeTFG · Telecomunicaciones
Pasillo de racks de servidores en un centro de datos

Arquitectura · Software & Cloud

Python, MAVLink y una pila cloud propia

Cuatro procesos independientes, cada uno responsable de un dominio de datos, publican por MQTT hacia un backend Flask en AWS que almacena la telemetría en InfluxDB.

Por qué MQTT y no HTTP

Un protocolo pensado para redes que fallan

MQTT es un protocolo de mensajería ligero, del tipo publicación/suscripción: cada proceso publica sus datos en un 'topic' (un canal con nombre) y cualquiera interesado se suscribe a él, sin necesidad de conocerse entre sí. A diferencia de una petición HTTP tradicional, está diseñado para redes inestables o de bajo ancho de banda — exactamente el escenario de un dron con conectividad 4G intermitente en el campo.

sensor.py

Lee el BME680 (I2C) y publica en dronsar/{dron_id}/ambiental.

sistema.py

Estado de la Raspberry Pi: CPU, RAM, disco, temperatura, uptime.

vuelo.py

Telemetría de vuelo vía MAVLink, validada primero contra ArduPilot SITL con pymavlink.

deteccion.py

Inferencia YOLO sobre la cámara y publicación de alertas de persona detectada.

Cada proceso corre como un servicio systemd independiente con su propia base de datos SQLite local: si la red falla, los datos se guardan y se reenvían en cuanto vuelve la conexión (patrón store-and-forward). systemd es el gestor de servicios de Linux: si un proceso se cae, lo reinicia automáticamente sin intervención manual, algo esencial para un sistema que opera sin supervisión constante en el campo.

Flujo de datos: del sensor al panel de control

SensorBME680 vía I2C
MQTTMosquitto, puerto 1883, QoS 1
Puentemqtt-to-influx en el servidor
InfluxDBSeries temporales por dominio
PanelPanel de control web

AWS EC2 + Flask

Instancia t3.small dentro de una VPC. Flask expone una API REST tanto para comandos de vuelo como para reconfigurar en caliente cada colector (por ejemplo, cambiar el intervalo del sensor) sin reiniciar procesos.

MQTT · Mosquitto

Broker autoalojado en el EC2, puerto 1883, QoS 1 (el mensaje se entrega al menos una vez, con confirmación). Jerarquía de topics dronsar/{dron_id}/{dominio}, con comodines como dronsar/+/deteccion.

InfluxDB

Base de datos de series temporales: cada dominio se guarda como una measurement, con el identificador del dron como tag indexado — pensada específicamente para datos con marca de tiempo de alta frecuencia, a diferencia de una base de datos relacional genérica.

nginx + Cloudflare

Proxy inverso que sirve el panel de control web y gestiona HTTPS, con Cloudflare como DNS sobre el dominio del proyecto.

Código abierto

Los tres repositorios del stack están publicados en GitHub — ver detalle en Impacto y futuro.

Está previsto ampliar el panel con análisis semántico sobre las detecciones apoyado en modelos de lenguaje en la nube (AWS Bedrock) — es una línea de trabajo futura, no una funcionalidad ya validada.