Das endlose GSX-R "SRAD" 750 Projekt - Replica mit DBW ?

[Chef_Koch]

Weil wenn es so angebaut wird, dann würden doch bei allen Unebenheiten falsche Werte ermittelt oder?

Mh also wenn ich ihn beispielsweise senkrecht zur Radachse (Und im Stillstand quasi auch senkrecht zum Boden) montiere, wären Unebenheiten eigentlich egal. Da das Rad die ja zur gleichen Zeit erfährt wie es der Sensor registiert.
Bzw. ein minimal geringerer Abstand wird wohl gemessen, weil der Reifen ja auch etwas federt. Was aber bei Messung über zwei Sensoren links und rechts dann auch wieder egal wäre, wenn man das Delta berechnet.
Bei Geradeausfahrt würde sich das komplett ausgleichen, bei Schräglage evtl nicht ganz.
Aber selbst dann sollte die resultierende angenommene Schräglage noch so gering sein, dass sie noch unter der Mindestschräglage zur Aktivierung der TC liegt.

Steilkurve rechts rum, innen Curbs und man fährt im Apex direkt an die Curbs. Dann wäre der Messwert rechts durch die Curbs doch komplett für die Katze und der Wert links durch die Schräge der Strecke ein Verfälschter oder sehe ich das falsch?

Ja da hast du Recht. Das wenn irgendwas im Weg ist und dadurch weniger Abstand gemessen wird, ist ein grundsätzliches Problem bei der Schräglagenermittlung über Abstandssensoren.
Können zum Beispiel die Curbs sein, wenn man quasi mit der Hinterreifen schon direkt dran ist.
Oder der nette Racer im Nacken der einem die Schräglagenmessung versauen will

Bei den Curbs würde das System durch den geringeren gemessenen Abstand mehr Schräglage annehmen.

Mir fällt aber auch keine Alternative ein. Habe schon überlegt immer nur den größeren der beiden Eingangswerte zu nehmen und somit kurvenaußen zu messen, aber ich glaube ab einer gewissen Schräglage ist dann evtl auch einfach der Abstand zu groß.
Muss ich aber erstmal schauen bei welcher Montageposition ich welchen Abstand in Abhängigkeit der Schräglage bekomme.

Andererseits ... wenn man mal annimmt, dass wenn man im Scheitelpunkt auf die Curbs auffährt eh schon so ziemlich in maximaler Schräglage ist. Ich sag jetzt einfach mal 55°. Plötzlich wird durch die Curbs ein geringerer Abstand gemessen und das System errechnet daraus z.B. 70°. Ist es ja immer noch die Frage was die Software daraus macht. Man könnte es ja auch schon so einstellen, dass die TC bei 55° sowieso schon im Anschlag ist. Und alles was als mehr Schräglageninput rein kommt, bewirkt keine Änderung am Regelverhalten mehr.

Und wenn man mal die Auswirkung überlegt, würde die Schlupfgrenze bei zu hoch angenommener Schräglage zur Kompensation der veränderten Abrollumfänge steigen. Sprich TC würde etwas später eingreifen.
Also hier wird dann der bestraft der mit zu wenig Schräglage durch die Kurve schleicht und trotzdem die Curbs schneidet

Die andere Frage ist natürlich welche Differenzen(vorne/hinten) im Radumfang habe ich bei einer Änderung von beispielsweise 45° auf 55° Schräglage überhaupt noch. In dem einen Bosch PDF gibt es so ein Schema, da sind die Differenzen bei so hohen Schräglagen nur noch sehr gering. Also bezogen auf Geradeausfahrt natürlich sehr groß, aber wenn man nur bedenkt was passiert wenn ich statt echten 45° eben durch z.B. durch Curbs 55° annehme.
Muss das aber auch erstmal selbst ausmessen. Ich weiß jetzt natürlich nicht wie realitätsnah dieses Schema wirklich ist.

Aber bezüglich Schräge der Strecke, genau hier wäre ja der Vorteil durch die IR-Sensoren im Vergleich zu Beschleunigungsaufneher+Drehraten etc..
Denn durch den Abstand würde ich die tatsächliche Schräglage bezogen auf die Strecke messen.
Wurde ja schon diskutiert - siehe Extrembeispiel Wall of Death.



