Hallo zusammen, ich arbeite nun schon seit ende Juni an einem ersten Prototypen für einen kleinen Hexacopter. Hier das öffentliche Repository auf GitHub https://github.com/CTHN/CTHNCopter Hier sind alle Datenblätter, die Firmware, der Bootloader sowie die Eagle-Files für die Platine enthalten. Auf der Platinen befindet sich ein Beschleunigungssensor vom Typ ADXL330. Der Sensor wird in meinem Fall mit 3,3V betrieben. Der Sensor liefert neben der momentanen Beschleunigung seine Lage im Raum. Dies geschieht über eine Offset-Spannung von etwa 1,56V, pro Achse. In meinem Fall betrachte ich nur die X/Y-Achsen. Diese werden jeweils über einen 100nF Keramik-Kondensator, gegen Masse, gefiltert (siehe Schaltplan C9/C10/C11). Zudem wird in der Firmware ein Software-Tiefpass auf die Messwerte angewendet, so dass die Lage sehr stabil und sauber ermittelt wird. Die gefilterte Lage werden über ein Bluetooth-Modul an einen Client übermittelt und dort entsprechend visualisiert. Dies funktioniert perfekt. Nun zu meinem Problem mit meiner Schaltung. All dies funktioniert also einwandfrei, solange alle 6 Motoren nicht aktiv sind. Sobald diese (einer oder mehrere) eine bestimmte Drehzahl erreichen gibt der ADXL330 eine andere Lage aus. Die Spannung der X-Achse erhöht sich um maximal 300mV und die Lage der Y-Achse verringert sich um etwa 300mV. Die 300mV entsprechend in etwa einer 90Grad Drehung in Positiver oder negativer Richtung. Ersetze ich die 100nF Kondensatoren durch 1µF Elkos und füge ich jeweils 100nF Kondensatoren an die Motoren zum Entstören dieser ein, reduziert sich das Lage-Problem um etwa ~50%. Der gemessene maximale Strom liegt, bei laufenden Motoren, bei knapp 5,5A. Als Spannnugnsquelle verwende ich einen 450mAh LiPo mit Max. Dauerlast von 15A und Kurzzeitbelasung von 30A. Das Problem tritt auch bei einem 350mAh LiPo mit 12,3A Dauerbelastbarkeit und 24,6A Kurzzeitbelastbarkeit auf. Ich habe weiterhin Zugang zu einem Labornetzteil mit 50V maximal Spannung bei 10A Maximalstrom (leider kann ich hier keine genaueren Werte angeben). Wenn ich hier als Eingangsspannung 8,4V an die Schaltung anlege und die Motoren laufen lasse, tritt der oben beschriebenen Fehler nur minimal auf (ca. 5Grad Abweichung von der Null-Lage). Die Ausgangsspannung des Spannungsreglers liegt konstant bei 3,3V, auch bei Spannungseinbruch des Akku-Spannung. Die Referenzspannung des ADC an AVCC ist ebenfalls stabil bei 3,3V und auch die Spannung am Sensor ist stabil. Leider habe ich aktuell keinen Zugriff auf ein Oszi, so dass ich leider hierzu keine genaueren Werte angeben kann. Ich vermute da einen großen Patzer im Layout was das EMV angeht. Leider bin ich kein Fachmann in Sachen HF-Technik, so dass ich hier für jeden Tipp oder Anregung dankbar wäre. Die das Platinenlayout habe ich bei PCB-Pool herstellen lassen. Da dies eine erste Version der Schaltung ist, sind in dieser 3 Fehler enthalten, welche ich jedoch in der aufgebauten Schaltung korrigiert habe. Es handelt sich dabei nur um einen falschen Widerstand (4kOhm statt 100kOhm) im Spannungsteiler für R8. Zudem sind die Leitungen für M2/3 per Kupferlackdraht an die Pins PC4/5 verlegt worden. Der letzte grobe Patzer ist, das dass größere "Beinchen" des Spannungsreglers nicht, wie erwartet, an Masse angeschlossen wird, sondern die Ausgangsspannung führt, so dass dieses Lötpad freigeschnitten werden musste. Die kommende Version der Platine wird voraussichtlich noch Gyroskope enthalten, da der Beschleunigungssensor vermutlich nicht ausreichen wird um die Lage des Hexacopters wirklich stabil zu halten. Unter https://github.com/CTHN/CTHNCopter/blob/master/doc/calculations.ods habe ich verschiedene Messungen eingetragen. Auf den Seiten "Angle Pitch Relation", "Angle PWM Relation" und "Angle PWM Relation (fine)" sind die Beziehungen der gemessenen Winkel zu den PWM-Signalen und auch des Steuersignales "Pitch" zu sehen. Ich hoffe das ich ausreichend Informationen angegeben habe um wenigstens einen Vorschlag für einen Lösungsansatz zu erhalten. Ich bin auch über jeden konstruktiven Hinweis zu meiner Arbeit dankbar um diese weiter verbessern zu können. Vielen Dank schonmal im Voraus! Kai --- Schaltplan: https://github.com/CTHN/CTHNCopter/blob/master/pcb/CTHNCopter%20-%20v0.1.sch Layout: https://github.com/CTHN/CTHNCopter/blob/master/pcb/CTHNCopter%20-%20v0.1.brd Bilder: https://www.dropbox.com/sh/e7du2u5ruezkqha/y8eKetowZ6 Blog: http://klautesblog.blogspot.de/search/label/CTHNCopter
Das ist ein bekanntes Problem bei den "sehr billigen" Beschleunigungssensoren, die eher für den Consumermarkt sind (Lagesensor im Handy z.B.). Vermutlich triffst du irgendeine interne Resonanzfrequenz im niedrigen Kilohertzbereich innerhalb der Sensoren. Ich hab das Problem dadurch behoben, indem ich mir in den eingängigen Foren "etablierte" Sensoren rausgesucht habe, die bewiesenermaßen keine Probleme mit Vibrationen bei Multikoptern haben. Und nein, der Beschleunigungssensor wird nicht reichen ;-) Sobald du dich mit dem Multikopter bewegst, hast du sowieso andere Beschleunigungen überlagert, die du gar nicht wissen willst und auch nicht (ohne weitere Sensoren) trennen kannst. Was angeblich geht ist ein Multikopter nur mit Gyros. Zumindest um den inherent instabilen Multikopter zu stabiliseren. Die absolute Lage kann man damit natürlich nicht halten.
Mach Schaltplan + Board lieber mal als PDf. Dann kann man die auch ansehen. Vibrationsprobeme kenn ich eher von Gyros. Die gehören auf jeden Fall gedämpft montiert. Nur mit ACC wirds nichts, Gyros brauchst du auf jeden Fall. Nur mit Gyros geht perfekt (ich finds ohne ACC besser). ACC ist zu langsam (Integral der Drehrate) und durch jede translatorische Beschleunigung wird die Lage versaut. Neigung um X und Y (2 Freiheitsgrade) und translatorische Beschleunigung (3 Freiheitsgrade) werden in 3 Werten untrennbar zusammengefasst. Ein waagerecht stehender, seitlich beschleunigter Copter liefert die gleichen Daten wie ein seitlich gekippter nach oben beschleunigter. Ich würd auch eher auf I2C-Sensoren gehen. MPU6050 (Gyro+ACC) liefert bei mir gute Ergebnisse. ADXL330 ist ja auch schon abgekündigt. Stephan
Wenn dein Problem von den Vibrationen herrührt, kannst du deine Platine auch mechanisch dämpfen. Bei openpilot gab es mal jemanden, der dazu einen 2K-Gel verwendet hatte mit sehr guten Ergebnissen. Alternativ soetwas hier: http://www.armokopter.at/forum/viewtopic.php?f=3&t=284
Vielen Dank für die schnellen und vielen Antworten!!! Ich werde mein Glück mit einem MPU6050 versuchen und dann noch den ganzen Aufbau entsprechend gegen Vibrationen dämpfen! Kai
Eigentlich könnt ihr dann auch gleich ein NanoWii-Board nehmen. z.B. hier: http://flyduino.net/NanoWii-ATmega32u4-Based-MultiWii-FC Programmieren könnt ihr den ja immer noch nach Lust und Laune. Die 138g Schub kommen mir übrigens arg grenzwertig vor. Fast die Hälfte schon verbraucht und Steuerung, Empfänger, Rahmen, Kabel und Kleinteile fehlen noch. Normalerweise sagt man Schub > 2*Gewicht. Warum eigentlich Hexa? Bei der größe wären mir etwas größere - damit effizientere - Propeller besonders wichtig. > Quadro. Stephan
Angehängte Dateien:
-
tp_acc.png
31 KB
Hallo Kai, ich hatte Anfangs ebenfalls das Problem mit den Vibrationen und dem Beschleunigungssensor. Die Aussage von "Simon K." dass es nur bei sehr billigen MEMS auftritt kann ich nicht bestätigen. Ich selbst verwende den Freescale MMA8451Q (~1€) und der ist nichts schlechter als der Beschleunigungssensor des MPU6050 den ich ebenfalls hier habe. Ich habe mir den MPU6050 besorgt da ich ebenfalls dachte, dass der "billige" Schuld ist. Dem ist aber nicht so. Beide zeigen das gleiche Verhalten beim Flug. Sicherlich hat jeder MEMS Beschleunigungssensor eine eigene Resonanzfrequenz auf der er besonders empfindlich reagiert, aber das gilt sowohl für die teuren als auch für die billigen. Der Gyro des MPU6050 ist hingegen temperaturstabiler als mein L3GD20 (~4€) aber der temperaturabhängige drift wird eh durch Acc und Mag rausgerechnet. Das einzige was bei mir geholfen hat ist ein "extremer" Software-Tiefpass. Etwa so:
1 | filtered_ax = filtered_ax - (filtered_ax >> 6) + ax; |
2 | ax = (filtered_ax >> 6); |
Wobei ax ist Rohwert aus dem Beschleunigungssensor ist, filtered_ax ist static bzw. global. Die die Schleife wird alle 10ms durchlaufen. Das ganze mache ich für alle 3 Achsen. Wenn man es dann durch den atan2 jagt, und den Sensor um 180° kippt dann dauert es ca. 5s bis der das Maximum erreicht hat. Das hat bei mir viel Stabilität des Quadcopters gebracht. Als Filter verwende ich einen einfachen Komplementärfilter mit 99% Gyro anteil (ungefiltert) und 1% Acc-Anteil (wie oben gefilter). Besserung erhält man natürlich auch durch Entkopplung des IMUs und/oder wuchten der Motoren und/oder Props
Timmo H. schrieb: > Wenn man es dann durch den atan2 > jagt, und den Sensor um 180° kippt dann dauert es ca. 5s bis der das > Maximum erreicht hat. Das ist dann aber schon ne halbe Ewigkeit. Timmo H. schrieb: > Das hat bei mir viel Stabilität des Quadcopters > gebracht. > Als Filter verwende ich einen einfachen Komplementärfilter mit 99% Gyro > anteil (ungefiltert) und 1% Acc-Anteil (wie oben gefilter). Ist ein Unterschied mit/ohne ACC erkennbar? Ich vermute ACC hat kaum Auswirkungen. Die 5s werden bei 10° Drehung ja nicht weniger! Hast du die Software eigentlich komplett selbst entwickelt oder was bestehendes angepasst? Die Frage ist auch ob man ACC ohne höhere Positionssteuerung überhaupt will. Ohne GPS find ichs nur störend. Kaum gegen den Wind ausgerichtet, schon steht er wieder waagerecht und ich muss wieder steuern. Automatisches Abbremsen aus dem Vorwärtsflug leistet die Aerodynamik ja von sich aus wenn Gyro-I nicht zu hoch ist. Timmo H. schrieb: > Besserung erhält man natürlich auch durch Entkopplung des IMUs und/oder > wuchten der Motoren und/oder Props Das sollte nicht Option sondern Voraussetzung sein. Extrem günstig zu haben (Entkopplung), bzw. der Lagerlebensdauer (Wuchten) wegen. Stephan
Stephan schrieb: > Timmo H. schrieb: >> Wenn man es dann durch den atan2 >> jagt, und den Sensor um 180° kippt dann dauert es ca. 5s bis der das >> Maximum erreicht hat. > > Das ist dann aber schon ne halbe Ewigkeit. Richtig, ist aber sogar die Standardeinstellung bei MultiWii (ist glaub ich aus der 1.8er)
1 | #define ACC_LPF_FACTOR 100
|
2 | accLPF[axis] = accLPF[axis] * (1.0f - (1.0f/ACC_LPF_FACTOR)) + accADC[axis] * (1.0f/ACC_LPF_FACTOR); |
3 | accSmooth[axis] = accLPF[axis]; |
Inzwischen haben sie es glaub ich auch auf Shift umgebaut wie ich. Der Acc-Wert den man in MultiWii Config sieht ist ja nicht der, den die Routine zur berechnung der Lage sieht. Ich habe halt die ganze Firmware von Grund auf neu gemacht, darum war und ist auch etwas mehr Forschung nötig. > Timmo H. schrieb: >> Das hat bei mir viel Stabilität des Quadcopters >> gebracht. >> Als Filter verwende ich einen einfachen Komplementärfilter mit 99% Gyro >> anteil (ungefiltert) und 1% Acc-Anteil (wie oben gefilter). > > Ist ein Unterschied mit/ohne ACC erkennbar? Definitiv. Der Gyro driftet halt um ca ein Zentel Grad pro Sekunde, da haut der Quadcopter schnell ab, und im Flug verhält es sich mit Gyro auch noch etwas anders. > Die 5s werden bei 10° Drehung ja nicht weniger! > Hast du die Software eigentlich komplett selbst entwickelt oder was > bestehendes angepasst? Nein aber das die "falschen" Winkel verursacht durch die Vibrationen werden weggebügelt. Letzten Endes ist der Beschleunigungssensor nur dafür da um den Drift auf längere Sicht auszugleichen. > Timmo H. schrieb: >> Besserung erhält man natürlich auch durch Entkopplung des IMUs und/oder >> wuchten der Motoren und/oder Props > > Das sollte nicht Option sondern Voraussetzung sein. Extrem günstig zu > haben (Entkopplung), bzw. der Lagerlebensdauer (Wuchten) wegen. Richtig, aber manchmal hat man eben nicht die besten Motoren und/oder Probs. Habe mir jetzt auch gerade neue bestellt, mal gucken wie sich das da verhält. Dann kann man den Acc TP auch wieder etwas tunen, wobei es vermutlich gar nicht nötig ist, wie gesagt klappt ja so sehr gut und mehr als die niedrigen Frequenzen vom Beschleunigungssensor brauche ich nicht. Das interne Oversampling des Accs soweit hoch zudrehen ist auch nicht so gut, da dann aus dem Acc sehr abgehackt/stufig die Werte rauskommen. Also lieber per Software, dann ist es auch "glatt".
Früher (tm) flog man einen Helikopter noch selbst. Natürlich brauchte es jahrelange Übung, um so ein Teil einigermaßen zu beherrschen. Aber heute will man ja alles gleich und sofort, also muss ein Computer drauf, der das Teil fliegt. Da habe ich mehr Respekt vor einem Anfänger, der seinen Koax-Heli halbwegs stabil in der Luft hält als vor so einen Quad- oder Hexacopter-"Piloten", dessen Fluggerät mehr Rechenleistung hat als die Mondlandefähren und der es trotzdem nicht hinbekommt.
Jens schrieb: > Früher (tm) flog man einen Helikopter noch selbst. Natürlich brauchte es > jahrelange Übung, um so ein Teil einigermaßen zu beherrschen. Aber heute > will man ja alles gleich und sofort, also muss ein Computer drauf, der > das Teil fliegt. Unsinn. Ein Quadrokopter ist im Gegensatz zum Helikopter inherent instabil. Den kann man ohne extra Lageregelung nicht fliegen.
Timmo H. schrieb: > Sicherlich hat jeder MEMS Beschleunigungssensor eine eigene > Resonanzfrequenz auf der er besonders empfindlich reagiert, aber das > gilt sowohl für die teuren als auch für die billigen. Klar, deswegen auch mein Tipp, dass man auf einen etablierten (in anderen Quadrokopter Projekten) Beschleunigungssensor zurückgreift. > Das einzige was bei mir geholfen hat ist ein "extremer" > Software-Tiefpass. Etwa so:filtered_ax = filtered_ax - (filtered_ax >> 6) + ax; > ax = (filtered_ax >> 6); Ok, also an dieser Stelle können wir gar nicht mehr von den gleichen Dingen reden. Wenn der Beschleunigungssensor schon "Geisterwerte" ausgibt, weil er in seiner Funktion gestört ist, wie kannst du da durch Filterung doch noch auf einen "richtigen" Wert kommen?
Simon K. schrieb: > Timmo H. schrieb: >> Sicherlich hat jeder MEMS Beschleunigungssensor eine eigene >> Resonanzfrequenz auf der er besonders empfindlich reagiert, aber das >> gilt sowohl für die teuren als auch für die billigen. > Klar, deswegen auch mein Tipp, dass man auf einen etablierten (in > anderen Quadrokopter Projekten) Beschleunigungssensor zurückgreift. Wie gesagt, der 15€ teure MPU6050 ist nicht besser was den Acc angeht als mein billiger 1€ Acc. > Ok, also an dieser Stelle können wir gar nicht mehr von den gleichen > Dingen reden. > Wenn der Beschleunigungssensor schon "Geisterwerte" ausgibt, weil er in > seiner Funktion gestört ist, wie kannst du da durch Filterung doch noch > auf einen "richtigen" Wert kommen? Naja durch die Vibrationen enstehen Beschleunigungsspitzen und zwar nicht auf allen Achsen in gleicher Weise. Wenn man nun die ungefilterten Werte nimmt, und die x-Achse z.B. gerade einen 0.5g Peak hat, währen die z-Achse einen Wert von -0.8g hat, dann ist der errechnet Winkel per atan() halt komplett daneben (für diesen Zeitpunkt). Diese Peaks werden dann direkt an den Algorithmus weitergegeben der die Lage bestimmt. Wenn der Gyro jetzt sich von den Vibrationen nicht sonderlich beeinflussen lässt, dann dann ändert der Integralanteil (des Gyros) auch den Winkel nicht. Auch wenn der Acc durch den Komplememtärfilter nur zu 1-2% in die Winkelberechnung einfließt kann dies für diesen Moment schon einige Grad bedeuten. Dies geht nun als Grundlage weiter an den PID-Regler welcher dann versucht für diesen Moment "gegenzusteuern". Wenn im nächsten Messdurchlauf wieder ein Peak den Winkel "total verdreht" dann kann sich das schon aufschaukeln. Insbesondere dann wenn die "Vibration" irgendwie synchron mit der Ausleserate des Beschleunigungssensors ist. Auf jeden Fall funktioniert es so, und die MultiWii-Leute haben ja auch gemerkt, dass es so geht und so einen TP in den Code eingebaut. Also was soll daran nun so falsch sein?
Timmo H. schrieb: >> Ok, also an dieser Stelle können wir gar nicht mehr von den gleichen >> Dingen reden. >> Wenn der Beschleunigungssensor schon "Geisterwerte" ausgibt, weil er in >> seiner Funktion gestört ist, wie kannst du da durch Filterung doch noch >> auf einen "richtigen" Wert kommen? > Naja durch die Vibrationen enstehen Beschleunigungsspitzen und zwar > nicht auf allen Achsen in gleicher Weise. Wenn man nun die ungefilterten > Werte nimmt, und die x-Achse z.B. gerade einen 0.5g Peak hat, währen die > z-Achse einen Wert von -0.8g hat, dann ist der errechnet Winkel per > atan() halt komplett daneben (für diesen Zeitpunkt). Blöd nur, dass der Threadopener überhaupt kein atan in seinem Post erwähnt. Er sagt: Kai Lauterbach schrieb: > Die Spannung der > X-Achse erhöht sich um maximal 300mV und die Lage der Y-Achse verringert > sich um etwa 300mV. Also die einzelnen Werte der Achsen-Komponenten des Beschleunigungssensors ändern sich (als Offset). Da kann man nix mehr mit einem Tiefpass machen, da dieser Offset eh schon DC Anteil hat. Und deswegen sagte ich: Simon K. schrieb: > Ok, also an dieser Stelle können wir gar nicht mehr von den gleichen > Dingen reden. Du meinst offensichtlich ein anderes Problem als er (und ich). > Auf jeden Fall funktioniert es so, und die MultiWii-Leute haben ja auch > gemerkt, dass es so geht und so einen TP in den Code eingebaut. Also was > soll daran nun so falsch sein? Es geht nicht darum ob es falsch ist oder nicht. Wenn es funktioniert isses ja super. Aber man kann sich ja auch mal nach Alternativen umschauen und nicht immer alles als gegeben (oder "richtig") hinnehmen. Fühlst du dich persönlich angegriffen?
Simon K. schrieb: > Blöd nur, dass der Threadopener überhaupt kein atan in seinem Post > erwähnt. Tut mir leid, aber wenn ich Hexacopter und was vom Beschleunigungssensor im Titel lese, dann denke ich automatisch an Lageregelung und damit auch an atan, was man früher oder später dazu verwendet Simon K. schrieb: > Kai Lauterbach schrieb: >> Die Spannung der >> X-Achse erhöht sich um maximal 300mV und die Lage der Y-Achse verringert >> sich um etwa 300mV. > > Also die einzelnen Werte der Achsen-Komponenten des > Beschleunigungssensors ändern sich (als Offset). > Da kann man nix mehr mit einem Tiefpass machen, da dieser Offset eh > schon DC Anteil hat. Gut vielleicht weißt du ja mehr als ich, aber ich bin mal davon ausgegangen dass er den Offset mit dem ADC vom µC gemessen hat (und vermutlich ein langsameres Zeitinterval) da er ja den Sensor schon auf seinem Hexacopter hat. Und da hängt natürlich auch einiges von der Samplefrequenz etc ab. Ob ich nun einen digitalen Sensor habe und dieser mir alle 30ms einen Beschleunigungspeak ausgibt und mittendrin was richtiges oder den ADC des µC nutze wäre mehr oder weniger dann egal. Wie gesagt, wenn ich keinen TP rein mache sieht es für mich erstmal auch aus wie ein Offset. > Simon K. schrieb: > Fühlst du dich persönlich angegriffen? Nö, warum sollte ich?! Habe mich nur eingebracht, weil ich scheinbar ein ähnliches Problem hatte und wie ich es umgangen habe. Und zudem bin ich auch nur soweit in Detail gegangen, weil du die Behauptung aufgestellt hast, dass die billigen Beschleunigungssensoren alle mist sind und nur die teuren was taugen. Was eben nach meiner Erfahrung so nicht pauschalisieren kann. Wodurch du dich aber scheinbar angegriffen fühltest.
Ach @Kai. Mir ist gerade noch was in den Sinn gekommen: Kai Lauterbach schrieb: > Diese werden jeweils > über einen 100nF Keramik-Kondensator, gegen Masse, gefiltert (siehe > Schaltplan C9/C10/C11). Kerkos zeigen einen Piezo-Effekt bei mechanischen Belastungen, daher bei Schocks etc. können sie eine Spannung erzeugen. Ich weiß jetzt nicht wie stark sich dieser Effekt in der Praxis auswirkt, aber es könnte ja durchaus sein, dass dein Offset durch den Piezo-Effekt der Kerkos, die eigentlich dein Signal filtern sollen, zustande kommt. Nur so eine Idee.
Timmo H. schrieb: >>> Wenn man es dann durch den atan2 >>> jagt, und den Sensor um 180° kippt dann dauert es ca. 5s bis der das >>> Maximum erreicht hat. >> >> Das ist dann aber schon ne halbe Ewigkeit. > Richtig, ist aber sogar die Standardeinstellung bei MultiWii (ist glaub > ich aus der 1.8er) Grad etwas Debug-Code spendiert. Bei mir (MW2.0) ist die Zyklenzeit ca. 2,85ms und ACCLPF ist auf 16 Zyklen eingestellt. Beides Standardeinstellungen und per Debug-Code plausibilisiert. Der geglättete ACC-Wert folgt den Bewegungen nahezu ohne Verzögerung. ACC wird den Gyro-Daten mit 1/310 je Zyklus beigemischt (deine 1% hatte ich falsch verstanden). Ergibt bei mir in etwa ein PT1-Verhalten mit 1s Zeitkonstante (der ACCLPF ist nicht relevant). Bei dir sinds 2xPT1 mit 1s Zeitkonstante (LPF100@10ms und 1%@10ms). In der Praxis recht ähnlich, bei mir etwas direkter. Timmo H. schrieb: > Definitiv. Der Gyro driftet halt um ca ein Zentel Grad pro Sekunde, da > haut der Quadcopter schnell ab, und im Flug verhält es sich mit Gyro > auch noch etwas anders. >> Die 5s werden bei 10° Drehung ja nicht weniger! > Nein aber das die "falschen" Winkel verursacht durch die Vibrationen > werden weggebügelt. Letzten Endes ist der Beschleunigungssensor nur > dafür da um den Drift auf längere Sicht auszugleichen. Mich nervt halt, dass der ACC den Copter waagerecht ausrichtet obwohl er gekippt bleiben sollte (Wind!). Die Drift auszugleichen finde ich persönlich einfacher als laufend erneut gegen den Wind anzusteuern. Die paar Zehntel °/s passen übrigens ganz gut zu meinen Messungen. Ruhig liegend hatte ich mit MPU6050 10° Drift in 90s (Messbereich 2k°/s, Vorteiler 8). Mit Messbereich 1k°/s und ohne Vorteiler warens nur noch 10° in 15 Minuten. Beim Offset wird hier scheinbar einiges verschenkt. Obs im Flug relevant ist werd ich noch rausfinden. Timmo H. schrieb: > Ich habe halt die ganze Firmware von Grund auf neu gemacht, darum war > und ist auch etwas mehr Forschung nötig. Spannend. Ich versuch mich grad an mehreren Fronten (Erfassung des Flugverhaltens, passende Beobachter, verbesserte dynamische Lagedaten, automatisierte PID-Regler-Einstellung). Egal ob/was am Ende rauskommt werd ich nme Menge gelernt hanen. Stephan
Thread beobachten
Seitenaufteilung abschaltenBitte 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.