Ich habe ABRP im Auto in Betrieb seit Dez. 2022. Damals OS 2.4. Zu dem Zeitpunkt gute Erfahrung. Wenig Ausfälle.
Inzwischen OS 2.9. ABRP friert bei jeder Benutzung ein. Ich habe bis auf Easy Park keine zusätzliche App installiert. Ich vermute, das die Leistung des Bordcomputers so auf Kante ausgelegt ist, das ABRP nicht flüssig laufen kann. Es friert ein, stürzt ab, ist nicht bedienbar wenn es startet. Bei 2.8 kam das ab und zu vor, seit 2.9 ist es noch nie gelaufen. Die App ist an sich gut. Es hatte mich am Anfang überzeugt, das die App direkt auf die Fahrzeugdaten zugreifen kann. Das hat am Anfang gut geklappt. Inzwischen ist da der Wurm drin. nun werden im Fahrzeug 3 SOC angezeigt. Einer im Display vorne, einer im ABRP und einer im Hauptdisplay Reichweiten App. Alle drei zeigen unterschiedliche Werte. Ich hoffe das es mal Verbesserung an der Stelle geben wird.
Empfehlen kann ich die Installation im Auto auf jeden Fall im Augenblick nicht.
Jein. Nicht zur Routenplanung und -führung, aber zum Übertragen von am PC geplanten Routen an GM. Und die Echtzeitverbräuche für die Planung kommen aus CSV.
Nachdem selbst die Planung im Auto sehr langsam geworden ist, ist dein Vorgehen das einzig sinnvolle.
Nebenbei: GM stolpert zur Zeit wieder bei der Planung in Verbindung mit den Filtern für die Ladeplanung bei mir einem notwendigen Stop.
Die ABRP Routenplanung am PC funktioniert, da habe ich keine Kritik. Das Tool finde ich gut. Die Integration in das OS des Autos ist der Punkt an dem ich zumindest Funktion erwartet habe. Wobei ich wirklich vermute, das die eingesetzte CPU im Polestar 2 nicht dafür geeignet ist, das Programm (Programme mit mehr Leistungsbedarf) auszuführen. Ich vermute da ist die Leistungsgrenze erreicht.
Die GM Lösung im Fahrzeug läuft aus meiner Sicht nicht wirklich viel besser. Auch da kommt zum Beispiel bei einer kurzen Brücken oder Tunneldurchfahrt, wenn das Display schnell von Hell auf Dunkel und dann wieder auf Hell umstellen muss, dann kommt auch GM aus dem Tritt und friert ein. Dann wieder Anhalten, Applikationen beenden, weiter fahren. Wenn ich Navigation für unbekannte Ziele zuverlässig brauche, dann nutze ich inzwischen nur noch das Handy. (nicht wirklich so gewollt bei einem 70k Fahrzeug)
Ich bin mir nicht sicher, ob das durch Updates noch gelöst werden kann. Inzwischen werden durch Google weitere Applikationen die im Fahrzeug nicht genutzt werden müssen, zwangsweise auf das Gerät geladen, Youtube wurde beim letzten Update als neue Möglichkeit angeboten. Ist aber etwas anders, Youtube wurde installiert und kann auch nicht entfernt werden. Warum? 
Beim Fahren kann es nicht genutzt werden, beim Laden sollte ich wählen können ob oder was ich nutze.
Hallo zusammen,
ich bin großer Fan von ABRP, insbesondere, da ich auf Langstrecken gerne ausschließlich mit IONITY und SuC fahre. Soweit, so gut. Leider friert ABRP bei mir ständig ein, ist richtig langsam und/oder lässt sich irgendwann gar nicht mehr bedienen. Früher lief ABRP bei mir performant und alles war OK. Wie sind Eure Erfahrungen? Was mache ich falsch?
… was mich auch triggert ist die Tatsache, das es auf meinem 5+ Jahre alten Samsung Tab super läuft. Ist die Hardware im Polestar 2 tatsächlich so träge und lahm? Macht AAOS etwas grundlegend anders als Android, wie wir es vom Tab kennen?
Geht mir genauso 
ABRP ist eine relativ schlecht optimierte Web-Anwendung, deshalb läuft das auf manchen Geräten nicht flüssig.
Da bleibt wohl nur die bekannte Lösung:
Planung ABRP
Übertrag nach GM im Auto
Navigation mit GM
Ja schon, ist aber nur bedingt toll, da sich auf langen Strecken die Parameter auch ändern können. Im Grunde total schade, denn mit ABRP ist/war der Polestar immer der BEV mit der besten Ladeplanung der Welt.
Das Zeit m.E., dass es wohl nicht an der Hardware liegt, denn wenn die Software vorher performant war und es jetzt nicht mehr ist, die Hardware hat sich ja nicht seit dem „zurück entwickelt“ 
Ja wäre zu vermuten, da die App, also dessen Funktion auf IOS, AAOS, Android und Web läuft. Schade nur, das die Hardware im Polestar das nicht mehr schafft. Wie gesagt mein altes Tab kommt immerhin noch damit klar.
Worauf stützt du dich mit dieser Aussage?
Oder anders gefragt: hat die Tatsache, dass ABRP im Polestar wiederholt Probleme mit der Performance hat(te), zwingend und alleine mit der verbauten Hardware zu tun?
Ich glaube, mal irgendwo aufgeschnappt zu haben, dass sich „mangelhaft“ Programmiertes auch auf der besten Hardware nicht wirklich gut nutzen lässt…und umgekehrt kann auch in die Jahre gekommene Hardware erstaunliche Performance bieten, wenn die Softwareentwickler mit den Ressourcen smart haushalten.
Von zwingend und allein war da nicht die Rede. Bereits weiter ob ist beschrieben, das die Tatsache, das ABRP auf vielen System identisch läuft, vermuten lässt, das es nicht für AAOS optimiert ist und sicherlich keine native AAOS-App ist. Wundern tut es mich aber schon, das ABRP sogar auf uralten Tabs und Smartphones *rund läuft.
Habe hier mal was im Internet gefunden: Intel liefert den Prozessor
Rechenleistung für alles liefert ein SoC von Intel, genauer gesagt eine in 14 nm gefertigte CPU der Baureihe A3900 (PDF), die speziell für das Automotive-Segment entwickelt wurde und mit entsprechenden Zertifizierungen für Temperaturen und Langlebigkeit kommt. Intern läuft diese SoC-Generation unter dem Namen Apollo Lake und nutzt CPU-Kerne der Goldmont-Generation. Intel hatte Apollo Lake im April 2016 zur Frühjahrsausgabe des IDF in Shenzhen, China vorgestellt. Obwohl das SoC damit schon einige Jahre auf dem Buckel hat, fiel der Chip im Test nicht negativ mit mangelnder Leistung auf. Reserven gibt es aber ebenso wenig. Android Automotive OS im Polestar 2 im Test - ComputerBase
Am Ende bringt das hätte, könnte, wäre auch nichts. Ich hatte gehofft etwas falsch gemacht zu haben um hier eine Lösung zu finden. Scheint aber so, als wäre ich mit dem Problem nicht allein.
ABRP ist mit einem plattformabhängigem Toolkit programmiert, der einen wahnsinnigen Overhead erzeugt. Eine native (Browser-)App wäre deutlich performanter.
Und vielleicht wird es mittelfristig sowieso Veränderungen geben, je nach dem, ob der Deal wie angekündigt zustande kommt und wie sich dies dann auf die weitere Entwicklung von ABRP unter den neuen Besitzern auswirkt.
EDIT: offenbar ist der Deal zustande gekommen…siehe auch hier.
Die hätte aber wahrscheinlich keinen Zugriff auf die Hardware… Also eine Browser-App
Aber wer weiß vll ist das auch der Knackpunkt… Wenn das schlecht programmiert ist (zu häufige Abfragen oder vll sogar Deadlocks, je nach dem wie die Ressourcen abgefragt werden), kann man eine Software auch ziemlich aus ausbremsen.
Aber das ist natürlich auch nur Spekulation.
Habe gerade einige Apps deinstalliert wie Chargemap, Fireplace, Spiele. Auch der CarStatsViewer hat nun keinen Zugriff mehr.
Siehe da, ABRP läuft rund, flott, stützt nicht mehr ab, ruckelt nicht mal mehr.
Mir unbegreiflich, mag das gar nicht glauben. Wäre jedenfalls zu schön um wahr zu sein.
Abwarten, bis der Speicher wieder voll läuft.
Ich schmeiße meine Vermutungen als jemand, der sich jetzt ein halbes Jahr recht intensiv mit AAOS beschäftigt hat, auch mal mit in den Ring:
Ich denke, es ist eine Kombination verschiedener Faktoren.
Ja, der SoC von Intel ist nicht mehr wirklich taufrisch. Sollte aber für so ein Android-System in der Regel hinreichend performant sein. Die Frage, warum Hersteller nicht „einfach“ übliche Smartphone-Hardware in ihre Autos bauen, wurde von Tobias in seiner Recherche ja auch schon benannt: Es gibt eine ganze Bandbreite von Anforderungen, die an Hardware im Automotive-Bereich gestellt werden. Das muss eben erst mal jemand verifizieren und nachweisen. Da kommt erst jetzt langsam Bewegung rein, seit dem Qualcom da in den Markt eingestiegen ist und spezielle Automotive-Plattformen anbietet.
Auch darf man nicht vergessen, dass AAOS anders als ein Smartphone vom Auto so einiges aufdiktiert bekommen kann. Das betrifft vor allem das Power Management. Das wird hinsichtlich ABRP sicher nur ein tangentiales Problem sein, ich wollte es aber mal erwähnt haben.
Aber der größte Schwachpunkt von ABRP wird vermutlich die plattformübergreifende Natur der App sein. Um eine App mit der selben Code Base auf Android, iOS und im Browser laufen zu lassen, wird ein wahnsinniger Overhead notwendig sein (zumindest wenn es nicht einfach nur eine embedded Web App ist). Für ein kleines Team von Programmierern macht es sowas natürlich einfach, eine App möglichst vielen Usern zur Verfügung zu stellen, auf der anderen Seite gehen solche Apps sehr verschwenderisch mit Systemressourcen um. Wie gut sowas funktioniert ist dann auch von Gerät zu Gerät unterschiedlich.
Solche Erfahrungen musste ich beruflich auch kürzlich machen, als ich eine IOT-App eines der Produkte meines AG testen sollte: Auf einem iPhone 6 lief die App sehr flüssig, auf einem Xiaomi Redmi Note 11 (also ein relativ modernes Android-Handy) dagegen hat sich die selbe App mächtig einen zurechtgeruckelt.
Ich denke die größte Achillesferse des CD im P2 ist die Grafikleistung. Solange man native Android-Apps verwendet ist das kein großes Problem. Denn diese sind in der Regel gut darauf optimiert, wie die UI-Elemente dargestellt werden. Benutzt man ein Framework, dann ist diese Optimierung schnell dahin, da diese Frameworks verschiedenste Grafik-APIs ansprechen können müssen. Und das kann sehr schnell sehr rechenintensiv werden. Vor allem dann, wenn man am liebsten von Android 4 bis Android 13 alles unterstützen will. Je weiter man zurück geht, ohne auf moderne Features zu verzichten, desto mehr Abstraktionsebenen kommen dazu.
Viele Software-Entwickler tendieren heutzutage dazu, Leistung als beinahe „unendlich“ anzunehmen, und Optimierungen entsprechend zu vernachlässigen. Kombiniert man das mit einer, ich nenne es mal „anwendungsoptimierten CPU“, dann ist die Performance von ABRP auf dem CD das Ergebnis.
Kurzgesagt: Es ist schwierig hier jemandem den schwarzen Peter zuzuschieben. Überschaubare Leistung und mangelhafte Optimierung sind für sich alleine selten problematisch, treffen sie zusammen, hat man allerdings ein Problem. Hier wird das CD einfach nicht für so rechenintensive Apps ausgelegt sein. Das merkt man ja z.B. auch an den Spielen, die ähnlich schlecht optimiert sein werden.
Dass der VHAL bzw. die Art, wie ABRP darauf zugreift, ein Problem sein könnte, denke ich auch nicht. Dieser Teil des Systems ist in meinen versuchen immer sehr stabil und schnell gewesen. Die Performance einer Android-App steht und fällt in den meisten Fällen mit der Optimierung der UI. Beispiel: Ich kann im CSV einen Log mit 50.000 Zeilen innerhalb von einer Sekunde aus einer Datenbank lesen und im Speicher bereithalten. Eine Darstellung wäre vor einer drastischen Optimierung unmöglich gewesen. Bereits ab wenigen tausend Zeilen musste man teils Minuten warten. Durch cleveres verwenden der Android-eigenen UI-Optimierungen habe ich die Darstellungsgeschwindigkeit um das mehrfach hundertfache beschleunigt, bzw. die Darstellung überhaupt erst ermöglicht. Damit will ich nicht sagen, dass ich eine geniale Lösung gefunden habe, sondern meine vorherige einfach nur sehr schlecht war 
Edit: Ups, so lang sollte das ganze doch gar nicht werden … 
Egal wie flüssig ABRP laufen sollte - ohne Vorkonditionierung in meinen Augen nutzlos. Planen kann ich auch auf jedem anderen Gerät. Oder hat sich daran was geändert?