Hier auf Durbahns Seite sieht man übrigends mal, wie so eine Schräglagenmessung über Abstandssensoren dann letztendlich im Data-Logging aussieht:
http://www.durbahn.de/Electronics%20sen ... age_de.htm

[Ar3s]

Wenn du genug Platz auf der ECU hast kannst du es ja einfach mal MotoGP gerecht machen und jede Kurve schon mit Neigungswinkel Eintragen. Gibt bei vielen Strecken die Information über Radien und Neigung.
Falls nicht vorhanden musst du halt eine Streckenbegehung machen und die Neigung messen ^^

Somit kannst du dann auch eine auf Kurven abhängige TC programmieren welche mit Sicherheit am feinfühligsten ist, wenn richtig eingestellt.

Oder die Sensoren dort anbringen wo, hoffentlich, nicht so schnell ein Curb hinkommt. Also zb im Bug in einem gewissen Winkel. Zb. 45° rechts und links. Der Abstand zur Fahrbahn wäre sehr gering, aber das delta wäre genauso Aussagekräftig. Auch würde ein Einfedern sich ja relativieren da das Delta noch immer das selbe ist.

Grüße

[techam]

Die Sensoren müssen ausreichend nah beieinander liegen.

Zudem sollte der Messpunkt immer etwa im Berech der Auflagefläche der Reifen liegen.

Möglichst direkt vor dem Hintereifen.

Problem sind dann die in die Winkelbestimmung sehr stark einfließenden Unebenheiten der Fahrbahn, je kleiner der Abstand der Sensorpunkte ist, desto größer wird der Fehler.
Da hilft dann nur eine hohe abtastrate und linearisierung der Messwerte.

Auch nicht zu verachten ist die Verschiebung der Messpunkte in Schräglage, sodass sie nicht mehr direkt vor dem Aufstandspunkt liegen. Hier könnte ein Außencurb das Ergebnis verfälschen.

MfG Christian

[Chef_Koch]

also wenn man das ganze mal zusammenfasst:

1) Methode mittels Beschleunigungsaufnehmer und Drehratensensor + geeigneter Filter per C#Code im Steuergerät (z.B. Kalman Filter)

Vorteil: Gutes Ergebnis
Nachteil: Teuer, Aufwendig und Neigung der Fahrbahn wird nicht mit berücksichtigt

Wobei man hier theoretisch noch den Vorschlag von Ares berücksichtigen könnte, indem man zu jedem Track noch ein Neigungsmapping lädt, wodurch dann in Abhängigkeit der aktuellen Position die Streckenneigung berücksichtigt wird. Ist halt noch etwas aufwendiger

2) Schräglage nur über Querbeschleunigung
Vorteil: Sehr günstig und einfach umzusetzen/ zu berechnen
Nachteil: Schräglage wird z.B. durch Hanging-Off, Schlaglöcher etc verfälscht.

3) Abstandsmessung über IR-Sensoren
Vorteil: Kostengünstig und einfach umzusetzen
Nachteil: Abweichung durch störende Objekte (Curbs etc) ; Montageposition; Filter sinnvoll


Habe gerade noch ein bisschen recherchiert zu der ersten Methode.
Werde das vielleicht doch mal probieren.
Eine Möglichkeit hier wäre z.B. den 3-Achs; 3-Gyro CAN Sensor von 2D zu verwenden für den ganzen benötigten Daten-Input.
Abhängig vom Preis den ich genannt bekomme kann ich dann entscheiden ob ich den wirklich nehme.
Alternative wäre noch der Bosch Sensor aus der KTM für 370€. Der liefert ja die gleichen Werte.
Oder ich bau mir das selbst, 3-Achsen Beschleunigungsaufnehmer und Gyro sind ja nicht wirklich teuer. Müsste das dann nur noch in einer externen Box auf den CAN-Bus bringen, damit ich keine weiteren Kanäle der Megasquirt dafür verbraten müsste.
Edit: Habe gerade auch noch ein paar gute Alternativen gefunden, werde mich da mal einlesen.

Zunächst könnte ich die erfassten Daten einfach mal nur mitloggen. Und anschließend offline am PC am entsprechenden Filter arbeiten bis der schon mal funktioniert.

