Gyro in °/s auslesen

[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