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“ 
1 „Gefällt mir“
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.
1 „Gefällt mir“
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.
3 „Gefällt mir“
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.
5 „Gefällt mir“
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.
1 „Gefällt mir“
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 … 
13 „Gefällt mir“
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?
Im Prinzip ja. Allerdings habe ich den Eindruck, dass ein Handy mit ABRP im Auto sich mit dem ABRP im Auto schlecht verträgt. Besser iist es m Auto zu planen bzw. einen gespeicherten Plan aufzurufen.
Na die braucht es ja nur im Winter. Aktuell sehe ich auch 150kW ohne Vorkonditionierung.
Perfekt, danke für die umfangreiche und qualifizierte Antwort. Finde das immer wieder beeindruckend, wie tief Du in dem Thema steckst.
Habe gestern einige Apps entfernt, Spiele, Chargepoint, Fireplace, Fahrtenbuch ausgeschaltet, aber auch dem CarStatsViewer alle Rechte entzogen, Speicher leer und nicht mehr gestartet.
Wie auch immer, ABRP läuft tatsächlich nun flüssig, ohne Ruckeln und TipTop flott. Könnte es sein, dass sich diverse Apps gegenseitig bremsen? Vielleicht machen die sich im Speicher breit (auch nach dem Systemboot ohne die Apps aufzurufen), vielleicht behindern sie sich gegenseitig bei Zugriff auf SoC, Standort, … ???
Ich mag das kaum glauben, aber ABRP läuft nun tatsächlich rund. Konnte das gestern ca. 2 Stunden lang testen. Habe öfters Zielführung abgebrochen, verändert, ein 1000km entferntes Ziel auf der Route angegeben, … 
Planung mit ABRP in eigenem Konto auf
Smartphone
Tablet
Desktop
speichern.
ABRP im Auto aufrufen, gespeicherten Plan aufrufen und dann an GM übertragen.
(Da klappt es dann auch häufig mit er Vorkonditionierung.)
Navigieren mit GM.
2 „Gefällt mir“
Ich habe grade selber nach Monaten mal wieder mit ABRP im Auto herumgespielt. Was ich sehr seltsam finde: Die Grafikintensive 3D-Karte reagiert eigentlich sehr flott und ohne ruckeln, man kann sie schnell zoomen, verschieben, neigen, drehen, etc. Aber das User Interface in den Menüs ist eine Katastrophe. Eine Menüsektion auszuklappen dauert ein paar Sekunden, das Popup für die Wahl des dunklen Themas hat über 10 Sekunden gebraucht um zu erscheinen.
Es ist mir echt ein Rätsel, wie eine eigentlich so simple UI dermaßen träge sein kann …
Ich will nicht ausschließen, dass CSV einen gewissen Performance-Impact hat, aber es würde mich schon sehr wundern. Wenn die App das ganze System träge machen würde, und irgendwas blockt, dann müsste man das ja auch in anderen Apps merken.
1 „Gefällt mir“
Die Performance Probleme mit ABRP hatten wir schon lange vor deiner tollen Arbeit mit CSV, und sie sind damit aus meiner programmiertechnisch sehr laienhaften Einschätzung quasi sytstemimanent, so dass ich mir eigentlich gar nicht (mehr) vorstellen möchte, was alles einfrieren und ruckeln würde, wenn „unser“ PlayStore mit den verfügbaren Apps seinen Namen tatsächlich verdienen würde…
Also, an CSV liegt das sicherlich nicht - ich hab’s nämlich nicht installiert und die ABRP-App ist quasi unbrauchbar. Jeder Klick im Menü ist super träge, beim Ausblenden des Menüs bleibt ABRP auch einfach mal 10 Sekunden hängen, um dann den „letzten Zentimeter“ Menü doch noch aus dem Bild zu schieben. Insgesamt habe ich nicht viele Apps im P2 installiert.
Ich werde morgen mal probieren, ob denn die Navigation an sich einigermaßen performant funktioniert und wenn nicht, ABRP nur noch als Planungstool am Rechner nutzen, wenn es nötig ist.
