MG4 · KLEVE
Navigation
Warum überhaupt ein eigenes Navigationssystem?
Ein normaler Routenplaner kennt Straßen, Geschwindigkeiten und Verkehr. Für eine längere Fahrt mit einem Elektroauto fehlt damit aber noch der entscheidende Teil: Wie viel Energie braucht dieser MG4 auf dieser Strecke, mit welcher Reserve kommt er an und wo sollte er laden, wenn das Ziel nicht sinnvoll in einem Stück erreichbar ist?
Das MG4-Kleve-Backend kannte schon vorher Fahrzeugstatus, Fahrten, Ladungen und Verbrauch. Deshalb musste die Navigation nicht mit einem pauschalen WLTP-Wert beginnen. Aus vorhandener Telemetrie, gemessener Fahrpraxis und der berechneten Strecke entstand Schritt für Schritt eine eigene EV-Logik.
Was heute während der Fahrt zusammenkommt
Der Weg: vom ersten Routing zum eigenen Stack
Valhalla: das Herzstück des heutigen Routings
Der selbst gehostete Valhalla ist mehr als ein Ersatz für eine fremde API. Er macht es möglich, Straßenrouting und die eigene EV-Logik sehr eng zu verbinden und die benötigten Routendetails reproduzierbar aus demselben Straßennetz zu beziehen.
EV-Routing: die Route wird zum Energieprofil
Nach der Straßenberechnung beginnt die MG4-spezifische Arbeit. Das Backend ermittelt aus der Strecke einen zu erwartenden Energiebedarf und leitet daraus ab, wie sich der SOC bis zum Ziel oder bis zum nächsten Ladestopp entwickeln sollte.
| Geschwindigkeit | Persönliche Verbrauchsprofile unterscheiden Stadt, Landstraße und Autobahn, statt mit nur einem Durchschnittswert zu rechnen. |
|---|---|
| Höhe & Rekuperation | Steigungen erhöhen den Energiebedarf, Gefälle können einen Teil zurückbringen. Das Höhenprofil wird deshalb entlang der Route ausgewertet. |
| Wind & Temperatur | Gegen- oder Rückenwind und äußere Bedingungen können die Reichweitenprognose merklich verschieben. |
| Verkehr | Andere reale Geschwindigkeiten ändern nicht nur die ETA, sondern auch den erwarteten Verbrauch. |
| Live-SOC | Die Planung startet mit dem tatsächlichen Fahrzeugzustand und kann die berechnete Entwicklung während der Fahrt mit der Realität vergleichen. |
| Reserve | Persönliche Mindest- und Ziel-SOC-Werte entscheiden darüber, wann eine Fahrt noch ohne Stopp sinnvoll ist. |
Ladeplanung: nicht irgendeine Säule, sondern ein sinnvoller Stopp
Erst wenn die Energieprognose zeigt, dass die gewünschte Zielreserve nicht erreicht wird, sucht die Planung nach geeigneten Ladestationen. Maximale Ladeleistung allein genügt dabei nicht.
| Position & Umweg | Der Ladepunkt muss sinnvoll zur Route liegen und darf die Reise nicht durch einen unnötigen Abstecher verschlechtern. |
|---|---|
| Ankunfts-SOC | Der erwartete Akkustand am Ladepunkt muss zur eingestellten Mindestreserve passen. |
| Ladeziel | Es wird nicht pauschal bis 100 % geplant, sondern nur so weit, wie es für den nächsten Abschnitt sinnvoll ist. |
| Anbieter & Tarife | Persönlich hinterlegte Anbieter, Abos und Preise können in Auswahl und Kostenbetrachtung einfließen. |
| Öffnungszeiten | Ist ein Standort zur geplanten Ankunft geschlossen, wird er nicht durch künstliche Wartezeit passend gemacht, sondern verworfen. |
| Alternative | Fällt ein geplanter Stopp aus, kann die verbleibende Fahrt mit einem anderen Kandidaten neu geplant werden. |
Welche Systeme zusammenspielen
| SAIC / iSMART | Fahrzeugstatus und Telemetrie des MG4; im Projekt über den vorhandenen SAIC-Poller angebunden. |
|---|---|
| OpenStreetMap | Offene Straßen- und Kartendaten als wesentliche Grundlage des selbst gehosteten Routings. |
| Valhalla | Heute primärer, selbst gehosteter Routing-Stack für Route und zahlreiche Streckenattribute. |
| TomTom | Live Traffic Flow, Incidents und für einzelne Planungsfunktionen weitere aktuelle Ortsinformationen. |
| ORS / GraphHopper | Waren wichtige Schritte in den frühen Routing-Versionen und haben viele Grundlagen des späteren eigenen Stacks ermöglicht. |
| Overpass / Nominatim | OSM-Abfragen und Geocoding ergänzen dort, wo zusätzliche Straßen- oder Ortsinformationen benötigt werden. |
| Piper TTS | Selbst gehostete Sprachsynthese für die Navigationsansagen. |
| PostgreSQL | Speichert Fahrzeug-, Fahr-, Lade-, Tarif- und Planungsdaten im Backend. |
| Docker & Caddy | Die Serverdienste laufen containerisiert; Caddy übernimmt den HTTPS-Zugang zum Backend. |
| Android Auto | Die sichtbare Fahrzeugschnittstelle mit NavigationTemplate, Manövern, ETA und Kartenbedienung. |
Vereinfacht sieht die Architektur so aus
Reichweite als echte fahrbare Fläche
Auch die Reichweitenansicht im Admin-Bereich nutzt inzwischen Valhalla. Statt nur einen Kreis um den Standort zu zeichnen, werden tatsächlich fahrbare Richtungen mit dem verfügbaren Energie-Budget geprüft. Die Kontur wurde von wenigen festen Richtungen zu einer adaptiven Berechnung mit typischerweise etwa 42 bis 50 energiegeprüften Grenzrichtungen weiterentwickelt.
Das ist typisch für das ganze Projekt: erst eine Funktion zum Laufen bringen, dann mit echten Daten und Fahrten prüfen und genau dort nachbessern, wo die Realität noch nicht gut genug abgebildet wird.
Planung gegen Realität
Die Navigation endet nicht mit dem Ankommen. Für über MG4 Navigation gestartete Fahrten kann die App anschließend vergleichen, wie gut Strecke, Energiebedarf und Ziel-SOC vorhergesagt wurden. So werden zu optimistische oder zu pessimistische Annahmen sichtbar und die nächsten Anpassungen können auf echten Fahrten statt auf Bauchgefühl beruhen.
Was am Ende die meiste Arbeit gemacht hat
Die großen Überschriften klingen einfach: Routing, Traffic, Laden, Android Auto. In der Praxis steckten die schwierigsten Arbeiten oft in kleinen Grenzfällen. Eine Head Unit verliert nach USB-Reconnect ihren Zustand. Beim Pan verändert Android Auto die nutzbare Kartenfläche. Eine formal mögliche Wende ist auf der Straße praktisch unsinnig. Traffic muss nicht nur empfangen, sondern auf das richtige Straßensegment gemappt werden. Ein Ladepunkt ist zwar vorhanden, aber zur geplanten Ankunftszeit geschlossen.
Deshalb entstand das Navi als lange Folge aus Testfahrt, Log-Auswertung, isoliertem Fix und erneutem Test. Gerade weil Routing, Navigation, Polling, Traffic und Ladeplanung inzwischen eng zusammenarbeiten, ist ein wichtiges Prinzip, neue Funktionen möglichst ohne Nebenwirkungen auf bereits funktionierende Bereiche einzubauen.
Das eigentliche Ziel
Nicht „noch eine Navi-App“ bauen und auch nicht Google Maps kopieren. Interessant ist die Verbindung: Das Auto liefert seinen echten Zustand, das eigene Backend kennt die bisherige Fahrpraxis, Valhalla berechnet das Straßennetz, Live-Traffic verändert die Bedingungen und die Ladeplanung setzt daraus eine komplette EV-Reise zusammen. Handy und Android Auto sind am Ende die sichtbaren Oberflächen dieses Systems.
Und genau daran wird weitergebaut: eine Navigation, die den eigenen MG4 und die dahinterliegenden Daten möglichst gut kennt.