# 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