KairOS Drone Agent est conçu comme la couche compagnon embarquée ouverte de #bezpiLOTa : il relie contrôleur de vol, vidéo, API locales, communications, télémétrie cloud, IA embarquée et extensions sur un seul SBC Linux.
L’architecture cible est entièrement décrite ; la disponibilité de chaque fonction KairOS est vérifiée séparément.
Dépôt KairOS ↗Sur cette page +
Tout ce qui se situe au-dessus de la boucle de stabilisation
Le contrôleur de vol reste responsable des moteurs, de la stabilisation, du GPS et des capteurs de base. KairOS Drone Agent ajoute une couche de calcul à ses côtés : routage MAVLink, collecte de télémétrie, traitement vidéo, interfaces locales, radio et réseau, extensions et interface logicielle unifiée pour les applications.
C’est une architecture horizontale plutôt qu’un écosystème vertical fermé. Un même agent doit s’adapter d’un Raspberry Pi peu puissant, limité à la télémétrie et aux communications, à un Jetson Orin capable de modèles de vision et de charges autonomes. Des frontières de services et d’API cohérentes permettent de changer de carte sans réécrire les couches supérieures.
Une seule plateforme
Une extension ou intégration est développée une fois, puis déployée sur les profils KairOS compatibles.
Le local d’abord
MAVLink local, vidéo, REST et configuration n’exigent pas de compte cloud.
Prévu pour la flotte
Une chaîne cloud MQTT/WebRTC est ajoutée comme second chemin pour l’observation distante et les commandes.
Extensions sécurisées
Paquets signés, processus distincts et autorisations de capacité réduisent l’étendue des défaillances.
Un parcours d’installation sur l’ordinateur compagnon
Le parcours cible s’exécute par SSH sous Raspberry Pi OS, Ubuntu, Armbian ou Debian. Le futur installateur doit détecter la carte, installer les dépendances, créer utilisateur système et dossiers, écrire la configuration, enregistrer les services systemd et lancer l’agent. La commande ne devient une fonction produit qu’après publication et vérification de l’installateur propre à KairOS.
git clone https://github.com/1kairosgo/KairOS_Drone-Agent.git
cd KairOS_Drone-Agent
# Следуйте README выбранной версииSept frontières entre Linux et l’opérateur
| Couche | Responsabilité | Frontière stable |
|---|---|---|
| L7 | Mission Control, tableau de bord ou application | WebSocket, MQTT, REST, WebRTC |
| L6 | Surface de commande | Télémétrie, paramètres, missions, commandes |
| L5 | Extensions | .kairosplug signé, isolation, IPC à capacités |
| L4 | Transport des données de vol | Routeur MAVLink, chaîne vidéo, MQTT, Wi-Fi, radio |
| L3 | Abstraction matérielle | Détection de carte, GPIO, I²C/SPI, caméras, modems |
| L2 | Confiance et cycle de vie | TLS, installateurs signés, OTA, enrôlement |
| L1 | Orchestration | systemd, surveillance de santé, ordre des dépendances |
| L0 | Système d’exploitation | Linux sur ARM64 ou une architecture compatible |
Le rôle des couches est de limiter le périmètre des changements. Un plugin L5 ne doit pas ouvrir directement l’UART du contrôleur de vol en contournant L4 ; un panneau web L7 ne doit pas gérer systemd sans API L6 vérifiée. Cette séparation rend le comportement observable et les services remplaçables.
Services durables en Rust, écosystème en Python
Rust / chemin critique
Superviseur, routeur MAVLink, chaîne vidéo, pile radio et surface de commande HTTP. Les flux de données de vol exigent sûreté mémoire, prévisibilité et consommation de ressources bornée.
Python / écosystème
Inférence IA et vision, initialisation matérielle, environnement des plugins et intégrations aux bibliothèques déjà développées dans l’écosystème Python.
Les services s’exécutent séparément sous la supervision de systemd. Une panne du module de vision ou d’une extension ne doit pas arrêter le routeur MAVLink. La couche de santé collecte l’état et l’expose au terminal, à l’application de configuration et à Mission Control via un même objet d’état.
Ce que couvre l’agent
Liaison de vol
Une seule liaison série ou USB du FC est partagée entre WebSocket, TCP, UDP, services locaux et relais cloud ; la signature MAVLink v2 passe de façon transparente.
Vidéo
Détection de caméras CSI, USB UVC et IP, encodage matériel lorsqu’il existe, OSD, WHEP/WebRTC et chaîne WFB-ng.
Flotte
Télémétrie MQTT, couche d’état HTTP, appairage et signalisation WebRTC pour le second chemin distant.
Autonomie
L’inférence embarquée publie les détections sur un bus commun pour les plugins, nacelles et futures fonctions autonomes.
Extensions
Les paquets signés s’exécutent dans un sous-processus isolé et ne reçoivent que les capacités accordées par l’opérateur.
Exploitation
Détection automatique de carte, configuration locale, état en lecture seule, santé, synthèses d’assistance et mises à jour gérées.
Profils de cartes cibles
KairOS doit détecter le modèle de carte au démarrage et n’activer que les fonctions prises en charge par son SoC et son câblage. Les profils ci-dessous sont des cibles ; chacun recevra un état distinct après compilation reproductible et essais sur matériel réel.
| Famille | Profils |
|---|---|
| Raspberry Pi | Pi 3, Pi 4B, Pi 5, CM3, CM4, CM5 |
| Radxa | CM3, CM4, Cubie A7Z, Rock 5C Lite |
| Orange Pi | Orange Pi 5 |
| Rockchip | RK3566, RK3576, RV1126B armv7l |
| NVIDIA | Jetson Nano, Jetson Orin Nano |
| Repli | ARM64 générique |
De la télémétrie à la coordination de groupe
Niveau 1 — communications
MAVLink et télémétrie via 4G, Wi-Fi ou réseau local.
Niveau 2 — calcul embarqué
Vidéo, extensions et charges de vision sur l’ordinateur compagnon.
Niveau 3 — intégration complète
Matériel et capteurs supplémentaires pour les fonctions autonomes ; une validation KairOS spécifique est nécessaire.
Niveau 4 — maillage et essaim
Coordination de groupe et logique distribuée. Dans KairOS, ce niveau reste un axe de recherche et n’est pas annoncé comme une fonction publiée.