Funktionieren bei Euch Kompass und Baro vernünftig ?

Die Sache mit dem Schalter habe ich beim MK nicht als störend empfunden. Dort ist/war es so, dass der Gaskanal den maximalen Gaswert für die Regelung vorgibt wenn der Höhenschalter umgelegt war. Hat man das Gas unterhalb des Schwebegases gesetzt ist der Kopter trotz aktiviertem Höhenschalter gesunken. Das einzig kritische war wenn man in der Wohnung mit Höhensensor fliegt und dann den Schalter umlegt kann es passieren, dass der Kopter durch die Decke will. Aber so etwas tut man ja auch nicht.

Der 2. Modus ist dann der Vario Modus. Sprich Gasknüppel in der Mitte -> Kopter hält die Höhe, Knüppel runter -> Kopter runter, Knüppel hoch -> Kopter hoch

Ach ja, dann gabs da noch die Möglichkeit die Höhe per Poti einzustellen. Das war auch witzig

@Sledge: Wenn Du willst, kann ich Dir so eine Schalterversion zusammenbrauen, dann wird Das "Einschaltgas" +-150 genommen.
@zerosight: Der ACC ist ein echtes Problem für mich und aktuell habe ich es nur geschafft einiger maßen sicher festzustellen, ob der Copter bei Zuschalten des Baros/oder neue Höhe nehmen, steigt oder fällt. Diese Information könnte man z.B durch einen "kleinen" Gasstoß nutzen.

Hallo Roberto,

ich komme gerade vom testen. Glückwunsch, bei mir läuft es wesentlich besser als mit der Originalversion. Ich habe zwar im Schwebeflug selbstständige Höhenänderungen im Bereich von ca. 2Mtr. aber besser ist es auf jeden Fall. Ich werde später mit anderen Werten selbst testen.

Gruß Paraglider58

@Paraglider58:
Super, dass es jetzt auch bei Dir besser läuft - jetzt sind wir schon 2!
Leider kann ich keine grundlegenden Verbesserungen programmieren, da mir das Know How der Sensordatenaufbereitung und der PID Kontroller Programmierung fehlen. Wenn Du schon eine neue IMU mit MPU6050 Gyro/ACC hast, hast Du dann vielleicht schon den MS5611 Baro?
Du kannst mal die beiden Debugs3&4 auskommentieren, dann siehst Du schon auf dem Schreibtisch (ohne gearmte Motoren!) wie der Code arbeitet und was Dein Baro für Daten liefert. Also z.B Throttle auf Mitte, Baroschalter umlegen (Debug 3 geht auf 0), dann Debug 4 beobachten und mal den Copter auf und ab bewegen, dann siehst Du schon ab welchen Daten man bei Deinem Baro von einer echten Bewegung ausgehen kann. Wenn Du am Throttle wackelst (Debug 3 > 20) und den Schwellenwert von 60 in Debug 4 überschreitest, wird Debug 3 wieder auf 0 gehen, d.h. Dein Kopter hat jetzt eine neue Referenzhöhe genommen.

LG
Rob

Das ist lieb aber im Moment fliege ich noch Rabbit. Wenn ich einen neuen Kopter aufbaue wird das Rabbit verpflanzt und in meinen Hexa kommt wieder ein Wii. Je nach dem wie der Höhensensor dann funktioniert komme ich aber gerne noch mal darauf zurück.

Hi Roberto,

ja den habe ich.

Ja, hab ich gemacht. Bei Debug 3 sehe ich dann ab und zu ganz kurz eine Zahl "blitzen" so wie ich erkenne ist es eine 2stellige 20er Zahl. Debug 4 bewegt sich im Stand nach dem Schalter umlegen, immer zwischen -60 und +60 manchmal geht es auch etwas höher/niedriger aber selten. Wenn ich das Gas auf ca. 1500 stelle wird die Zahl in Debug4 höher ins positive, negative so gut wie gar nicht. Beim Bewegen des Kopter in die Höhe (ca. 50-80cm) geht die Zahl in Debug4 in ähnliche Bereiche wie wenn der Kopter steht nach dem umlegen des Schalters.

Gruß Paraglider58

