Frequenz Gyro Integration

Fuer solche Fragen gibt's ein Forum : 
http://www.mikrokopter.com/ucwiki/en/MikroKopter?action=show&redirect=FrontPage

joe schrieb:
> Mit welcher Frequenz sollte man die Daten des
> Gyroskops inregrieren?

Überhaupts nicht. Das ist der falsche Weg. Der Wert rennt dir innerhalb 
von 10 Sekunden dermaßen weg, dass du nichtmal mehr eine Ahnung hast ob 
dein Sensor auf dem Kopf steht oder nicht. Glaub mir - Erfahrungswerte. 
Zuviel Rauschen und Temperaturdrift. Bei jedem Gyro < 1000€.
Du benötigst immer eine Kombination aus Beschleunigungssensor und 
Gyroskop, auch als IMU bekannt. Darüber legt man dann einen Kalmanfilter 
http://en.wikipedia.org/wiki/Kalman_filter
Wenn man von der doch etwas komplexerern Mathematik zum Kalmanfilter 
keinerlei Ahnung hat, dann nehmen die meisten Jordis Kalmanfilter: 
http://diydrones.com/profiles/blogs/705844:BlogPost:23188
Hinterher kommt noch ein PID-Regler 
http://de.wikipedia.org/wiki/Regler#PID-Regler drauf und nach ein paar 
Wochen od. Monaten PID-Parameter-Einstellen wirst du erste Erfolge 
haben.
Das hier ist noch interessant bzgl. der Tests / Einstellung des PID: 
http://thomaspfeifer.net/quadrocopter_selbstbau_avr.htm

Nochmal zum Thema Sensorik: empfehlenswert und sehr bekannt sind die 
Sensoren von Sparkfun. Ein dt. Importeur ist Watterott. Hier gleich ein 
Link zu den IMUs:
http://www.watterott.com/de/Sensoren/IMU

Hallo joe,

> Mit welcher Frequenz sollte man die Daten des
> Gyroskops inregrieren?

Ich bastel momentan an einem Tricopter und hab nen dt von 2.5ms, also 
400Hz.

> Überhaupts nicht. Das ist der falsche Weg. Der Wert rennt dir innerhalb
> von 10 Sekunden dermaßen weg, dass du nichtmal mehr eine Ahnung hast ob
> dein Sensor auf dem Kopf steht oder nicht. Glaub mir - Erfahrungswerte.

Ich habe gegenteilige Erfahrungen gemacht. Ich nutze derzeit das 
ITG-3200 von Watterott. Wenn die Temp nicht zu sehr steigt und sinkt und 
sich innerhalb von +-5 Grad gewegt, dann ist die Drift relativ gering. 
"Langzeitmessungen" über eine ganze Stunde haben eine Drifterhöhung von 
2 - 3 Grad/s ergeben. Auch das Rauschen ist wirklich sehr sehr gut 
(deutlich kleiner 1 Grad/s) Problem, wie Michael auch schon geschrieben 
hat ist, dass der Fehler quadratisch ansteigt, wenn man integriert.

> Zuviel Rauschen und Temperaturdrift. Bei jedem Gyro < 1000€.
> Du benötigst immer eine Kombination aus Beschleunigungssensor und
> Gyroskop, auch als IMU bekannt. Darüber legt man dann einen Kalmanfilter
> http://en.wikipedia.org/wiki/Kalman_filter

Für den Anfang vllt. ein wenig ein Overkill. Such mal unter Google nach 
"The Balance Filter". Ist ein einfacher Komplementärfilter der wirklich 
im schwebenahen Flug mit wenig bzw. aussetzenden dynamischen 
Beschleunigungen sehr schöne Ergebnisse liefert! Aber vorher liegt 
meiner Meinung nach schon das Problem, dass Wenige den Unterschied 
zwischen der Messgrößenerfassung im körperfesten (Gyro) und inertialen 
(Beschleunigungsmesser) kennen. Sprich die Umrechnung der 
Body-fixed-Raten (Roll, Nick, Gierrate) in die Eulerraten ... ist zwar 
nur ne lappige Jacobi-Matrix, aber ohne die kommt schnell Käse aus dem 
Filter ...

