KairOS Drone Agent को #bezpiLOTa की खुली onboard companion परत के रूप में बनाया जा रहा है: यह flight controller, वीडियो, स्थानीय API, communication, cloud telemetry, वाहन पर AI और extensions को एक Linux SBC पर जोड़ता है।
लक्षित architecture पूरी तरह वर्णित है; KairOS की हर सुविधा की readiness अलग से पुष्ट होती है।
KairOS repository ↗इस पृष्ठ पर +
Stabilization प्रणाली से ऊपर की सभी क्षमताएँ
Motors, stabilization, GPS और मूल sensors की ज़िम्मेदारी flight controller के पास रहती है। KairOS Drone Agent उसके साथ computing परत जोड़ता है: MAVLink routing, telemetry collection, वीडियो processing, स्थानीय interfaces, radio और network connection, extensions चलाना और applications के लिए एकीकृत software प्रणाली।
यह horizontal architecture है, बंद vertical ecosystem नहीं। Agent को कम शक्ति वाले Raspberry Pi, जहाँ केवल telemetry और communication चाहिए, से लेकर Jetson Orin, जहाँ vision models और autonomous workloads संभव हैं, तक scale करना चाहिए। समान service boundaries और API से ऊपरी स्तर दोबारा लिखे बिना board बदला जा सकता है।
एक प्लेटफ़ॉर्म
Extension या integration एक बार बनाया जाता है और संगत KairOS profiles पर deploy किया जाता है।
स्थानीय को प्राथमिकता
स्थानीय MAVLink, वीडियो, REST और सेटअप के लिए cloud account अनिवार्य नहीं है।
Fleet के लिए तैयार
Cloud MQTT/WebRTC प्रणाली दूरस्थ निगरानी और commands के दूसरे मार्ग के रूप में जोड़ी जाती है।
सुरक्षित extensions
Signed packages, अलग processes और capability permissions विफलता का प्रभाव सीमित करते हैं।
Companion computer पर एक installation प्रणाली
लक्षित installation SSH द्वारा Raspberry Pi OS, Ubuntu, Armbian या Debian पर होता है। भविष्य का installer board पहचानेगा, dependencies स्थापित करेगा, system user और directories बनाएगा, configuration लिखेगा, systemd services register करेगा और agent शुरू करेगा। अपने KairOS installer के publication और verification के बाद ही command उत्पाद का हिस्सा बनेगी।
git clone https://github.com/1kairosgo/KairOS_Drone-Agent.git
cd KairOS_Drone-Agent
# Следуйте README выбранной версииLinux और operator के बीच सात सीमाएँ
| परत | ज़िम्मेदारी | स्थिर सीमा |
|---|---|---|
| L7 | Mission Control, dashboard या application | WebSocket, MQTT, REST, WebRTC |
| L6 | नियंत्रण interface | Telemetry, parameters, मिशन, commands |
| L5 | Extensions | Signed .kairosplug, sandbox, capability IPC |
| L4 | उड़ान data transport | MAVLink router, video pipeline, MQTT, Wi‑Fi, radio |
| L3 | Hardware abstraction परत | Board detection, GPIO, I²C/SPI, cameras, modems |
| L2 | विश्वास और lifecycle | TLS, signed installers, OTA, enrollment |
| L1 | Orchestration | systemd, health monitoring, dependency order |
| L0 | Operating system | ARM64 या संगत architecture पर Linux |
परतों का उद्देश्य बदलाव के दायरे को सीमित करना है। L5 plugin को flight controller का UART सीधे खोलकर L4 bypass नहीं करना चाहिए; L7 web panel को verified L6 API के बिना systemd नियंत्रित नहीं करना चाहिए। इस विभाजन से behavior निगरानी योग्य होता है और individual services बदली जा सकती हैं।
Rust पर long-running services, Python पर ecosystem
Rust / महत्वपूर्ण मार्ग
Supervisor, MAVLink router, वीडियो pipeline, radio stack और HTTP control interface। Flight data streams के लिए memory safety, predictable behavior और सीमित resource use महत्वपूर्ण हैं।
Python / ecosystem परत
AI और vision inference, hardware bootstrap, plugin runtime तथा Python ecosystem में पहले से विकसित libraries के integrations।
Services अलग-अलग शुरू होती हैं और systemd द्वारा नियंत्रित होती हैं। Vision module या extension की त्रुटि से MAVLink router बंद नहीं होना चाहिए। Health परत स्थिति इकट्ठी करके एक status object के माध्यम से terminal, setup webapp और Mission Control को उपलब्ध कराती है।
Agent का कार्यक्षेत्र
उड़ान link
FC का एक serial या USB link WebSocket, TCP, UDP, स्थानीय services और cloud relay में वितरित होता है; MAVLink v2 signing पारदर्शी रूप से पास होता है।
वीडियो
CSI, USB UVC और IP cameras की पहचान, उपलब्ध होने पर hardware encoding, OSD, WHEP/WebRTC और WFB-ng प्रणाली।
वाहनों का समूह
दूसरे, दूरस्थ मार्ग के लिए MQTT telemetry, HTTP status layer, pairing और WebRTC signaling।
स्वायत्तता
वाहन पर inference plugins, gimbal और भविष्य की autonomous सुविधाओं के लिए shared bus पर detections प्रकाशित करता है।
विस्तार
Signed packages subprocess sandbox में चलते हैं और केवल operator द्वारा दी गई capabilities पाते हैं।
संचालन
Automatic board detection, स्थानीय setup, read-only status, health, support summary और नियंत्रित update।
लक्षित board profiles
Boot पर KairOS को board model पहचानकर केवल वे सुविधाएँ सक्षम करनी चाहिए जिन्हें उस SoC और wiring का support है। नीचे लक्षित profiles हैं; reproducible build और वास्तविक hardware पर जाँच के बाद हर profile की अलग स्थिति होगी।
| परिवार | 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 |
| वैकल्पिक मार्ग | सामान्य ARM64 |
Telemetry से समूह coordination तक
Tier 1 — communication
4G, Wi‑Fi या स्थानीय network पर MAVLink और telemetry।
Tier 2 — onboard computing
Companion computer पर वीडियो, extensions और vision workloads।
Tier 3 — पूर्ण integration
Autonomous सुविधाओं के लिए अतिरिक्त hardware और sensors; विशिष्ट KairOS validation आवश्यक है।
Tier 4 — mesh और swarm
समूह coordination और वितरित logic। KairOS के लिए यह स्तर अनुसंधान का विषय है और तैयार सुविधा के रूप में घोषित नहीं है।