Komisch eigentlich, dass der MS Baro auf auf dem Schreibtisch +- 60cm an der Multiwii macht - wie der alte BMP. Ich habe schliesslich die eigentliche Baro-Auswertroutine nicht geändert. Sollte der nicht 10cm Auflösung haben? Hoffentlich sind die Werte Draussen besser. Vielleicht hast Du ihn auch nur für 50cm angebrüllt .
Bei mir ist bei Debug 3 kein Blitzen, die Zahlen sind gut zu erkennen. Vielleicht liegt es an meinem config.h #define DEADBAND 10. Statt "rcCommand[THROTTLE]" könnte man auch die Rohdaten mit rcData[THROTTLE] verwenden um Throttlestickbewegungen zu erkennen.
Edit: Habe jetzt die rcData - Variante durchgespielt - bringt nichts. Meine config.h DEADBAND 10 hat, wie erwartet, keinen Einfluss. Die Bewegung ist eher in meinem Baro! Ich glaube mit 60 komme ich mit dem BMP wohl doch nicht ganz hin - testen.

So, da der Code hier soweit in Ordnung ist und man eigentlich nur die Werte an seine Gegebenheiten anpassen muss, habe ich die Sache im multiwiiforum gepostet: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1463&p=14488#p14488. Dort bin ich als crashpilot1000 (http://www.multiwii.com/forum/memberlist.php?mode=viewprofile&u=1305) angemeldet. Mein Denglisch ist jetzt nicht so der Knaller - ich hoffe man versteht mich da. Es gibt schon wieder eine neue DEV Version "MultiWii_dev_20120522". Bezüglich unserer Codezeilen hier hat sich nichts geändert, auch der Baro PID controller ist Zeile für Zeile gleich geblieben. Es hat sich jedoch eine bedeutende Sache geändert: Die Auflösung der Timer, aus denen sehr viel im Code abgeleitet wird, wurde verbessert. Wenn dort ein Fehler besteht, gehts richtig vor die Wand. Also die neue Dev Version nicht unkritisch flashen. EEPROM Clear nicht vergessen.....
LG
ROB

EDIT: Ich habe meinen Code mit MultiWii_dev_20120522 erfolgreich getestet. Statt "60cm" bin ich bei meinem BMP085 mal auf "100" gegangen und den Throttleunterschied habe ich mal von 20 auf 40 erhöht - aber das sind nur meine 2 cents.

EDIT: Hier habe ich die letzten beiden DEV Versionen mit meinem Barocode verändert zusammengestellt.
Bei Versionswechsel zur Sicherheit EEPROM Clear durchführen.

Hallo Roberto,

wie löscht man das EEprom vorher?

Gruß Paraglider58

@Paraglider58
Die Arduino 10 laden und dann unter dem Menü File/Examples ist unter eeprom auch eeprom clear. Es wird sofort ein Sketch aufgerufen, den Du dann flashen kannst. Schreibe Dir vorher Deine Einstellungen auf, oder mache von der mwii GUI einen Screenshot - sonst gehts Dir wie mir manchmal.... was hatte ich nochmal bei xxx....

LG
Rob

P.s.: Hat vielleicht noch jemand mal meinen Mod probiert?

Ich teste heute abend mit Drotek 10 dof.

Den Mod teste ich mal bei nächster Gelegenheit.

Mein Alt-Hold hat mit der V 2.0 schon recht brauchbar funktioniert. Er "bounct" halt immer in der Zone herum, in der das Barometer "rauscht". Je nach PID-Einstellungen mal stärker, mal schwächer. Beim etwas zügigen Fliegen klappt das Höhe halten dann aber nicht mehr so gut, vermutlich, weil durch den Fahrtwind einfach der Luftdruck stärker schwankt.
Auf jeden Fall fand ich es schon ganz hilfreich, man muss deutlich weniger korrigieren als ohne Alt-Hold.

Mag: Manchmal driftet er ein wenig, was ich mir nicht so recht erklären kann. Wenn ich mal ordentlich Throttle gebe und den Copter festhalte bleibt der Mag-Wert in der Gui stabil. Störungen durch Ströme schliesse ich also aus.
Was mich mehr stört: Wenn der Copter schräg steht, dann dreht er sich weg. Das sieht man auch in der Gui. Vor allem bei Pitch dreht er sich kräftig weg, bei Vorwärtsflug in eine Richtung, Rückwärts in die andere Richtung.
Ich habe ein Crius SE und das auch im Sketch so ausgewählt. An der Mag-Orientierung sollte es also nicht liegen.

