Le contrôleur assure la boucle de vol temps réel stricte. Le SBC compagnon gère vidéo, routage, API et communications externes. Mission Control choisit USB direct, LAN ou relais distant en séparant leurs responsabilités.
Le flux de bout en bout est une architecture cible ; latence et fréquences restent des objectifs jusqu’aux mesures KairOS.
Dépôt KairOS ↗Sur cette page +
Deux ordinateurs embarqués, des responsabilités distinctes
Le contrôleur de vol commande moteurs, stabilisation, GPS et capteurs. Le compagnon — Raspberry Pi, Radxa, Jetson ou autre SBC Linux — exécute KairOS Drone Agent sans remplacer le FC : il ajoute vidéo, relais de télémétrie, cloud, radio, API REST et extensions.
Au sol, Mission Control fonctionne dans le navigateur. Il accède au FC par WebSerial, à Drone Agent par LAN ou à un relais distant via MQTT/Convex et signalisation WebRTC. Ground Agent s’ajoute aux scénarios WFB-ng et transforme la réception radio en chaîne web locale accessible.
Le circuit complet de télémétrie, commande et vidéo
FC → Agent
MAVLink UART fonctionne généralement à 115200–921600 bauds ; l’agent attend un heartbeat et identifie le micrologiciel.
Agent → clients locaux
Le routeur distribue le MAVLink brut au socket IPC, au WebSocket, au service cloud et à l’état de santé.
Agent → cloud
La cible publie la télémétrie à environ 2 Hz et l’état par HTTP/MQTT.
Caméra → navigateur
La capture V4L2 passe par encodage H.264, MediaMTX/RTSP et transport WHEP, WebRTC ou WFB-ng choisi.
GCS → FC
Les commandes d’armement, de mode, de mission et autres reviennent par le même chemin ; le FC applique les règles de préarmement.
ACK → UI
Les accusés de réception et nouveaux heartbeats/états reviennent, puis l’interface actualise son état.
USB direct, LAN et P2P distant
| Mode | Transport | Quand l’utiliser | Objectif de conception |
|---|---|---|---|
| USB direct | WebSerial → FC, sans agent | Banc, configuration, étalonnage, micrologiciel | Objectif <10 ms |
| LAN direct | REST :8080, MAVLink WS :8765, WHEP :8889 | Intérieur, courte portée, développement, LAN de terrain | Objectif : vidéo 50–150 ms ; télémétrie <100 ms |
| P2P distant | 4G/Internet, signalisation SDP MQTT, WebRTC, Convex | Observation distante et second chemin | Objectif : vidéo 100–300 ms ; télémétrie 2–5 Hz |
Le transport automatique doit d’abord rechercher un chemin LAN pendant environ quatre secondes, puis passer à la signalisation P2P avec une fenêtre d’environ quatorze secondes. Ces durées dépendent du réseau et ne constituent pas un SLA KairOS.
Le routeur gère heartbeats, flux et plusieurs clients
- L’agent envoie un heartbeat compagnon à 1 Hz avec MAV_TYPE_ONBOARD_CONTROLLER.
- Après le heartbeat du FC, il demande attitude, GPS, batterie, RC et capteurs.
- Les demandes de flux se répètent environ toutes les 30 secondes pour résister aux redémarrages et changements d’état du FC.
- Ports typiques : /dev/ttyS0, /dev/ttyUSB0, /dev/ttyACM* ; le profil de carte définit les priorités de détection.
- Le socket IPC /run/kairos/mavlink.sock transporte les trames binaires aux autres services.
- Mission Control analyse MAVLink v2 avec CRC ; ArduPilot/PX4 utilisent MAVLink, Betaflight/iNav 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 la capture V4L2 à la lecture H.264 native
Capture
USB UVC ou MIPI CSI est ouvert via V4L2 ; formats et résolutions disponibles sont vérifiés avant lancement.
Encoder
ffmpeg utilise H.264 high profile, level 4.1, yuv420p et des options de faible latence ; l’encodeur matériel est choisi s’il existe.
Publier
Le flux encodé est publié dans MediaMTX/RTSP et devient la source des transports suivants.
LAN
WHEP fournit WebRTC directement au navigateur local.
Distant
MQTT porte la signalisation SDP, puis les médias passent en WebRTC P2P ou par relais si nécessaire.
Radio
wfb_tx envoie H.264 par WFB-ng ; Ground Agent reçoit et republie localement.
nobuffer, low_delay et une petite taille de sonde réduisent les files, mais la latence réelle dépend de la capture, de l’encodage, du débit, de la FEC, de la radio, du réseau et du décodage navigateur. KairOS publiera des mesures par profil plutôt qu’un chiffre universel.
MQTT pour le temps réel, Convex pour l’état et la file de commandes
L’agent cible publie la télémétrie MQTT à environ 2 Hz. Le pont MQTT-Convex agrège l’état avec une temporisation d’environ trois secondes par appareil ; le navigateur reçoit des requêtes réactives. Les commandes sont écrites dans Convex, récupérées par interrogation de l’agent, converties en MAVLink, puis acquittées.
Telemetry: FC → Agent → MQTT → bridge → Convex → Mission Control
Commands: Mission Control → Convex queue → Agent poll → MAVLink → FC
Video: Camera → Agent → MQTT SDP → P2P WebRTC → BrowserLe nœud de terrain convertit la radio en interfaces locales
| Client | Chemin |
|---|---|
| Ordinateur portable | Point d’accès Wi-Fi, Ethernet ou partage USB CDC-NCM |
| Téléphone / tablette | Navigateur sur le même réseau local ou piste Android KairOS |
| Écran de terrain | HDMI et kiosque Chromium |
| Mission Control | Profil de station sol avec sources vidéo/télémétrie |
Le profil littéral est ground-station. Il partage le code de Drone Agent mais active d’autres services : réception plutôt qu’encodage embarqué, AP/partage/kiosque plutôt qu’intégration centrée sur le FC.
Des magasins distincts pour appareil, télémétrie, mission et transport
| Magasin d’état | Responsabilité |
|---|---|
| drone-manager | Nœuds, chemins de connexion et appareil actif |
| telemetry-store | État en direct et tampon circulaire de 300 échantillons |
| mission-store | Points de passage, motifs, validation, état d’envoi |
| video-store | Sources, transport, lecture et erreurs |
| settings-store | Persistance IndexedDB et migrations |
| ground-station-store | Récepteurs, chemins de relais, sources et E/S de terrain |
L’armement est une chaîne confirmée, pas un commutateur local
Intention de l’opérateur
Mission Control appelle protocol.arm() après confirmation explicite.
Protocole
MAV_CMD_COMPONENT_ARM_DISARM, commande #400, est créée.
Transport
La trame rejoint l’agent par WebSocket/LAN ou le chemin Convex/cloud.
Série
L’agent transmet la commande au FC sans se substituer à l’arbitre des vérifications de préarmement.
Validation du FC
Le micrologiciel vérifie capteurs, GPS, batterie, interrupteur de sécurité, EKF et failsafes configurés.
Confirmation d’état
Le bit 7 de HEARTBEAT base_mode et l’ACK reviennent via IPC/MQTT ; l’interface affiche ARMED uniquement après confirmation.