Danach müsste ich das ganze noch in die Firmware übertragen. Das wird dann der schwierigste Teil.
Vielleicht finde ich da noch einen mit C# Kenntnis der mir dann dabei etwas hilft.

Habe da schon jemanden in Verdacht Werde mit ihm mal am Wochenende sprechen.
Er macht auch privat viel mit so Quadrocoptern.
Und in der Community wird das auch viel eingesetzt, da habe ich jetzt schon ein paar Beispiel Codes gefunden.

Auf der letzten Seite hatte ich ja diesbezüglich noch das Zitat aus dem Bosch-Datenblatt.
Aber nachdem ich mir den Filter inzwischen etwas genauer angeschaut habe, würde ich fast sagen, dass die sich da einfach etwas unglücklich ausgedrückt haben. Die meisten Informationen werden ja eigentlich nur im Nachhinein benötigt um dann den Schlupf zu berechnen. Und die Einbauposition sollte eigentlich nur zur Korrektur der Eingangswerte wichtig sein, falls der Sensor aus Package-Gründen in einer ungünstigen Lage montiert worden ist.

Naja wird schon noch irgendwie mal funktionieren

[Elle]

http://www.amazon.de/Estimate-lean-angl ... 3639263286

[Dr.Best]

Sieh bloß zu das du anfängst den KIT Motor aufzubauen !

Wird Zeit für Hardware, bekomme Kopfschmerzen von dem ganzen Elektro Firlefanz

[Ar3s]

@Chef_Koch: Ist die Megasquirt in C# geschrieben? Garnicht C oder C++ und ohne Misra? Wundert mich etwas C# in einer ECU. Da geht ja jede Menge laufzeit für nichts drauf, hehe.
Würde dir gerne dabei helfen. Weiß aber nicht wie viel Zeit ich habe da ich leider von der Arbeit so sehr eingedeckt bin das ich meine Freizeit lieber am Bike verbringe ^^
Aber wenn ein Kumpel von dir sich mit Quadrocoptern beschäftigt, sollte das für den glaub ich kein Problem sein. Die benutzen selbst genug Lage-sensoren usw. Allerdings kaum C# (zumindest nicht diese welche ich kenne).
Wenn dann doch mal Not am Mann ist kannst dich ja per PN melden

Und wie Dr.Best schrub. Mehr Hardware Pics *lächz**sabber*

@Elle: Da gibt es ein eigenes BUCH darüber? Auch nicht schlecht, aber die Überschrift "Estimate .." würde bei mir schon nen Grauschleier darüber legen. Ich will es ja nicht schätzen sondern exakt berechnen ^^

Grüße

[Tante Edit sagt:] Hat nicht schonmal wer hier eine Gyro-Cam gebaut? Diese hält sich doch ständig in der Waagrechten. Damit das funktioniert muss man ja die Schräglage kennen. Vielleicht kann man diesen Herren ausfindig machen und mal kurz bequatschen wie er das gelöst hat.
Somit hättest du zumindest mal den Winkel zum Horizont, was nicht der tatsächlichen Schräglage zur Fahrbahn entspricht, aber schon mal ein Anfang ist.

[Chef_Koch]

@Chef_Koch: Ist die Megasquirt in C# geschrieben? Garnicht C oder C++ und ohne Misra? Wundert mich etwas C# in einer ECU. Da geht ja jede Menge laufzeit für nichts drauf, hehe.
Würde dir gerne dabei helfen. Weiß aber nicht wie viel Zeit ich habe da ich leider von der Arbeit so sehr eingedeckt bin das ich meine Freizeit lieber am Bike verbringe ^^

oh Gott, meinte natürlich C++.
Dachte bis jetzt das wäre das gleiche
Da siehste wie ich mich damit auskenne

Hab gestern schon mal mit meinem Kollegen gesprochen, der meinte das klingt nicht so kompliziert und er schaut sich das mal an -> yees

Habe aber auch noch ein paar Sachen gefunden.
Zu 2D und BMW Acc+Gyro Systemen gibt es noch ein paar Alternativen wenn man genau sucht. Aber ebenfalls recht teuer.