Hört sich so an als wäre der Mag nicht richtig kalibriert.

Dachte ich auch erst, aber ich habe es mehrmals wiederholt, das Verhalten bleibt identisch.
Eigentlich kann man beim Kalibrieren ja nicht so viel falsch machen, oder?

Was passiert, wenn man z.B. beim rotieren um die Z-Achse den Copter etwas schief hält?

@Joachim08
Mir fällt grade auf, dass ich Deinen Thread zum Teil gehijacked habe. Ich hasse solche Hijackertypen ....!
Aber ich glaube, mit dem Baro sind wir jetzt ein Stück weiter. Leider besitze ich kein Magnetometer, aber die Dinger müssen relativ störempfindlich sein - z.B anderer Akku, und plötzlich gibt es Störungen http://vimeo.com/29519728. Ich brenne natürlich darauf zu erfahren, ob bei anderen der Baro jetzt auch besser funktioniert. Wenn ich doch nur C programmieren könnte! Ich kann mittlerweile den Mwii code einigermassen lesen und verstehe immer besser, was passiert. Aus meinen längst vergangenen MC68000 Assemblerzeiten stechen mir ein paar Sachen aus dem aktuellen MWII/Baro Code ins Auge, bei denen ich rote Rufzeichen sehe, ohne eine konkret bessere Lösung zu haben, oder genau zu wissen, ob diese "roten Rufzeichen" gerechtfertigt sind. Irgendwie habe ich den Eindruck, die Barowerte könnten besser aufbereitet werden. M.E würde es reichen, 1-2 mal in der Sekunde gute Baro Werte zu haben. Bei jedem Durchlauf müsste man schon eine sinnvolle Vorselektion und Vorsortierung der Daten durchführen, dann ist die Endauswertung auch schnell erledigt. Bei dem NAZA ist der MS Baro dermassen dicht eingepackt, dass man sich wundert, wie der überhaupt noch was messen kann. Vielleicht ist das ein Schlüssel des Erfolges? Den Baro stärker kapseln? Ich weiss auch nicht, warum jetzt so viel an dem MWII GPS herumgefummelt wird, wo der Barocode noch nicht maturiert ist. Hoffentlich verzettelt sich MWII nicht und kann dann alles ein Bisschen, aber vieles eben nur rudimentär.

LG
ROB

Rob, ich habe gestern mal Deine Version auf meinen Quadro gespielt und das mal kurz ausprobiert. Leider hat es bei uns dauernd geregnet, aber am Abend habe ich es einfach mal im Haus getestet. Habe den Kopter auf Brusthöhe gebracht und den Baro zugeschaltet. War wachsam, da ich von meinen bisherigen Versuchen draußen weiß, dass sich der Kopter da in einem recht großzügigen Korridor bewegt und ich wollte nicht, dass er mir an die Decke knallt.
Ist er aber nicht. Der hat sich in einem Höhenbereich von etwa 1m bewegt, was ich eigentlich sehr gut fand.
Einzig die Höhenregelung mit dem Gasstick fand ich nicht so richtig gut gelöst. Vom APM1 kenne ich das so, dass es ein ziemlich großes Deadband rund um die Mitte gibt, was auch sinnvoll ist. Beim Wii ist das praktisch nicht vorhanden. So passiert es auch schon mal, dass man beim Gieren die Gasstellung leicht verstellt und der Kopter dann die Höhe ändert. Im Grunde genommen sehe ich da fast keinen Unterschied ob ich den Baro an oder aus habe. Wenn ich ohne Baro den Gasstick nicht anrühre, dann bleibt der Kopter auch ziemlich stabil, was die Höhe anbelangt.
Vom Baro würde ich mir erwarten, dass er die Höhe behält, auch wenn der Gasstick mal ein paar Rasten bewegt wird. Vielleicht kann man das so einstellen, dass das Deadband da größere ist.

Ich sehe gerade, dass es draußen heute sehr schön ist. Werde dann mal einne Test im Freien machen.

