El controlador de vuelo ejecuta el lazo de vuelo de tiempo real estricto. El SBC auxiliar gestiona vídeo, enrutamiento, API y comunicaciones externas. Mission Control elige USB directo, una vía LAN o retransmisión remota sin mezclar sus responsabilidades.
El flujo de extremo a extremo se describe como arquitectura prevista; latencia y frecuencias siguen siendo referencias de diseño hasta que KairOS las mida.
Repositorio de KairOS ↗En esta página +
Dos ordenadores a bordo, responsabilidades distintas
El controlador de vuelo controla motores, estabilización, GPS y sensores. El ordenador auxiliar —Raspberry Pi, Radxa, Jetson u otro SBC Linux— ejecuta KairOS Drone Agent y no sustituye al FC: añade vídeo, retransmisión de telemetría, conexión en la nube, radio, API REST y extensiones.
En tierra, Mission Control funciona en el navegador. Puede acceder al FC directamente mediante WebSerial, a Drone Agent por LAN o a un retransmisor remoto mediante MQTT/Convex y señalización WebRTC. Ground Agent se añade en escenarios WFB-ng y convierte la recepción de radio en un entorno web local comprensible.
Ciclo completo de telemetría, comandos y vídeo
FC → Agente
MAVLink UART suele funcionar entre 115200 y 921600 baudios; el agente espera el heartbeat e identifica el firmware.
Agente → consumidores locales
El enrutador distribuye MAVLink sin procesar al socket IPC, WebSocket, servicio en la nube y estado de salud.
Agente → nube
El sistema previsto publica telemetría a unos 2 Hz y estado mediante vías HTTP/MQTT.
Cámara → navegador
La captura V4L2 pasa por codificación H.264, MediaMTX/RTSP y el transporte WHEP, WebRTC o WFB-ng elegido.
GCS → FC
Los comandos de armado, modo, misión y otros regresan por la misma vía seleccionada; el FC aplica las reglas previas al armado.
ACK → interfaz
La confirmación del comando y los nuevos heartbeat y estados regresan, tras lo cual la interfaz actualiza el estado.
USB directo, red local y P2P remoto
| Modo | Transporte | Cuándo usarlo | Referencia prevista |
|---|---|---|---|
| USB directo | WebSerial → FC; sin necesidad de agente | Banco, configuración, calibración y firmware | Objetivo de diseño <10 ms |
| LAN directa | REST :8080, MAVLink WS :8765, WHEP :8889 | Interiores, corto alcance, desarrollo y LAN de campo | Objetivo: vídeo 50–150 ms; telemetría <100 ms |
| P2P remoto | 4G/Internet, señalización SDP por MQTT, WebRTC y Convex | Observación remota y segunda vía | Objetivo: vídeo 100–300 ms; telemetría 2–5 Hz |
El transporte automático debe buscar primero una vía LAN durante unos cuatro segundos y después pasar a señalización P2P con una ventana aproximada de catorce segundos. Son intervalos de diseño: dependen de la red y no constituyen un SLA de KairOS.
El enrutador gestiona heartbeat, flujos y varios clientes
- El agente envía un heartbeat de ordenador auxiliar a 1 Hz con MAV_TYPE_ONBOARD_CONTROLLER.
- Tras recibir el heartbeat del FC, solicita actitud, GPS, batería, RC y sensores.
- Las solicitudes de flujos se repiten aproximadamente cada 30 segundos para tolerar reinicios o cambios de estado del FC.
- Puertos habituales: /dev/ttyS0, /dev/ttyUSB0, /dev/ttyACM*; el perfil de placa define la prioridad de búsqueda automática.
- El socket IPC /run/kairos/mavlink.sock transporta tramas binarias a otros servicios.
- Mission Control analiza MAVLink v2 con CRC; ArduPilot/PX4 usa MAVLink, mientras Betaflight/iNav usa MSP v1/v2.
Flight Controller UART
│
▼
kairos-mavlink router
├─ /run/kairos/mavlink.sock
├─ /run/kairos/state.sock
├─ WebSocket :8765
├─ TCP :5760 / UDP :14550
└─ optional cloud relayDe captura V4L2 a reproducción H.264 nativa
Captura
USB UVC o MIPI CSI se abre mediante V4L2; se verifican el formato y la resolución disponibles antes de iniciar.
Codificación
ffmpeg usa H.264 de perfil alto, nivel 4.1, yuv420p y opciones de baja latencia; se selecciona codificador por hardware cuando está disponible.
Publicación
El flujo codificado se publica en MediaMTX/RTSP y sirve como fuente para los transportes posteriores.
LAN
WHEP ofrece WebRTC directamente al navegador local.
Remoto
MQTT transporta la señalización SDP; después los medios viajan por WebRTC P2P o por retransmisor si es necesario.
Radio
wfb_tx envía H.264 mediante WFB-ng; Ground Agent lo recibe y vuelve a publicarlo localmente.
Las opciones nobuffer, low_delay y un tamaño de sondeo pequeño reducen la cola, pero la latencia real depende de captura, codificador, tasa de bits, FEC, radio, red y decodificación del navegador. KairOS publicará mediciones por perfiles concretos, no una cifra universal.
MQTT para tiempo real, Convex para estado y cola de comandos
El agente KairOS previsto publica telemetría en MQTT a unos 2 Hz. El puente MQTT-to-Convex agrega el estado con una espera de estabilización de unos tres segundos por dispositivo, mientras el navegador recibe consultas reactivas. Los comandos se escriben en Convex, el sondeo del agente recoge el elemento pendiente, lo convierte a MAVLink y devuelve el ACK.
Telemetry: FC → Agent → MQTT → bridge → Convex → Mission Control
Commands: Mission Control → Convex queue → Agent poll → MAVLink → FC
Video: Camera → Agent → MQTT SDP → P2P WebRTC → BrowserEl nodo de campo convierte la recepción de radio en interfaces locales
| Cliente | Vía |
|---|---|
| Portátil | Punto de acceso Wi-Fi, Ethernet o conexión compartida USB CDC-NCM |
| Teléfono / tableta | Navegador en la misma red local o línea Android de KairOS |
| Monitor de campo | HDMI + quiosco Chromium |
| Mission Control | Perfil de estación terrestre con fuentes de vídeo y telemetría |
El literal del perfil es ground-station. Comparte base de código con Drone Agent, pero activa otros servicios: recepción en lugar de codificación a bordo; punto de acceso, conexión compartida y quiosco en lugar de incorporación centrada en FC.
Los almacenes separan vehículo, telemetría, misión y transporte
| Almacén | Responsabilidad |
|---|---|
| drone-manager | Nodos, vías de conexión y vehículo activo |
| telemetry-store | Estado en directo y búfer circular de 300 muestras |
| mission-store | Puntos de ruta, patrones, validación y estado de carga |
| video-store | Fuentes, transporte, reproducción y errores |
| settings-store | Persistencia IndexedDB y migraciones |
| ground-station-store | Receptores, vía de retransmisión, fuentes y E/S de campo |
Armar es una cadena confirmada, no un interruptor local
Intención del operador
Mission Control llama a protocol.arm() después de una confirmación explícita.
Protocolo
Se crea MAV_CMD_COMPONENT_ARM_DISARM, comando #400.
Transporte
La trama llega al agente por WebSocket/LAN o por Convex/nube.
Serie
El agente transmite el comando al FC y no se atribuye el arbitraje de las comprobaciones previas al armado.
Validación del FC
El firmware comprueba sensores, GPS, batería, interruptor de seguridad, EKF y failsafes configurados.
Confirmación de estado
El bit 7 de HEARTBEAT base_mode y el ACK regresan por IPC/MQTT; la interfaz muestra ARMED solo después de confirmarse.