Gyrosensor Rekorder zur Geschwindigkeitsaufzeichnung bei Fahrwiderstandmessungen

T

ThomasT

Beiträge
1.727
Hier soll das Thema Gyrosensor Rekorder diskutiert werden. Hardware, Software, Auswertungen und Probleme.
Die Indoor-Rollmessungen werden weiterhin dort diskutiert.
Die Vergleichsfahrten von Quest und DF mit dem Gyrosensor werden dort diskutiert.
Bitte hier keine Diskussion über alternative Messverfahren. Ein kurzer Hinweis auf einen diesbezüglichen Thread ist ok.
Andere Hardware wurde z.B. hier diskutiert: https://www.velomobilforum.de/forum...ng-über-reedkontakt-am-com-port-des-pc.33093/
Es gibt noch bestimmt noch mehr Threads zu dem Thema.
 
Ich habe gestern mein Olimexino-Nano bekommen das ist ein kleiner Arduino-Plattform Computer. Man muss diesen zum Programmieren mit einem USB-Anschluss am PC verbinden, mein Smartfone USB Kabel passte zufällig. Solange der Olimexino-Nano mit dem PC verbunden ist, bekommt er den Strom über die USB-Verbindung. Auf der Platine vom Olimexino-Nano ist ein Einschub für eine Micro SD Speicherkarte auf welcher die erfassten Geschwindigkeiten gespeichert werden. Die Speicherkarte kann man dann jeweils nach erfolgten Messungen mit dem PC auslesen.

Die Programmier-Software gibt es hier: http://arduino.cc/en/Main/Software die hatte ich vorher auf meinem PC installiert.

Ich habe also die Arduino Software gestartet und den Olimexino-Nano mit dem USB Kabel mit meinem PC verbunden.
Im PC habe ich unter Systemsteuerung->Gerätemanager COM9 gefunden bei welchen der "Arduino Leonardo" angezeigt wurde.

In der Arduino Software (1.0.6 aktuellste Version) habe ich unter Tools->Serieller Port "COM9" ausgewählt. Auch habe ich unter Tools->Board->"Arduino Nano w/ ATmega328" ausgewählt. Der aktuelle Treiber für den Arduino unter Windows 7 war schon installiert.

Eine gelbe "RXL" LED blinkte ohne das ich weiteres gemacht hatte etwa 1 sek. an, 1 sek. aus., usw.

Dann habe ich wie in der Arduino Software bei Hilfe->"Erste Schritte mit Windows w/Arduino" erklärt, das erste Beispielprogramm "Blink" hochgeladen und dann habe ich "Upload to Board" (Pfeil nach rechts) angeklickt.

Es dauerte einige Sekunden bis der Upload abgeschlossen war, Meldung "Upload abgeschlossen" wurde in der Statusleiste unten angezeigt. Kein Unterschied beim Blinken zu sehen.

Dann habe ich im Beispielprogamm die beiden Wartezeiten von 1000 ms durch 200 ms ersetzt. wieder "Upload abgeschlossen" leider wird Binken nicht schneller, auch nicht nach tasten der Reset Taste am Olimexino und erneuten Upload.

@ThomasT Hast Du einen Tipp, woran es bei mit liegen könnte, das es nicht schneller blinkt ?

Sehe gerade die "RX" LED ist nicht die welche mit Pin 13 angesprochen wird, die ist leider nur auf größeren und nciht auf der kleinen Olimexino-Nano Platine vorhanden. Muss ich ein anderes Beispiel suchen oder warten bis Gyrosensor ankommt.

*****

Den Gyrosensor gibt es auch von Olimex: https://www.olimex.com/Products/Modules/Sensors/MOD-MPU6050/open-source-hardware
Ich habe aber diesen hier <klick> bestellt. @ThomasT bitte die Bilder hier einstellen wie man das mit dem Olimexino-Nano Mikroprozessor verbindet. Der fünfte Draht den man nicht sieht, kannst Du bitte auch eine Zeichnung einstellen mit Bezeichnung der Anschlüsse ? <Hier> ist noch was zum Anschluss zu sehen.

