Connect real aircraft

Virtual and real aircraft can share Mainframe. Their provider identities and serial numbers remain distinct. Staging’s auto-operator selection is world-sim plus SIM-STG-; Mainframe checks it again when the module submits a command. Callsigns and editable tags cannot make an Autel aircraft match that selection.

Two modules

Vanagas (profile vanagas) observes an existing vanago-akis deployment: the other system keeps controlling the aircraft while this Mainframe subscribes to its broker, records messages, relays video and shows every controller and aircraft read-only (the OBSERVE chip). Configure its broker URL and credentials, optional controller serials, and its SRS API/RTMP addresses.

Autel (profile autel) hosts real controllers natively with the authenticated MQTT broker owned by this deployment. It needs explicit controller/aircraft bindings and native configuration. Provision the initial native configuration once, then manage controller accounts from Assets as described below. Keep deployment credentials separate from development.

Both can run at the same time under one Mainframe; they have separate provider identities. Aircraft hosted by autel are fully controllable, but only by an operator holding a control lease who engages explicitly; login, reconnect and panel opening never acquire authority.

Network and video

The native Enterprise HTTP/WS routes are reserved on the Mainframe domain. Controller MQTT reachability is configured separately: its listener defaults to loopback until the deployment explicitly exposes it. The RC must also reach the MEDIA_RTMP address returned in its signed media assignment. SRS’s HTTP API stays private.

Host firewall lines for a full stack: 80/tcp and 443/tcp (Caddy), MEDIA_RTC_PORT udp and tcp (video, 8189 by default), 1883/tcp when controllers connect (profile autel), and for voice rooms (profile voice) 7881/tcp and 7882/udp to PUBLIC_IP. LiveKit’s own HTTP port stays on the Compose network; browsers reach it through /rtc on the Mainframe domain.

After connecting, confirm stable controller/airframe identity, fresh telemetry, optical/IR video as supported, and a recorded segment. Inspect command availability and observation indicators in Terminal. Enabling real control requires the separate device-specific authority and lease checks; neither a successful login nor a reconnect grants it.

The native hardware runbooks track firmware, payload behavior, calibration, command completion, takeover, and emergency behavior. Treat those results separately from simulator and container tests. The combined first-flight procedure (controller bindings at the bench, take off, every axis, gimbal presets, land, drop) is services/autel/runbooks/06-field-flight.md.

Add controllers and aircraft from Terminal

Sign in as a Mainframe administrator. In Assets, use the controller icon (Manage Autel controllers) or + → Add Autel controller.

1. Enter a controller name and unique login username. Its controller serial is discovered at first sign-in.
2. Create the login and save the seven Enterprise connection fields. Generated passwords are shown once.
3. Enter those fields in Enterprise and connect. The controller and its currently connected aircraft appear in Assets.
4. Use Aircraft profiles → Edit aircraft to configure a drone’s camera and flight settings by serial. Profiles are shared across all controllers. Disconnect the aircraft before changing its profile.

Aircraft can rotate freely between controllers. No account owns an aircraft, and no assignment edit is needed. Current topology grants temporary broker access and determines video/control routing. Disconnects, timeouts, and restarts clear connections. Simultaneous conflicting controller reports refuse routing until a unique connection is known. Existing control sessions are invalidated on connection changes; engage explicitly again after reconnecting.

Controller Edit changes the login name, label, passwords or enabled status. Profile edits are separate and do not rotate controller credentials. Names, callsigns, model identity and camera profiles stay with the aircraft serial.

Generate a new password rotates both the Enterprise login and MQTT credentials and invalidates the old session. Login enabled can disable an account without deleting its history. Ordinary account lists never expose passwords. If a save reports that broker permissions are synchronizing, refresh until it is ready before connecting; the change is saved and retried automatically.

Account storage and deployment upgrades

The native module owns account configuration. Mainframe authenticates administrator requests and audits changes; passwords are not stored in Mainframe documents, events, or replay history. The account database lives in the private autel-accounts Docker volume. Mosquitto’s live security configuration lives in autel-broker. Preserve both volumes during upgrades and include them in your private host-state backup procedure.

The first managed startup imports existing accounts from the provisioned native.json, preserving their credentials. Legacy per-account aircraft entries migrate into a separate serial-keyed profile list; no historical controller links are imported. Additional reviewed settings are preserved, and conflicting profiles require explicit resolution rather than an array-order choice. Later startups read the managed account database. Editing the old bootstrap file does not overwrite accounts managed in Terminal. Migrating an existing static broker requires one broker/module restart and an Enterprise sign-in; adding or editing accounts after migration requires no deployment.

Staging deliberately exposes authenticated plain MQTT on TCP 1883 for mobile controllers, as required by Enterprise. HTTPS and WSS use the Mainframe domain. Manual control tests need a control lease and an explicit engage. The auto-operator remains limited to world-sim aircraft whose serials start with SIM-STG-.

Copy the camera profile firmware string exactly from the aircraft’s first update_topo/reported firmware_version, and re-check it after firmware updates. A mismatch degrades module health and disables calibrated pointing until the profile is validated for the reported firmware; do not bypass the geometry guard.

Native configuration accepts a separate drcAddress for the controller’s second MQTT connection; it defaults to mqtt.address. The managed broker also listens for WebSockets on port 9001 (AUTEL_DRC_WS_PORT, with the same bind address and dynamic-security accounts). For the first bench engage, try the configured DRC scheme; if the controller never opens its second connection, set drcAddress to ws://<controller-reachable-host>:9001 and repeat the human bench procedure. TCP transport remains hardware-unverified here; record the actual scheme and result in the bench log. This configuration change does not itself verify DRC.

In the host development stack, bun dev:infra autel uses the same managed broker bootstrap and retains its state in dev-autel-broker. Its WebSocket host port defaults to 9002, because MinIO’s development console uses 9001. Set drcAddress to the matching reachable host and port; AUTEL_DRC_WS_PORT overrides the published port. Migrating a running static development broker requires an explicit broker restart; updating the Compose file alone leaves it running. AUTEL_ACCOUNT_STATE defaults to ./data/native/accounts.json; set it to a private writable persistent path for the host installation. Account reconciliation provisions the managed broker credentials and temporary aircraft permissions.