ExoMy_Cuno/ROUTENPLANUNG_TODO.md

# Routenplanung To-do

Stand: 24.05.2026

## Aktueller Stand

- Karten-Tab in `admin.html` vorhanden
- Wegpunkte können gesetzt werden
- Wegpunkte können verschoben werden
- Wegpunkte können gelöscht werden
- Klick auf die Route fügt einen Wegpunkt zwischen zwei vorhandenen Wegpunkten ein
- Route kann unter Namen gespeichert werden
- Gespeicherte Route kann geladen werden
- Gespeicherte Route kann gelöscht werden

## Offene Produktentscheidung

Noch nicht final entschieden ist, wie die Fahrart zwischen zwei Wegpunkten festgelegt wird:

- Vollautomatisch aus der Richtungsänderung ableiten
- Pro Wegpunkt manuell festlegen
- Automatik als Standard, aber pro Wegpunkt übersteuerbar

Aktuell bevorzugte Idee:

- Automatik als Standard
- Pro Wegpunkt optionaler Override

## Geplante Logik für Fahrart-Vorschlag

Beim Klick auf einen Wegpunkt soll sofort eine Empfehlung berechnet werden:

- unter `20°`: einfach `Ackermann`
- `20° bis 60°`: engerer `Ackermann-Bogen`
- über `60°`: erst `Turn on Point`, danach `Ackermann`

Wichtig:

- Die Winkeldifferenz soll aus den benachbarten Segmenten berechnet werden
- Bei inneren Wegpunkten: Richtung `vorheriger Punkt -> aktueller Punkt` gegen `aktueller Punkt -> nächster Punkt`
- Beim ersten Wegpunkt: optional Richtung `Rover -> Wegpunkt` gegen `Wegpunkt -> nächster Punkt`
- Beim letzten Wegpunkt: keine automatische Weiterfahr-Empfehlung oder eigener Sonderfall

## Geplante UI-Erweiterungen

- Klick auf Wegpunkt zeigt Popup
- Im Popup soll zusätzlich zur Löschfunktion die berechnete Fahrart-Empfehlung stehen
- Im Popup soll klar stehen:
  - berechneter Winkel
  - empfohlene Fahrart
  - kurze Begründung
- Später optional:
  - manuelle Auswahl `Ackermann`
  - manuelle Auswahl `Turn on Point`
  - manuelle Auswahl `Ackermann-Bogen`
  - manueller Override `Automatik`

## Wegpunktlogik im Detail

Für jeden Wegpunkt sind später diese Fragen wichtig:

- Wie wird der Punkt angefahren?
- Muss am Punkt gestoppt werden?
- Muss am Punkt neu ausgerichtet werden?
- Soll direkt in das nächste Segment übergegangen werden?

Mögliche Varianten:

- `nur passieren`
  - Punkt gilt als erreicht, wenn der Rover den Radius schneidet
- `präzise anfahren`
  - Punkt gilt erst als erreicht, wenn der Rover im Radius steht und genug verlangsamt hat
- `stoppen und neu ausrichten`
  - Punkt wird erreicht, dann `Turn on Point` auf gewünschte Richtung

## Segmentlogik

Später soll die Route nicht nur als Punktliste gesehen werden, sondern als Folge von Segmenten:

- Segment 1: `Start -> WP1`
- Segment 2: `WP1 -> WP2`
- Segment 3: `WP2 -> WP3`

Für jedes Segment interessant:

- Segmentlänge
- Zielrichtung
- empfohlene Fahrart
- erlaubte Geschwindigkeit
- Abbruchbedingungen

## Marsrover-inspirierte Denkweise

Für den ExoMy sinnvoll:

- nicht die ganze Route als einen Block behandeln
- sondern Abschnitt für Abschnitt
- vor jedem neuen Abschnitt bewerten:
  - Zielrichtung
  - Platzverhältnisse
  - gewünschte Genauigkeit
  - Sicherheitslage

Das bedeutet:

- Menschen planen die Route
- der Rover arbeitet Segment für Segment ab
- am Übergang zum nächsten Segment wird neu bewertet

## Vorschlag für Standardregeln

Erste Regelbasis für die spätere Automatik:

- unter `20°`: `Ackermann`
- `20° bis 60°`: `Ackermann-Bogen`
- über `60°`: `Turn on Point`, danach `Ackermann`

Zusätzliche mögliche Regeln:

- wenn Wegpunkt sehr nah am nächsten liegt:
  - lieber präzise neu ausrichten
- wenn Toleranzradius klein ist:
  - langsamer anfahren
- wenn wenig Platz oder Hindernisse:
  - eher `Turn on Point`

## Pro-Wegpunkt-Override

Wahrscheinlich beste spätere Lösung:

- Standardmäßig entscheidet die Automatik
- pro Wegpunkt kann man die Entscheidung überschreiben

Mögliche Werte:

- `automatik`
- `ackermann`
- `ackermann_bogen`
- `turn_on_point`

## Was noch fehlt, bevor der Rover wirklich fahren kann

- sauberes Routenformat für den Rover
- Status je Wegpunkt:
  - `offen`
  - `aktiv`
  - `erreicht`
  - `übersprungen`
  - `fehler`
- Status je Route:
  - `bereit`
  - `läuft`
  - `pausiert`
  - `abgebrochen`
  - `fertig`
- Start/Stop/Pause in der GUI
- Anzeige des aktuell aktiven Wegpunkts
- Anzeige der aktuell gewählten Fahrart

## Sensorik-Fragen

Noch offen für die spätere echte Fahrfunktion:

- Woher kommt das Heading?
  - IMU
  - GPS-Bewegungsrichtung
  - Fusion aus beidem
- Wie genau ist das GPS im Zielbereich?
- Brauchen wir zusätzlich Odometrie für den Nahbereich?
- Ab welcher Geschwindigkeit ist GPS-Kurs überhaupt brauchbar?

## Sicherheitsfragen

Vor echter Abarbeitung der Route klären:

- Was passiert bei GPS-Verlust?
- Was passiert bei ROS-Verlust?
- Was passiert bei großem Positionssprung?
- Was passiert, wenn ein Wegpunkt nicht erreicht wird?
- Wann wird die Route automatisch abgebrochen?
- Muss der Rover bei Fehler immer sofort stoppen?

## Spätere Komfortfunktionen

- Richtungspfeil oder Segmentrichtung in der Karte anzeigen
- Wegpunktnummern und geplante Fahrart direkt in der Karte
- Route duplizieren
- Wegpunktreihenfolge manuell ändern
- Route exportieren/importieren
- Routenkommentar oder Missionsname
- Toleranzradius pro Wegpunkt einstellen
- Geschwindigkeit pro Segment oder Wegpunkt einstellen

## Späterer Unterbau für echte Rover-Route

Wenn aus der Planungsroute später eine ausführbare Rover-Route wird, soll das Datenformat erweitert werden:

- `name`
- `waypoints`
- pro Wegpunkt:
  - `id`
  - `lat`
  - `lon`
  - `radius_m`
  - `mode` oder `mode_override`
  - optional `heading_deg`
  - optional `stop_at_waypoint`
  - optional `arrival_action`
  - optional `speed_limit`
  - optional `notes`

## Technische Folgefragen

- Woher kommt die zuverlässige aktuelle Fahrtrichtung?
  - nur GPS ist bei langsamer Fahrt oft ungenau
  - später besser mit IMU oder gemittelter Bewegungsrichtung
- Wann gilt ein Wegpunkt als erreicht?
  - Toleranzradius in Metern
- Soll vor jedem neuen Segment neu entschieden werden?
  - wahrscheinlich ja

## Nächster sinnvoller Schritt

1. Winkelberechnung zwischen Routensegmenten implementieren
2. Fahrart-Vorschlag nach obiger Tabelle erzeugen
3. Vorschlag im Wegpunkt-Popup anzeigen
4. Danach entscheiden, ob wir direkt einen manuellen Override pro Wegpunkt einbauen

## Nicht vergessen

- Die Route soll später leicht wiederzufinden und fortsetzbar sein
- Entscheidungen nicht still im Code verstecken, sondern in der GUI sichtbar machen
- Bei kleinen Rover-Geschwindigkeiten keine Scheingenauigkeit vortäuschen
- Lieber klare, nachvollziehbare Regeln als zu frühe komplizierte Autonomie