*****

Ich möchte den Arduino mit Gyrosensor vorerst zum genauen Messen des Trägheitsmomentes eines Laufrades benutzen.

Gruß Leonardi
 
Zuletzt bearbeitet:
Hallo Leonardi,
das jungfräuliche Blinken ist das Zeichen, daß der Bootloader auf die Daten vom USB-Bus wartet. Es ist ein gewisser Nachteil des Olimexino Nano, daß er nach jedem Power-On 5 Sekunden Bootloader-Pause macht (könnte man auch wegprogrammieren, dann wird aber das Re-Programming lästig).
Das Bootloader-Blinken sollte nach 5 Sekunden aufhören und dann sollte das Blinken Deines Programmes anfangen. Vielleicht hast Du den falschen LED-Anschluß definiert. Beim Arduino ist das der Pin 17 (Arduino-Zählung).
Nach dem Ändern des Codes mußt Du auch nochmal Compilieren. Ich weiß grad nicht, ob die Arduino IDE das automatisch vor dem Upload macht.
Wenn ich die Bilder von meinem Bastelteil hier hochlade und auch noch meinen Source Code veröffentliche finde ich nie wieder einen Job - nicht mal beim KFC.

BTW: Bei meinem Code fehlt die Initialisierung des digitalen Tiefpaßfilters des Sensors. Es sieht so aus, als stehe es wenigstens bei zwei meiner Rekorder unterschiedlich.
Was sonst noch am Code Wichtiges gemacht werden muss:
* Akkuspannungsüberwachung mit akustischem Alarm
* Temperaturlogging: der MPU hat einen eingebauten Temperatursensor
* Nichtbewegungspiepser: Dann hört man vor dem Rollstart, daß das Teil noch funktioniert und vergißt auch nicht das Ausschalten.
 

Anhänge

  • gyro1.jpg
    gyro1.jpg
    193,1 KB · Aufrufe: 210
  • gyro2.jpg
    gyro2.jpg
    291,1 KB · Aufrufe: 158
noch zwei Tutorials zu MPU6050
http://playground.arduino.cc/Main/MPU-6050

****

die fünf Drähtchen zwischen
MPU6050 Olimexino-Nano

Vcc C17 (+5V)
GND C17 (GND)
SCL UEXT (5)
SDA UEXT (6)
INT UEXT( ?) @ThomasT wo hast Du die Interrupt Leitung dran, ist doch die fehlende fünfte ?

****

Ich wollte es so machen:
Taster ran, einmal Tasten eine LED blinkt einmal
dann losrollen bzw. für Trägheitsmoment Laufrad dreht los, wenn Messung zu Ende, beim Stillstand.
Taster wieder drücken, die LED blinkt zwei mal.

Gruß Leonardi
 
Zuletzt bearbeitet:
Hallo Thomas,

danke für dieses Thema.
Ich hab "deine Hardware" auch bestellt. Zusätzlich noch Lichtsensor, Reflexlichtschranke, Piezo-Element für Vibrationen/Erschütterungen. Mal sehen was davon noch Sinn macht.
Falls Änderungen / neue Erkenntnisse zu deiner Sensoric und SW hast, gerne.

Den Arduino Nano incl. PC-Tools hab ich gestern auch wieder reaktiviert. Nur hab ich es (aktuell) nicht so dolle mit dem Zeitkontingent und der Programmierung

Gruß Elmi
 
Gear7Lover schrieb:
Ist das de Versuch ein Smartphone nachzubauen um besser an die Rohdaten zu kommen?
Zum Vergrößern anklicken....

Nein es geht um einen besseren Geschwindigkeitssensor als der Polar.

Schau mal die v(s) Darstellungen an. Der Sensor wir an der Radnabe reingedrückt und hat beim Df bei ca.35km/h auf 0,1 km/h genau gemessen. Vor allem misst er bis runter zum Stillstand bei 0,5km/h mit Radimpulssensor undenkbar. Und er misst jede 16ms und nicht nur jede Sekunde die Geschwindigkeit, je nach Programmierung und die Schwankungen lassen sich vielleicht noch reduzieren, denn nur das Quest und nicht das Df hatte solche Schwingungen drin. Desweiter ist so ein Sensor sehr günstig vom Preis, keine Ahnung 20,-€ Material.
https://www.velomobilforum.de/forum...llmessungen-mit-gyrosensor.40632/#post-611903

