Gyro in °/s auslesen

[JanPet]

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

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.

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

Volt = (analogRead(Gyro_X) * 3.3) / 1024.0;
GradProSec = Volt * 110.0;

bzw.

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.

Gyro = ((Gyro - Offset_Gyro) * (3.3/1023) / 0.0091 )* 3

Soooooooooo......

Jetzt kommt das "verrückte":

Wenn ich nach meiner Formel oder nach deiner Formel Rechne dann machen wir beide:

(3.3/1024) * 110     = 0.3544
(3.3/1024) /0.0091  =0.3544

Und wenn das dann mit * multipliziere

0.3544 * 3 ~1

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


Ich hab absolut keine Ahnung was da los ist

[schorsch_76]

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

[JanPet]

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.

[Besserwessi]

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.

[schorsch_76]

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

[Besserwessi]

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.

[schorsch_76]

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