KairOS Drone Agent is designed as #bezpiLOTa’s open onboard companion layer: it connects the flight controller, video, local APIs, communications, cloud telemetry, on-vehicle AI and extensions on a single Linux SBC.
The target architecture is fully described; readiness of each KairOS feature is verified separately.
KairOS repository ↗On this page +
Everything above the stabilization loop
The flight controller remains responsible for motors, stabilization, GPS and basic sensors. KairOS Drone Agent adds a computing layer alongside it: routing MAVLink, collecting telemetry, processing video, serving local interfaces, connecting radios and networks, running extensions and providing applications with one software interface.
This is a horizontal architecture rather than a closed vertical ecosystem. A single agent should scale from a low-power Raspberry Pi needing only telemetry and communications to a Jetson Orin capable of vision models and autonomous workloads. Consistent service and API boundaries allow the board to change without rewriting upper layers.
One platform
An extension or integration is developed once and deployed on compatible KairOS profiles.
Local-first
Local MAVLink, video, REST and configuration do not require a cloud account.
Fleet-ready
A cloud MQTT/WebRTC path is added as a secondary route for remote observation and commands.
Secure extensions
Signed packages, separate processes and capability permissions reduce the impact of failures.
One installation workflow on the companion computer
The target installation workflow runs over SSH on Raspberry Pi OS, Ubuntu, Armbian or Debian. The future installer must detect the board, install dependencies, create the system user and directories, write configuration, register systemd services and start the agent. The command becomes a product feature only after KairOS’s own installer is published and verified.
git clone https://github.com/1kairosgo/KairOS_Drone-Agent.git
cd KairOS_Drone-Agent
# Следуйте README выбранной версииSeven boundaries between Linux and the operator
| Layer | Responsibility | Stable boundary |
|---|---|---|
| L7 | Mission Control, dashboard or application | WebSocket, MQTT, REST, WebRTC |
| L6 | Control surface | Telemetry, parameters, missions, commands |
| L5 | Extensions | Signed .kairosplug, sandbox, capability IPC |
| L4 | Flight data transport | MAVLink router, video pipeline, MQTT, Wi‑Fi, radio |
| L3 | Hardware abstraction | Board detection, GPIO, I²C/SPI, cameras, modems |
| L2 | Trust and lifecycle | TLS, signed installers, OTA, enrollment |
| L1 | Orchestration | systemd, health monitoring, dependency ordering |
| L0 | Operating system | Linux on ARM64 or a compatible architecture |
The purpose of layering is to limit the scope of changes. An L5 plugin must not open the flight controller’s UART directly and bypass L4; an L7 web panel must not manage systemd without a verified L6 API. This separation makes behavior observable and individual services replaceable.
Long-running services in Rust, ecosystem in Python
Rust / critical path
Supervisor, MAVLink router, video pipeline, radio stack and HTTP control surface. Flight data streams require memory safety, predictability and bounded resource consumption.
Python / ecosystem
AI and vision inference, hardware bootstrap, plugin runtime and integrations with libraries already developed in the Python ecosystem.
Services run separately under systemd supervision. A failure in a vision module or extension must not stop the MAVLink router. The health layer collects status and exposes it to the terminal, setup webapp and Mission Control through one status object.
What the agent covers
Flight link
One FC serial or USB link is shared across WebSocket, TCP, UDP, local services and cloud relay; MAVLink v2 signing passes through transparently.
Video
Discovery of CSI, USB UVC and IP cameras, hardware encoding where available, OSD, WHEP/WebRTC and a WFB-ng pipeline.
Fleet
MQTT telemetry, an HTTP status layer, pairing and WebRTC signaling for the secondary remote path.
Autonomy
On-vehicle inference publishes detections to a shared bus for plugins, gimbals and future autonomous features.
Extensions
Signed packages run in a subprocess sandbox and receive only operator-granted capabilities.
Operate
Automatic board detection, local setup, read-only status, health, support summaries and managed updates.
Target board profiles
KairOS should detect the board model at boot and enable only features supported by its specific SoC and wiring. The following are target profiles; each will receive a separate status after a reproducible build and testing on real hardware.
| Family | Profiles |
|---|---|
| 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 |
| Fallback | Generic ARM64 |
From telemetry to group coordination
Tier 1—communications
MAVLink and telemetry over 4G, Wi-Fi or a local network.
Tier 2—onboard computing
Video, extensions and vision workloads on the companion computer.
Tier 3—full integration
Additional hardware and sensors for autonomous features; specific KairOS validation is required.
Tier 4—mesh and swarm
Group coordination and distributed logic. In KairOS, this tier remains a research direction and is not claimed as a released feature.