Man kann mit einem zusätzlichen Radimpulssensor einen evtl. Summierungsfehler derart reduzieren, das sich die zurückgelegte Strecke bei vielleicht 2Km Rollweite auf zB. auf +- 5cm genau bestimmen lässt. Also Anzahl Radumdrehungen*Radumfang+Rest.

Natürlich: Wenn Radumfang auf 1 mm genau bestimmt und eingegeben werden kann, entspricht dies auf 1,5 Km nur 1 m Genauigkeit. (wie 1500mm Reifenumfang zu 1mm). Die bisherigen Genauigkeitsgrenzen vom GPS sowieso, aber auch Polar werden mit dem Gyrosensor weit unterschritten.

Gruß Leonardi
 
Leonardi schrieb:
Nein es geht um einen besseren Geschwindigkeitssensor als der Polar.

Schau mal die v(s) Darstellungen an. Der Sensor wir an der Radnabe reingedrückt und hat beim Df bei ca.35km/h auf 0,1 km/h genau gemessen. Vor allem misst er bis runter zum Stillstand bei 0,5km/h mit Radimpulssensor undenkbar. Und er misst jede 16ms und nicht nur jede Sekunde die Geschwindigkeit, je nach Programmierung und die Schwankungen lassen sich vielleicht noch reduzieren, denn nur das Quest und nicht das Df hatte solche Schwingungen drin. Desweiter ist so ein Sensor sehr günstig vom Preis, keine Ahnung 20,-€ Material.
https://www.velomobilforum.de/forum...llmessungen-mit-gyrosensor.40632/#post-611903

Man kann mit einem zusätzlichen Radimpulssensor einen evtl. Summierungsfehler derart reduzieren, das sich die zurückgelegte Strecke bei vielleicht 2Km Rollweite auf zB. auf +- 5cm genau bestimmen lässt. Also Anzahl Radumdrehungen*Radumfang+Rest.
Zum Vergrößern anklicken....
Hallo zusammen,

ich bin gespannt auf Eure Ergebnisse und positiv überrascht von der guten Qualität der Daten.

Vor zwei bis drei Jahren gab es einmal einen Hype, bei dem jeder versuchte mit billigen IMUs und Smartphone-Sensoren solche Messungen zu machen. Drei meiner Kollegen (mich eingeschlossen) haben damals Arbeiten an Studierende vergeben. Auch renommierte Forschungseinrichtungen haben Versuche in diese Richtung unternommen. Die Erfahrung, die Beschleunigungsdaten zu integrieren waren damals durchweg negativ, da sich die Fehler leider nicht heraus gemittelt haben und auch nicht korrigieren ließen. Um so mehr freut es mich, dass dies nun mit dem von Euch gewählten Sensor besser zu klappen scheint.

Die von Leonardi erwähnte Fusion mit den Ergebnissen eines Odometers sollte sich per Kalman-Filter relativ einfach realisieren lassen, allerdings bedarf es einiger Versuche, bis man die Kovarianzen richtig geschätzt (oder falls möglich gemessen) hat.

Weiterhin viel Erfolg,
Alex
 
Hatte ich auch gestern noch zufällig gefunden, Kalman Filter rot gegen ungefiltert gelb. Bei der Messung von ThomasT muss aber wohl schon ein Filter (nur Tiefpass ?) dringewesen sein, denke ich - die Daten waren zu gut.

Gruß Leonardi
 
@gyps: Die Beschleunigung Intgrieren war auch meine ursprüngliche Intention bei den Beschleunigungssensoraufzeichnungen in ElfershaUsen 2012:
Der APproach hier ist viel profaner. Hier nehmen wir das Teil als hochauflösenden Drehzahlmesser. Wohlgemerkt: hochauflösend - nicht unbedingt hochgenau.
Was daß Video von Leonardi damit zu tun hat,, verstehe ich nicht. Ich habe z.Zt. keinen Ton.
 
