Sixty Motion Aerospace · Status: Pre-implementation baseline (Phase 0) · Doc set: v0.1.0 · 2026-07-03
UAOP is an operational platform that sits above existing UAV autonomy ecosystems — PX4, ArduPilot, MAVLink, ROS 2, Gazebo — and unifies ground control, deep tuning, simulation, AI diagnostics, fleet operations, and regulatory compliance into one coherent, deployable edge-to-cloud product.
UAOP is not another ground control station and not another autopilot. It does not fork or replace the open ecosystems it integrates; it composes them through adapters and presents a single operational surface.
Professional UAV operations today require six or more disconnected tools: a GCS (QGroundControl / Mission Planner), tuning workflows buried inside the GCS, ROS 2 introspection (RViz/rqt), simulation (Gazebo/SITL), log analysis (Flight Review), and ad-hoc fleet/compliance tooling. Each works alone; none work together. UAOP's thesis: the integration layer is the product.
| Tier | Purpose | Phase |
|---|---|---|
| Workstation | Development, simulation, training | 1 |
| Edge Node | Field operations near the aircraft — the primary product | 1–3 |
| Cloud | Fleet analytics, multi-site enterprise, compliance archive | 4 |
The Edge Node must operate fully without internet connectivity (air-gap mode is a supported deployment configuration, not a degraded one).
Technology spine (fixed — see DECISIONS.md before proposing changes)
- Services: C++17 microservices (Drogon) · Python 3.11 (FastAPI) for AI/simulation orchestration
- Desktop GCS: Qt 6 / QML — professional aerospace UI, dense information, dockable panels
- Messaging: NATS JetStream internal bus · MAVLink v2 · ROS 2 (DDS) · gRPC · WebSocket
- Data: PostgreSQL 15 + TimescaleDB (telemetry to 1000 Hz) · Redis 7 · MinIO
- Simulation: Gazebo + PX4 SITL / ArduPilot SITL
- Compliance: DO-178C-aligned processes, MISRA C++, requirements traceability from day one
All engineering documentation lives in docs/ as a living design system in nine numbered areas (00_Project_Foundation → 08_Developer_Handbook), evolved incrementally with a mandatory critical review after every document — see DOCUMENTATION_PROCESS. Start here:
| Area | Documents |
|---|---|
| Foundation | MASTER_CONTEXT · VISION · MISSION · PRODUCT_REQUIREMENTS |
| Architecture | SYSTEM_ARCHITECTURE · SOFTWARE_ARCHITECTURE · HARDWARE_ARCHITECTURE · EDGE_ARCHITECTURE · CLOUD_ARCHITECTURE · MICROSERVICES |
| Flows & extension | DATA_FLOW · EVENT_FLOW · PLUGIN_SYSTEM · SDK_DESIGN · API_SPECIFICATION |
| Integrations | MAVLINK_INTEGRATION · ROS2_INTEGRATION · SIMULATION_ARCHITECTURE · DIGITAL_TWIN |
| Engines | MISSION_ENGINE · TELEMETRY_ENGINE · TUNING_ENGINE · AI_ENGINE · FLEET_MANAGEMENT |
| Operations | DEPLOYMENT · SECURITY · COMPLIANCE · VALIDATION · TESTING · CI_CD · DEVOPS · DATABASE · LOGGING · OBSERVABILITY |
| UI & standards | UI_GUIDELINES · UX_GUIDELINES · STYLE_GUIDE · REPOSITORY_STRUCTURE · CODING_STANDARDS |
| Governance | DECISIONS · ROADMAP · RISK_REGISTER · COMPETITOR_ANALYSIS · BUSINESS_MODEL |
| Implementation | IMPLEMENTATION_PLAN · PROJECT_STRUCTURE · DOCUMENTATION_PROCESS |
- MASTER_CONTEXT.md is the constitution. On conflict, it wins; conflicts are resolved only through an ADR in DECISIONS.md.
- No technology enters the stack without an ADR stating the engineering reason and the rejected alternatives.
- Flight-critical modules carry
@req:traceability annotations from the first commit — traceability is never retrofitted. - AI output is advisory only: confidence-scored, audit-logged, operator decides.
- Air-gap operation is a permanent requirement. No service may hard-depend on an external network.
uaop-platform/
├── api/proto/ # Protobuf + gRPC contracts (the platform's data constitution)
├── backend/
│ ├── api-gateway/
│ └── services/ # telemetry-engine, mission-engine, ai-engine, compliance-engine, remote-id, ...
├── middleware/ # mavlink-bridge, ros2-bridge
├── frontend/qt-desktop-gcs/
├── infrastructure/docker/compose/
├── tests/ # unit, integration, sitl, compliance
└── docs/ # everything linked above
Full rationale: REPOSITORY_STRUCTURE.md.
This repository is in the documentation-baseline stage. Implementation begins only after the Phase 1 validation gate in ROADMAP.md is agreed.