Five-layer architecture per DMC_Architektur_und_Design.md: FlightControllerLink abstraction (Mock + MSP stub), protocol-neutral mission domain layer, App-Mode state machine with Ready-to-Fly gate, Drift persistence schema, and placeholder UI screens wired via go_router. App icon generated from design/Y2_pink_dark.svg. Verified with flutter analyze and flutter test. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.7 KiB
Drone Mission Control (DMC)
Mobile App zur Missionsplanung und Flugsteuerung für einen Fixed-Wing-Drohnen-Aufbau (Heewing T1 Ranger, iNAV-Firmware). Wegpunkt-Missionen, Live-Fly-Modus, Point-and-Fly (PnF)-Einzelziel-Anflug.
Vollständige Architektur- und Design-Entscheidungen: DMC_Architektur_und_Design.md — vor jeder größeren Änderung lesen, insbesondere Abschnitt 4 (Entscheidungen inkl. Begründung), Abschnitt 5 (verworfene Alternativen) und Abschnitt 6 (offene Fragen).
Sprachregelung
Konversation und Dokumentation auf Deutsch, Code und UI-Texte auf Englisch.
Projektstruktur
Drone Mission Control.html— lauffähiger Vanilla-JS/Leaflet-Demonstrator, dient als Referenz für UI-Verhalten und bereits gelöste Probleme (Wind-Interpolation, Terrain-Sampling, Fillet-Geometrie, swipe-adjustierbare Wegpunkt-Chips, ...). Bei Unklarheiten über gewünschtes Verhalten zuerst hier nachsehen, bevor neu entschieden wird.design/— Logo-Assets (SVG-Varianten) und Icon-Sketches. Aktuell verwendetes App-Icon:design/Y2_pink_dark.svg.app/— Flutter-Zielarchitektur (Einzelpaket, kein Melos-Monorepo). Siehe unten.test/— Altlast/Sandbox, nicht Teil der aktiven Entwicklung.
Flutter-App (app/)
Fünf-Schichten-Architektur (Doku Abschnitt 2):
lib/
ui/ Screens (plan, fly, settings, library) + geteilte Widgets
app_mode/ App-Mode State Machine (Plan → Connect → Upload → Fly)
domain/ Mission-Domain-Layer (Strategy Pattern: TrackMission, ...)
+ protokollneutrale FlatWaypointList
services/ MissionSyncService, TelemetryService, Drift-Datenbank
transport/ FlightControllerLink-Abstraktion (msp/, mavlink/, mock/)
MVP-Scope (Doku 4.1): nur Android, nur iNAV via MSP, nur WiFi/TCP. MAVLink, USB-Seriell und iOS sind bewusst zurückgestellt.
Kernprinzip: Die Domain-Schicht kennt nur FlatWaypointList, protokollneutral.
Divergenz zu MSP/MAVLink findet ausschließlich im Encoder statt. FlightControllerLink
ist die zentrale Abstraktion; MockFlightControllerLink erlaubt UI-Arbeit ohne
Hardware. MspFlightControllerLink ist aktuell nur ein Gerüst (UnimplementedError)
— die eigentliche MSP-Protokoll-Implementierung (Framing, MSP_SET_WP,
MSP_NAV_STATUS) ist noch offen.
Ready-to-Fly-Gate (Doku 2.2/4.5): Upload + verifiziert + disarmed. Wird in
AppModeCubit.toFly() technisch erzwungen (wirft StateError), nicht nur als
UI-Konvention behandelt.
Persistenz: Drift (SQLite), nicht Hive — siehe Begründung 4.15. Schema in
lib/services/database/app_database.dart. Nach Schema-Änderungen:
dart run build_runner build
(im app/-Verzeichnis; --delete-conflicting-outputs wird von der installierten
build_runner-Version ignoriert und ist nicht nötig).
Entschiedene Pakete (siehe Doku Abschnitt 8): flutter_map + flutter_map_tile_caching
(nicht google_maps_flutter), drift, flutter_bloc + flutter_riverpod (kombiniert:
Bloc für die App-Mode State Machine, Riverpod für reaktive Einzelwerte wie Telemetrie),
go_router.
Noch nicht umgesetzt / bewusst zurückgestellt:
- Eigener MSP-Encoder/Decoder in Dart (4.19) — kein fertiges Paket verfügbar.
- Telemetrie-Verarbeitung in eigenem Isolate (4.21) — erst sinnvoll mit echtem Protokoll-Adapter zu verifizieren.
SurveyAreaMission/SearchAreaMission(Strategy-Pattern vorgesehen, Details offen).- Foreground Service (Android) für Hintergrund-Telemetrie (4.20).
flutter_launcher_iconsist konfiguriert für Android; iOS ist aus MVP-Gründen deaktiviert (ios: falsein derflutter_launcher_icons-Sektion derpubspec.yaml).
Verifikation nach Änderungen
Im app/-Verzeichnis:
flutter analyze
flutter test