Aero Arc Ops

Aero Arc Ops is a Flutter operations dashboard for monitoring distributed aerial infrastructure. The app presents a command-center view of relay health, agent activity, service registration, compute node utilization, and live telemetry in a responsive dark interface.

Aero Arc Ops dashboard overview

Provide operators with a fast, readable surface for understanding whether the Aero Arc network is healthy and where attention is needed. The primary readiness, aircraft, operations, preflight, conformance, maintenance, records, intent, and aircraft-map views consume typed Aero Arc API read models.

• Responsive shell with desktop sidebar navigation and a mobile drawer.
• System overview with status cards, latency and throughput charts, node heartbeats, and recent events.
• Relay monitoring with relay counts, health states, node counts, regions, message rates, and heartbeat freshness.
• Aircraft fleet view with durable identity, readiness, active intent, registry placement, and telemetry recency.
• Live operations view with connected/stale/offline/unmapped state and independently timestamped position, battery, vehicle, system, HUD, extended-state, and GPS samples.
• Live conformance view with assignment condition, monitoring freshness, recording durability, active findings, evaluated axes, and evaluation/frame provenance read from Registry through the API.
• Aircraft map that combines replay, operational volumes, conformance evidence, and a two-second live tracker. Fresh position samples move and rotate the aircraft marker, build a bounded recent breadcrumb, and produce a clearly labeled ten-second constant-velocity projection. Follow mode can be paused for manual map inspection, and a failed refresh retains the last known track while explicitly marking the update delayed.
• Compute nodes with CPU, memory, disk, region, uptime, and per-node utilization bars.
• Telemetry dashboard with latency, throughput, error rate, uptime, trend charts, system health radar, and fleet activity.
• Events and settings placeholders for timeline review and environment configuration workflows.

• Flutter 3.41+
• Dart 3.11+
• Material 3
• Custom CustomPainter charts
• Multi-platform Flutter project targets: web, Android, iOS, macOS, Linux, and Windows

flutter pub get
flutter run -d chrome --dart-define=AERO_ARC_API_BASE_URL=http://localhost:8080

For WSL or another environment where Flutter cannot launch Chrome directly, start the web server and open http://localhost:7357 in your browser:

make web

Override the defaults when needed, for example:

make web WEB_PORT=8081 API_BASE_URL=http://localhost:8080

For another target, replace chrome with an available device from:

flutter devices

Run the local checks before pushing changes:

flutter analyze
flutter test
flutter build web --release

lib/
 api/
 aero_arc_api.dart # Typed HTTP client and configurable API origin
 models/
 aero_arc_models.dart # Workflow and dashboard read models
 live_aircraft_state.dart # Registry plus independent telemetry groups
 main.dart # App shell, theme, routing, responsive navigation
 pages/
 overview_page.dart # System status, charts, heartbeats, event summary
 relays_page.dart # Relay health and operational status
 agents_page.dart # Agent fleet table and mission state
 registry_page.dart # Live Operations and intent posture
 aircraft_map_screen.dart # Live state, replay, intent, and conformance map
 nodes_page.dart # Compute node health and utilization
 telemetry_page.dart # Performance metrics and custom charts
 events_page.dart # Events placeholder
 settings_page.dart # Settings placeholder
 widgets/
 section_page.dart # Shared placeholder page layout

The Operations page reads live_aircraft from GET /api/v1/operations so a fleet refresh is a single API request. Aircraft detail reads GET /api/v1/aircraft/{aircraft_id}/state alongside the existing map endpoint.

Registry status and telemetry status are intentionally distinct. Every MAVLink group retains its own recorded_at and fresh/stale status; missing groups remain missing rather than being filled from an unrelated message. The UI uses the API's configured freshness classification and shows each group's sample age. See test/fixtures/live_aircraft_state.json for an executable example.

If the live-state request fails, the aircraft map continues to render durable aircraft, replay, intent, volume, and conformance data with an explicit unavailable state.

Operations and Conformance consume the API's Registry-backed projections. The condition (conforming, suspected, or non_conforming), monitoring status, and recording status are separate signals and are displayed independently. A clear evaluated axis is evidence that a check ran; it is not an active finding. The client does not invent freshness or conformance thresholds.

The Conformance page refreshes the batch dashboard every three seconds. Its Evaluate API sample action is an explicit legacy/single-sample diagnostic; normal live results are produced by Agent telemetry flowing through Relay, Conformance, and Registry. Missing optional live fields degrade locally without hiding durable conformance history.

The diagnostic action is hidden in normal builds. Enable it only for a local diagnostic session with --dart-define=AERO_ARC_ENABLE_SAMPLE_CONFORMANCE=true; submitted samples are persisted and can create conformance findings.

The repository includes a local WSL-oriented runner for watching one real ArduCopter SITL instance through the full observation path. It builds sibling Aero Arc repositories, starts isolated PostGIS and InfluxDB containers, starts Registry, Relay, Conformance, API, Agent, Ops, and SITL, and then creates the aircraft, battery installation, intent, volume, and flight through API routes. It does not load fixture or seed data.

Prerequisites are Docker Compose, Flutter, Go, OpenSSL, tmux, and an existing ArduPilot checkout with a built ArduCopter SITL binary. With the Aero Arc repositories and ardupilot checked out beside this repository, run:

make sitl-up
make sitl-status

Open http://localhost:7357. sitl-up activates a ten-minute plan and gives Conformance a separate 24-hour monitoring authority. Crossing the planned end therefore produces an overdue temporal-deviation state; it does not silently stop monitoring or mark the flight complete. Override these windows with AERO_ARC_SITL_PLAN_MINUTES and AERO_ARC_SITL_MONITOR_HOURS.

The currently implemented Aero Arc command plane supports authenticated ARM and DISARM commands:

make sitl-arm
make sitl-disarm

Movement commands are still issued from MAVProxy. Start a takeoff and waypoint demonstration, or attach to the interactive console:

make sitl-demo-flight
make sitl-console

Land first, observe the landing/disarm, and only then complete the operational lifecycle:

make sitl-land
make sitl-complete
make sitl-down

sitl-complete is deliberately explicit: it completes the API intent and clears the matching Agent context, while the flight remains active if no authoritative flight-completion signal has been implemented. Automatic Agent-driven flight completion and broader guided movement commands remain command-lifecycle work, not behavior simulated by this runner.

Source checkouts can be selected without editing the script, for example AERO_ARC_API_SOURCE=/tmp/aero-arc-api-feature make sitl-up. Runtime binaries, certificates, WAL, logs, and PID files live under /tmp/aero-arc-sitl-observer by default.

• Add authenticated API sessions and role-aware controls.
• Add event filtering, severity grouping, and timeline drill-downs.
• Add relay and agent detail pages backed by registry read endpoints.
• Add golden tests for responsive dashboard layouts.

Generated build output, local editor files, Flutter tool caches, and machine-specific platform files are ignored. Source, platform scaffolding, assets, tests, and pubspec.lock are tracked so the app can be reproduced consistently.