Dann habe ich noch ein Microcontroller Board gefunden mit 6-Achsen System (Also wieder 3xAcc und 3xGyro) und USB-Schnittstelle zum Programmieren (C ) und CAN-Bus etc.
Aber das ist eher was industrielles (Robotik blablabla) und dementsprechend kaum dokumentiert.
Ist zwar auch Open Source, aber in in der Standard-Firmware wird auch noch nichts über CAN gesendet. Das müsste man selbst schreiben
Wäre aber vom Preis her echt super und total klein das Teil. Und man hätte sogar noch ein paar Analog Ein- und Ausgänge.
Da könnte man aber direkt auf dem Board schon die Schräglage berechnen (Gibt Beispiele dazu) und dann über CAN-Ausgeben. Oder falls das mit CAN nicht klappt .. vielleicht bekomme ich ja eventuell den Analog Ausgang zum Laufen.

Eine andere alternative habe ich auch noch aufgetan. Da ist nebem dem 6-Achsen Zeug auch noch ein GPS-Empfänger mit Antenne drauf. Aber da hat man nur eine CAN-Bus Schnittstelle. Die muss man dann auch zum Flashen benutzen und dafür brauchts wieder ne weitere Hardware. Wird dann insgesamt recht teuer.
Aber hier ist in der Standard-Firmware schon einiges los auf dem Can-Bus und da die auch Open Source ist und ich hier sogar ansatzweise durchblicke, könnte ich die so ändern, damit die Megasquirt die Daten lesen kann.

Oder über son Arduino, hab mir gestern nur mal ein Beispiel reingezogen wie die über son Can Bus Shield mit der Megasquirt kommunizieren. Das sah machbar aus. Muss ich mich aber erst noch mehr damit beschäftigen.

Und Danke fürs Angebot. Werde evtl mal darauf zurückkommen

Aber jetzt hierzu:

Sieh bloß zu das du anfängst den mit Motor aufzubauen !

Wird Zeit für Hardware, bekomme Kopfschmerzen von dem ganzen Elektro Firlefanz

Bin selbst schon total auf Entzug Aber in knapp einem Monat habe ich endlich wieder (etwas) mehr Zeit und bin wieder ab und zu daheim beim Motorrad. Da wird dann mindestens ein Motor aufgebaut. (Mit etwas Glück auch zwei). Mit ein paar netten Teilen die ich hier noch nicht gepostet habe.
Die möchte ich dann noch dieses Jahr im Straßenbike einfahren und abstimmen (Für Vergaser und Einspritzanlage ), damit ich dann einen gleich ins Rennbike setzen kann.

[Chef_Koch]

Wird doch nochmal etwas elektronisch

Die ganze Sache hat mir nach der Diskussion hier keine Ruhe mehr gelassen ...
tja...inzwischen steht der Schräglagensensor
(Zumindest im Trockentest funktioniert alles so wie es soll. Test am Fahrzeug folgt, warte noch ein paar Komponenten)

Aber zum Anfang.

Im Grunde reicht ein Beschleunigungsaufnehmer nicht aus um die Schräglage verlässlich zu berechnen.
Das Signal ist einfach zu instabil bzw. weitere auftretende Kräfte würden das Ergebnis stark verfälschen.
Ein Drehratensensor (Gyro) zeigt zwar die Winkelgeschwindigkeit an und über eine Integration würde man auch wieder an die Änderung des Winkels kommen. Aber das Signal neigt zum driften.

Wenn man aber beide Sensoren zusammen verwendet lässt sich mittels Sensorfusion bzw. einem Filter (Kalman, Complementary oder ähnlichs) die tatsächliche Schräglage berechnen.

Hatte dazu so ein schönes Schema. Finde das aber gerade nicht mehr.

Auf alle Fälle kann man um das Ergebnis zu verbessern auch noch einen Magnetometer und Temperatursensor und ggf auch noch Drucksensor eine Kompensation vornehmen.
Dazu gibts genügend weiterführende Infos im Netz, will das nur mal ganz grob anschneiden.

Bei mir findet jetzt ein 3-Achsen Beschleunigungsaufnehmer, ein 3-Achsen Drehratensensor, ein 3-Achsen Magnetfeldsensor und ein Temperatursensor Anwendung -> ergibt 10 Freiheitsgrade (10 DOF).

