mirror of
https://github.com/azaion/autopilot.git
synced 2026-06-21 16:11:10 +00:00
Oleksandr Bezdieniezhnykh
bc40ea7300
Greenfield Steps 1-6 baseline for the autopilot rewrite from legacy Qt/C++ to a Rust workspace. - Remove legacy Qt/C++ tree (ai_controller, drone_controller, misc/camera, python_scaffold, root Dockerfile, autopilot.pro, legacy main.py / requirements.txt). - Add _docs/00_problem (problem, restrictions, acceptance criteria, security approach, input data + fixtures). - Add _docs/01_solution/solution_draft01. - Add _docs/02_document (architecture, system-flows, data_model, glossary, decision-rationale, deployment, 13 component descriptions, tests/ specs, FINAL_report, module-layout). - Add _docs/02_tasks/todo with 47 task specs (AZ-640..AZ-686, one bootstrap + 46 component tasks) and _dependencies_table.md. - Add .cursor/rules/artifact-srp.mdc (single-responsibility rule for canonical _docs artifacts). - Track autodev state in _docs/_autodev_state.md (Step 6 completed, ready for Step 7 Implement). Jira: bootstrap AZ-626; component epics AZ-627..AZ-639; tasks AZ-640..AZ-686. Total complexity 173 points across 12 epics. Co-authored-by: Cursor <cursoragent@cursor.com>
56 lines
4.4 KiB
Markdown
56 lines
4.4 KiB
Markdown
# 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.
|