... da finde ich den Höhenregler beim Mikrokopter nicht schlecht. Auf Wunschhöhe aktiviert man den HR mit einem Schalter. Jetzt kann ich mit dem Gasknüppel etwas nach oben gehen und der MK hält die Höhe sehr gut. Der Regler deckelt im Prinzip. Gebe ich noch mehr Gas steigt der MK nur langsam ein paar Meter höher und hält dann die Höhe. Man muß dann nur aufpassen wenn man den HR wieder deaktiviert .... Könnte man das nicht abkupfern ?

@ Roberto : Kein Problem, gerade dies habe ich eigentlich damit bezweckt... Ich habe auch wie Du den Eindruck, daß der Multiwii viel können muß, aber alles noch sehr unausgereift ist. Ich habe immer noch Probleme beim ACC Modus mit dem 6050.
Auch der Kompass geht mit dem original P nicht, erst ab P=12 geht etwas..

Die neueste dev ist schon mit Deinen Optimierungen aufgespielt, aber bin leider noch nicht zum testen gekommen.

@Helste:
Das Deadband an dem Throttlestick kannst Du bei meinem code direkt einstellen. Du brauchst nur die Zahl im Hauptprogramm zu ändern (weit unten ab ca zeile 700) "if (abs(estaltmw - AltHold)>100 && abs(thrstickmw - initialThrottleHold)>40)". Hier wird festgestellt, ob sich der copter wirklich bewegt hat (hier:100 sind 100cm) UND ob der Gasknüppel bewegt wurde (hier 40 "Ticks").
Wenn Du das Deadband um den Throttlestick vergrössern willst, brauchst Du nur die "40" in z.B 150 oder so zu ändern. Probiere doch einfach mal in 50er Schritten andere Werte aus. Mehr als 300 dürfte aber dabei nichts mehr bringen.
@Joachim:
"...Ich habe immer noch Probleme beim ACC Modus mit dem 6050.." Das ist genau was ich meine. GYRO und ACC müssen solide funktionieren, dann Baro, dann Magnetometer und wenn dann alles perfekt läuft kann man sich an das GPS machen. Momentan habe ich den Eindruck, dass nur noch am GPS gefrickelt wird.

LG
Rob
P.s.: Die GUI in der neuen DEV 20120522 läuft sehr zäh! Das ist normal und liegt nicht an der Änderung.

Danke Rob, werde das gleich mal testen.
Ich werde mir jetzt doch mal auch den Code näher ansehen. Ich bin ja Soft5wareentwickler, aber meine Programmiersprache ist ObjectPascal (Delphi). Wenn ich mir den Arduinocode ansehe, dann verstehe ich ihn aber sehr gut. Zwischen Verstehen, was ein Code macht und selber welchen schreiben ist aber noch ein Unterschied. Für zweiteres muss man sich die Syntax mal genauer anschauen.
Bisher hat mich das eher nicht so interessiert, aber ich denke, ich werde mich da mal einlesen und schauen, ob ich da nicht was dazu beitragen kann. Ist halt auch ein Zeitproblem.

Achja, was mich doch etwas nervt ist, dass die GUI keine Möglichkeit hat die Parameter zu speichern. Oder habe ich das bisher einfach noch nicht entdeckt. Überhaupt finde ich die GUI etwas "gewöhnungsbedürftig", um das mal vorsichtig auszudrücken.
Ich will da nicht zu kritisch sein, weil da Leute ihre Freizeit dafür opfern und dafür auch noch nicht mal was bekommen, wenn ich das richtig verstehe, aber wenn man das etwas anwenderfreundlicher macht, bedeutet das ja gar nicht mal mehr Aufwand.
Die 2 Dinge, die mich am meisten stören:
1. Parameter können nicht gespeichert werden, wodurch man die jedes mal nach einem Softwareupdate neu eingeben muss.
2. Beim Eingeben der Parameter ist das eine ziemliche Fummelei mit dem Taste festhalten und Verschieben. Kann man das nicht einfach so machen, dass man einfach die Werte eintippt, so wie das bei den meisten anderen Programmen auch der Fall ist?

Es gibt ja eine wirklich gut gelungene WinGUI (MultiWiiWinGUI), aber die verweigert leider bei den neuen DEV Versionen den Dienst.