Aus den Daten kann dann der Winkel um 3-Achsen berechnet werden.
X: 0 bis 360°
Y: -90 bis 90°
Z: -180 bis 180°

Das entspricht wegen der Montageposition jetzt nicht der üblichen Konvention am Fahrzeug. Ist aber für mich auch egal. Könnte man ja auch noch umbenennen.

Bei meiner Einbaulage steht dann die Y-Achse für die Schräglage und Z-Achse für die Neigung (Steigung, Nicken beim Bremsen etc). Es muss auch nichts kalibriert werden. Bei einer "schiefen" Einbaulage des Sensors könnte man das aber korrigieren bzw. berücksichtigen. Die X-Achse ist eigentlich unwichtig.

Die ganzen Berechnungen finden bei mir schon extern statt. Sprich die Megasquirt bekommt direkt die Winkelwerte geliefert und hat selbst keinen Stress damit !

Die nächste Herrausforderung war dann die Übertragung über den CAN-Bus bzw. das korrekte verpacken der Werte in die CAN-Message. Da muss man sich auch erstmal reinfinden. Aber dank guter Hilfe im MS-Forum hat das dann doch noch geklappt

Man muss eben nur etwas aufpassen, dass man den richtigen Wertebereich nimmt. Ggf muss man manche Werte dann auf zwei Bytes aufteilen.
Für die ganzen Winkelwerte habe ich jetzt die CAN-Receiving Funktion der Megasquirt benutzt. Die ist noch relativ neu und wegen dem Standard 11-Bit Header Funktioniert die mit ziemlich vielen Geräten. Ist primär für ADC-Werte vorgesehen. Also 0-5V Signale bzw umgewandelt 0-1023 bei 10bit ADC.
Hier kann man dann einfach nach Lust und Laune die Message von einer beliebigen CAN-ID senden.
Über eine weitere Funktion "Generic Sensor Inputs" könnte man die Werte noch beliebig skalieren bzw. auch über hinterlegte Kennlinien in Temperatur oder Druckwerte umwandeln.

Can-Receiving-Winkel.jpg (189.38 KiB) 2740 mal betrachtet

GPS

Zusätzlich habe ich mir gleich noch ein GPS Modul mit eingebaut.
Das kann man mit interner oder externen Antenne betreiben. Durch die externe Antenne erhoffe ich mir dann auch noch Vorteile. Die Update-Rate liegt bei dem Modul bei 10Hz. Bei den ersten Tests war die Positionsbestimmung sogar nur mit der internen Antenne überraschend gut.

Das gute an der Lösung ist, dass der GPS Emfänger fest im Boardnetz mit integriert ist.
Und ich muss mir keine Sorgen machen, dass ich z.B. den Qstarz Empfänger nicht aufgeladen habe etc. Und rein von den Kennwerten her und im Betrieb dann noch mit der externen Antenne erhoffe ich mir noch bessere Ergebnisse als mit dem Qstarz.

Die GPS Daten werden dann ebenfalls über CAN-Bus an die Megasquirt übertragen und können dort auf die SD-Karte mitgeloggt werden oder über Bluetooth ans Tablet/Smartphone/Laptop weiterschicken und dort mit dem ganzen Rest aufzeichnen.

Die Übertragung hier hat sich aber etwas schwieriger gestaltet.
Zunächst wird hier ein extended 29-Bit Header benutzt. Im Grunde schickt die Megasquirt einen Request und mein externes Gerät muss dann aus dem Request auslesen welche Daten benötigt werden und wo genau die hinsollen. Hat dann aber mit Hilfe aus dem Forum noch geklappt.

