CONCEPT ET DÉVELOPPEMENTSPORT SANS PILOTE · #bezpiLOTa · KAIROS DRONE AGENTDocumentation
#bezpiLOTa→Premiers pas→Fonctionnement
PREMIERS PAS / ARCHITECTURE

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.

CONCEPT

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 ↗
03modes de connexion
1 Hzheartbeat du compagnon
2 Hztélémétrie cloud cible
MAVLINKprotocole principal
01
VUE D’ENSEMBLE

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.

02
FLUX DE DONNÉES

Le circuit complet de télémétrie, commande et vidéo

01

FC → Agent

MAVLink UART fonctionne généralement à 115200–921600 bauds ; l’agent attend un heartbeat et identifie le micrologiciel.

02

Agent → clients locaux

Le routeur distribue le MAVLink brut au socket IPC, au WebSocket, au service cloud et à l’état de santé.

03

Agent → cloud

La cible publie la télémétrie à environ 2 Hz et l’état par HTTP/MQTT.

04

Caméra → navigateur

La capture V4L2 passe par encodage H.264, MediaMTX/RTSP et transport WHEP, WebRTC ou WFB-ng choisi.

05

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.

06

ACK → UI

Les accusés de réception et nouveaux heartbeats/états reviennent, puis l’interface actualise son état.

03
TROIS MODES DE CONNEXION

USB direct, LAN et P2P distant

ModeTransportQuand l’utiliserObjectif de conception
USB directWebSerial → FC, sans agentBanc, configuration, étalonnage, micrologicielObjectif <10 ms
LAN directREST :8080, MAVLink WS :8765, WHEP :8889Intérieur, courte portée, développement, LAN de terrainObjectif : vidéo 50–150 ms ; télémétrie <100 ms
P2P distant4G/Internet, signalisation SDP MQTT, WebRTC, ConvexObservation distante et second cheminObjectif : 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.

05
LA CHAÎNE VIDÉO

De la capture V4L2 à la lecture H.264 native

01

Capture

USB UVC ou MIPI CSI est ouvert via V4L2 ; formats et résolutions disponibles sont vérifiés avant lancement.

02

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.

03

Publier

Le flux encodé est publié dans MediaMTX/RTSP et devient la source des transports suivants.

04

LAN

WHEP fournit WebRTC directement au navigateur local.

05

Distant

MQTT porte la signalisation SDP, puis les médias passent en WebRTC P2P ou par relais si nécessaire.

06

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.

Cockpit avec flux H.264 : cap, vitesse, altitude, GPS, batterie, mini-carte, témoin d’enregistrement et commandes de vol.
INTERFACE / EXEMPLE VISUELVidéo sur la surface opérateur

L’image caméra est complétée par HUD, mini-carte, mode de vol et témoin d’enregistrement. Le format H.264 est indiqué séparément.

06
RELAIS CLOUD

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.

textChemins de données distants
Telemetry: FC → Agent → MQTT → bridge → Convex → Mission Control
Commands: Mission Control → Convex queue → Agent poll → MAVLink → FC
Video: Camera → Agent → MQTT SDP → P2P WebRTC → Browser
07
RÔLE DE GROUND AGENT

Le nœud de terrain convertit la radio en interfaces locales

ClientChemin
Ordinateur portablePoint d’accès Wi-Fi, Ethernet ou partage USB CDC-NCM
Téléphone / tabletteNavigateur sur le même réseau local ou piste Android KairOS
Écran de terrainHDMI et kiosque Chromium
Mission ControlProfil 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.

08
ÉTAT DE MISSION CONTROL

Des magasins distincts pour appareil, télémétrie, mission et transport

Magasin d’étatResponsabilité
drone-managerNœuds, chemins de connexion et appareil actif
telemetry-storeÉtat en direct et tampon circulaire de 300 échantillons
mission-storePoints de passage, motifs, validation, état d’envoi
video-storeSources, transport, lecture et erreurs
settings-storePersistance IndexedDB et migrations
ground-station-storeRécepteurs, chemins de relais, sources et E/S de terrain
Vue d’une flotte de six agents : cartes vidéo, télémétrie et ressources, filtres online, stale et offline.
INTERFACE / EXEMPLE VISUELÉtats des nœuds dans la vue de flotte

Chaque agent a sa vidéo, sa télémétrie et ses ressources. Filtres et états montrent pourquoi distinguer disponibilité et fraîcheur des données.

09
CE QUI SE PASSE À L’ARMEMENT

L’armement est une chaîne confirmée, pas un commutateur local

01

Intention de l’opérateur

Mission Control appelle protocol.arm() après confirmation explicite.

02

Protocole

MAV_CMD_COMPONENT_ARM_DISARM, commande #400, est créée.

03

Transport

La trame rejoint l’agent par WebSocket/LAN ou le chemin Convex/cloud.

04

Série

L’agent transmet la commande au FC sans se substituer à l’arbitre des vérifications de préarmement.

05

Validation du FC

Le micrologiciel vérifie capteurs, GPS, batterie, interrupteur de sécurité, EKF et failsafes configurés.

06

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.