Probeflug mit MultiWii Pro 2.0 - Das hätte ins Auge gehen können

Miss-Lynn

Erfahrener Benutzer
#1
Hallo zusammen

Hier zur Diskussion mein kurzer Bericht über den Probeflug gestern mit meiner neuen Multiwii Pro 2.0 mit GPS und angeschlossenem Bluetooth Modul.

Sender an, Den Kopter an den Akku angeschlossen und hochgebootet. Alle Werte sind standart wie im sketch mitgeliefert.
Die Handy App gestartet und Verbindung hergestellt.
Kopter gearmt, Meldung in der App kommt. Soweit also alles klar.

Abheben, schweben und rumfliegen bei mir im Garten und draussen auf dem Feld sowohl im Akro als auch im ACC Mode ist prima. Funktioniert alles super. Jetzt das GPS testen.
Also ein Herz gefasst, etwas höher gestiegen, (ca. 13 meter laut App) Acc Mode ein und umgeschaltet auf POS Hold.

Der Kopter zuckt kurz, bleibt aber zunächst stabil. Dann "eiert" er etwas um die Position herum. Auch die Höhe schwankt etwas. Wahrscheinlich das hier schon oft beschriebene Verhalten bevor die Werte optimiert wurden. Alles noch akzeptabel.

Nach etwa 3o Sekunden kippt der Kopter plötzlich nach vorne links ab in Windrichtung und rauscht mit einem Affenzahn davon. Eigentlich hätte er gegenhalten müssen.
Hab sofort POSHOLD rausgenommen und versucht den Kopter wieder einzufangen. ACC hab ich dringelassen. Es gelingt mir einigermassen das Teil wieder einzufangen. Inzwischen ist der Kopter schon so weit weg daß ich kaum noch die Lage erkennen kann. Außerdem ist er kaum zu kontrollieren. Trotz ACC Mode wildes hin und her Geschwanke, sogar 2 Überschläge hat er gemacht. Habe den Eindruck, er macht was er will. Lässt sich kaum steuern. Ich will ihn langsam runterholen nehme Gas raus, kaum reaktion. Gehe auf Leerlauf, jetzt fällt der Kopter runter (ist ja klar, keine Regelung mehr), kommt dabei ausser Sicht hinter ein paar Bäumen. Ich lass ihn runterfallen und disarme sicherheitshalber.

Finde meinen Kopter dann, Akku kann ich wegschmeissen(Folie hat ein Loch), BT Modul ist abgerissen liegt in der Umgebung.
Arme sind leicht verbogen, aber reparabel. Zum Glück ist er durch einen Baum gefallen und nirgends voll eingeschlagen.

Was könnte eurer Meinung nach diese Fehlfunktion verursacht haben?

Gruss erstmal Stefan
 
Zuletzt bearbeitet:

Miss-Lynn

Erfahrener Benutzer
#2
Hat denn keiner ne Ahnung was das gewesen sein könnte? Nicht mal ansatzweise?
So aussergewöhnlich das ganze? Noch nie vorgekommen?

Kann ich fast nicht glauben...................
 

Q-Man

Erfahrener Benutzer
#3
Also bei POS Hold habe ich so ein Ausreissen noch nicht gesehen.
Vielleicht ein zu großer D-Wert. Hier würde ich vielleicht ganz ohne arbeiten. Auch ohne I Anteil, wirklich nur P.

Beim GPS Home schon.
Mei Copter ist im Wind weggedriftet gut und gerne 400m, gefählich nahe an eine Hauptstrasse. In ca. 60m Höhe habe ich das GPS-HOME aktiviert. Der Copter hat sich in 90Grad schräglage gelegt und ist auf mich zu gekommen. Nach 2 Sek. musste ich abschalten, weil er schon heftig Höhe verloren hat. Er hat sich dann wieder gefangen und ich habe ihn landne können.
 

sandrodadon

Fliegender Maschi
#4
Hi Miss-Lynn !

Ich hatte mal ähnliche Probleme, MultiWii hat mir beim RTH 2x richtig den Copter zersägt als er einfach einen 180° Flip machte und in den Boden rauschte.

Hier im Forum konnte mir keiner helfen und ich bekam oft zu hören "das hatte ich nie" aber als ich den dritten RTH-Flip so gerade noch durch zurückwechseln zu Acro retten konnte, habe ich es dann für immer gelassen.

Einem bekannten von mir ist trotz RTH der Copter abgehauen, immer weiter Richtung Osten bis der Akku leer war und der Copter aus 30m wie ein Stein fiel.

So ernüchternd das jetzt klingt: Ich werde bei MultiWii nie wieder auf GPS vertrauen.
 