Aber auch die Data Message an sich war etwas tricky. Zuerst muss ich die Dezimalkoordinate in Grad, Minuten und Sekunden umwandeln.
Diese Werte dann übertragen und die MS wandelt das dann wieder zurück.
Grad und Minute sind super zum Übertragen, da es nur ganzzahlige Werte sind. Bei den Sekunden sieht es anders aus. Je mehr Nachkommastellen ich übertragen kann, desto genauer ist natürlich die Position. Bei dem gewählten Datentyp kann ich dann Werte von 0 bis 65535 übertragen. Brauche ich bei der CAN-Nachricht wieder zwei Bytes dafür.
Wenn man den Sekunden Wert vor dem Senden *1000 multipliziert könnte man also 59.999s noch übertragen.
Danach muss der Wert von der MS nur wieder von 59999 auf 59.999 umgerechnet werden.
Sprich es wären drei Nachkommastellen möglich.
Nur blöderweise findet da aktuell in der MS noch eine weitere Umrechung (*6) statt. Um das auszugleichen muss ich das vor dem Senden auch vornehmen und das kostet letztendlich etwas Genauigkeit.
Deshalb bin ich gerade noch auf der Suche wie ich das in der Megasquit Firmware ändern kann.
Wenn das so klappt wäre ich erstmal zufrieden.
Da ich die GPS-Werte sowieso nur für die nachträgliche Analyse benötige, könnte ich die auch noch mit höherer Genauigkeit über die andere CAN-funktion übertragen und nachträglich bei der Auswertung noch viel exaktere Dezimalkoordinaten berechnen.


Außerdem übertrage ich über den CAN-Bus jetzt noch Datum und Uhrzeit (RTC - Real Time Clock). Hier wird die aktuelle Uhrzeit über GPS abgerufen und dann eben an die MS weitergeleitet. Das ist vor allem für Daten-Aufzeichnungen auf der SD-Karte praktisch. So kann man die wenigstens zuordnen. Ansonsten hätten die alle nur 00:00:00 als Uhrzeit.

Zusätzlich auch noch die 3-Achsen Beschleunigungswerte. Die Beschleunigung bzw. Verzögerung in Fahrzeuglängsrichtung kann ja auch ganz interessant sein. (Zum Beispiel maximale Verzögerung beim Bremsen als gute objektive Beurteilungsmöglichkeit)

Nur mal als Beispiel, so sieht das dann in der Megasquirt aus.
Das schwierige an der Sache war aber eh die richtigen Nachrichten zurück zuschicken .

Rest-CAN.jpg (266.09 KiB) 2740 mal betrachtet

Oben sieht man schon mal die Vorbeitung für die Laptime über CAN.
Denn die GPS Funktion möchte ich dann auch noch für einen Laptimer verwenden. Dazu dann später noch mehr. Bin da noch am testen.


Zusammenfassend mal die nützlichsten Funktionen von meiner CAN-Extender Box:
- 3-Achs Winkelerfassung möglich incl Schräglage für Traktionskontrolle
- 3-Achs Beschleunigungsaufnehmer
- Übertragung per CAN-Bus mit 0.5 MB/s
- Uhrzeit und Datum (Real Time Clock mit Knopfzellenbatterie um die Werte zu behalten,
falls kein GPS Empfang ist)
- 10 Hz GPS Empfänger mit Anschlussmöglichkeit einer externen Antenne
- Ggf. weitere Sensoreneingänge
- Wahrscheinlich kommt in die Box auch noch ein 4-Fach Abgastemperatursensor bzw. die Auswertung dafür.
Daten wieder per CAN-Übertragen.
- GPS Laptimer in Arbeit. Laptime wird extern berechnen, über CAN aus MS übertragen. Von dort per
Bluetooth aufs Tablet Dashboard.

Und Dank Selbstbau für einen sehr guten Preis.
Hätte auch noch ein paar weitere Ideen beispielsweise winkelabhängige Wheelie-Kontrolle.

Und hier noch ein Schnappschuss vom Testaufbau. Grün und Gelb sind die CAN-Leitungen.

Aufbau.jpg (370.86 KiB) 2740 mal betrachtet

[100gr_leberwurst]

Wird doch nochmal etwas elektronisch

Ich kanns immer wieder nur sagen, du faszinierst mich mit Deinem Wissen, Willen, Ideen und Pioniersgeist!

Da ändert auch die Tatsache nichts, dass ich schön länger ausgestiegen bin und den Thread nur noch überfliege, wenns zu "elektronisch" wird, da es mich einfach nicht mehr so sehr interessiert. Aber trotzdem, Hammer Leistung weiterhin, was Du da baust!