Registro cronológico del trabajo realizado en el desarrollo del sistema de búsqueda y rescate basado en UAV.
El proyecto tiene ya resuelta toda la base sobre la que se construirá el resto del sistema. Está cerrada la parte normativa —certificado de piloto A1/A3 y número de operador AESA— y el acceso a un espacio de vuelo seguro, gracias a la federación en el club Alas de Galapagar, cuya licencia de socio incluye el seguro obligatorio. He realizado además un primer vuelo de referencia, cuyo registro GPS me sirve para planificar misiones en simulación.
En el plano técnico, la infraestructura extremo a extremo está operativa: el nodo edge (Raspberry Pi 5 con el sensor ambiental BME680) publica sus lecturas por MQTT hacia el servidor en la nube (AWS EC2 con Mosquitto e InfluxDB), con almacenamiento intermedio local para no perder datos ante cortes de red. El dominio y los servidores web están en marcha, y tanto las páginas como los servicios dinámicos (API REST e InfluxDB) se sirven ya por HTTPS con certificado propio, accediéndose a estos últimos a través de un reverse proxy en nginx que permite mantener cerrados sus puertos al exterior.
En cuanto al vuelo, he llevado el control autónomo de la simulación a la Raspberry Pi: la Pi comanda el dron simulado (Mission Planner + ArduPilot SITL) por MAVLink a través de la red. Sobre esa base he montado el control por MQTT —un publicador en el EC2 y un receptor en la Pi que traduce las órdenes a MAVLink— y una API REST con una página de botones para teleoperar el dron (armar, despegar, aterrizar, RTL, misión) desde el navegador, ya validada contra el simulador. Tanto la API como el receptor se ejecutan como servicios systemd, de modo que arrancan solos y se reinician ante cualquier interrupción.
El repositorio del servidor se ha reorganizado por carpetas para separar las páginas web, el panel de control y la API, y se trabaja ahora sobre una rama develop que mantiene la rama principal con la versión estable. El fallo de la tarjeta microSD que dejó temporalmente fuera de servicio a la Raspberry Pi está resuelto, se ha sustituido y repetido la instalación de la imagen, además de realizar nuevamente el script del receptor, ya que no estaba subido dicho código
Próximos pasos: montar el dron definitivo, estoy a la espera respuesta correos, COMPRAR MATERIALES; y desplegar la detección de personas por visión artificial (YOLO sobre el acelerador Hailo-8L), parte en la que ya he comenzado a trabajar con Roboflow (construcción del dataset y entrenamiento del modelo en local). Queda pendiente incorporar autenticación a la API y cifrado al canal MQTT antes de conectar la cadena de mando a la aeronave real.
1883 para la comunicación MQTT con el broker Mosquitto, puerto 22 para SSH y puerto 8086 para el acceso a la base de datos InfluxDB.sensor.py en la Pi y mqtt_to_influx.py en la EC2.sensor.py para que ningún dato se pierda ante una caída temporal de la conexión (cada lectura se almacena primero en una base de datos local SQLite, buffer.db).mqtt_to_influx.py actúa como cliente suscriptor; se ejecuta en la EC2 dentro de un entorno virtual propio (env) con las librerías paho-mqtt (comunicación con el broker) e influxdb-client (escritura en la base de datos).8086, de forma que se pueda acceder desde el navegador mediante la dirección pública de la EC2..gitignore (evita subir archivos sensibles o innecesarios), requirements.txt (dependencias reproducibles) y .env.example (plantilla de credenciales, que se mantienen fuera del repositorio).
gorostiditfg.com en Cloudflare 10,41 $, para acceder a los servicios mediante subdominios legibles en vez de la IP del servidor.www.gorostiditfg.com y control.gorostiditfg.com.8086 en la petición HTTP, había que indicarlo y ya no es necesario especificarlo → influxdb.gorostiditfg.com..ssh en la EC2 para permitir el acceso con mi clave pública en lugar del .pem (habilitando esta otra forma editando el .ssh).14550.8086 del grupo de seguridad de la EC2, ya innecesario: el acceso a la interfaz de InfluxDB se realiza ahora a través de nginx configurado como reverse proxy (influxdb.gorostiditfg.com), sin exponer el puerto directamente a internet.127.0.0.1, el reenvío UDP y el puerto 14550.udpin/udpout) y por qué en MAVLink la Pi escucha mientras recibe la telemetría del autopiloto.comandos.py, en el EC2) que envía las órdenes por MQTT, y de un receptor (receptor.py, en la Pi) que las traduce a MAVLink y las ejecuta sobre el dron simulado.api.py, en el EC2) para poder invocar los comandos por HTTP en lugar de por terminal, y para ello se ha abierto el puerto 5000 en el grupo de seguridad de AWS.api.py) para entender no solo qué hace, sino por qué existe y qué papel tiene dentro de la arquitectura. Se ha revisado la cadena completa de comunicación: navegador (HTTP) → api.py en el EC2, que traduce HTTP a MQTT → broker Mosquitto (puerto 1883) → receptor.py en la Raspberry Pi, que traduce MQTT a MAVLink → autopiloto → dron.
api.py y receptor.py no están conectados directamente: se comunican a través del broker, gracias al modelo publicador/suscriptor desacoplado de MQTT.comandos.py y api.py son alternativas paralelas para enviar los mismos comandos, no pasos consecutivos.5000 y Mosquitto en el 1883. receptor.py no abre ningún puerto porque actúa como cliente, no como servidor.Ctrl+C incompleto. Resuelto con pkill -f api.py.api.py y receptor.py en servicios systemd, igual que ya lo están mqtt_to_influx.py y sensor.py, para que arranquen solos y no dependan de una terminal abierta. PENDIENTE443 en el grupo de seguridad del servidor.api.gorostiditfg.com en Cloudflare en modo Proxied, configurar nginx como reverse proxy hacia localhost:5000 y actualizar la URL del fetch en el JavaScript del panel. PENDIENTEwww/web/, control/ y api-rest/) e incluyendo las páginas HTML, que hasta ahora solo existían en el servidor.sudo poweroff. Se ha intentado volver a cargar la imagen de Raspberry Pi OS en la tarjeta y no es capaz de leerla.sudo poweroff y mantener todo actualizado en GitHub, para no perder los códigos ni el trabajo hecho hasta el momento.receptor.py, único script que no estaba subido al repositorio y que se perdió con la tarjeta.api.gorostiditfg.com, configurado nginx como reverse proxy hacia localhost:5000, emitido el certificado TLS y actualizada la URL del fetch en el panel de control.receptor.py en la Raspberry Pi y para api.py en la instancia EC2, de forma que ambos arranquen automáticamente y se reinicien ante cualquier interrupción, sin depender de una sesión SSH abierta.best.pt).patience=20); la métrica de validación se estabiliza en torno a la época 40, por lo que ese número resulta suficiente para la convergencia.output.mp4. La he probado tanto con un vídeo grabado con el móvil como con uno grabado desde el dron.