Miss-Lynn

Erfahrener Benutzer
#5
Hallo zusammen

Naja, dann bin ich wenigstens nicht allein damit. Ich würde jetzt aber trotzdem ungern auf die Möglichkeit von RTH und PosHold verzichten. Deshalb hab ich mir ja das Board mit dem GPS Aufsatz geholt. Wozu ist das sonst gut? Es gibt ja nun jede Menge Videos auf denen das ganze ausgezeichnet funktioniert. Die Jungs müssen das ja auch irgendwie hingekriegt haben. Ich versteh das ganze auch in zeitlichem zusammenhang nicht. Das ist ja erst nach ca. 30 sekunden passiert. Wären es total falsche Werte zb. hätte es gleich passieren müssen. Hätte ich evt. anders vorgehen müssen? Vielleicht erst nur den Baro ausprobieren, optimieren und dann den Mag, dann mal beides zusammen probieren usw. Und zum schluss dann alle sensoren zusammen beim PosHold? Gibt es da eine bewährte einzuhaltende Reihenfolge? Wie habt ihr das denn gemacht?
Sandro wie hat es denn deinen Kopter zersägt? Was ist da denn passiert?

Gruss erstmal Stefan
 
Zuletzt bearbeitet:

weisseruebe

Erfahrener Benutzer
#6
Ich habe solche Probleme auch noch nicht gehabt.
Was mich sehr wundert ist der "Affenzahn". Denn eigentlich ist die maximale Geschwindigkeit für Navigation ja eher gering.
Ich bin eigentlich immer recht mutig beim Gedrehe am PID und hatte auch mit sehr großen P/I/D-Werten für die Navigation noch keine solchen Probleme. Ausserdem hat sich der Copter sofort nach dem Abschalten von RTH immer normal verhalten. Ich habe PH und RTH auf einem 3-Positions-Schalter, so dass man immer über PH nach RTH schaltet.
 

Miss-Lynn

Erfahrener Benutzer
#7
Was ich vielleicht noch erwähnen sollte ist daß ich das BT Modul in Betrieb hatte. Das hing einfach so am Kabel nach unten und funkte zum Handy. Vielleicht hat da was gestört?
Der Kopter ging nach dem abkippen gleich auf fast Vollgas (sah jedenfalls so aus) und ist dadurch mit ca 40-45 Grad Schräglage davongeflogen. Ich habe ACC , PosHold mit Baro und Mag, und RTH mit Baro und Mag jeweils auf einem separaten schalter.
Sollte ich die vielleicht alle trennen? Also RTH und PH jeweils ohne Baro und Mag?
 

Miss-Lynn

Erfahrener Benutzer
#8
Mir fällt da gerade was ein!

Um ein Positionfix zu speichern muss doch der Kopter zwischengelandet und disarmed werden. Erst beim zweiten armen wird die Position als Homeposition gespeichert. Richtig? und erst dann kann auch PH funktionieren, oder lieg ich da falsch?

Das zwischenlanden und rearmen hab ich nicht gemacht! Ist das vielleicht der Grund? Hatte der Kopter am ende gar keine Homeposition gespeichert? Au backe!
 

Roberto

Erfahrener Benutzer
#9
Zumindest PH geht auch ohne Homeposition.
Für gute Sensordaten sorgen (Mag und GPS entstören). Mwii Filter besser zunächst aus schalten.
 

Q-Man

Erfahrener Benutzer
#11
Eigentlich wird beim ARMen die aktuelle Position als Home gespeichert.
Wenn ich den Copter an die Startposition stelle und einschalte, warte ich immer bis er GPS gefunden hat (durchgehend 3xgrün blinken an I2C/Seriell Modul). Dann erst ARMe ich.
Wie habt ihr das gemacht?

Das der Copter beim RTH so stark reagiert, verstehe ich auch nicht, denn eigentlich sind die Aktionen ja stark gedrosselt in den Parametern: Erlaubte Schräglage, maximale Geschwindigkeit.
Die Nutzung des Z-ACCs für eine automatische Höhenkontrolle wäre nett...


Was für GPS Module habt ihr denn? Vielleicht liegt es ja daran.
* Crius CN-06 GPS Receiver Module U-blox NEO-6M GPS module, seriell, 9600BAUD
* Crius I2C-GPS NAV Module Navigation Board, Anschluß zwischen GPS Modul und FC (Flight Controller: MultiWII SE)

Ich habe auch die 5fach Filterung aktiviert.

Der Einfluß den GPS auf das Flugverhalten hat ist zu groß. Interessant wäre mal die PID Werte auf 0 zu setzen. Dann dürfte eigentlich nichts mehr passieren...
Und dann den P Wert statt 1.xx mal 0.1x und 0.01 testen.

