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>
4.4 KiB
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
missionsservice 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.