KairOS Drone Agent проектируется как открытый бортовой companion‑слой #bezpiLOTa: он связывает полётный контроллер, видео, локальный API, связь, облачную телеметрию, on‑vehicle AI и расширения на одном Linux SBC.
Целевая архитектура описана полностью; готовность каждой функции KairOS подтверждается отдельно.
Репозиторий KairOS ↗На этой странице +
Всё, что находится выше контура стабилизации
Полётный контроллер остаётся ответственным за моторы, стабилизацию, GPS и базовые датчики. KairOS Drone Agent добавляет вычислительный слой рядом с ним: маршрутизирует MAVLink, собирает телеметрию, обрабатывает видео, обслуживает локальные интерфейсы, подключает радио и сеть, запускает расширения и даёт приложениям единый программный контур.
Это горизонтальная архитектура, а не закрытая вертикальная экосистема. Один агент должен масштабироваться от маломощной Raspberry Pi, где нужны только телеметрия и связь, до Jetson Orin, где возможны vision‑модели и автономные рабочие нагрузки. Одинаковые границы сервисов и API позволяют менять плату без переписывания верхнего уровня.
Одна платформа
Расширение или интеграция разрабатывается один раз и разворачивается на совместимых профилях KairOS.
Local-first
Локальные MAVLink, видео, REST и настройка не требуют обязательной облачной учётной записи.
Fleet-ready
Облачный MQTT/WebRTC‑контур добавляется как второй путь для удалённого наблюдения и команд.
Безопасные расширения
Подписанные пакеты, отдельные процессы и capability‑разрешения уменьшают область отказа.
Один установочный контур на companion computer
Целевой установочный контур работает по SSH на Raspberry Pi OS, Ubuntu, Armbian или Debian. Будущий установщик должен определить плату, поставить зависимости, создать системного пользователя и каталоги, записать конфигурацию, зарегистрировать systemd‑сервисы и запустить агент. Команда станет продуктовой только после публикации и проверки собственного установщика KairOS.
git clone https://github.com/1kairosgo/KairOS_Drone-Agent.git
cd KairOS_Drone-Agent
# Следуйте README выбранной версииСемь границ между Linux и оператором
| Слой | Ответственность | Стабильная граница |
|---|---|---|
| L7 | Mission Control, dashboard или приложение | WebSocket, MQTT, REST, WebRTC |
| L6 | Управляющая поверхность | Телеметрия, параметры, миссии, команды |
| L5 | Расширения | Подписанные .kairosplug, sandbox, capability IPC |
| L4 | Транспорт полётных данных | MAVLink router, video pipeline, MQTT, Wi‑Fi, radio |
| L3 | Hardware abstraction | Board detection, GPIO, I²C/SPI, камеры, модемы |
| L2 | Доверие и жизненный цикл | TLS, подписанные установщики, OTA, enrollment |
| L1 | Оркестрация | systemd, health monitoring, порядок зависимостей |
| L0 | Операционная система | Linux на ARM64 или совместимой архитектуре |
Смысл слоёв — ограничить область изменения. Плагин уровня L5 не должен открывать UART полётного контроллера напрямую и обходить L4; веб‑панель уровня L7 не должна управлять systemd без проверенного API уровня L6. Такое разделение делает поведение наблюдаемым и позволяет заменять отдельные сервисы.
Долгоживущие сервисы на Rust, экосистема на Python
Rust / critical path
Supervisor, MAVLink router, video pipeline, radio stack и HTTP control surface. Для потоков полётных данных важны memory safety, предсказуемость и ограниченное потребление ресурсов.
Python / ecosystem
AI и vision inference, hardware bootstrap, plugin runtime и интеграции с библиотеками, которые уже развиваются в Python‑экосистеме.
Сервисы запускаются отдельно и контролируются systemd. Ошибка в vision‑модуле или расширении не должна останавливать MAVLink‑маршрутизатор. Health‑слой собирает состояние и делает его доступным терминалу, setup webapp и Mission Control через один объект статуса.
Что покрывает агент
Flight link
Один serial или USB‑канал FC распределяется между WebSocket, TCP, UDP, локальными сервисами и облачным relay; MAVLink v2 signing проходит прозрачно.
Video
Обнаружение CSI, USB UVC и IP‑камер, аппаратное кодирование при наличии, OSD, WHEP/WebRTC и WFB-ng‑контур.
Fleet
MQTT‑телеметрия, HTTP‑слой состояния, pairing и WebRTC signaling для второго, удалённого пути.
Autonomy
On‑vehicle inference публикует detections в общий bus для плагинов, gimbal и будущих автономных функций.
Extensions
Подписанные пакеты запускаются в subprocess sandbox и получают только выданные оператором capability.
Operate
Автоопределение платы, локальный setup, read‑only status, health, support summary и управляемое обновление.
Целевые профили плат
KairOS должен определять модель платы при загрузке и включать только функции, которые поддерживает конкретный SoC и разводка. Ниже перечислены целевые профили; каждый получит отдельный статус после воспроизводимой сборки и проверки на реальном оборудовании.
| Семейство | Профили |
|---|---|
| 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 |
От телеметрии до координации группы
Tier 1 — связь
MAVLink и телеметрия поверх 4G, Wi‑Fi или локальной сети.
Tier 2 — бортовые вычисления
Видео, расширения и vision‑рабочие нагрузки на companion computer.
Tier 3 — полная интеграция
Дополнительное аппаратное обеспечение и датчики для автономных функций; требуется конкретная KairOS‑валидация.
Tier 4 — mesh и swarm
Координация группы и распределённая логика. Для KairOS этот уровень остаётся направлением исследований и не заявлен как готовая функция.