Arquitectura · Vídeo
Analógico o digital: cómo sacamos el vídeo del dron
Sacar la imagen de un dron hacia el exterior se puede hacer de dos formas radicalmente distintas, con implicaciones directas en el retardo con el que llega esa imagen. Aquí explicamos por qué elegimos vídeo digital, y cómo lo llevamos desde la cámara hasta cualquier pantalla que quiera verlo.
Dos formas de transmitir vídeo
Vídeo digital o VTX analógico
A la hora de sacar la imagen de un dron hacia el exterior existen, en esencia, dos familias de transmisión completamente distintas — y la elección entre una y otra no es una cuestión de preferencia técnica menor: tiene un impacto directo en el retardo (latencia) entre lo que ve la cámara y lo que ve quien lo supervisa.
Vídeo digital (TCP/IP)
La imagen se captura digitalmente, se comprime en un formato de vídeo (H.264 y similares) y se envía como paquetes de datos por WiFi, 4G/5G o cualquier red IP — el mismo tráfico que una videollamada o un vídeo de Internet.
VTX analógico
La señal de la cámara se envía tal cual, como una onda analógica de radiofrecuencia, directamente desde un transmisor de a bordo a un receptor en tierra — sin digitalización, compresión ni red de datos de por medio.
Glosario rápido
VTX
Video Transmitter: el módulo de radio que monta un dron para enviar vídeo analógico en directo a un receptor en tierra (unas gafas o una pantalla FPV). No pasa por WiFi, 4G ni ningún protocolo de red — es una señal de radiofrecuencia pura, tan simple como sintonizar un canal.
Por qué el retardo es tan distinto
Sin apenas etapas, frente a una cadena de procesamiento
La transmisión analógica no necesita ningún procesamiento intermedio: la señal eléctrica que sale de la cámara viaja, se modula en radiofrecuencia y se demodula al otro lado prácticamente a la velocidad de la luz. La digital, en cambio, atraviesa varias etapas — y cada una añade algo de retardo.
VTX analógico
Del orden de 1 a 5 milisegundos de extremo a extremo — casi ninguna etapa que atravesar.
Vídeo digital
Fácilmente varios cientos de milisegundos, o incluso segundos si la red va cargada.
La analogía del fútbol: TDT frente a streaming
Es el mismo fenómeno que mucha gente ha vivido viendo un partido: la señal de TDT tradicional —una emisión de radiofrecuencia, conceptualmente parecida a la vía analógica— suele llegar antes que la misma señal servida por una plataforma de streaming por Internet, que necesita codificar, empaquetar y enviar el vídeo por una red de datos. Durante los últimos Mundiales de fútbol no ha sido raro que un vecino grite el gol varios segundos antes que otro que lo ve por una plataforma distinta — diferencias de 3 a incluso 10 segundos, según cuántas etapas de procesamiento atraviese la señal en cada caso. Es exactamente el mismo principio que se aplica al vídeo de un dron.
Por qué el FPV racing usa VTX analógico
Cuando cada milisegundo importa
En el vuelo FPV de carreras, el piloto controla el dron exclusivamente a través de lo que ve en las gafas, a velocidades donde una reacción tardía de solo unos cientos de milisegundos puede significar chocar contra un obstáculo. Por eso ese mundo sigue apostando por VTX analógico: no porque la imagen sea de mejor calidad (de hecho es peor, con más ruido y menos resolución), sino porque el retardo es prácticamente nulo. Para pilotar en tiempo real a alta velocidad, esa diferencia de latencia importa mucho más que la calidad de imagen.
Nuestro caso
Edge computing e IA, no pilotaje FPV
Nuestro planteamiento es estructuralmente distinto al de un dron de carreras, y por eso la solución técnica también lo es.
La cámara no va conectada directamente a un transmisor VTX para que un piloto la vea en gafas en tiempo real: va conectada a la Raspberry Pi, que procesa la imagen a bordo (edge computing) con el acelerador Hailo-8 para detectar personas — en el propio dron, sin depender de ningún enlace externo para tomar esa decisión. Esto cambia por completo el problema: el vídeo que enviamos a tierra no es la señal de la que depende el control del dron en tiempo real —eso va por el enlace de telemetría independiente, ver Comunicaciones—, sino una copia para supervisión humana, que sí puede permitirse el retardo de una vía digital.
Barajamos montar además una cámara analógica con su propio VTX, pero finalmente hemos optado por una única cámara digital conectada a la Raspberry Pi: nuestro objetivo es la detección automática a bordo, no el pilotaje manual en tiempo real, así que no hemos necesitado esa complejidad adicional. La puerta queda abierta a instalar un VTX en el futuro si algún día hiciera falta vídeo de latencia mínima además del procesado por IA — por ejemplo, con una segunda cámara analógica independiente.
Cómo transmitimos en la práctica
Grabación local a máxima calidad, streaming reducido
La Raspberry Pi hace dos cosas con cada fotograma detectado: lo graba en el propio dron a su resolución original, sin ninguna reducción de calidad, y en paralelo empuja una copia a un servidor de streaming en la nube.
Esa copia en directo viaja reducida a 640×360, a 12 fotogramas por segundo y unos 400 kbps — pensada para caber cómodamente en un enlace 4G limitado, no para verse con calidad de estudio. El servidor es MediaMTX, sobre la misma infraestructura de AWS que el resto del stack. Si el streaming se cae, la detección y la grabación local siguen exactamente igual: está diseñado como un extra, nunca como una dependencia.
Raspberry Pi · a bordo del dron
AWS Cloud
Por qué un servidor de streaming, no el dron directamente
Una sola copia, cuantos espectadores hagan falta
Conectarse directamente a la Raspberry del dron exigiría conocer su dirección IP en cada momento — nada trivial cuando el dron sale a Internet por una tarjeta 4G sin IP fija, detrás del NAT del operador.
Y aunque se resolviera con una red privada como Tailscale (ver Comunicaciones), si varias personas se conectaran a la vez directamente a la Raspberry, sería ella —con su CPU y su enlace 4G limitados— quien tendría que generar una copia del streaming por cada espectador, arriesgando saturar tanto el vídeo como la propia detección de IA a bordo. Un servidor de streaming en la nube resuelve ambos problemas: la Raspberry solo empuja una única copia hacia MediaMTX, y es el servidor —con recursos de sobra— quien reparte el vídeo a cuantos espectadores se conecten, sin que eso afecte en absoluto al dron.
Ese último tramo, del servidor al navegador, no puede ser el mismo RTSP que publica el dron: un navegador no reproduce RTSP directamente. Se evaluó primero HLS, pero se descartó por introducir varios segundos de retardo, inaceptables para supervisar un dron en vuelo. MediaMTX redistribuye en su lugar el vídeo al panel web mediante WebRTC, con una latencia inferior a un segundo desde la cámara hasta la pantalla del operador.
Lo que vimos en vuelo real
El vídeo en directo se cortó por encima de unos 10 metros
En la demostración del sistema integrado en vuelo, el enlace de datos 4G/LTE se mantuvo con el dron en tierra y a baja altura, pero la retransmisión de vídeo en directo (RTSP al servidor en la nube) se interrumpió al alcanzar unos 10 metros de altura. Al ser un flujo en tiempo real sin almacenamiento intermedio, no hubo imagen remota durante ese tramo.
La grabación local en la Raspberry Pi, en cambio, siguió sin problemas: los datos de los cuatro dominios, incluidos los eventos de detección generados durante la pérdida de enlace, se guardaron en el buffer local de SQLite y se sincronizaron íntegros con InfluxDB al recuperar la conexión tras el descenso, conservando sus marcas de tiempo originales. Fue la primera confirmación en vuelo real del mecanismo de store-and-forward, que hasta entonces solo se había probado con un corte de red forzado en banco (ver Datos e IoT).
La causa exacta aún no está identificada
Podría deberse a interferencias electromagnéticas por la cercanía del módem a otro componente, a una orientación desfavorable de la antena en el fuselaje, a la reelección de celda o a un ancho de banda de subida insuficiente. También es posible que fuera un fallo puntual de la línea de datos del módem USB —una caída de la sesión de datos— y no un problema de cobertura celular en altura: la literatura sobre drones conectados a redes móviles describe esa degradación a alturas de unos 170 metros, muy por encima de los 10 metros de este ensayo, donde el dron todavía está dentro del lóbulo principal de las antenas cercanas. Queda pendiente repetir la prueba, incluso con otro operador de telefonía, para saber si el comportamiento depende de la red o del propio módem.
El visor vive en la propia PWA: ese vídeo en directo no hace falta verlo en una herramienta aparte. El panel de control —la PWA que se explica en Software & Cloud— tiene el visor integrado en su grupo «Cámara», junto con los botones para empezar y detener la grabación: la misma acción que arranca o para la detección en la Raspberry Pi.
Cada captura deja rastro: el vídeo en directo, a menor calidad, es una comodidad para la supervisión humana — nunca una dependencia crítica, porque la detección y el registro completo ya han ocurrido a bordo antes de que un solo fotograma salga del dron. Cada vez que YOLO detecta a una persona, la foto de ese fotograma se guarda siempre en el propio dron a máxima calidad, y junto con la alerta se envía por MQTT el nombre de ese fichero —no la imagen en sí, solo la referencia—, un dato ligero que cabe cómodamente en un enlace pobre. Esa alerta, con la posición del dron y la caja de la detección, sigue el mismo camino ya descrito en Datos e IoT: se guarda primero en un buffer local (store-and-forward) y acaba en InfluxDB, donde puede consultarse a posteriori.