Arquitectura · Datos e IoT
Sensores, brokers y MQTT: por qué el dron piensa como un sistema IoT
Software & Cloud explica qué corre a bordo — cuatro procesos Python, MQTT, InfluxDB. Esta página explica por qué está diseñado así: el objetivo de sensorizar el dron sin depender de que la red funcione siempre, y cómo hemos llevado esa idea más allá de un IoT tradicional.
Un objetivo del proyecto
Sensorizar el dron sin depender de que la red funcione siempre
Uno de los objetivos de Guardian Eye era dotar al dron de sensores propios, capaces de transmitir información sobre su entorno y su propio estado — no solo volar y grabar. Pero un dron real, y más aún en un entorno rural con cobertura 4G intermitente, es de los peores sitios posibles para dar por sentado que una conexión va a funcionar.
En Comunicaciones ya se explica el enlace múltiple redundante que construimos para que el dron siempre tenga una vía de vuelta a tierra. Pero una base de comunicaciones robusta no basta por sí sola: siendo conscientes de que hasta el mejor enlace puede fallar, quisimos reforzar también esta capa aplicando los conceptos clave de las comunicaciones IoT — un broker de mensajería, el protocolo MQTT, y un procedimiento de store-and-forward que evita perder datos cuando la red falla a mitad de camino.
Glosario rápido
Broker
Un intermediario de mensajería. Los procesos no se hablan entre sí directamente: publican en un canal (topic) y el broker se encarga de entregarlo a quien esté suscrito.
MQTT
El protocolo ligero de publicación/suscripción que habla con el broker — pensado específicamente para redes inestables o de bajo ancho de banda, no para una conexión siempre estable.
Store-and-forward
Cada dato se guarda primero en local y se reenvía cuando hay conexión confirmada. Si la red cae a mitad de camino, no se pierde nada: solo llega más tarde.
Detalle completo del broker (Mosquitto), la jerarquía de topics y el resto de la pila cloud en Software & Cloud.
Más allá de un IoT tradicional
No solo sensores hacia un panel
En un proyecto IoT típico, el broker existe solo para mover lecturas de sensores hacia una base de datos que después se consulta en un panel: sensores → MQTT → InfluxDB → Grafana. Guardian Eye parte de esa misma base, pero la hemos llevado más allá.
Información de vídeo
Además de telemetría y datos ambientales, los procesos también publican información sobre las grabaciones que realiza el dron — no solo lecturas de sensores sueltas.
Localización de personas detectadas
Cada detección de YOLO se acompaña de la posición del dron en ese instante, para poder situar aproximadamente dónde se ha visto a una persona sobre el terreno.
Comandos hacia el propio dron
El canal no es de una sola dirección: el dron también se suscribe a un canal de comandos, por el que puede recibir instrucciones de alto nivel — iniciar una misión, aterrizar, empezar o detener una grabación — sin depender de una conexión directa punto a punto.
Los procesos que lo hacen posible
Cuatro procesos independientes, un mismo broker
Antes de entrar en el detalle del pipeline de detección (más abajo, el más completo de los cuatro), así es como los cuatro procesos conviven alrededor del mismo broker: cada uno publica en su propio dominio, de forma independiente del resto.
Los cuatro publican de forma independiente al mismo broker; desde ahí, un puente (mqtt_to_influx.py) los inserta en InfluxDB — detalle completo en Software & Cloud.
sensor.py
Lee el sensor ambiental (BME680) y publica temperatura, humedad y calidad del aire — pensado para detectar indicios como humo de un incendio incipiente o condiciones extremas.
sistema.py
Publica el estado de salud de la propia Raspberry Pi — CPU, memoria, temperatura, tiempo de actividad — para poder detectar en remoto si el equipo de a bordo empieza a fallar.
vuelo.py
Publica la telemetría de vuelo obtenida vía MAVLink: posición, altitud, velocidad y estado de la misión.
deteccion.py
Ejecuta YOLO sobre el vídeo en directo y publica cada detección de persona junto con la posición del dron en ese instante.
Los cuatro procesos son independientes entre sí — cada uno con su propio ciclo, y si uno falla, los demás ni se enteran. La única excepción es detección, que necesita saber en qué posición estaba el dron en el instante exacto de cada detección: esa coordinación ocurre dentro de la propia Raspberry Pi, entre procesos que conviven en el mismo equipo, sin pasar por la red ni por el broker.
No todos son solo emisores: tres de los cuatro (sensor.py, sistema.py, deteccion.py) también se suscriben a su propio topic de configuración, para cambiar su comportamiento en caliente desde el panel de control — el intervalo del sensor ambiental, el throttling del vídeo, empezar o parar una grabación, o apagar la propia Raspberry Pi (lo gestiona sistema.py, no un proceso aparte). Solo vuelo.py es puramente emisor.
Los comandos de navegación del dron —armar, desarmar, iniciar una misión, volver a casa— van por un canal aparte, hacia un quinto proceso dedicado: receptor.py se suscribe al topic de comandos de su dron y los traduce en órdenes MAVLink para el autopiloto, sin pasar por ninguno de los cuatro procesos anteriores. De dónde vienen esos comandos (el panel de control, una PWA) está explicado en detalle en Software & Cloud.
De la cámara a la nube
El camino completo de una detección
De los cuatro procesos de arriba, este es el más completo — y el que mejor ilustra el store-and-forward en la práctica. La secuencia que atraviesan los dos lados del sistema, edge y servidor, cada vez que YOLO localiza a una persona.
Raspberry Pi · a bordo del dron
AWS Cloud
La detección se escribe primero en el buffer local (paso «Guarda en buffer local» arriba) — ese es el store-and-forward en la práctica. El broker en AWS solo confirma que ha recibido el mensaje; quien decide que ya está a salvo y marca el registro como enviado en su propio buffer es la Raspberry Pi, no el servidor. Si la red se corta en cualquier punto de la cadena — antes o después de esa confirmación —, el registro sigue en el buffer local y se reintenta al recuperar la conexión: la detección nunca se pierde, aunque llegue tarde.
Solo píxeles, no geolocalización
YOLO no entrega coordenadas geográficas: la alerta lleva la posición del dron más la caja en píxeles del fotograma. Estimar la posición real de la persona en el terreno exigiría georreferenciación (fusionar píxeles, altitud y actitud), que queda como línea futura — con la resolución de trabajo actual, ese cálculo tendría un margen de varios metros. Ver también las limitaciones descritas en Inteligencia Artificial.
Validable sin hardware
El flujo de detección se prueba con un vídeo real en CPU y una posición simulada; el colector de vuelo, contra el simulador SITL. El desarrollo avanza en paralelo a la compra y el montaje del hardware, siguiendo la misma filosofía de validación por etapas que Metodología.
Cómo lo hemos reforzado técnicamente
Tres principios que sostienen esta arquitectura
Toda la arquitectura de datos de Guardian Eye se apoya en tres ideas. No son teoría: cada una responde a un problema real de operar un dron en el campo, con red intermitente.
Edge-first
El nodo opera de forma autónoma y la conexión con tierra es oportunista, no obligatoria: el dron captura y registra siempre, y envía cuando puede. Esencial en SAR, donde la cobertura de red es incierta.
Store-and-forward
Captura y envío van desacoplados. Cada medida se guarda primero en local — la fuente de verdad — y se reenvía cuando hay conexión confirmada. Si la red cae, no se pierde ningún intervalo.
Productor-consumidor
Quien captura los datos y quien los envía no se hablan directamente, sino a través de un buffer local. Ese desacoplamiento permite que la captura no se detenga aunque falle el envío.
MQTT, bridges y nuestro store-and-forward
MQTT bridge: la solución lógica — y por qué construimos la nuestra
MQTT, con su paradigma de publicación/suscripción, encaja perfectamente en un sistema donde las comunicaciones pueden fallar. Cuando además hace falta persistir los datos y reintentar el envío al recuperar la conexión, la respuesta más lógica a priori es un MQTT bridge: dos brokers, uno a bordo del dron y otro en la nube, unidos por un puente que trae esa persistencia y esos reintentos de fábrica.
En esta arquitectura, los procesos publicarían contra un broker que corre en la propia Raspberry Pi, no contra uno remoto. Ese broker local mantendría la conexión con el broker de AWS mediante una configuración de bridge — una función nativa de Mosquitto — que reenvía los topics indicados en cuanto hay red, y se encarga él mismo de reconectar si la conexión se cae.
Raspberry Pi · a bordo del dron
AWS Cloud
Sin embargo, en Guardian Eye hemos preferido construir nuestra propia versión de esa persistencia y esos reintentos, en vez de apoyarnos en la función de bridge nativa de Mosquitto: cada proceso guarda sus propios datos en un buffer local (SQLite) y los reenvía él mismo en cuanto el broker confirma la recepción — el store-and-forward que ya se explica en el diagrama de más arriba (guardar → publicar por MQTT → marcar como enviado solo si hay confirmación), hecho a medida en Python en cada proceso, en lugar de delegarlo en la configuración de un bridge.
La ventaja se nota sobre todo pensando en escalar: si en vez de un único dron llegamos a gestionar un escuadrón de varios, esta arquitectura sigue siendo mucho más sencilla de administrar — un solo broker central en AWS, en vez de un broker adicional por cada dron. Y tenemos más control sobre los datos de cada uno: podemos consultar directamente el SQLite local de cualquier dron para comprobar exactamente qué ha enviado y qué no, en vez de depender del estado interno de un bridge al que no tendríamos ese mismo acceso directo.