KairOS Drone Agent é concebido como camada auxiliar aberta a bordo de #bezpiLOTa: liga controlador de voo, vídeo, API local, comunicações, telemetria na nuvem, IA no veículo e extensões num único SBC Linux.
A arquitetura prevista está integralmente descrita; a disponibilidade de cada função KairOS é confirmada separadamente.
Repositório KairOS ↗Nesta página +
Tudo o que está acima do ciclo de estabilização
O controlador de voo mantém a responsabilidade por motores, estabilização, GPS e sensores básicos. KairOS Drone Agent acrescenta uma camada de computação ao seu lado: encaminha MAVLink, recolhe telemetria, processa vídeo, mantém interfaces locais, liga rádio e rede, executa extensões e oferece às aplicações um ambiente de software unificado.
É uma arquitetura horizontal, não um ecossistema vertical fechado. Um agente deve escalar desde uma Raspberry Pi de baixa potência, que só precisa de telemetria e comunicações, até Jetson Orin, capaz de modelos de visão e cargas autónomas. Os mesmos limites de serviços e API permitem mudar de placa sem reescrever a camada superior.
Uma plataforma
Uma extensão ou integração é desenvolvida uma vez e implementada em perfis KairOS compatíveis.
Prioridade local
MAVLink, vídeo, REST e configuração locais não exigem uma conta obrigatória na nuvem.
Preparado para frotas
O sistema MQTT/WebRTC na nuvem é acrescentado como segunda via para observação e comandos remotos.
Extensões seguras
Pacotes assinados, processos independentes e permissões de capacidades reduzem o alcance das falhas.
Um processo de instalação no computador auxiliar
O processo de instalação previsto funciona por SSH em Raspberry Pi OS, Ubuntu, Armbian ou Debian. O futuro instalador deverá identificar a placa, instalar dependências, criar utilizador do sistema e diretórios, escrever a configuração, registar serviços systemd e iniciar o agente. O comando só fará parte do produto após publicação e verificação do instalador próprio KairOS.
git clone https://github.com/1kairosgo/KairOS_Drone-Agent.git
cd KairOS_Drone-Agent
# Следуйте README выбранной версииSete limites entre Linux e o operador
| Camada | Responsabilidade | Limite estável |
|---|---|---|
| L7 | Mission Control, painel ou aplicação | WebSocket, MQTT, REST, WebRTC |
| L6 | Superfície de controlo | Telemetria, parâmetros, missões e comandos |
| L5 | Extensões | .kairosplug assinados, isolamento e IPC de capacidades |
| L4 | Transporte de dados de voo | Encaminhador MAVLink, cadeia de vídeo, MQTT, Wi-Fi e rádio |
| L3 | Abstração de hardware | Deteção de placa, GPIO, I²C/SPI, câmaras e modems |
| L2 | Confiança e ciclo de vida | TLS, instaladores assinados, OTA e integração inicial |
| L1 | Orquestração | systemd, monitorização de saúde e ordem das dependências |
| L0 | Sistema operativo | Linux em ARM64 ou arquitetura compatível |
As camadas limitam o âmbito das alterações. Um plugin L5 não deve abrir diretamente o UART do controlador de voo, contornando L4; um painel web L7 não deve controlar systemd sem uma API L6 validada. Esta separação torna o comportamento observável e permite substituir serviços individuais.
Serviços persistentes em Rust, ecossistema em Python
Rust / caminho crítico
Supervisor, encaminhador MAVLink, cadeia de vídeo, pilha de rádio e superfície de controlo HTTP. Os fluxos de dados de voo exigem segurança de memória, previsibilidade e consumo limitado de recursos.
Python / ecossistema
Inferência de IA e visão, inicialização do hardware, ambiente de plugins e integrações com bibliotecas já desenvolvidas no ecossistema Python.
Os serviços são executados separadamente e supervisionados por systemd. Um erro no módulo de visão ou numa extensão não deve parar o encaminhador MAVLink. A camada de saúde recolhe o estado e disponibiliza-o ao terminal, aplicação web de configuração e Mission Control através de um único objeto de estado.
O que o agente abrange
Ligação de voo
Um único canal série ou USB do FC é distribuído por WebSocket, TCP, UDP, serviços locais e retransmissão na nuvem; a assinatura MAVLink v2 passa de forma transparente.
Vídeo
Deteção de câmaras CSI, USB UVC e IP, codificação por hardware quando disponível, OSD, WHEP/WebRTC e sistema WFB-ng.
Frota
Telemetria MQTT, camada HTTP de estado, emparelhamento e sinalização WebRTC para a segunda via remota.
Autonomia
A inferência no veículo publica deteções num barramento comum para plugins, gimbal e futuras funções autónomas.
Extensões
Pacotes assinados executam-se num subprocesso isolado e recebem apenas as capacidades concedidas pelo operador.
Operação
Deteção automática da placa, configuração local, estado de leitura, saúde, resumo de suporte e atualização controlada.
Perfis de placas previstos
KairOS deverá detetar o modelo da placa ao arrancar e ativar apenas funções compatíveis com o SoC e o circuito concretos. Abaixo estão os perfis previstos; cada um receberá um estado próprio após compilação reproduzível e verificação em hardware real.
| Família | Perfis |
|---|---|
| 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 |
Da telemetria à coordenação de grupos
Nível 1 — comunicações
MAVLink e telemetria sobre 4G, Wi-Fi ou rede local.
Nível 2 — computação a bordo
Vídeo, extensões e cargas de visão no computador auxiliar.
Nível 3 — integração completa
Hardware e sensores adicionais para funções autónomas; exige validação específica KairOS.
Nível 4 — malha e enxame
Coordenação de grupos e lógica distribuída. No KairOS, este nível permanece uma linha de investigação e não é apresentado como função disponível.