Grüße,
Michael

Hallo joe,

Die Raten, welche von Deinen Gyro gemessen werden, sind unabhängig der 
aktuellen Lage des Fluggeräts (körperfestes Koordinatensystem). Stell 
Dir vor, das Fluggerät ist in Nulllage (Roll und Nickwinkel sind 0) und 
Du integrierst deinen Nickwinkel aus Deinen Nickraten). Aus der Nulllage 
raus funktioniert das auch wunderbar.
Jetzt stell Dir vor, das Fluggerät ist im "Messerflug" (also Rollwinkel 
= 90). Eine Nickrate hat jetzt jedoch nur Einfluss auf die Flugrichtung 
und nicht den Nickwinkel. Wenn Du jetzt wieder über die Nickrate 
integrierst, dann machst Du einen erheblichen Rechenfehler und Dein 
Filter spukt falsche Lageinformationen aus.
Das genannte ist jetzt zwar das extrem und um die Nulllage +-10 Grad 
sollte es auch funktionieren, aber wenn Du bis +-45 Grad mal die Lage 
von Deinem Fluggerät regeln willst, dann funzt das nicht mehr so gut ... 
(die Erfahrung hab ich auch selbst gemacht).
Hier ist die Umrechnung dokumentiert:
http://www.mathworks.com/help/toolbox/aeroblks/simplevariablemass6dofeulerangles.html

und die Umrechnung ist für Dich interessant:

http://www.mathworks.com/help/toolbox/aeroblks/eqn1243882117.gif

Sieht sehr schlimm an Anfang aus, aber ist leider unverzichtbar. Schau 
mal im Internet nach Flugmechanik Skripten da stehen meist die 
unterschiedlichen Koordinatensysteme drin (anfangs ist für Dich nur 
Bodyfixed und Inertial wichtig, also körperfestes und inertiales KS).

Du fängst aber hoffentlich LRT an zu studieren, oder?

Grüße,
Michael

Michael K. schrieb:
>> Überhaupts nicht. Das ist der falsche Weg. Der Wert rennt dir innerhalb
>> von 10 Sekunden dermaßen weg, dass du nichtmal mehr eine Ahnung hast ob
>> dein Sensor auf dem Kopf steht oder nicht. Glaub mir - Erfahrungswerte.
>
> Ich habe gegenteilige Erfahrungen gemacht. Ich nutze derzeit das
> ITG-3200 von Watterott. Wenn die Temp nicht zu sehr steigt und sinkt und
> sich innerhalb von +-5 Grad gewegt, dann ist die Drift relativ gering.
> "Langzeitmessungen" über eine ganze Stunde haben eine Drifterhöhung von
> 2 - 3 Grad/s ergeben. Auch das Rauschen ist wirklich sehr sehr gut
> (deutlich kleiner 1 Grad/s) Problem, wie Michael auch schon geschrieben
> hat ist, dass der Fehler quadratisch ansteigt, wenn man integriert.

Dann schaukel mal ein bisschen dein Gyro und freu dich über imposante 
Werte. Noch ein bisschen (viel) Vibration von Brushlessmotoren + ein 
bisschen Wind am Quadrocopter im Einsatz und du wirst stauenen. Da dann 
auch noch nach den Mischern einen PID drüber zu stülpen ist ziemlich 
arg. Wir haben uns in nur einer einer Achse versucht. Sobald da Bewegung 
/ Vibrationen dabei sind ist der Zirkus nichtmehr zu retten.

@Michael: Wie gesagt, der Fehler beim Integrieren der Bodyrates führt 
sicherlich langfristig zu keinen brauchbaren Ergebnissen, da gebe ich 
Dir Recht. Dennoch sind die Sensorwerte in meinen Augen sehr brauchbar. 
Ohne Lagefilter ala Kalman, DCM oder Komplementär wird das trotzdem nix 
...

Grüße,
Michael

Michael K. schrieb:
> Dennoch sind die Sensorwerte in meinen Augen sehr brauchbar.

