KairOS Drone Agent se diseña como una capa auxiliar abierta a bordo de #bezpiLOTa: conecta el controlador de vuelo, vídeo, API local, comunicaciones, telemetría en la nube, IA en el vehículo y extensiones en un solo SBC Linux.
La arquitectura prevista está descrita íntegramente; la disponibilidad de cada función de KairOS se confirma por separado.
Repositorio de KairOS ↗En esta página +
Todo lo que está por encima del lazo de estabilización
El controlador de vuelo sigue siendo responsable de los motores, la estabilización, el GPS y los sensores básicos. KairOS Drone Agent añade una capa de cómputo junto a él: enruta MAVLink, recoge telemetría, procesa vídeo, mantiene las interfaces locales, conecta radio y red, ejecuta extensiones y ofrece a las aplicaciones un entorno de software unificado.
Es una arquitectura horizontal, no un ecosistema vertical cerrado. Un mismo agente debe escalar desde una Raspberry Pi de baja potencia, donde solo se necesitan telemetría y comunicaciones, hasta Jetson Orin, que admite modelos de visión y cargas autónomas. Los mismos límites entre servicios y API permiten cambiar de placa sin reescribir la capa superior.
Una plataforma
Cada extensión o integración se desarrolla una vez y se despliega en perfiles compatibles de KairOS.
Prioridad local
MAVLink, vídeo, REST y configuración locales no requieren una cuenta obligatoria en la nube.
Preparado para flotas
El sistema MQTT/WebRTC en la nube se añade como segunda vía para observación y comandos remotos.
Extensiones seguras
Los paquetes firmados, los procesos independientes y los permisos de capacidades reducen el alcance de los fallos.
Un proceso de instalación en el ordenador auxiliar
El proceso de instalación previsto funciona por SSH en Raspberry Pi OS, Ubuntu, Armbian o Debian. El futuro instalador deberá detectar la placa, instalar dependencias, crear un usuario del sistema y directorios, escribir la configuración, registrar servicios systemd e iniciar el agente. El comando solo formará parte del producto tras la publicación y verificación del instalador propio de KairOS.
git clone https://github.com/1kairosgo/KairOS_Drone-Agent.git
cd KairOS_Drone-Agent
# Следуйте README выбранной версииSiete límites entre Linux y el operador
| Capa | Responsabilidad | Límite estable |
|---|---|---|
| L7 | Mission Control, panel o aplicación | WebSocket, MQTT, REST, WebRTC |
| L6 | Superficie de control | Telemetría, parámetros, misiones y comandos |
| L5 | Extensiones | .kairosplug firmados, aislamiento e IPC de capacidades |
| L4 | Transporte de datos de vuelo | Enrutador MAVLink, cadena de vídeo, MQTT, Wi-Fi y radio |
| L3 | Abstracción de hardware | Detección de placa, GPIO, I²C/SPI, cámaras y módems |
| L2 | Confianza y ciclo de vida | TLS, instaladores firmados, OTA e incorporación |
| L1 | Orquestación | systemd, supervisión de salud y orden de dependencias |
| L0 | Sistema operativo | Linux en ARM64 o arquitectura compatible |
La finalidad de las capas es limitar el alcance de los cambios. Un complemento L5 no debe abrir directamente el UART del controlador de vuelo saltándose L4; un panel web L7 no debe controlar systemd sin una API L6 validada. Esta separación hace observable el comportamiento y permite sustituir servicios individuales.
Servicios persistentes en Rust, ecosistema en Python
Rust / ruta crítica
Supervisor, enrutador MAVLink, cadena de vídeo, pila de radio y superficie de control HTTP. Los flujos de datos de vuelo requieren seguridad de memoria, previsibilidad y consumo limitado de recursos.
Python / ecosistema
Inferencia de IA y visión, inicialización del hardware, entorno de complementos e integraciones con bibliotecas ya desarrolladas en el ecosistema Python.
Los servicios se ejecutan por separado y están supervisados por systemd. Un error en el módulo de visión o en una extensión no debe detener el enrutador MAVLink. La capa de salud recopila el estado y lo expone al terminal, la aplicación web de configuración y Mission Control mediante un único objeto de estado.
Qué abarca el agente
Enlace de vuelo
Un único canal serie o USB del FC se distribuye entre WebSocket, TCP, UDP, servicios locales y retransmisión en la nube; la firma MAVLink v2 se transmite de forma transparente.
Vídeo
Detección de cámaras CSI, USB UVC e IP, codificación por hardware cuando esté disponible, OSD, WHEP/WebRTC y sistema WFB-ng.
Flota
Telemetría MQTT, capa HTTP de estado, emparejamiento y señalización WebRTC para la segunda vía remota.
Autonomía
La inferencia en el vehículo publica detecciones en un bus compartido para complementos, gimbal y futuras funciones autónomas.
Extensiones
Los paquetes firmados se ejecutan en un subproceso aislado y reciben únicamente las capacidades concedidas por el operador.
Operación
Detección automática de placa, configuración local, estado de solo lectura, salud, resumen de soporte y actualización controlada.
Perfiles de placas previstos
KairOS debe detectar el modelo de placa al arrancar y activar solo las funciones compatibles con el SoC y el diseño concretos. A continuación se enumeran los perfiles previstos; cada uno recibirá un estado independiente tras una compilación reproducible y una prueba en hardware real.
| Familia | Perfiles |
|---|---|
| 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 |
| Alternativa | ARM64 genérico |
De la telemetría a la coordinación de grupos
Nivel 1 — comunicaciones
MAVLink y telemetría sobre 4G, Wi-Fi o red local.
Nivel 2 — cómputo a bordo
Vídeo, extensiones y cargas de visión en el ordenador auxiliar.
Nivel 3 — integración completa
Hardware y sensores adicionales para funciones autónomas; se requiere validación específica de KairOS.
Nivel 4 — malla y enjambre
Coordinación de grupos y lógica distribuida. En KairOS este nivel sigue siendo una línea de investigación y no se presenta como una función disponible.