APM 2.5, ArduCopter 3.0.1 - plötzlicher Steigflug im Alt Hold

[PeBo]

Hi,

nachdem zu Beginn mit der APM, meiner ersten FC, alles recht einfach und Out-of-the-Box funktioniert hat bin ich gestern und heute je einmal kräftig erschrocken.

Aktuell mache ich mit dem Copter zwei Dinge. Zum einen plane und fliege - besser beaufsichtige - ich GPS-Missionen. Das hat damit zu tun, dass ich dafür ganz konkrete Anwendungen habe und mich mit der Funktionsweise vertrautmachen will.

Zum anderen fliege ich gern einfach so durch die Gegend, derzeit noch mit Stabilize und für weitere Rundflüge mit Alt Hold. Nun kam es heute zum zweiten Mal vor, dass der Copter nach mehreren Minuten schnelleren Rundflugs bei konstanter Höhe plötzlich schnell zu steigen beginnt.

Beim ersten Auftreten gestern habe ich zuerst noch in Alt Hold den Gas-Stick auf Null gezogen, der Copter stieg weiter, dann habe ich den Modus auf Stabilize gewechselt was natürlich bei der Stickposition die Motoren gestoppt hat. Ich hab es schnell genug registriert, wieder Gas gegeben und die Stabilisierung hat den Copter in sicherer Höhe wieder abgefangen. Er ließ sich problemlos zurücksteuern und landen. Beim zweiten Akku ist das Problem gestern nicht wieder aufgetreten, ich bin aber danach auch gemütlicher geflogen.

Heute dann das gleiche Spiel wieder. Copter flog - für meine Verhältnisse recht sportlich - im Rundflug, plötzlich begann er wieder zu steigen, im Alt Hold keine Reaktion auf die Gasposition, im Stabilize war er normal steuerbar. Nachdem ich ihn wieder eingefangen hatte schaltete ich nochmals in Alt Hold und sofort stieg er wieder mit hörbar voller Leistung. Nach Landung, Disarm, Arm und neuem Start funktionierte wieder alles.

Ich hänge hier einmal das tlog an in der Hoffnung, dass jemand von Euch weiß, wie man da den Fehler sichtbar machen und eingrenzen kann. Welche Parameter kann man plotten um das zu diagnostizieren?


Danke für Eure Hilfe!

Gruß, Peter

 

[PeBo]

Ich habe gerade das Log nochmal abgespielt. Bei ca. 21:09 - 21:10 zeigt der Höhenmesser plötzlich Höhen von bis zu -80m an. Im Diagramm sieht man einen Spike in der Kurve von NAV CONTR alt_error. Kein Wunder, dass daraufhin ein steiler Steigflug erfolgt.

Die Frage ist nun: Woher kommt die Fehlinformation? Der Barosensor ist mit offenporigem Schaumstoff abgedeckt und Alt Hold funktioniert sonst eigentlich sehr gut. Nun Frage ich mich, ob im schnellen Vorwärtsflug eventuell eine ungünstige Luftströumng in der Kuppel entsteht, die zu solchen Druckabweichungen führt. Die Kuppel hat auf der Oberseite einen Ausschnitt für die GPS-Antenne und ein kleines Loch für die RC-Antenne. Nach unten hin ist sie jedoch weder besonders eng anliegend noch abgedichtet. Ein Druckausgleich nach Außen müsste eigentlich jederzeit möglich sein.

Es würde mich auch interessieren, wie die die Beschleunigungssensoren damit zusammen hängen. Die Höhe im HUD ist eine Kombination aus barometrischen Werten zusammen mit Beschleunigungswerten in Z. Diese sind aber nicht auffällig. Erst als der Copter den "Tiefflug" beenden will ist auf Z ein deutlicher Ausschlag zu sehen.

 

[0n3 70uch]

Hallo,

das mit der Höhe ist ein bekannter Bug der Version 3.0.1.

"Warning #4: loiter turns does not maintain altitude. This bug will be fixed in AC-3.0.2."

http://diydrones.com/m/discussion?id=705844:Topic:1324701

Gruß
Fabi

 

[PeBo]

Loiter Turns ist nicht mein Problem sondern nur Alt Hold. Die Warnung wäre wohl nicht auf Loiter Turns begrenzt wenn es ein genereller Bug wäre der Alt Hold direkt betrifft.

 

[0n3 70uch]

Loiter Turns ist nicht mein Problem sondern nur Alt Hold. Die Warnung wäre wohl nicht auf Loiter Turns begrenzt wenn es ein genereller Bug wäre der Alt Hold direkt betrifft.

Es reichen schon minimale Yaw Steuerbewegungen im Loiter. Mir ist auch aufgefallen das eine Richtung empfindlicher ist als die andere...

 

[milz]

moin
der bug bezieht sich das nur auf loiter turns im auto modi oder hab ich was verpasst ?

mfg milz

 

[PeBo]

Es ist aber so, dass ich das Problem eben nicht im Loiter Mode habe. Der funktioniert bei mir ganz ausgezeichnet. Der Copter schwebt auf der Stelle, YAW-Eingaben im Loiter Mode haben bei mir auch nahezu keine Auswirkungen auf die Flughöhe.


Ich denke eher, dass meine Vermutung aus Post #2 zutrifft denn ich habe folgendes in den Diagrammen gefunden:



Der NAV CONTROL alt_error tritt genau während einer horizontalen Beschleunigung auf und beendet die Vorwärtsbewegung abrupt, vermutlich weil die volle Motorleistung nun für den Steigflug zur Korrektur des - nicht vorhandnen - Höhenfehlers aufgewendet wird.

Eventuell gibt es einen ungünstigen Winkel der Anströmung wodurch sich unter der Kuppel ein Druck aufbauen kann. Anders kann ich mir nicht erklären wieso die FC plötzlich eine Messung von -80m ermittelt. Im Schwebeflug hat sich die angezeigte Höhe recht langsam wieder ausgeglichen. Der zweite Spike bei alt_error entstand weil ich noch einmal zum Test Alt Hold aktiviert hatte während der Copter im Sinkflug war.

 

[PeBo]

Eine neue Frage in dem Zusammenhang: Welchen Einfluss hat die GPS-Höhe auf das HUD und die Navigation im Alt Hold?

Grund für die Frage ist die Auswertung der DataFlash Log. Dort scheint es, als sei die GPS-Höhe plötzlich gefallen und die Barometrische hat den plötzlichen Steigflug aufgezeichnet.

Ich hatte bisher angenommen, dass der barometrische Sensor die Höhe bestimmt sofern kein Sonar installiert ist.

Was ist denn nun richtig?


Anbei ein weiterer Graph.



Die helle horizontale Linie zeigt die Zahl der Satelliten und zu Beginn der "Störung" war diese kurz von 9 auf 8 gesunken und gleich danach wieder auf 9 gestiegen. Die GPS-Höhe fiel dabei von den korrekten 15m auf -81m und stieg dann auf 130m an während der Copter barometrisch gemessen nich höher als 80m war.

Kann ein einzelner verloren Satellit eine derart große Abweichung in der Höhe erzeugen?

Und kann man die Gewichtung der GPS-Höhe verändern, z.B. mit PIDs?

 

[PeBo]

Schade, meine letzte Theorie ist gerade geplatzt.

Rel Alt ist zwar im GPS Datensatz enthalten, die Daten sind aber dennoch barometrisch. So zumindest steht's bei copter.ardupilot.com geschrieben.

GPS:

• Status – 0 = no GPS, 1 = GPS but no fix, 2 = GPS with 2D fix, 3 = GPS with 3D fix
• Time: the GPS reported time since epoch in milliseconds
• NSats: the number of satellites current being used
• HDop: a measure of gps precision (1.5 is good, >2.0 is not so good)
• Lat: Lattitude according to the GPS
• Lng: Longitude according to the GPS
• RelAlt: Accelerometer + Baro altitude in meters
• Alt: GPS reported altitude (not used by the flight controller)
• SPD: horizontal ground speed in m/s
• GCrs: ground course in degrees (0 = north)

Also doch ein Problem mit Druck unter der Haube?

 

[Roberto]

Die GPS Höhe kann man vergessen.
Wenn Du wissen willst, ob Dein Problem vom ACC oder Baro kommt, kannst Du diese Zeitkonstante mal kleiner machen. D.h es wird mehr dem Baro vertraut. Wenn er dann immer noch abgeht, ist es der Baro, wenn es "besser" wird, ist Deine Acc Komponente schuldig. "Besser" und "schlechter" beziehen sich natürlich nur auf Deine extremen Höhenänderungen.

 

[PeBo]

Danke für den Tipp Roberto, das werde ich versuchen und dazu das Log auf Default+IMU erweitern. Dadurch sollte man ja auch erkennen können, ob die Z-Achse des ACC spinnt.

Kann so ein Beschleunigungssensor hängenbleiben und dadurch einen permanenten Sinkflug "erkennen" welcher garnicht stattfindet?

 

[Roberto]

Tatsächlich kann ein Acc "hängen bleiben" dann hat er allerdings durch einen harten Crash eine interne Zerstörung seiner "MECHANIK" erlitten. Ob dann noch eine ACC Kalibration fehlerfrei durchläuft, ist zu bezweifeln. Wenn Dein künstlicher Horizont in der Gui richtig angezeigt wird, ist aber sehr, sehr, sehr wahrscheinlich Dein ACC in Ordnung. Weil der Horizont den Erdgravitationsvektor benötigt, und der kann nur vom ACC geliefert werden. Der Umkehrschluss: Horizont funktioniert, dann muss auch das acc/baro Althold gehen, klappt nicht, weil die ACC Werte für den Horizont stark gefiltert sind und sein können, weil die Gyros nur eine langsame Korrektur ihres Fehlers benötigen. Für das Althold darf das acc nicht stark gefiltert werden, weil es dort die "schnelle" Komponente gegebenüber dem Baro ist. Deswegen knallen da die "bad vibrations" schneller rein. Erweitertes Logging ist natürlich die Beste Idee. Die Sache mit der Zeitkonstanten ist nur ein quick & dirty Globaltest, damit man sieht wohin der Hase hoppelt...
Zu 99% wirst Du ein Acc Vibrationsproblem haben bzw. die davon abhängigen Pids sind zu hoch. Genaueres zu den "erlaubten" Vibrationsleveln findest Du in ihrer neuen Wiki.

LG
Rob