Die Frage ist was für dich brauchbare Werte sind. IMHO sind die Werte 
(in Bewegung mit Vibration, etc) ohne den Zusammenhang mit einem 
Acc-Sensor und Kalmanfilter unbrauchbar.

Michael K. schrieb:
> Ohne Lagefilter ala Kalman, DCM oder Komplementär wird das trotzdem nix
> ...

Sag ich ja die ganze Zeit. Ich bin nun in diesem Thread wahrlich der 
erste, der den Kalmanfilter als notwendig genannt hat. =)

> Die Frage ist was für dich brauchbare Werte sind. IMHO sind die Werte
> (in Bewegung mit Vibration, etc) ohne den Zusammenhang mit einem
> Acc-Sensor und Kalmanfilter unbrauchbar.

Bei meinem Tricopter liegen die Vibrationen der Gyros im Flug bei rund 
+-5 - 10 Grad/s. Derzeit stabilisiere ich die Hochachse nur über die 
Gyrowerte (Heading-Lock) und es funzt ohne Probleme und ohne dass das 
Ding sich die ganze Zeit aus der relativen, zu haltenden Richtung 
wegdreht. Sicher ist eine leichte Drift auf dem integrierten "Heading", 
aber dennoch gering genug um stressfrei 10-15 Minuten zu fliegen 
(Statisch ca. 5-10 Grad Drift pro Minute).

> Sag ich ja die ganze Zeit. Ich bin nun in diesem Thread wahrlich der
> erste, der den Kalmanfilter als notwendig genannt hat. =)

Das stimmt, wobei ich der Meinung bin, dass so ein Kalman für das 
"bisschen" Lageregelung von einem xCopter ein wenig overdone ist. Da 
gibt es auch einfachere Verfahren, welche weniger theoretisches 
Hintergrundwissen erfordern, wie DCM oder KP-Filter und zudem erheblich 
weniger Rechenaufwand benötigen. Ich hab auch ein paar Paper hier, wo 
Vergleiche zwischen Kalman und DCM gefahren wurden, die gezeigt haben, 
dass die Performanz des Kalman zwar marginal besser ist als DCM, dafür 
jedoch fast 50% mehr Rechenaufwand bedeuten. Wenn man ne FPU im Proz 
hat, dann ist das noch stressfrei, aber auf einem AVR mit 8bit ohne FPU, 
wo man bei den gängigen Regelfrequenzen von 400 - 1000Hz den Filter und 
die Regelung fahren muss bedeutet das relativ viel Aufwand und 
Hirnschmalz, um das Ganze auf Fixed-Point zu bringen. Da ist es doch 
einfacher einen weniger komplizierten Algo zu verwenden ...
Du scheinst mir ein Kalman-Fan zu sein ;-) Ich find die Filter auch 
geil, aber der TE fängt erst zu studieren an ... IMHO, da ist ein Kalman 
für den Anfang wohl ein wenig zu viel ...

Grüße,
Michael

> lass dir bitte hier keinen Unsinn einreden.

Mit Verlaub, aber ich denke dass das kein Unsinn ist, was ich bzw. der 
andere Michael geschrieben haben. Der TE hat jedoch nicht genau 
definiert, wie er das Fluggerät fliegen/steuern möchte (Das ist Dein 
Einsatz joe ;-) ). Wenn er "nur" Raten-Kontrolle haben will, dann ok. Da 
reichen die Gyros. Nachdem er aber schon was von Beschleunigungssensoren 
geschrieben hatte, ging ich davon aus, dass er das Vehikel auch 
lagestabilisieren will.

Grüße,
Michael

Michael K. schrieb:
> Bei meinem Tricopter liegen die Vibrationen der Gyros im Flug bei rund
> +-5 - 10 Grad/s. Derzeit stabilisiere ich die Hochachse nur über die
> Gyrowerte (Heading-Lock) und es funzt ohne Probleme und ohne dass das
> Ding sich die ganze Zeit aus der relativen, zu haltenden Richtung
> wegdreht. Sicher ist eine leichte Drift auf dem integrierten "Heading",
> aber dennoch gering genug um stressfrei 10-15 Minuten zu fliegen
> (Statisch ca. 5-10 Grad Drift pro Minute).

