# Problem

## What is being built

`autopilot` is the onboard mission executor for a reconnaissance winged UAV. It runs on the airframe's edge compute device. It receives a mission from outside, controls the airframe, drives the camera + gimbal to inspect terrain, and feeds a remote human operator with everything the operator needs to confirm or decline each candidate target.

## What problem it solves

The reconnaissance UAV detects vehicles and military equipment well enough today, but the current high-value targets are **camouflaged positions** — FPV-operator hideouts, hidden artillery emplacements, dugouts masked by branches. These cannot be found by visual similarity to known object classes alone.

Three observation gaps must be closed:

- **Visual sweep coverage** — the camera must follow the planned route and keep eyes on the terrain it overflies, not only on already-known targets.
- **Movement detection on a moving camera platform** — small movers must be surfaced as they appear, even while the airframe and gimbal are themselves moving and even at higher zoom levels.
- **Context-aware target recognition** — a candidate position has to be assessed against scene context (footpaths arriving at it, fresh-vs-stale tracks, concealment patterns), not just shape.

For every candidate it does surface, the system must reach a human operator quickly enough to act, without overwhelming the operator with too many candidates at once, and with confidence-scaled urgency so high-confidence targets are not lost to a low-confidence noise queue.

## Who uses it

- **Operators** — single primary, optional remote secondary. They see camera feed + telemetry + candidate overlays in a browser at a Ground Station and respond with confirm / decline / target-follow / abort. Their decisions must be authenticated, signed, and replay-protected because the radio link is hostile territory.
- **Mission planners** — define the mission region and consume the post-mission diff of what was found.
- **Airframe / Ground-Station crews** — depend on the system to safely abort or RTL when the operator link is lost, and to refuse takeoff if the system is not in a flight-ready state.
- **Suite operations** — need to know when the airframe is in flight so that other ground-side housekeeping (model updates, OTA) does not interfere.

## The operational reality this problem lives in

Stated as fact, not as a design choice. (Design lives in `_docs/01_solution/solution.md` and `_docs/02_document/architecture.md`.)

- The airframe is a reconnaissance winged UAV flying at 600–1000 m altitude.
- Missions cover all four seasons and all common terrain types (winter snow, spring mud, summer vegetation, autumn; forest, open field, urban edges, mixed terrain).
- The link between the airframe and the Ground Station is a modem radio that can degrade or drop entirely mid-flight; the system has to keep flying safely when this happens.
- The operator is remote, watches a browser UI on the Ground Station, and is not co-located with the airframe.
- Primitive (Tier 1) object detection is the responsibility of a separate service running alongside the autopilot on the same compute, accessible over a local interface — this split is fixed at the suite level, not something autopilot can choose.
- Mission state and the area-level map of previously-seen objects come from a separate `missions` service over the network and are reconciled before takeoff and after landing.

## What this system is NOT for

(Scope-clarifying so the reader does not project unrelated concerns onto autopilot.)

- Multi-airframe coordination, fleet management, swarm logic.
- Mission planning across regions.
- GPS-denied navigation algorithms (a separate suite service provides corrected GPS).
- Annotation tooling, model training, dataset curation.
- The operator browser UI itself (the Ground Station hosts it; autopilot feeds it).
- Cloud-hosted inference of any kind.

## Where to read further

- `_docs/00_problem/restrictions.md` — the hard constraints (hardware, environment, regulatory).
- `_docs/00_problem/acceptance_criteria.md` — measurable success criteria.
- `_docs/00_problem/security_approach.md` — threat model + security non-negotiables.
- `_docs/00_problem/input_data/` — runtime inputs + test fixture references.
- `_docs/01_solution/solution.md` — the chosen solution shape (component breakdown, tech stack rationale).
- `_docs/02_document/architecture.md` — the full architectural design.