Drone Fleet Management

• Listing & selecting vehicles from the fleet (the dropdown and the fleet dialog).
• The DroneService action surface — the flat REST facade every component calls to CRUD drones and issue flight/mission/geofence/param/video actions.
• The telemetry HUD — the five status tags (system state, GPS/RTK fix, mode, altitude, battery) rendered by DroneStatusComponent.
• Selected-drone propagation — how a selection made anywhere fans out to every component and back-end subscription without infinite loops.

​

The players

export interface Drone {
  id: string;
  name: string;
  ip: string;
  port: number;
  mission_id: number;
  type: string;          // 'physical' | 'sitl'
  initial_pos?: { lat: number; lng: number };
  vehicle_type: string;  // 'copter' | 'rover'
  video_room_id?: number;
  video_room_password?: string;
  activation_token?: string;
}

​

Listing & selecting drones

​

The fleet dialog

• type === 'sitl' → always Online.
• Has an activation_token → Pending Activation (a physical drone that has not yet called GET /drone/activate on the gateway).
• Otherwise → getVPNStatus(id) (GET /drone/{id}/vpn/status); truthy status → Online, else Offline.

​

Selected-drone propagation

1. Always tears down the previous telemetry subscriptions (diagnostics, gps, gpsRaw, relAlt) and calls websocketService.killAllActiveEventSource(), then clears the HUD fields.
2. Always re-subscribes for the new drone: websocketService.getAllData(drone.id) (the dashboard stream) plus the four subject subscriptions.
3. Only when fromUserInteraction === true writes back to appStateService.setSelectedDrone(drone) and droneSubscriptionService.setValue('selectedDrone', drone).

​

Adding a vehicle

• Type: Physical (physical) or Simulated (sitl). typeChange() disables the ip/port controls for SITL, since simulated containers are spawned by the gateway (their ip/mac/port are assigned server-side — see SITL Drone Lifecycle).
• Vehicle Type: Rover or Copter — drives control/axis mappings downstream.

​

DroneService action surface

​

The telemetry HUD

​

What each subject provides

​

GPS / RTK fix mapping

​

Altitude: MSL vs AGL

• alt — relative altitude from relAltSubject, i.e. AGL height above the home/takeoff point. This is what the ALT tag shows (alt <n>M) and what appStateService.altitude is set to.
• gpsAltitude — absolute MSL altitude from gpsSubject.

​

Other tag logic

• System state — systemStatus === 'ACTIVE' renders ARMED (green); anything else renders DISSARMED (red — the literal string is misspelled in the template). systemStatus comes from the Heartbeat System status diagnostic.
• Mode — MANUAL/LOITER/LOYTER/POSHOLD are warning, GUIDED is info, everything else success. MODE_DESCRIPTIONS provides tooltip text.
• Battery — ≤ 0 or < 10% → danger, < 30% → warning, else success. Tooltip adds voltage/current and a Good/Low/Critical health line.

​

Gotchas to preserve

• getAllData is the only live path. The HUD subscribes via getAllData(id) → the dashboard stream. getGpsData()/getLogsData() (single-stream subscriptions) exist but the gateway only delivers data on the dashboard room — treat them as effectively dead. Details in Real-time Telemetry Client.
• Selection teardown is mandatory. onChange() unsubscribes the four subjects and calls killAllActiveEventSource() before re-subscribing. Skipping teardown leaks subscriptions and mixes telemetry from the previous drone into the new HUD.
• Name mutation. The parts.slice(3) truncation rewrites drone.name on the shared cached object, so downstream consumers see the shortened name too.
• localStorage is the persistence layer. Selection survives reloads via selected_drone_id; a stale id (deleted drone) is cleared on next fleet load.
• Client-side vehicle-limit check is advisory. The real free-tier / subscription enforcement is the gateway 402 response; keep both in sync but trust the backend.