Das ist interessant - hätte ich nicht gedacht, dass das so gut geht. 
Werde mir das ITG-3200 mal anschauen und selbst versuchen. Ich hatte 
meinen ersten Kontakt vor 2 od. 3 Jahren mit einem mittelgroßen 
balancierenden Roboter gemacht (ca. 10kg). Da hatten wir zuerst versucht 
nur über die Gyros zu gehen (ist ja nur eine Achse), da gabs ordentlich 
Trouble. Darum sind wir dann ganz schnell in Kalman eingestiegen.

Michael K. schrieb:
> Ich hab auch ein paar Paper hier, wo
> Vergleiche zwischen Kalman und DCM gefahren wurden, die gezeigt haben,
> dass die Performanz des Kalman zwar marginal besser ist als DCM, dafür
> jedoch fast 50% mehr Rechenaufwand bedeuten.

Das klingt interessant - dürfte ich dieses Paper auch haben? Also nicht, 
dass ich dir nicht glaube - mich interessiert nur die Thematik ziemlich. 
Gute und Zuverlässige Informationen die nicht vom Hören-Sagen kommen 
sind leider nicht mehr allzu häufig.

> Wenn man ne FPU im Proz
> hat, dann ist das noch stressfrei, aber auf einem AVR mit 8bit ohne FPU,
> wo man bei den gängigen Regelfrequenzen von 400 - 1000Hz den Filter und
> die Regelung fahren muss bedeutet das relativ viel Aufwand und
> Hirnschmalz, um das Ganze auf Fixed-Point zu bringen. Da ist es doch
> einfacher einen weniger komplizierten Algo zu verwenden ...

Okay da ist was dran - ich hab dann natürlich auch zu höheren Mitteln 
gegriffen. Hab halt einen dsPIC33 eingespannt. Der kann halt schon Daten 
schaufeln. Gerade beim Kalman, etc lässt sich das hervorragend nutzen. 
60 MIPS haben schon einiges Potenzial. Overkill ist es trotzdem ...

> Du scheinst mir ein Kalman-Fan zu sein ;-) Ich find die Filter auch
> geil, aber der TE fängt erst zu studieren an ... IMHO, da ist ein Kalman
> für den Anfang wohl ein wenig zu viel ...

Ja klaro ist es für den Anfang schon ziemlich heftig. Ich glaube / 
erwarte auch nicht, dass man versteht was man da tut. Ich gehe beim TO 
eher davon aus, dass er einen Quadrocopter bauen möchter der ordentlich 
fliegt und sich nicht mit höherer Mathematik beschäftigen möchte. Ich 
bin in der Tat ein Kalman-Fan. Ich habe ihn als Magic-Black-Box 
kennengelernt den man mit miesen Daten füttern konnte und hinten kamen 
gute Daten raus =) Das Verständnis kommt erst viel später. Um ihn mal 
richtig verstanden zu haben, muss man ihn einfach mal selbst durchdacht, 
durchgespielt und programmiert haben. Aber das ist ja nicht das, was ein 
Anwender machen möchte. Ich empfehle den Kalmanfilter Anfängern ganz 
gerne weil es ein Rundumsorglospaket ist (und für den 
Anwendungsorientierten Basteler / Entwickler einfach). Es gibt ihn 
fertig - man muss nur noch minimalste Anpassungen machen (Jordis 
Implementierung ist gut auskommentiert) - man braucht dazu eigentlich 
kaum Kalmanfilter-Wissen. Um ihn natürlich voll auszuschöpfen und sein 
enormes Potenzial nutzen zu können, bedarf es schon ein erweitertes 
Verständnis. Für den Anfänger ist das tolle, dass er  in der 
Grundkonfiguration (natürlich in begrenztem Maße) aus Dreck und Rauschen 
Gold machen kann. Das geht natürlich wie du ganz richtig erwähnt hast 
auf Kosten der Leistung.

