El escenario previsto empieza con un modo local de demostración: se exploran Dashboard, Plan, Configure, Flight Control y Simulate con datos sintéticos. El FC real se conecta solo tras publicar el componente y verificar contexto seguro, flujo serie y condiciones de seguridad.
#bezpiLOTa Mission Control es un componente asociado del ecosistema, no una parte de KairOS Drone Agent; el repositorio ejecutable todavía no está publicado.
Repositorio de KairOS ↗En esta página +
Entorno de desarrollo y navegador
- Node.js 20 o posterior.
- npm 9 o posterior.
- Git para clonar y actualizar el código fuente cuando se publique el repositorio.
- Chrome, Edge o Firefox para la interfaz habitual; WebSerial/WebUSB requieren un navegador Chromium.
- Cable USB con líneas de datos si se conecta posteriormente un FC real.
node --version
npm --version
git --versionEntorno de demostración seguro sin FC
El modo de demostración se diseña para explorar la interfaz de forma segura sin conectar un vehículo real. Usa telemetría simulada y no presenta un banco de pruebas como sistema de vuelo operativo.
Modo local de demostración
# Отдельный репозиторий #bezpiLOTa Mission Control ещё не опубликован
# После выпуска ожидаемый поток будет таким:
npm install
NEXT_PUBLIC_DEMO_MODE=true npm run devLa interfaz prevista debe abrirse en http://localhost:4000. Con NEXT_PUBLIC_DEMO_MODE=true no se requieren base de datos externa, SITL ni hardware físico. Este bloque define el contrato de inicio y no afirma que el comando exista en el repositorio actual de KairOS Drone Agent.
Cinco superficies de trabajo principales
Panel
Actitud, GPS/altitud, batería, modo de vuelo, vía de conexión y alertas del sistema.
Planificación
Puntos de ruta, siete generadores, altitud/velocidad/disparo de cámara, geocercas, puntos de reunión y QGC WPL/KML/CSV.
Configuración
Failsafe, PID, alimentación, OSD, puertos, sensores, gimbal y paneles específicos del firmware.
Control de vuelo
Armado/desarmado, más de 25 modos ArduPilot, mando/HOTAS a 50 Hz, teclado y punto de ruta guiado.
Simulación
Trayectoria 3D de misión, seguimiento del terreno, marcadores de cámara, tiempos y perfil de altitud.
Flujo WebSerial en localhost
npm run devAbrir localhost
Abra http://localhost:4000 en un navegador Chromium.
Conectar el FC
Use un cable USB de datos, pulse Conectar y seleccione el puerto serie en el cuadro del navegador.
Apertura del puerto serie
El navegador obtiene permiso mediante una acción del usuario y abre el puerto.
Heartbeat
Mission Control espera el heartbeat del FC e identifica el piloto automático y el vehículo.
Capacidades
Solicita AUTOPILOT_VERSION y las capacidades del protocolo.
Flujos + parámetros
Solicita flujos de telemetría y descarga parámetros; la referencia de diseño para la negociación inicial es de 2–5 segundos.
WebSerial funciona solo en un contexto seguro
WebSerial, WebUSB y Web Bluetooth requieren HTTPS o la confianza especial de localhost. Por ello se permite http://localhost:4000, pero http://<lan-ip>:4000 desde otro dispositivo no obtiene estas API. El acceso al hardware desde otro dispositivo requiere HTTPS o una compilación de escritorio/Electron.
La conexión a Drone Agent mediante WebSocket y REST normales no utiliza el permiso WebSerial, pero siguen importando las reglas de contenido mixto: una página HTTPS puede bloquear un agente HTTP/WS sin cifrar. Para un modo completamente local con HTTP, el GCS y el agente deben estar disponibles en un contexto coherente.
Servidor local y agente en la misma red
npm run dev
# GCS on this machine
http://localhost:4000
# GCS from another LAN client
http://<your-lan-ip>:4000
# Example KairOS Agent address
http://kairos.local:8080
http://192.168.1.50:8080Física y protocolo sin vehículo real
cd KairOS_Drone-Agent/tools/sitl
npm install
npm startArduPilot SITL debe instalarse por separado; el binario suele estar en ~/.ardupilot/. El puente conecta la telemetría del simulador con el transporte del navegador. Es más seguro que un primer experimento de protocolo en un vehículo, pero aún exige verificar versiones, parámetros y comportamiento de misión.
Electron para API de hardware y paquete independiente
npm run desktop:dev
npm run desktop:demo
npm run desktop:build:mac
npm run desktop:buildComo referencia de planificación se prevén unos 200 MB en disco y 200–300 MB de RAM. Los requisitos reales dependen de la plataforma y versión de ejecución y se publicarán con la compilación de Mission Control.
Variables de modo e infraestructura externa
| Variable | Valor por defecto | Finalidad |
|---|---|---|
| NEXT_PUBLIC_DEMO_MODE | false | Siete drones simulados en lugar de fuentes reales |
| PORT | 4000 | Puerto del servidor de desarrollo |
| NEXT_PUBLIC_CONVEX_URL | ninguno | Backend Convex opcional |
| NEXT_PUBLIC_MQTT_URL | ninguno | Broker MQTT opcional |
El modo local/directo no necesita variables de nube. La ausencia de Convex o MQTT no debe bloquear USB directo, descubrimiento del agente local ni planificación de misiones sin conexión.
Estructura prevista del GCS independiente
KairOS_Drone-Agent/
├── agent/ onboard runtime
├── api/ local control surface
├── protocols/ MAVLink and MSP adapters
├── media/ video transports
├── extensions/ sandbox runtime and SDK
├── tools/sitl/ simulator bridge
├── deploy/systemd/ Linux services
├── docs/ project documentation
└── tests/ contracts and hardware profiles