Zuletzt bearbeitet:
Ein bißchen OT, aber ziemlich wichtig:
Bei dem oben erwähnten "klassischen" Beschlunigungsensormess- bzw. Auswertungsverahren muss man nicht integrieren, um die Leistung zu ermitteln. Denn zur Bestimmung der Leistung braucht man nur die Beschleunigungv.
Will man aber die Leistung abhängig von der Geschwindigkeit haben und dann auch noch die potentielle Energie abhängig von der Position rausrechnen, muss man ein- bzw. Zweimal integrieren. Und dann kommt nur Mist raus. Aber die Beschleunigung (des Fahrzeugs) vom Beschleunigungssensor, Geschwindigkeit mit dem Radsensor und Position mit GPS scheint mir eine sinnvolle Kombination. Die Beschleunigung des Fahrzeugs direkt mit dem Radsensor zu messen, wird wohl nicht viel bringen. Dazu braucht man einen zweiten Sensor an der Karosserie (den man auch zur Steigungsmessung einsetzen könnte).
 
ThomasT schrieb:
Was daß Video von Leonardi damit zu tun hat,, verstehe ich nicht. Ich habe z.Zt. keinen Ton.
Zum Vergrößern anklicken....
Ton ist keiner dabei, braucht man nicht. Soll nur zeigen wie gut ein Kalman Filter Störungen beseitigen kann, am Ende des Videos wo er auf den Tisch klopft, zum Beispiel Deine Ripple. In unserem Fall kann man die Werte ja auch nach der Messung filtern oder zB. exponentiell Glätten wenn es Sinn macht, also das Ripple wegmachen. Genügend Messwerte sind ja durch die häufigen Messungen vorhanden. Noch besser wenn das erst gar nicht auftreten würden.

@gyps: von der MPU6050 ist wird nicht die Beschleunigung ausgelesen, sondern direkt die Kreisgeschwindigkeit: http://meineweltinmeinemkopf.blogspot.de/2013/07/kreisgeschwindigkeit-aus-dem-sensor.html

ThomasT schrieb:
Wohlgemerkt: hochauflösend - nicht unbedingt hochgenau.
Zum Vergrößern anklicken....
Deshalb meint ThomasT das es mit zusätzlicher Erfassung jeder Umdrehung und Einrechnung dann genau wird.

Und in der MPU6050 ist ein Tiefpassfilter, welches sich einstellen lässt, habe ich auch hier gelesen, hat ThomasT wohl auch gemacht:
http://www.roboternetz.de/community...it-Integrieren?p=551083&viewfull=1#post551083

Gruß Leonardi
 
ThomasT schrieb:
@gyps: Die Beschleunigung Intgrieren war auch meine ursprüngliche Intention bei den Beschleunigungssensoraufzeichnungen in ElfershaUsen 2012:
Der APproach hier ist viel profaner. Hier nehmen wir das Teil als hochauflösenden Drehzahlmesser. Wohlgemerkt: hochauflösend - nicht unbedingt hochgenau.
Zum Vergrößern anklicken....
Das verstehe ich nicht ganz: wenn ich die Graphiken betrachte sind da doch Geschwindigkeiten (1 x integriert) und sogar Strecken (2 x integriert dargestellt). Aber vermutlich habe ich noch nicht genug in dem betreffenden Thread gelesen...
ThomasT schrieb:
Was daß Video von Leonardi damit zu tun hat,, verstehe ich nicht. Ich habe z.Zt. keinen Ton.
Zum Vergrößern anklicken....
Das verstehe ich auch nicht. Wirklich Sinn macht ein Kalman-Filter ja erst, wenn man mehrere Quellen zusammenführen will (sonst kann man irgend etwas Low-Pass-artiges nehmen) und in dem Video wirkt es so, als ginge es nur um einen Rotationssensor.

Viele Grüße,

Alex
 
