Proyecto · Metodología
Desarrollo en paralelo, validación por etapas
Electrónica, comunicaciones y software no se construyen uno detrás de otro: avanzan a la vez, y cada pieza se valida contra hardware y vuelo real antes de confiar en ella — nunca fiándolo todo a la simulación.
Metodología transversal
Tres frentes en paralelo, no en serie
Un desarrollo secuencial —primero toda la electrónica, luego todas las comunicaciones, luego todo el software— retrasaría la detección de problemas de integración hasta el final del proyecto. Por eso los tres frentes avanzan a la vez.
Electrónica (gestión de potencia y sensores), comunicaciones (4G, RF y telemetría) y software (Python, MAVLink y stack cloud) se desarrollan en paralelo y se validan en cuatro fases progresivas, de menor a mayor riesgo: simulación, banco de hardware en tierra, campaña de vuelo de la plataforma y, por último, vuelo del sistema completo integrado. Cada etapa reduce el coste de un fallo — un error de lógica detectado en simulación se arregla editando código; el mismo error, si aparece ya en vuelo, se mide en riesgo físico, no en horas de trabajo. Por eso ninguna etapa se salta, por mucho que ralentice el desarrollo.
1. Simulación SITL
Software In The Loop: el firmware de vuelo (ArduPilot) corre contra un dron simulado, enlazado con Mission Planner y con el origen fijado en el campo del club. Sirve para depurar la máquina de estados de la misión y los scripts de pymavlink sin arriesgar hardware.
2. Banco Semi-HITL
La Raspberry Pi 5 se conecta a la Pixhawk 6X real por UART (puerto TELEM3), sin hélices y con el dron sujeto. Se verifican el armado, el cambio de modos y la lectura de telemetría directamente sobre la electrónica del vehículo.
3. Campaña de vuelo
Pruebas físicas en el espacio autorizado del Club Alas de Galapagar (LECMUAV090, subcategoría A3). Primera parte: se revisan la sustentación, la estabilidad y el peso de la plataforma, con un MTOW real de 1.817 g medido en báscula.
4. Sistema integrado
Segunda parte de la campaña: un vuelo con el sistema completo a bordo — nodo edge infiriendo y grabando, enlace 4G y store-and-forward activos — para comprobar en condiciones reales lo validado antes por separado.
Nota de alerta
Latencia y ancho de banda no son intercambiables: un enlace de vídeo analógico o digital introduce retardo que un enlace MQTT, ligero y tolerante a redes inestables, no tiene. Elegir el protocolo correcto para cada tipo de dato es, en sí mismo, una decisión de ingeniería, no un detalle de implementación — y es parte de la misma metodología: validar cada decisión contra el comportamiento real de la red, no solo contra el caso ideal.
Validación temprana en campo
El 12 de julio de 2026 se realizó un primer vuelo real de referencia en el Club Alas de Galapagar, con el apoyo de José Manuel, para registrar un track GPS real y compararlo contra la simulación — la filosofía del proyecto es validar contra el vuelo real antes de confiar en el simulador, no al revés.
Resultados de la validación
Qué quedó comprobado, y con qué alcance
El objetivo de un prototipo no es demostrar que el sistema ya está listo para operar, sino que la arquitectura propuesta es técnicamente viable. Con ese criterio, la validación cubre todo lo definido en los objetivos del trabajo.
Cadena de mando
Validada de extremo a extremo en banco: panel PWA → API Flask en EC2 → MQTT por el túnel de Tailscale → receptor en la Raspberry Pi → MAVLink a la Pixhawk. Se confirmó la respuesta física de la controladora — encendido de los variadores, cambios de modo y avisos acústicos y luminosos de seguridad.
Comunicaciones
RC a 2,4 GHz y telemetría a 433 MHz verificados en vuelo real; el enlace 4G/Tailscale/AWS, en banco. El WiFi convencional de la Raspberry Pi, sin antenas específicas, solo alcanzó unos 20 m — por eso el 4G/LTE quedó fijado como canal permanente hacia la nube.
Plataforma IoT
Ingesta simultánea de los cuatro dominios en InfluxDB, cuadros de Grafana, y el mecanismo de store-and-forward probado con un corte de 4G forzado en banco y confirmado después ante una pérdida de enlace real en vuelo, sin perder ningún dato.
Detección en vuelo
La Raspberry Pi procesó el vídeo de la cámara a bordo e infirió en tiempo real sobre el acelerador Hailo-8: detectó a las dos personas que entraron en el campo de visión y generó las alertas. Hubo un falso positivo al inicio —esperable en una prueba de concepto, donde se prioriza el recall— y la imagen osciló por la vibración, lo que confirma la conveniencia de un gimbal de dos ejes.
Con una salvedad
El vuelo del sistema integrado se hizo alimentando la Raspberry Pi y el acelerador con una batería externa portátil, no desde la batería principal del dron: el regulador UBEC necesario para esa integración llegó sin margen para soldarlo antes del cierre del trabajo. La solución provisional sumó unos 400 g y redujo la autonomía, pero permitió validar el sistema completo dentro de plazo. La integración definitiva queda como deuda técnica.
| Objetivo del TFG | Estado |
|---|---|
| Análisis normativo y regulatorio SAR | Cumplido |
| Selección y montaje de la plataforma hardware | Cumplido |
| Diseño del sistema de comunicaciones y telecontrol | Cumplido — RC y telemetría en vuelo real; 4G/Tailscale/AWS en banco |
| Arquitectura IoT en la nube (AWS EC2) | Cumplido y validado en banco |
| Construcción y curación de dataset propio | Cumplido — 717 imágenes |
| Entrenamiento y optimización de YOLO en el borde | Cumplido a nivel de prototipo (prueba de concepto) |
| Validación integral del sistema completo | Cumplida — fases SITL, banco Semi-HITL y vuelo real |
Resumen de la matriz de cumplimiento de objetivos de la memoria (Tabla 9.1).