So ähnlich verhält es sich mit dem PID Regler - die meisten nutzen eine 
fertige Library die sie zwar kaum verstehen, aber die Parametrisierung 
klappt dann nach einigem Probieren bei den meisten.

OlliW schrieb:
> lass dir bitte hier keinen Unsinn einreden. Such mal nach den Projekten
> Wii-MultiCopter und KK-MultiCopter (z.B. im Forum rcgroups.com). Deren
> Code ist offen und da kannst du reinschauen. Du wirst feststellen
> (gerade beim KK-Projekt), dass man eine Quadrocopter hervorragend mit
> simplen P-Reglern auf simplen Piezo-Gyros fliegen kann. Die neue Version
> vom KK Code, sowie der Wii-Code im acro-mode benutzen einen PI-Regler.
> Die Kombination mit nem Beschleunigungssenosr (und erst dann wird Kalman
> etc relevant) braucht man erst wenn man den Copter nicht nur als
> Sprotgerät verwenden sondern eine gewisse "Autonomie" haben will, wenn
> du also die Finger für ne lange Zeit vom Sender nehmen können willst.
> Aber auch das kann der Wii-Code.

Das ist natürlich immer eine Frage der Ambitionen. Ich sage ehrlich, 
dass ich bei meinem Octo so gerarbeitet habe, dass er problemlos autonom 
fliegen kann. Heißt, dass sämtliche Korrekturen, etc. von der Software 
vorgenommen werden müssen. Lustig wirds dann wenn du z.B. in engen 
Innenräumen fliegen möchtest, da gibts dann lustige Verwirbelungen, etc 
... da ist es dann wichtig eine möglichst exakte Sensorik zu haben - 
ansonsten hat man da schnell verloren. Wollte man z.B. Kunstflug machen 
(mehrere Loopings am Stück, etc), dann reichen dir Piezogyros nichtmehr. 
Da läuft dann dein PID am Limit und es wird plötzlich ziemlich 
entscheidend mit welcher Updaterate du deinen Regler fütterst ...
Für einen 
"ich-fliege-durch-die-Gegend-mit-der-Hand-am-Steuerknüppel-Tri/Quardo/Oc 
to"  sind sicherlich mit Einschränkungen einfachere Aufbauten effektiv 
und für die meisten auch ausreichend. Erfahrungsgemäß steigert man sich 
dann mit der Zeit ganz automatisch.

> ich kann im ersten Post nichts von Beschleunigungssensor lesen sondern
> nur im vierten Post das Gyrosignal integrieren nicht gut ginge...

Stimmt.

> PS: heading hold ist nichts anders als der I Term, bei dem bekanntlich
> zu integrieren ist...

Das ist mir bewußt, ich habs ja auch implementiert. Die Sache ist nur, 
dass die Drift auf der Hochachse, wenn auf die Lagewinkeln geregelt wird 
(Phi, Theta, Psi) wenig "Schlimmes" anrichten kann ausser, dass der 
Flieger in eine "falsche" Richtung schaut. Im Gegenzug hat eine eine 
Drift auf die Roll- und Nickwinkel einen erheblichen Einfluss! Die 
einzige Alternative wäre eine RCAH (Rate command attitude hold) Regelung 
mit relativen und NICHT absoluten Lagewinkeln.

> @Joe:
> link zum Wii multicopter von AlexinParis Project
> http://www.multiwii.com/
> http://www.rcgroups.com/forums/showthread.php?t=1261382.
> Beim Wii hast du alle Optionen. ITG3205/3200, Acc, Barometer. Und läuft
> auf nem popeligen Atmega.
>
> links zum KK mulitcopter projekt von KaptainKuk
> http://www.kkmulticopter.com/
> http://www.rcgroups.com/forums/showthread.php?t=1143569
> http://www.rcgroups.com/forums/showthread.php?t=1458663

