Guten Abend, zur Zeit bin ich an der Planung eines Quadrocopters. Ich habe schon viel über das Thema gelesen und mich eingearbeitet. Nun habe ich aber mal eine kleine Frage: Mit welcher Frequenz sollte man die Daten des Gyroskops inregrieren? Klar ist eine höhere Frequenz/ein kleineres dt besser, aber ab wann erhält man sinnvolle und aussagekräftige Werte? Sind 300Hz genug?
Fuer solche Fragen gibt's ein Forum : http://www.mikrokopter.com/ucwiki/en/MikroKopter?action=show&redirect=FrontPage
Hi, joe, > Mit welcher Frequenz sollte man die Daten des > Gyroskops inregrieren? Klar ist eine höhere Frequenz/ein kleineres dt > besser, aber ab wann erhält man sinnvolle und aussagekräftige Werte? Wenn Du Dein Fluggerät stabilisieren willst, dann modelliere dies als System. Wie funktioniert Dein Fluggerät? Was stört dessen Balance? Wie schnell reagiert es auf eine Störung? Wie schnell musst Du die Abweichung erkennen, um mit einer PID-Regelung wieder den Sollzustand zu erreichen? Daraus kannst Du dann selbst errechnen, wie oft Du abfragen musst. Joe, Ingenieurdenken hilft auch beim Quadrokopterbau. Ciao Wolfgang Horn
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, > Wenn Du Dein Fluggerät stabilisieren willst, dann modelliere dies als > System. > Wie funktioniert Dein Fluggerät? Was stört dessen Balance? Wie schnell > reagiert es auf eine Störung? Wie schnell musst Du die Abweichung > erkennen, um mit einer PID-Regelung wieder den Sollzustand zu erreichen? > Daraus kannst Du dann selbst errechnen, wie oft Du abfragen musst. Danke für deine Antwort. Wie modelliere bzw simuliere ich so ein Modell am besten? Gibt es dafür spezielle Software? > Joe, Ingenieurdenken hilft auch beim Quadrokopterbau. Ingenieur bin ich noch nicht, aber zum Wintersemester fange ich ein Ingenieurstudium an ;) Bin dieses Jahr erst mit der Schule fertig geworden... > Ü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. Das ist mir schon klar ;) Ich habe 3 Beschleunigungssensoren und auch 3 Gyroskope. Wie die Regelung eines Quadrocopters in der Theorie funktioniert habe ich fast verstanden... Und nun bin ich eben an der praktischen Umsetzung..
Wenn es analoge Sensoren sind, dann ist da meist ein Tiefpass auf der Platine drauf mit der die Grenzfrequenz eingestellt wird. Nach Shannon/Nyquist musst Du dann mit der doppelten Grenzfrequenz abtasten...bekommst dann aber noch gedämpft die Spiegel-Frequenzen mit rein. Ansomsten stimme ich meinen Vorrednern zu, das isz nicht gerade trivial! Von Stochastik sollte man schon etwas Ahnung haben. Dann noch Sensordatenfusion der Gyros/Beschleunigungssensoren über Kalman-Filter oder Direction Cosine Matrix (DCM). Gruß
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
>> 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. Danke für deine Antwort ;) >> Ü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 ... Genau den "The Balance Filter" wollte ich auch verwenden. Wieso muss ich das in Eulerraten umrechnen? Hast du da mehr Infos für mich? Ich kenn mich zwar noch nicht so gut aus, aber ich bin bereit zu lernen ;) In der Schule hatte ich auch Mathe Leistungskurs und Physik im Abitur (sogar 15 Punkte xD ich frage mich immernoch wie ich das geschafft habe...), also denke ich, dass ich mich einiger Einarbeitung solche Themen auch verstehen sollte... Viele Grüße
Achso, ich verwende auch den ITG3200, nur mit dem habe ich im moment noch ein kleines Problem... : Beitrag "Problem mit ITG3200 Gyro (i2c)"
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
Lieber Joe, 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. Olli PS: Integrieren der Gyrosignale ist kein Problem (musst halt nur das mit den 360 Grad handhaben), und die Ferquenz ergibt sich ganz natürlich aus der Fregeunz mit der du die Motoren ansteuerst, welche möglichst gross sein soll, 400-500Hz sind bei den DIY Coptern momentan das normale. PPS: der Wii-Code kann auch den ITG3205/3200 __________ www.olliw.eu
> 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: ich kann im ersten Post nichts von Beschleunigungssensor lesen sondern nur im vierten Post das Gyrosignal integrieren nicht gut ginge... PS: heading hold ist nichts anders als der I Term, bei dem bekanntlich zu integrieren ist... @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
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
Hallo, puh, das sind ja inzwischen einige Antworten.. ich fange mal von oben an ;) Michael K. schrieb: > 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/sim... > > und die Umrechnung ist für Dich interessant: > > http://www.mathworks.com/help/toolbox/aeroblks/eqn... > > 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). Danke für deine Erklärung ;) Ganz steige ich da noch nicht durch, aber ich werde mir das mal genauer anschauen und dann versuchen zu implementieren. > Du fängst aber hoffentlich LRT an zu studieren, oder? 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) > @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. 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 >> 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 ... Kalman-Filter wollte ich erstmal weglassen... Kurz etwas zur Hardware: Als Mikrocontroller verwende ich einen ATmega1284 (128k Flash, 16k RAM, 20Mhz). Gyro ist der ITG-3200 und als Beschleunigungssensor benutze ich einen BMA180. 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?) Achso, ich will auch alles von Grund auf selbst bauen und programmieren... Als nächsten kommen die Brushless-Regler dran ;) > 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 beiden Projekte kenne ich und finde sie sehr interessant... Dort hab ich schon oft mal nachgeschaut wie die etwas gelöst haben ;) > 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. Genau ;) Das ganze soll von selbst seine Lage halten können Lehrmann Michael 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. Das klingt wirklich interessant... Wäre nett wenn ich das auch haben dürfte (wenn du es wieder findest) >> 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. Ehrlich gesagt will ich mich schon mit der Mathematik beschäftigen... Nur fertige Libs verwenden kann (so gut wie) jeder, mir interessiert das Bauen des Quadrocopters mehr als diesen zu fliegen... Vielen Dank für eure Antworten ;)
> 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 ....
Hallo ;) >> 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? Ja so ca. Der Quellcode ist (zumindest meiner Meinung nach) aber totales Chaos und unleserlich... Da suche ich im Moment noch eine gute Erklärung, aber so schwierig ist das ja nicht... Eigentlich ja nur im richtigem Moment die Phasen umpolen. Ich glaube ich werde bei den MOSFET Endstufen die meisten Schwierigkeiten haben... > Alles FP und die trigonometrischen Funktionen aus LUTs. Benutzt du eine atan() LUT? Weil ich bin gerade am überlegen wie ich das am besten löse... Klar kann ich jeden atan() Wert von 0 bis 180° in 0.1° Schritten in eine Tabelle schreiben, aber dann muss ich ja noch schauen wie ich den Wert finde, der dem in der Tabelle am nähsten ist. Und dann habe ich ja immernoch eine Division (Gegenkathete/Ankathete)...
Ah, vielen Dank :) Das bringt mich um einiges weiter... Ich wusste nicht genau wie man sowas am besten programmiert. Dann mach ich mich morgen mal drüber eine Funktion zu programmieren, die für meine Anwendung passt (wie gesagt, 0.1° Auflösung, Rückgabewert im Gradmaß)
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.
Hallo, danke an den Tipp bezüglich der Auflösung... Daran habe ich natürlich nicht gedacht... Ist aber ja logisch... vielen Dank :) Ich löse nun 1° in 1/32 auf, also eine Auflösung von 0.03125° ;) So habe ich eine Ausreichende Genauigkeit und alles passt in eine int16_t Variable.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.