ThomasT schrieb:
Ein bißchen OT, aber ziemlich wichtig:
Bei dem oben erwähnten "klassischen" Beschlunigungsensormess- bzw. Auswertungsverahren muss man nicht integrieren, um die Leistung zu ermitteln. Denn zur Bestimmung der Leistung braucht man nur die Beschleunigungv.
Will man aber die Leistung abhängig von der Geschwindigkeit haben und dann auch noch die potentielle Energie abhängig von der Position rausrechnen, muss man ein- bzw. Zweimal integrieren. Und dann kommt nur Mist raus. Aber die Beschleunigung (des Fahrzeugs) vom Beschleunigungssensor, Geschwindigkeit mit dem Radsensor und Position mit GPS scheint mir eine sinnvolle Kombination. Die Beschleunigung des Fahrzeugs direkt mit dem Radsensor zu messen, wird wohl nicht viel bringen. Dazu braucht man einen zweiten Sensor an der Karosserie (den man auch zur Steigungsmessung einsetzen könnte).
Zum Vergrößern anklicken....
Das hätte ich vorher lesen sollen, bevor ich den anderen Post gepostet habe:rolleyes: Trotzdem erstaunlich wie nah die integrierte Beschleunigung an den Strecke aus der Odometrie liegt.

Das mit der Steigungsmessung ist genau das was ich in dem Projekt im Sinn hatte, das ich an den Studenten vergeben hatte. Betrachtet haben wir Gyro, Beschleunigung, Kompass, GPS und Barometer. Am brauchbarsten war zum Schluss die Kalman-gefilterte Kombination aus Barometer und GPS aber immer noch viel zu ungenau. Schlussendlich habe ich für mich entschieden, dass Sensoren, die genau genug für unsere Zwecke wären (bzgl. Steigung/Höhe) in der Preisklasse ab 1000€ anfangen. Das aber nur auf Basis von Herstellerangaben und nicht selbst nachgeprüft.

-- Alex
 
ThomasT schrieb:
Aber trotzdem ist die Aussagekraft des Videos gering.
Zum Vergrößern anklicken....
Ja man sieht nicht wie der Tiefpassfilter im Vergleich dazu abschneidet und ob er zum Gyro auch den Beschleunigungssensor eingebunden hat von welchen evtl. die Störungen beim klopfen herrühren. Andere fragen bei dem Thailänder auch schon nach dem Wunder-Code an :ROFLMAO:
Hier kann man evtl. nähere Infos dazu finden, wenn man die Sprache versteht :LOL: http://www.mechanic-top.blogspot.de
Mich interessiert es erst mal weniger.
Ob der wohl zweirädrige VM stabilisieren will, die würden dann im Stand an der Kreuzung nicht umkippen wenn man das Video mit dem fahrenden und stehenden Modellmotorrad betrachtet: https://www.youtube.com/user/TOPTHL/videos

Gruß Leonardi
 
Joerg046 schrieb:
Warum eigentlich der Aufwand mit eigenem G-Sensor und Mini Computer ?
Tut's da nicht auch ein aktuelles Smartphone ?
Zum Vergrößern anklicken....
Habe gerade entdeckt, daß mein Sony Ericson Xperia einen Gyrosensor hat - wenigstens behauptet das die App Sensorutils. Also, wenn sich jemand traut, sein Händi den riesigen Beschleunigungen am Laufrad auszusetzen, dann braucht er keine Microcontroller-Bastelei.
Anstelle des von mir noch geplanten Reedkontaktes kann man die Radumdrehungen über die Beschleunigungsspitzen zählen. Das ist aber nicht sehr zuverlässig.
 
Meine Rede. Die Hardware hat eh fast jeder bereits in der Hosentasche. Da gibt es Schrittzähler Apps und weiss nicht was noch alles. Eine Handy in die Speichen App müsste aber wahrscheinlich erst noch programmiert werden.
 
Ich versuche gerade mir vorzustellen bei einem Milan SL etwas in den Speichen zu befestigen ohne das Rad mitsamt dem Federbein ausbauen zu müssen.
 
Oben Neue Beiträge
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten