Awaiting heartbeatNo vehicle signal ยท No packet

Test Readiness

Real equipment testers start here. Move from simulation to flight-controller bench to real aircraft only after each blocking gate has evidence.

APP :3002 / BRIDGE :3001

Simulation LabLAB

Validate UI, WebSocket bridge behavior, command ACK handling, map tracking, mission upload, and regression checks without hardware risk.

Hardware
No physical hardware. Uses the deterministic simulated bridge with two virtual vehicles.
Bridge command
npm run bridge:dev:sim:fleet
Blocking gates
  1. Simulated bridge online

    Start the two-vehicle simulated bridge and confirm the Fleet board shows both vehicles with live heartbeat age.

    Screenshot of Fleet Command with Vehicle 1 and Vehicle 2 visible plus BRIDGE ONLINE.

  2. Browser command loop

    Open a vehicle detail page, send Arm, GUIDED, RTL, and Land, then confirm command status text changes without page errors.

    Browser screenshot of command console accepted status and bridge log command lines.

  3. Mission planning loop

    Create at least four waypoints, upload the mission, and verify mission status appears in the planner timeline.

    Screenshot of Mission Operations after upload with waypoint count and current mission item.

Flight Controller BenchBENCH

Connect a real ArduPilot flight controller over telemetry, UDP, or serial while motors remain safe and propellers removed.

Hardware
Real flight controller, telemetry radio or USB/serial adapter, stable bench power, and no propellers installed.
Bridge command
npm run bridge:dev -- --listen-port 14550
Blocking gates
  1. Propellers removed

    Physically remove propellers and confirm motor outputs cannot create thrust before any arm or motor command is tested.

    Tester checklist note: props removed, battery state, frame restrained.

  2. Telemetry identity confirmed

    Connect the controller, verify sysid, vehicle type, firmware mode, GPS status, and heartbeat in the Fleet board.

    Screenshot of Vehicle detail showing sysid, mode, GPS, battery, and live position map.

  3. Non-flight command ACKs

    Send mode changes that are safe on the bench and confirm COMMAND_ACK status before testing any armed state.

    Bridge log excerpt showing COMMAND_ACK result accepted for each tested mode command.

Real Aircraft FieldFIELD

Perform controlled outdoor validation after simulation and bench gates prove telemetry, modes, failsafe posture, and mission upload behavior.

Hardware
Complete aircraft, charged batteries, secured test area, pilot in command, spotter, and verified RC/manual takeover path.
Bridge command
npm run bridge:dev -- --listen-port 14550
Blocking gates
  1. Propeller safety hold

    Pilot in command explicitly releases the safety hold only after simulation and bench gates are complete and geofence/failsafe posture is reviewed.

    Signed or timestamped field checklist with pilot, spotter, location, weather, geofence, and manual takeover confirmation.

  2. Low-altitude hover

    Arm, take off to a low test altitude, hold position, then land while the tester watches telemetry and map movement.

    Video or screenshot sequence showing takeoff, stable hover telemetry, and landed state.

  3. Small mission box

    Upload a short square mission inside the test area, switch AUTO only after the pilot confirms manual takeover readiness, then observe mission progress.

    Mission timeline screenshot with current item progress, map track, and post-flight log export.

Connection Setup

WebSocket disconnected
Command channel offlineUDP changes affect real SITL or hardware bridge mode.
Ready to apply connection settings.

Hardware Bench ReportREADY FOR CONTROLLED COMMAND-ACK TEST

Use this before real aircraft testing. The first hardware session is telemetry-only until every bench evidence item is captured.

Props removed

A bench controller or aircraft must not be able to create thrust during first contact.

Photo or tester note confirming propellers are removed before any command-authority test.
Command authority disabled

First hardware contact must prove identity and telemetry before the GCS can send control actions.

Screenshot or tester note showing arm, motor, takeoff, and mission commands remained disabled for telemetry-only contact.
Telemetry identity confirmed

The tester must prove the UI is connected to the intended controller, not a stale simulator or wrong vehicle.

Vehicle detail screenshot with sysid, vehicle type, mode, GPS, battery, heartbeat age, and connection profile.
Parameter baseline downloaded

A baseline is required before parameter write, firmware, calibration, or failsafe work can be reviewed safely.

Parameter page screenshot or exported parameter file from the connected controller.
Battery voltage verified

Incorrect voltage telemetry can hide power problems before command or calibration testing.

Measured or operator-confirmed voltage compared against GCS telemetry.
Fresh heartbeat

Stale telemetry cannot be used to approve command ACK testing.

Vehicle detail screenshot showing heartbeat age under the bench limit.
Tester handoff template

After the bench session, copy this report into the tester handoff with screenshots, bridge logs, and exported parameters attached.