Ich habe auch gehört, das es mit RTH ab 64m Probleme gibt und ab 654m einen overflow...

Das Problem wird wohl am I2C-NAV-Modul liegen.
Dort werden auch Werte für PID Hinterlegt. Schaut mal in die config.h

Es gibt auch eine "neuere" Version I2C_GPS_NAV_v2.2Beta1-r62.rar . Zwar Beta, aber mann kann es ja mal Testen.
 
Zuletzt bearbeitet:

Q-Man

Erfahrener Benutzer
#12
Um die ganzen Daten die der I2C_GPS_NAV so sendet einordnen zu können, habe ich mal die Koeffizienten aus der MultiWii2.1/def.h zu Rate gezogen. Die Bescheibung stammt aus der r33 Docu.

[table="width: 70%, align: left"]
[tr]
[td]Variable[/td]
[td]Berechnung[/td]
[/tr]

[tr]
[td]I2C_GPS_HOLD_P[/td]
[td]poshold_P*100[/td]
[/tr][tr][td]
Parameter: POSHOL_P is by default .4 or 30 cm/s for a 1m error. The desired rate maxes out at 150cm/s. This doesn't limit the pitch of the copter, The rate controller will do what it takes to maintain this speed as it approaches the location.
[/td][/tr]

[tr]
[td]I2C_GPS_HOLD_I[/td]
[td]poshold_I*100[/td]
[/tr][tr][td]
Parameter: POSHOLD_I is used to overcome wind that may be pushing us away from our target. The higher the number the faster the copter will compensate. If your number is too high it will cause oscillations and overshoot.
[/td][/tr]
[tr]
[td]I2C_GPS_HOLD_IMAX[/td]
[td] poshold_IMAX*1[/td]
[/tr]

[tr]
[td]I2C_GPS_HOLD_RATE_P[/td]
[td]poshold_rate_P*10[/td]
[/tr][tr][td]
Parameter: POSHOLD_RATE_P are the proportional response. Your copter’s optimal setting will depend on the weight and thrust of your engines. If your copter overshoots the target, lower this value.
[/td][/tr]

[tr]
[td]I2C_GPS_HOLD_RATE_I[/td]
[td] poshold_rate_I*100[/td]
[/tr][tr][td]
Parameter: POSHOLD_RATE_I is set to 0 by default. Use this value to maintain tight control of the speed of the copter. If the copter is not achieving the speed it needs, this term will make up the difference by tilting the copter more or less.
[/td][/tr]

[tr]
[td]I2C_GPS_HOLD_RATE_D[/td]
[td] poshold_rate_D*1000[/td]
[/tr][tr][td]
Parameter: POSHOLD_RATE_D is the dampening part. If the value is too high you will see small oscillations in pitch or roll. Once the POSHOLD_RATE_P value is dialed in, start at 0, and increment slowly. You should see oscillations die down.
[/td][/tr]

[tr]
[td]I2C_GPS_HOLD_RATE_IMAX[/td]
[td] poshold_rate_IMAX*1[/td]
[/tr][tr][td]

The navigation (RTH) has only one PID control, the desired speed is directly calculated from the distance to the target and the defined speed constrains. The NAV_P, NAV_I and NAV_D parameters have the same functions as the POSHOLD_RATE. <BR>
Also hier können Probleme entstehen, wenn die Entfernung größer wird!
Vor allem bei D*1000.


[/td][/tr]

[tr]
[td]I2C_GPS_NAV_P[/td]
[td] nav_P*10[/td]
[/tr]

[tr]
[td]I2C_GPS_NAV_I[/td]
[td] nav_I*100[/td]
[/tr]

[tr]
[td]I2C_GPS_NAV_D[/td]
[td] nav_D*1000[/td]
[/tr]

[tr]
[td]I2C_GPS_NAV_IMAX[/td]
[td] nav_IMAX*1[/td]
[/tr]


[/table]
 

Q-Man

Erfahrener Benutzer
#13
PosHold

So jetzt was, wie Poshold eingestellt wird: (aus R33)

Once a solid GPS lock is achieved, home position is set when copter is armed. So plug your battery, wait for GPS lock and fly to your home position (I recommend at least 5/10 meters away from you) land, disarm and arm again. This sets the home position. Copter must be well trimmed and in level mode.
Copter unter Strom setzen, Warten bis GPS OK ist.
5-10m weit weg fliegen und landen.
DISARM, ARM: Home Position wird gespeichert.


