-
Gyro in °/s auslesen
Hallo,
ich habe hier die IMU Sensoreinheit 5DOF von PSarkfun vor mir liegen.
Verbaut sind hier Beschleunigungssensoren für Z,Y und X Achse und
Gyrosensorik für X und Y Achse.
Ich möchte die X-Achse des Gyrosensors auslesen und in °/s also Grad pro Sekunde umrechnen.
Damit komme ich leider nicht klar, weil ich so viele unterschiedliche Ansätze im Internet gelesen habe...:confused:
Der Gyrosensor besitzt einen Hi und eine Low-Res anschluss. ich möchte den Hi-Res anschluss verwenden.
Daten:
Messbereich: 110°/s
Sensitivity: 9.1mV/°/s
Zum Einlesen verwende ich einen Mikrocontroller mit 10-Bit ADC und als
Referenzspannung verwende ich 3.3V. Der Sensor besitzt ebenfalls 3.3V als Versorgungsspannung.
1.Löungsversuch:
Code:
float Gyro = analogRead(Gyro_X);
Gyro = (Gyro - Offset_Gyro) * (3.3/1023) / 0.0091;
Die Auflösung des uC mit (3,3 Referezspannung / 1023 Stellen) / Auflöung des Sensors
Leider kommt so definitiv kein °/s raus, die Werte sind viel zu gering
2.Lösungsversuch:
Code:
110°/s * 0.0091 = 1V <-- Also gibt der Sensor 1V aus, wenn die Winkelgeschwindigkeit 110°/s beträgt.
1024/3.3V = 310 <-- So viel Schritte sinds pro V, also pro 110°/s
310 Schritte / 110° <-- 1Schritt = 2,81°/s
float Gyro = analogRead(Gyro_X);
Gyro = (Gyro - Offset_Gyro) * 2,81 <-- Also die Schritte kommen vom ADC Wandler, und ich weis pro Schritt sinds 2,82°/s
Alle weiteren Lösungsversuche waren eher (sinnfreies) rumprobieren...
Ich wäre sehr Dankbar um eure hilfe :)
häng da iwie...mein Hirn will nicht mehr :(
-
Hi,
ich würde die Zeile
Code:
Gyro = (Gyro - Offset_Gyro) * (3.3/1023) / 0.0091;
so schreiben
Code:
Volt = (analogRead(Gyro_X) * 3.3) / 1024.0;
GradProSec = Volt * 110.0;
Immer schön in einzelnen Schritten denken ;)
Gruß
Georg
EDIT: Welche Spannung gibt dir der Gyro bei 110°/s? 1 Volt oder Vcc?
EDIT2:
Ok, hier sind die datasheets der verwendeten Chips [1] [2] Laut [1] müsstest du also 1V bei 110° pro sec haben. Denke dass die Formel wie oben dann passen müsste.
[1] http://www.zagrosrobotics.com/files/...eet_IDG500.pdf
[2] http://www.zagrosrobotics.com/files/adxl335.pdf
-
hmmm der code ist so zwar schöner aber leider kommt
immernoch der selbe mist raus....Ändert null am ergebnis.
Edit:
ich glaub das is einfach richtig, kann das sein? ;)
Ich versteif mich hier voll dass das Ergebnis falsch ist....
Ich brächte vllt einfach ne bestätigung dass kein Programmierfehler vorhanden ist.
-
Der Sensor gibt mir bei 100°/s 1V aus.
Laut Internet 110°/s * 9,1mV = 1V
-
Kannst du AREF auf 1V reduzieren mittels einer Zener Diode? So würdest du die Auflösung deutlich erhöhen :)
Gruß
Georg
-
Das geht leider nicht, weil die Sensoren bei 0°/s bereits eine Bias-Spannung ausgeben.
Laut Datenblatt liegt im "Stillstand" eine Spannung von 1.35V an.
Im Datenblatt vom IDG-500 findet man das unter Static Output (Bias).
Durch Beschleunigen nach links wird dann 1V abgezogen, bei Beschleunigung
nach rechts dann +1V addiert.
-
Wenn möglich würde ich versuchen eine Tabelle mit gelieferten Werten und echten Werten aufzunehmen. Hieraus kannst du dann eine Kalibrierung vornehmen. Mit etwas Glück kommst du mit einer Geraden hin. Mit der Methode der kleinsten Quadrate kannst du dann die beste Mittelung errechnen.
Siehe das Beispiel mit der Geraden
Gruß
Georg
-
Den Filter den du da nennst verwendet man doch eher bei Rauschendem Signal oder?
Der Sensorwert schwank nur minimal. Das könnte ich aber sehr gut bei meinem zweiten Sensor,
dem Beschleunigungssensor verwenden :p
Wie ich jetzt weiter vor gegangen bin:
Die Winkelgeschwindigkeit stellt ja immer eine änderung des Winkels dar. Addiere, bzw integriere ich die änderungen
über die Zeit auf, so sollte ich den Winkel in ° erhalten.
Code:
Winkel = Winkel + Gyro * dt
dt ist die Zeit, z.B. Zykluszeit von einem Interrupt.
Also die Zeit, die seit der letzten integration vergangen ist.
wenn ich jetzt den Sensor neige, werden die werte auch schön integriert und ich erhalte meinen Winkel, der ist allerdings viel zu klein :(
Dann habe ich ne Tabelle angelegt mit echtem Winkel (Waaserwage mit Winkelanzeige) und der Integrierten Winkel.
und der Integrierte Winkel ist IMMER um x3 kleiner als der tatsächliche.
Also entweder stimmt die Formel von oben
Code:
Volt = (analogRead(Gyro_X) * 3.3) / 1024.0;
GradProSec = Volt * 110.0;
bzw.
Code:
Gyro = (Gyro - Offset_Gyro) * (3.3/1023) / 0.0091;
nicht, oder Sensor ist schuld und gibt mir zu wenig °/s aus.
Da es sich um nen Faktor handelt, der immer gleich bleibt.....kann ich natürlich einfach das Gyrosignal *3 nehmen.
Code:
Gyro = ((Gyro - Offset_Gyro) * (3.3/1023) / 0.0091 )* 3
Soooooooooo......:strom
Jetzt kommt das "verrückte":
Wenn ich nach meiner Formel oder nach deiner Formel Rechne dann machen wir beide:
Code:
(3.3/1024) * 110 = 0.3544
(3.3/1024) /0.0091 =0.3544
Und wenn das dann mit * multipliziere
Mit Worten ausgedrückt: Ich rechne momentan mit den "Steps" des AD-Wandels....
Also ich rechne im Prinzip wieder zurück und benutze zum errechnen des Winkeln die Integerzahlen von 0-1023 :confused:
Ich hab absolut keine Ahnung was da los ist
-
Ich verstehe, du siehst dass das ganze nicht ganz passt, am Ergebnis deiner Integration. Du drehst deinen Bot/Sensor um 110° und siehst, dass das Integrationsergebnis eben nicht 110° sind. Also wieder einen Schritt zurück. WIe sieht das Signal bei der Drehung wirklich aus? Kannst du mit einem Speicheroszi die Spannung während der Drehung messen und den uC den maximalen Wert der "Volt" aufzeichnen lassen? Passen die Messwerte Oszi/uC überein?
Evtl. ist dein dt zu klein oder der Interrupt löst noch nicht mit der richtigen Frequenz aus.
Dir ist klar, dass sich hier am Winkel der Messfehler aufsummiert?
Diese Kalibrierfunktion wird beispielsweise bei Verarbeitungsmaschinen eingesetzt um ausgelesene Sensorwerte mit extern gemessenen Werten zu kalibrieren. So wird sichergestellt, bei der jährlichen Wartung, dass die Maschine immer noch richtig funktioniert und nicht einen verstellten Sensor hat.
Maschinen Sensor --> AD --> Kalibrierungsgerade ---> Maschinenwert
Gruß
Georg
-
Ja genau das hast du richtig verstanden! Ich neig den Roboter und anhand der Integration muss zumindest
Zeitweise der richtige Winkel als Ergebnis kommen.
Also der Interrupt kommt auf jeden Fall alle 10ms, das habe ich mit einem Oszi nachgemessen (ausgänge gesetzt).
Die Signale kann ich leider nicht am Oszi messen, weil das keine Specherfunktion hat. Und für direktes Messen ist es zu träge....
Was meinst du die Messfehler summieren sich auf? Bzw. welche Messfehler meinst du?
Also rein mit Gyrosensoren bekommt man keinen vernünftigen Winkel! Das ist Fakt. Nicht mit den aufwendigsten Filtermethoden.
Aber zumindest kurzzeitig muss es klappen. Meine Gyros weichen wenn ich jetzt den Faktor von 3 verwende in 40 sekunden um 5° ab.
Also ohne Winkelgeschwindigkeit, rein das Gyro-Bias aufintegrieren bin ich nach 40 sekunden bei 5°.
Wenn ich den Faktor von 3 benutze passt ja alles, ich versteh nur nicht warum.
Die Kalibierung von Gyros erfolgt auch in der Praxis häufiger! Die Sensoren besitzen auch eine Auto-Zero funktion, die aber anscheinend nichts anderes macht als
ich per Programm.
-
Die Umrechnung mit den Fließkommazahlen kann je nach µC und Takt schon relativ lange brauchen, ggf. auch mehr als 10 ms ( z.B. bei 1 MHz Takt). Die Zeit wird dann nicht mehr vom Timer bestimmt, sondern von der Laufzeit.
Ideal sollte die Abfrage des ADs sogar noch etwas schneller sein (z.B. alle 2,5 ms) um die volle Bandbreite bis 140 Hz abzutasten.
Wenn irgend möglich sollte man die Integration noch mit Integer-zahlen machen. Das ist schneller, braucht weniger Speicher und gibt keine Rundungsfehler. Die Umrechnung kann man dann nachher machen, wenn man den Winkel ausgibt oder damit rechnet. Nur mit dem Offset wird das ggf. etwas schwieriger, denn der muss nicht ganzzahlig sein - das lässt sicher aber auch lösen, z.B. indem man den Bruchteil noch einmal über Zeit * Bruchteil berechnet.
Der Offset vom Gyro gibt immer wenigstens einen kleinen Fehler, auch nach Nullabgleich. Aufsummiert wandert der Winkel mehr oder weniger langsam, halt so etwa wie die 5 Grad in 40 s oder 1/8 Grad/s. Das entspricht einem Fehler von rund 1 mV oder etwa 1/3 der AD Stufung.
-
Flieskommazahlen haben nur sehr begrenzte Genauigkeit. Jede Messung hat immer eine gewisse Ungenauigkeit. Egal ob Zeit oder Drehung. Du summierst am Winkel, wiederholt eine ungenaue Messung auf. Hier summiert sich also ein Fehler auf. Das ist ein ähnliches Problem, dass die Wettervorhersage hat ;) Siehe dazu auch Toleranzrechnung bei Wikipedia.
Gruß
Georg
-
Die Fließkommazahlen bringen schon einen kleinen zusätzlichen Fehler rein, aber der ist zu vernachlässigen, denn auch die Single Version hat 24 Bit Auflösung für die Matisse. Das sind deutlich kleinere Fehler als durch den AD-Wandler oder den Sensor. Die Zeit ist eher keine Problem: der Takt ist leicht sehr genau hinzubekommen und das Timing lässt sich ohne zusätzliche Fehler an den Takt anbinden.
Das Problem beim aufsummieren ist einfach der Offset des Sensors. Ein kleiner Fehler ist da nicht zu vermeiden und entsprechend hat man immer eine Drift. Je besser man es macht, desto kleiner wird die Drift, aber ganz ohne Drift geht es nicht.
-
Das Problem mit der Messung ist, dass du hier zyklisch 2 Messwerte (Zeit und Winkel) multiplizierst. Es multipliziert sich auch der Fehler. Dieser wird zusätzlich aufsummiert und geht in alle folgenden Ergebnisse ein.
Siehe dazu auch "Kumulation von Rechenfehlern" bei http://www.mpdvc.de/artikel/FloatingPoint.htm
Das heißt nicht, dass man keine floats hernehmen darf, mann muss es nur wissen ;)
Hab oben den nicht ganz richtigigen Link genannt: http://de.wikipedia.org/wiki/Fehlerrechnung
Gruß
Georg
