Dígitales Cockpit

[schlumpf]

Eine alte Projektidee geht mir gerade mal wieder durch den Kopf: Das Cockpit durch eine moderne Version mit Navigationsfunktion ersetzen.

Das ganze hat ein französischer Fazer-Kollege vor ca 2 Jahren ins Rollen gebracht. Er suchte nach einer passenden Peripherie um einen Bildschirm mit Raspberry Pi an seiner 600er Fazer zu verbauen. Auf halber Strecke ist die Sache allerdings ein paar Monate später wieder eingeschlafen weil es zu komplex und kostspielig erschien.

Im letzten Motorrad-Urlaub gab es dann einen neuen Trigger. Wir haben ein iPhone für die Navigation benutzt, in einer schönen Halterung am Lenker montiert. Alles prima, funktionierte sehr zufriedenstellend. Nach 2 Tagen ging aber plötzlich die Camera kaputt (der Autofokus-Mechanismus). Apple selbst hat kürzlich davor gewarnt das die hochfrequenten Vibrationen die Mechanik beschädigen können. Nun ja...

Das war für mich Anlass genug die alte Idee mit dem Navi-Cockpit wieder hervorzuholen. Die bisherigen Ergebnisse möchte ich euch hier präsentieren und zur Diskussion stellen. Und möglicherweise finden sich auch ein paar Unterstützer die sich mit dem Raspberry Pi, HTML und JS besser auskennen...

Etwas ähnliches gibt es übrigens bereits seit einigen Jahren unter dem Titel "TFT Dash": https://www.facebook.com/tftdashproject
Im UK-Forum gibt es ein paar Threads dazu.

Hier nun ein paar Bilder der bisherigen Ergebnisse. Das "Programm" für den Raspi ist eine HTML-Seite auf der "Leaflet" als Maps-App läuft. Eingeblendet werden die üblichen Cockpit-Daten. Ein spezielles Shield ersetzt die Cockpit-Elektronik und schickt die Daten als Stream zum Raspi. Die komplette Box sitzt an der originalen Cockpit-Position.

[schlumpf]

In der Hauptfunktion soll das Cockpit ein Navi sein. Mit der Möglichkeit vordefinierte Routen anzuzeigen. Die eigentlichen Motorrad-Cockpit Funktionen sollen "nebenbei" eingeblendet werden. Zusätzlich gibt es (umschaltbar) eine reine "Motorrad"-Seite wo nur Tacho/Drehzahlmesser/Tank/etc angezeigt werden.

Die Verbindung zwischen beiden Welten übernimmt ein Shield-Board. Das ist im Kern eine erweitere Ganganzeige die sämtliche Peripherie ansteuert, das GPS auswertet, den Gang berechnet, den Lüfter ansteuert und ähnliches. Einzige Verbindung zum Raspi ist eine serielle Verbindung. Schaltplan und erstes Layout existieren bereits. Zum Testen des Raspi ohne Peripherie habe ich einen Emulator programmiert der auf dem PC läuft und Dummy-Daten erzeugt.

Das Display ist ein kleiner Knackpunkt. Es muss im Sonnenlicht gut ablessbar sein, da ist aber der Markt leider sehr beschränkt. 5 Zoll sind möglicherweise ausreichend, mir wären 7 Zoll lieber. NewHaven-Display ist ein möglicher Anbieter (USA), aktuell aber schwer zu bekommen.

Die Mechanik/ das Gehäuse werden gedruckt. Befestigungspuntke und Begrenzungen sind mit dem Papp-Modell bereits ausgemessen worden. Natürlich fehlen noch jede Menge Details, die man leider erst lösen kann wenn das Display ausgewählt ist. Gilt ebenso für die Stromversorgung und die Stecker.

Wie bedient man sowas? Eine Maus wird man kaum mitnehmen können. Also braucht man zusätzliche Taster an den Griffen. Die aktuellen R1-Griffe hätten schöne Bedienelemente, verursachen aber andere Kopfschmerzen. Hierfür habe ich noch keine gute Lösung gefunden.

Die Software im Raspi ist auch nicht trivial. Man muss mit plötzlichem Spannungsausfall rechnen (Speicherbereiche werden fehlerhaft beschrieben) und irgendwie müssen externe Daten eingespeisst werden können (Tracks). Die meisten Raspis haben Wlan und Bluetooth, man kann daher bei Bedarf online arbeiten (Hotspot vom Handy).

Man merkt vielleicht dass in dem ganzen Projekt bereits einige Monate Vorarbeit und -Überlegungen drinstecken. Trotzdem sind immer noch viele Dinge offen..

[InTheY2K]

Boah! Genial!

Das wäre eine Sünde wert.Ich hab vor 2,5 Jahren mal ein Off-road-Training mit einer 1200er GS gemacht und war ganz angetan von dem Mäusekino im Cockpit. Die Bedienung mit Drehrad und zwei Knöpfen am linken Lenkerende hatte man auch schnell raus.

Könnte man irgendwie rauskriegen, wer für die Displays der Zulieferer ist? Die waren nämlich unter allen Lichtverhältnissen gut abzulesen.

Grüße Sascha

Gesendet von meinem F1 mit Tapatalk

[schlumpf]

Wenn du keinen Insider kennst dann ist es praktisch unmöglich einen Lieferanten herauszufinden. Zudem wird das eine Kette von Lieferanten sein, BMW wird kaum selbst ein Cockpit entwerfen und bauen (lassen). Plan B könnte sein solch ein Cockpit zu besorgen und versuchen das Display selbst anzusteuern. Ist aber auch ein Weg den ich nicht gehen möchte.

NewHaven (https://www.newhavendisplay.com) hat Displays im Programm die als "sunlight readable" deklariert sind. Erreicht wird das durch ein hohe Leuchtdichte. Für Dunkelheit benötigt man deshalb eine Regelung der Helligkeit.
Displays mit weniger Leuchtkraft kann man sicherlich ebenfalls einsetzen, ist nur eine Frage bis zu welcher Umgebungshelligkeit es funktionieren soll.

Eine zweite Gruppe von Displays arbeitet mit einem Rest von Reflektivität. Die Sonne ist dabei die Hauptbeleuchtung, nicht der Hintergrund. Die sind aber auch nicht gerade sehr verbreitet weil die Farbwiedergabe recht schlecht ist.

Welches sonstigen Displays am Motorrad in der Sonne akzeptabel funktionieren wird man wohl erst herausfinden wenn man selbst testet. Ich habe aber wenig Lust auf einen grossen Vergleichstest..

[schand99]

Über so eine Lösung hatte ich auch schon mal nachgedacht, eine Ganganzeige könnte problemlos in ein großes Display integriert werden
An einem brauchbaren Display ist die Idee dann aber auch gescheitert. Und an der notwendigen Freizeit, Lust am Basteln...
Für Programme auf dem RasPi, vorausgesetzt es läuft ein Linux als Betriebssystem, verwende ich Lazarus. Das ist sowas wie objektorientiertes Pascal und läuft auf dem RasPi beinahe genau so gut wie auf Windows. Grafiken für Tacho, Drehzahl, usw. zu erstellen wäre damit kein Problem. Theoretisch müsste es auch möglich sein, Google Maps in einem Browserfenster darzustellen.

[schlumpf]

Aha, das mit Lazarus ist ja sehr interessant. Da ich mit Delphi "aufgewachsen" bin huschte mir direkt ein Lächeln durch Gesicht. Das werde ich mal ausprobieren.

[schand99]

RasPi mit Raspbian Linux dann geht das sogar recht einfach, guck mal https://wiki.freepascal.org/Lazarus_on_ ... r_Raspbian
Hab da in der Vergangenheit schon ein paar Kleinigkeiten gemacht wie z.B. Druckprüfung über Zeit für einen Wärmetauscher-Prüfstand, oder Arbeitsanweisungen von einem SQL Server abrufen & anzeigen.
Wenn Lazarus direkt auf dem RasPi läuft, dann ist Debuggen einfach. Über Netz mit RDP kann man da recht komfortabel mit arbeiten.

[schlumpf]

Ein wenig Fortschritt:

Den RasPi in Betrieb zu nehmen ist dank der vielen Tutorials kein grosses Problem. Er ist nun remote über WLAN über VNC mit dem PC verbunden. Lazarus ist installiert und das erste "Hallo Welt" funktioniert ebenfalls.

Trotz langer Suche konnte ich in der Lazarus/Pascal-Welt aber keinen funktionierenden Ersatz für "Leaflet" finden. (Leaflet basiert auf JavaScript und dient zum Anzeigen von Strassenkarten und sowas).
"MapViewer" läuft ansatzweise, aber nicht sauber. Es scheint auch deutlich weniger Funktionsumfang als Leaflet zu haben.

Hat jemand von euch ein Idee wie man da weiter vorgehen kann? Oder ist jemand fit in Pascal?

[schand99]

Hallo,

Leaflet kannte ich bisher nicht. Einen funktionierenden Ersatz für Leaflet in Lazarus oder Delphi wird wird es wohl kaum geben deshalb würde ich nach einer Möglichkeit suchen, Leaflet in einem Browser auszuführen. Mit Lazarus den Standardbrowser erkennen ist einfach, diesen mit Parametern zu starten ist ebenfalls kein Problem. (z.B. unter Uses die Bibliothek "LCLIntf" laden, anschließend im Quellcode einfach openurl('www.fazerforum.info');) Der Browser wird geöffnet aber leider mit all dem Zeugs wie Toolbar und Reitern.
Zum Testen ob Leaflet mittels Parametern in den Browser geschuppst werden kann, würde das aber vorerst ausreichen.
Wenn's läuft könnte mittels Chromium ein eigenes Browserfenster gebastelt werden, da gibt es schon was https://wiki.freepascal.org/fpCEF3.

[schlumpf]

Ich habe es geschafft "MapViewer" zum Laufen zu bringen. Eine für Windows kompilierte Version habe ich hier abgelegt:
http://cvieth.bplaced.net/MapViewer/
Vielleicht kannst du es mal in deiner Umgebung testen?

Die Quelldateien liegen hier:
https://sourceforge.net/p/lazarus-ccr/s ... mapviewer/
Es ist das Demo "fulldemo_with_addons" aus dem Example-Verzeichnis
Einige Packages müssen vorab installiert werden, ein wenig Anleitung findet man hier:
https://forum.lazarus.freepascal.org/in ... ic=47389.0

Es scheint erstmal eine gute Ausgangsbasis für meine Zwecke zu sein. Interessant finde ich das man unterschiedliche Kartenanbieter auswählen kann, auch z.B. so Spezialkarten für's Fahrradfahren.
Alle heruntergeladenen (Teil-)Karten werden im Ordner "cache" abgelegt. Das sind die Teilkarten von den Gebieten die man bereits betrachtet hat, in der jeweiligen Zoom-Stufe. Wenn man dort händisch alle Karten ablegt könnte man offline arbeiten.
Einen GPX-Track habe ich auch schon erfolgreich eingelesen.

Der Umweg über Leaflet und einen Browser funktioniert möglicherweise ebenfalls. Aber ob die nicht Geschwindigkeit unter der Verschachtelung leidet?

[schand99]

Das sieht gut aus Und vor allem nach wenig Tipparbeit.
Für Leaflet im Browser wäre der Aufwand mit Sicherheit deutlich umfangreicher. Dafür, weil du die Geschwindigkeit angesprochen hast, wird bei der Lösung mit LazMapViewer vermutlich für die Anzeige Karte oder Geschwindigkeit, Drehzahl, usw.. in der Applikation ein eigener Thread benötigt. Für die Lösung mit dem Browser würde dies das Betriebssystem erledigen.

[schlumpf]

Die letzten Wochen habe ich immer wieder mal am Raspberry "gespielt" und möchte euch hier über meine Erfahrungen und den Fortgang berichten. Das soll kein Programming-Tutorial werden. Nur ein paar Hinweise für Leute die sowas auch gerade machen, oder planen.

Meine erste Freude über die erfolgreiche Lazarus-Installation (siehe oben) war schnell verflogen als ich bemerke dass die Version total veraltet war. Zudem liessen sich keine Erweiterungen installieren (Packages genannt), das hat die ganze Installation zerschossen. Aktuelle Versionen muss man sich selbst kompilieren. Die dafür passende, funktionierende und aktuelle Anleitung zu finden und umzusetzen war eine Aufgabe für sich.

Erschwerend kam hinzu dass ich keinerlei Ahnung von Linux und seinen Befehlen hatte und auch dort erstmal Lernen musste.

Zur weiteren Belustigung passierte es öfters mal dass das Dateisystem der SD-Karte kaputt ging. Raspbian schreibt munter irgendwelche Daten auf die Karte und man muss höllisch aufpassen diese nicht zu unterbrechen. Sonst darf man das komplette Betriebssystem neu aufsetzen.

Eine weitere Quelle für Problemchen ist der "Headless" Betrieb. Dabei wird der Raspbi über VNC "ferngesteuert". Gekoppelt über WiFi benutzt man Bildschirm und Tastatur des PCs. Besonders lustig wenn man die serielle Schnittstelle verwenden möchte die eigentlich mit dem WiFi Modul gekoppelt ist..

Ich bin mir noch nicht ganz sicher ob der RasPi nicht doch eine Sackgasse für den Einsatz am Motorrad ist..
Die Probleme die ich bisher mit der Programmierumgebung hatte werden sicherlich noch weiter gehen.
Eine Read-Only Konfiguration, um die SD-Karte zu schonen, ist das nächste auf der Liste um das System überhaupt überlebensfähig zu machen.
Die Stromversorgung muss gut und sauber sein und viel Strom liefern können. Überhaupt ist noch viel Aufwand für eine sichere Peripherie notwendig.
In Summe ist es noch ein langer Weg zu einem zuverlässig funktionierenden System wie ich es mir wünsche.

Immerhin läuft "Hello World" schon mal

[schand99]

Das liest sich nicht besonders lustig .
Ja, die Lazarus IDE für RasPi ist alt. Das war Version 1.6 glaub ich. Riesengroß sind die Änderungen zur 2.0.12, die ich verwende aber nicht bzw. zumindest nicht für die Funktionen die ich benötige. Was mit 2.0.12 geht, sollte sich auch mit 1.6 machen lassen.
Noch weit weniger lustig sind deine Erfahrungen mit dem RasPi und der SD Karte. Im Betrieb hatten wir vorübergehend mehr als 20 RasPi im Einsatz, mit Touch-Monitor als Zugang zu Fertigungsanweisungen. Vereinzelt gab es Probleme mit SD Karten, nach Umstieg auf Karten von besserer Qualität und der Klasse 10 war das kein Thema mehr. Ausgemustert und durch mini Pc's ersetzt wurden die Raspi weil Wlan unzuverlässig und letzten Endes waren sie auch etwas zu lahm.
Den seriellen Port am RasPi habe ich bisher nicht direkt benutzt, wüsste da im Linux auch nicht wie einstellen. Externe Geräte hatte bzw. habe ich immer am USB-Port angeschossen (ja, ist auch seriell ), gab keine Störungen am Wlan oder Lan.

Ob der RasPi die richtige Lösung ist? Da hilft wohl nur probieren.
Wenn man es schaffen würde, die Informationen von Tacho, Motordrehzahl und eventuell auch noch Benzinstand im Tank in ein "artegerechtes" CAN-Bus Signal zu verpacken, dann wäre alles einfacher. Ein (ausgemustertes) Android-Smartphone oder -Tablet würde dann ausreichen. Theoretisch kann ein Bluetooth ELM327 obd2 und CAN Bus verarbeiten und via Bluetooth an ein Android Smartphone übermitteln. Apps für OBD2 gibt es im Playstore viele, Motordrehzahl usw. anzeigen wäre kein Problem. Und dann mit Zeit und Ruhe eine App basteln die Tacho & Navigation beherrscht.

[Waldheizer]

Spannendes Thema, nicht das ich es bräuchte aber meine Technikerschule geht langsam zu Ende und ich programmier grad fleißig an meinem Projekt herum. Motorbobbycar mit ex-BMW/Bosch-LiMa als Motor, umgewickelt auf segmentierte 9 Phasen Wicklung, getrieben von 3 FOC-Controllern, mit nem Arduino Due als Hauptsteuerung für Last und Erregerspannung. Will sagen, ich kann zumindest ansatzweise mittlesen/mitfühlen weiter so

[schlumpf]

Da hast du ein spannendes und anspruchsvolles Projekt! Bin gespannt wenn du es hier mal vorstellst


Die Kopplung der Motordaten per CAN wollte ich nicht machen. Bei der FZS ist sowieso alles analog, das wäre für meine Zwecke ein Umweg. Bei der Dekodierung setze ich auch nicht auf bestehendes auf. Mein Fokus ist zudem auf der Kartendarstellung, die Fahrdaten sind nur Beiwerk und trivial.

Ich habe bereits einen fast fertigen Signaladapter, eine extra Platine. Der basiert auf meiner Ganganzeige und sendet alle Cockpit-Daten nicht an ein Display sondern auf eine serielle Schnittstelle (4 x pro Sekunde ein paar Hundert Byte). Warnlampen, Taster und GPS sind ebenfalls enthalten. Der RasPi muss diesen Stream nur dekodieren und hat somit keine direkten HW Verbindungen oder Aufgaben. Die komplette analoge Signalverarbeitung und sonstige Steuerung passiert in diesem Adapter. Für sowas ist ein kleiner Atmel dicke ausreichend und viel besser zu beherrschen.

Noch besser, ich habe einen Emulator für den PC geschrieben der genau die gleichen Signale generiert. Man könnte daher im Team gleichzeitig am RasPi entwickeln ohne irgendwelche Zusatz-HW

Der Thread ist schon so lang und alt dass ich jetzt erst bemerke dass ich das alles schon am Anfang erzählt habe ..