Now takeoff, and try PosHold. It works best if there is minimal horizontal speed when activating. If copter is moving when you activating PosHold, you will experience a couple of swings before it settles. You can try increasing poshold_rate D only by 0.001-0.002 at a time. If hold is not good enough you can increase P terms, also by 0.01-0.02 at a time. If copter swings or circles then decrease it, or increase D.
Starten und PosHold aktivieren, wenn der Copter ganz ruhig steht.
D um 0.001 und I um 0.01 ändern, nicht mehr!

Fly away some distance from your home location, and first activate poshold, let the copter settle for a couple of seconds, and then activate RTH. With the default tail control settings your copter should turn towards the home point and start approaching. Once it's arrived it will switch to a poshold and rotate it's head to the same direction as it was when armed. Please note, tail control works only when magHold is enabled.
Wenn PosHold funktioniert, etwas wegfliegen und PosHold aktivieren. Warten bis der Copter sich eingependelt hat.
RTH aktivieren.
Wenn er zurück ist aktiviert sich automatisch PosHold.


Mit all den Informationen Versuche ich mal was ich da so konfiguriert habe.
Es geht um Pos und PosR:

c005.gif


Pos_P. (1.230) * 0100 =123
Pos_I. (0.100) * 0100 = 10
PosR_P (4.000) * 0010 = 40
PosR_I (0.080) * 0100 = 8
PosR_D (0.046) * 1000 = 46
NavR_P (2.700) * 0010 = 27
NacR_I (0.080) * 0100 = 8
NavR_D (0.049) * 1000 = 49

Mal Sehen ob ich sie hier testen kann:
http://www.jasonshort.com/
 
Zuletzt bearbeitet:

Miss-Lynn

Erfahrener Benutzer
#14
Hi Q-man (kenne deinen Namen nicht)

Das sind ja jede Menge Infos. Werde mir die alle zu gemüte ziehen. Als GPS habe ich das hier:
http://s4e3c56b671b69.img.gostorego...d6e5fb8d27136e95/6/-/6-13-2013_9-40-35_pm.jpg
Ein U-blox neo 6-m, vorkonfiguriert wie auf der webseite beschrieben. Werde morgen mal einen screenshot von meinen einstellungen in der GUI machen und hier posten. Wäre doch gelacht wenn man das nicht hinkriegen würde.
Ich werde mich jedenfalls nicht von so einem Fehlschlag abschrecken lassen.

Gruss erstmal und danke für die Mühe bisher Stefan
 
Zuletzt bearbeitet:

Q-Man

Erfahrener Benutzer
#15
Hallo Stefan,

Schließt du das GPS direkt an den FC oder verwendest du das I2C-GPS NAV Module?
Schau dir mal meinen Baubericht an. Auch wenn ich alles wieder in seine Einzelteile zerlegt habe um einen besseren Frame zu bauen...

Grüße Jörg
 
#16
ich hatte gerade letzte woche etwas ähnliches... allerdings ohne gps oder mag ... aber mit bluetooth... bei mir hat der copter angefangen verrückt zu spielen, genau als die bluetooth verbindung abgerissen ist... ich denke der Arduino "verschluckt" sich in dem Moment irgendwie...
 

Miss-Lynn

Erfahrener Benutzer
#18
Hallo Stefan,

Schließt du das GPS direkt an den FC oder verwendest du das I2C-GPS NAV Module?

Grüße Jörg
Hi Jörg
Nein das GPS ist direkt an serial 2 angeschlossen. Versuche mal ein paar fotos hochzuladen.

Hier noch ein screenshot der MW-confi
 

Anhänge

Zuletzt bearbeitet:

Q-Man

Erfahrener Benutzer
#20
Hallo Stefan,

dein NavR-I Wert ist relativ groß. Ich wage jetzt mal eine Theorie.
Der FC berechnet zuerst die Stabilität (Gyro+ACC+MAG) und dann rechnet er die Abweichung (was er so von der Funke bekommt + GPS). Bei aktivierung von GPS-Home sind die Stabi-Werte erst einmal viel größer, das I summiert sich aber mit der Zeit auf, bis es durchschlägt und den Kopter heftig aus der Bahn wirft.
Das könnte man mal mit NavR (P=3.3, I=0, D=0) mal testen.

Ich habe auch schon ein paar rätselhafte Aktionen gesehen, die ich auf einen Reset zurückführen konnte. Grund waren I2C Fehler, plötzliche zu lange Schleifenzeiten (Cycle Time)... Das waren aber nur die Auswirkungen von Spannungsschwankungen. Obwohl mein ESC 2A BEK kann habe ich manchmal zuwenig Spannung!
Bei meinem neuen Modell werde ich einen externen 3A Regler nehmen und ihm einen ordentlichen Eklo verpassen.
 
FPV1

Banggood

Oben Unten