Die Projekte kenne ich und ich find sie auch klasse! Als ich mit meinem 
Tricopter angefangen habe, war ich anfangs auch auf der Suche nach 
nachvollziehbaren Implementierung, von denen man sich ggf. Anregungen 
holt. Dennoch habe ich mich entschlossen alles "from scratch" zu 
implementieren um einerseits das Gesamtsystem von A-Z zu durchdringen 
und andererseits mich sehr stringent, auch im Hinblick auf meinen Job an 
der Uni für beispielsweise Praktika, an die entsprechenden 
Luftfahrtnormen (Bezeichnungen und Koordinatensysteme) zu halten (z.B. 
LN9300).

@Michael: Ich gebe Dir Recht, dass es sehr viel gute Implementierung 
(Kalman, PID, ...) gibt und es für einen Anwender einfacher ist die 
Dinge zu nehmen und anzupassen. Im meinem Fall war das jedoch nicht das 
Designziel und Zweck der Übung ...
Ich versuche das Paper mal zu finden ... Momentan jonglier ich hier mit 
rund 500 Papern, die alle ihren Weg in das State-of-the-Art Kapitel 
meiner Diss finden wollen ... sobald es wieder auftaucht leite ich's Dir 
weiter ...

Grüße,
Michael

> Nein ;) Das ist so ein allgemeines Ingenieurstudium, das von allem etwas
> enthält... Und dann kann ich mich mit dem Masterstudiengang weiter
> spezialisieren (Engineering Science an der Uni Bayreuth)

Klingt doch wunderbar!

> Wie groß ist bei dir der Offset der Sensoren? Bei mir liegt der (im
> Ruhezustand) bei der Z-Achse bei bis zu 5°/s... Ich mache das im Moment
> so, dass ich beim Starten 100 Werte der einzelnen Achsen lese und daraus
> den Mittelwert berechne und den dann von jeder Messung abziehe. So
> erhalte ich ein Rauschen von max. 1°/s

Das ist bei mir ähnlich ... vor dem Fliegen werden 1024 Messwerte 
erfasst, gemittelt und von den nächsten Sensorwerte als "Initialbias" 
abgezogen ..

> Ich habe gestern mal kurz etwas zusammengestrickt aus den Werten des
> Beschleunigungssensors und des Gyros (wie in "The Balance Filter"
> beschrieben)  und die Daten die ich erhalte sehen recht brauchbar aus...
> Das ganze werde ich nun noch auf fixed-point umschreiben (0.1° Auflösung
> sollten ja reichen oder?)

jup. Ich habs da ein wenig übertrieben ... ich löse ein Grad in 10bit 
auf ...

> Achso, ich will auch alles von Grund auf selbst bauen und
> programmieren... Als nächsten kommen die Brushless-Regler dran ;)

Cool. Nach dem MK-Vorbild?

Grüße,
Michael

Michael K. schrieb:
> jup. Ich habs da ein wenig übertrieben ... ich löse ein Grad in 10bit
> auf ...

lol - dann kann ich verstehen, dass du Probleme mit der Rechenleistung 
bekommen würdest, wenn du dann mit einem Atmega rangehst und versuchen 
würdest einen Kalman mit 400kHz zu füttern. Wie sieht es denn bei deinen 
10bit mit der Signalqualität aus? 6 LSB Hintergrundrauschen? Oder wie 
darf ich mir das vorstellen?

:) So schlimm ists nicht. Der Filter braucht momentan knapp 0.2ms für 
die Rechnung. Alles FP und die trigonometrischen Funktionen aus LUTs. Im 
Endeffekt ist es wurscht da eh alles int32 gerechnet wird ...
Soviel Rauschen ists zum Glück nicht ... halt einfach ein paar gültige 
Stellen mehr ....

jup, siehe Anhang.

Grüße,
Michael

Gern. Zehntelgrad sind für uns Menschen zwar "schön", da einfach 
interpretiertbar, aber bedenke dass der AVR leichter durch 8 als durch 
10 teilen kann ... Demnach ist vllt. eine Basis 2^n eventuell günstiger 
(Stichwort: Bitshiften)

Grüße,
Michael

Außerdem nutzt es den natürlichen Wertebereich der Variablen besser aus.