# INSEE GCS Hardware Bench Report

## Session
- Tester: <tester name>
- Tested at: <ISO timestamp>
- Connection profile: <USB serial, telemetry radio, UDP, or TCP profile>

## Vehicle
- Vehicle: sysid 1, <vehicle type>, firmware <firmware version>
- Mode: <current mode>
- Armed: no
- Battery: 12.40 V
- GPS: fix 3, satellites 10
- Heartbeat age: 1.0 s

## Safety Evidence
- Props removed: yes
- Command authority disabled: yes
- Telemetry identity confirmed: yes
- Parameter baseline downloaded: yes
- Battery voltage verified: yes

## Readiness
- Readiness: READY FOR CONTROLLED COMMAND-ACK TEST
- Blockers:
- None

## Notes
- Notes: <tester notes and link to screenshots/log export>

Executable Gate Matrix

Static Type and Lint Gate
LOCAL
npm run verify:static

Runs TypeScript strict checking and ESLint so protocol and UI type drift cannot be hidden by passing runtime tests.

Unit and Component Gate
LOCAL
npm run verify:unit

Runs Vitest across bridge, stores, hooks, functional libraries, and server-rendered component tests for every small piece.

Production Build Gate
LOCAL
npm run verify:build

Runs Next.js production compilation to catch route, server component, and bundle issues that unit tests do not exercise.

Browser Smoke Gate
LOCAL
npm run verify:browser

Runs Playwright against the real Next.js app shell and critical routes so pages cannot silently ship broken in a browser.

Simulated Bridge Development Gate
LOCAL
npm run verify:simulated

Runs the app against bridge simulated mode for development velocity, but it does not prove real ArduPilot compatibility.

Simulated Fleet Browser Gate
LOCAL
npm run verify:simulated:fleet

Runs the app against a two-vehicle simulated bridge so fleet UI and WebSocket snapshot handling cannot regress while real multi-SITL coverage is being added.

Real SITL Availability Gate
REAL SITL
npm run verify:sitl:preflight

Fails loudly when ArduPilot SITL is not installed so simulated mode cannot be mistaken for a real MAVLink checkpoint.

Real SITL End-to-End Gate
REAL SITL
npm run verify:sitl:e2e

Runs the browser and bridge against real SITL scenarios before any phase can be claimed compatible with real ArduPilot.

Real SITL Flight Command Gate
REAL SITL
npm run verify:sitl:flight

Commands a real SITL vehicle through the browser into GUIDED, arm, and takeoff so heartbeat-only compatibility cannot be mistaken for flight control.

Real SITL Fleet Telemetry Gate
REAL SITL
npm run verify:sitl:fleet

Requires a real two-copter SITL fleet and proves both vehicle sysids stream through the bridge into the browser fleet board.

Real SITL Parameter Load Gate
REAL SITL
npm run verify:sitl:params

Loads the real ArduPilot SITL parameter list through the browser so the configuration UI cannot pass with simulated or static parameter data.

Real SITL Parameter Write Gate
REAL SITL
npm run verify:sitl:param-write

Writes a controlled simulator parameter, waits for a real PARAM_VALUE confirmation, then restores the original value so write safety is proven end to end.

Real SITL Mission Upload Gate
REAL SITL
npm run verify:sitl:mission-upload

Uploads a browser-created mission to real SITL and waits for MAVLink MISSION_ACK so mission planning cannot be validated by UI state alone.

Real SITL Mission Download Gate
REAL SITL
npm run verify:sitl:mission-download

Uploads a mission, clears local mission state, downloads it back from real SITL, and proves the browser can reconstruct vehicle-side mission items.

Real SITL Mission Clear Gate
REAL SITL
npm run verify:sitl:mission-clear

Clears an uploaded real SITL mission with MAVLink MISSION_CLEAR_ALL and verifies a follow-up download returns no waypoints.

Real SITL Mission Execution Gate
REAL SITL
npm run verify:sitl:mission-execution

Uploads a browser-created mission, switches the real SITL vehicle into AUTO, and requires mission progress telemetry so mission execution cannot be inferred from upload success.

Evidence to capture

Browser state

Proves the tester used the same UI surface operators will use in the field.

Screenshot or screen recording of the page under test.
Bridge log

Proves commands and ACKs crossed the WebSocket to MAVLink bridge boundary.

Terminal log excerpt with timestamp, vehicle id, command, and ACK/result.
Vehicle telemetry

Proves the aircraft or controller emitted real state instead of only static UI data.

Telemetry snapshot with sysid, mode, GPS, battery, heartbeat age, and position.
Post-test export

Keeps a durable artifact for regression review after the physical session ends.

Telemetry JSON/CSV export, SITL log, or ArduPilot dataflash log when available.