Funktionieren bei Euch Kompass und Baro vernünftig ?

Joachim08

Erfahrener Benutzer
#1
Hallo zusammen,

vor kurzem habe ich mein D&C Board mit einer 10DOF von Drotek mit MPU6050 etc. ausgerüstet. Aufgespielt ist die 2.0dev vom Mai. Quadro mit Baumarktframe, also nichts unübliches.

Irgendwie habe ich den Eindruck, daß der Kompass und der Baro zwar Signale liefern, aber der Kopter macht was er will.

Der Kopter schwankt bei aktiviertem Baro in der Höhe um mehrere Meter, gebe ich mehr Gas steigt er einfach so weg. Ich zumindest erwartet, daß der HR die Höhe zumindest deckelt, d.h. der MK bei mehr Gas dann nur wenig steigt. So macht es zumindest mein Mikrokopter.
Auch die Kompasswirkung ist nicht merkbar, der Kopter giert um bis zu 45 Grad bei aktiviertem Kompass. Sollte der Kopter mit dem Kompass nicht die Ausrichtung beibehalten bei Gierknüppel in der Mitte ? ... oder zumindest die Ausrichtung wie bei Start ?

Wie sind Euere Erfahrungen und wie kann man das Verhalten optimieren ?
Kompass ist kalibriert und in der GUI reagiert auch alles richtig...

Grüße

Joachim
 
Erhaltene "Gefällt mir": phischi

zerosight

Erfahrener Benutzer
#2
Wenn er mit Kompass immer in einem bestimmten Winkel giert und nicht einfach nur rotiert, dann hört sich das nach Störungen durch ein elektrisches Feld an. Prüf mal den Verlauf Deiner Stromversorgung.

Grundsätzlich ist die Barofunktion gerade erst dabei vernünftig implementiert zu werden. Soweit mir bekannt stellt die Baro-Funktion zur Zeit nur eine Korrektur gegen Äußere Einflüsse zur Verfügung. D.h. wenn Du Throttle veränderst, dann führt er die Höhe nach, steht der Copter in der Luft und wird. z.B. durch einen Windstoß oder per Hand runtergedrückt oder nach oben geschubbst, versucht er wieder in die Ausgangshöhe zu kommen. Welchen Baro hast Du den und welche PIDs sind für die Barofunktion eingestellt? Der "alte BMP" Baro ist da sehr ungenau, die Egebnisse mit dem neuen "MS" Typ sind präziser. hast DU ihn zugfrei (Watte/ luftdurchlässiger Schaumstoff) installiert?
 

Paraglider58

Erfahrener Benutzer
#3
Hallo Joachim,

das mit dem Baro kann ich bestätigen. Ich komme gerade von der Wiese. Die Ausrichtung durch den Kompass ist zwar recht gut, aber er dreht langsam und leicht weg. Die Höhe hält er schlecht, und so wie du schreibst, mit ein wenig Gas mehr, da steigt er sofort hoch. Auch mit GPS u. Ultraschall verändert sich nicht viel. Keine Ahnung was das sein kann, den Baro habe ich leicht zugepackt.
Mein Quad hat die Flyduino MEGA Flight Controller 10DOF m. MPU6050 von Drotek, FMP04 GPS Modul, und ein Ultraschall Entfernungsmesser SRF02 (Fertigmodul).

Gruß Paraglider58
 

Joachim08

Erfahrener Benutzer
#4
Als Stromverteiler habe ich die Warthox Stromverteilerplatine, da kann ich nichts verändern und da ich als Träger das Divide&Conquer Shield habe ist die Position des Sensorboards fix. Ich muß gestehen, daß ich nicht gerade begeistert vom Multiwii bin. Es gibt sehr viele Sensoren und Möglichkeiten, doch was nützen diese wenns nicht richtig funktioniert ?

Als Kompass ist der HMC5883 verbaut, als Baro der MS5611. Luftdurchlässiger Schaumstoff ist rum. Mit aktiviertem Kompass rotiert er schon, aber das doch eben nicht sein, sondern eher um eine Ausrichtung hin und her mit einer bestimmte Gradzahl, oder ?
 

Roberto

Erfahrener Benutzer
#5
@Joachim08

Zum Baro gibt es multiwii Forum eine PID Einstellungsanleitung:
http://www.multiwii.com/forum/viewtopic.php?f=17&t=1564#p12824

Ich habe teilw etwas andere Erfahrungen mit dem BMP085 (http://fpv-community.de/showthread....den-MultiWii_dev_20120504-BARO-PID-Kontroller)

Zum Ansprechen des Baros:
Wie man aus dem Codeabschnitt

Code:
    if (baroMode) {
      if (abs(rcCommand[THROTTLE]-initialThrottleHold)>20) {
         baroMode = 0; // so that a new althold reference is defined
      }
      rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
    }
sehen kann, wird bei eingeschaltetem Baro eine "Totzone" von 21 um den aktuellen Gasknüppelbefehl gebildet. D.h. wird der Gasknüppel aus dieser Zone herausbewegt, wird eine neue zu haltende Höhe definiert. Und das ist m.E auch schon Teil des Problems, denn der Code hat schon längst den Stickinput verarbeitet und liesst den neuen Barowert aus, obwohl sich der Copter überhaupt noch nicht bewegt hat und der Baro noch keinen neuen Wert hat (naja, bei dem Sensorrauschen hat er wohl immer einen "neuen" Wert), oder einen falschen, weil der copter sich im Moment des Auslesens grade in die falsche, also der Knüppelbewegung entgegengesetzten Richtung bewegt hat. So schaukelt sich das schnell mal auf.
Liege ich mit meiner Interpretation falsch?

Wäre nicht das sinnvoller:

Wenn sich die Höhe glaubwürdig d.h. im Rahmen der Sensorauflösung geändert hat UND der Gasknüppel in die gleiche Richtung bewegt wurde, DANN nimm die neue Höhe als Referenz.


Lg
Rob
 
Zuletzt bearbeitet:

Roberto

Erfahrener Benutzer
#6
Ich will ja nichts sagen, aber in dem Barocode war noch ein Klopper.
Die Zeile "rcCommand[THROTTLE] = initialThrottleHold + BaroPID" ist schlichtweg Unsinn und funktioniert nur durch dieses blödsinnige, sofortige neue Höhe setzten bei Throttleveränderungen. D.h. man hat jetzt auch noch eine 21er Rasterung auf dem Gaskanal. Ich glaube, das Problem gelöst zu haben. Meine Testflüge waren jedenfalls DEUTLICH BESSER als mit dem Originalcode!

So sieht der Originalcode aus:
Code:
  #if BARO
    if (baroMode) {
      if (abs(rcCommand[THROTTLE]-initialThrottleHold)>20) {
         baroMode = 0; // so that a new althold reference is defined
      }
      rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
    }
  #endif
Mein neuer Code arbeitet nach dem Schema aus meinem vorherigen Post:

Wenn sich die Höhe glaubwürdig d.h. im Rahmen der Sensorauflösung geändert hat UND der Gasknüppel in die gleiche Richtung bewegt wurde (also keine Windböe), DANN nimm erst die neue Höhe als Referenz sonst behalte die alte Referenzhöhe. D.h. die Trägheit des Copters wird jetzt mit berücksichtigt.

Dabei ist in dem Code die +-50 die Sensorauflösung in cm, die ich bei meinem BMP085 mit 50 cm angenommen habe.
Die 10 ist quasi das Deadband um den Gaskanal, ab dem eine Knüppelbewegung erkannt wird. Es erfolgt dadurch keine Rasterung des Gasbefehls (wie vorher!), dieser wird weiterhin in voller Auflösung durchgereicht.
Code:
  #if BARO
    if (baroMode)
    {
      if (EstAlt - AltHold > 50 && rcCommand[THROTTLE]-initialThrottleHold > 10) //Did he rise on purpose?
      {
        baroMode = 0; // so that a new althold reference is defined
      }
      if (EstAlt - AltHold < -50 && rcCommand[THROTTLE]-initialThrottleHold < -10) //Did he fall on purpose?
      {
        baroMode = 0; // so that a new althold reference is defined
      }
      rcCommand[THROTTLE] = rcCommand[THROTTLE] + BaroPID;
    }
  #endif
Also einfach mal den Originalcode durch meinen ersetzen

EDIT:
"Ich glaube, das Problem gelöst zu haben" - noch nicht ganz, die Änderung des Throttlekanals kann schon wieder zurückgenommen worden sein, obwohl der Copter noch auf dem Weg zur Wunschhöhe ist. Daran arbeite ich grade - und ausserdem AKKUS LADEN :( .

LG
Rob
 
Zuletzt bearbeitet:

Paraglider58

Erfahrener Benutzer
#7
Hallo Roberto,

ist der Code (der Originale wie auch deiner) nur für den BP085 oder ist da auch ein anderer angesprochen. Ich habe ja die 10DOF von Drotek mit dem MPU-6050. Oder haut das damit nicht hin.

Gruß Paraglider58
 

Roberto

Erfahrener Benutzer
#8
Der Code ist sozusagen im obersten Level d.h. er funktioniert mit jedem Baro, der mit Multiwii funktioniert. Ich habe jetzt noch weiter getestet mit 20cm und "5" Deadband. Es ist besser geworden, aber ich habe noch einen weiteren Fehler im orig Code gefunden, den ich bis jetzt noch nicht isolieren - aber immerhin unschädlich machen konnte. Ich muss mich erst in Arduino und die Materie einarbeiten - ich habe vor 20 Jahren in Assembler Grafikdemos geschrieben... ist also nicht so einfach für mich.
 

Roberto

Erfahrener Benutzer
#11
So, der Code ist jetzt weiter gepimpt, und wieder ein paar Akkus am Lader.. Es tut sich was! Der Code von oben ist schon OK - nur die Werte "zappelten" noch zu viel für die Auswertung. Das habe ich jetzt mit einem Einfachen Schleifenzähler und Mittelwert gelöst. Das einzige Problem ist die neue Wunschhöhe zu erkennen. Bei meinem Quad muss ich schon am Gas ziehen, damit er hoch kommt, und wenn ich dann die Höhe erreicht habe (oder auch vorher) nehme ich Gas zurück. Jetzt weiss ich auch, warum beim NAZA im ATTI Modus die Mittelstellung des Gasknüppels als "Höhe halten" definiert ist. Das ist einfacher.

EDIT 21Uhr: Ich gaub ich bin vor einer guten Lösung
 
Zuletzt bearbeitet:

micha59

Erfahrener Benutzer
#13
Baro BMP085 funktiniert auf +_ 1m super, zur Landung sollte es abgeschalten werden, der Copter weigert sich sonst den Erdboden zu berühren. Das MAG funktioniert erst bei P-Werten ab 10-15 (zumindest bei mir).

Gruß, Micha
 
Zuletzt bearbeitet:

Roberto

Erfahrener Benutzer
#14
So, ich bin jetzt zu einem Ergebnis gekommen, von dem ich glaube, dass es besser ist als in der aktuellen MWII Dev 20120504. An dem Baro PID Kontroller habe ich nichts geändert - weil ich es nicht kann.

Die ursprüngliche Idee:
" Wenn sich die Höhe glaubwürdig d.h. im Rahmen der Sensorauflösung geändert hat UND der Gasknüppel in die GLEICHE Richtung bewegt wurde (also keine Windböe), DANN nimm erst die neue Höhe als Referenz sonst behalte die alte Referenzhöhe. D.h. die Trägheit des Copters wird jetzt mit berücksichtigt."
Ist leider so nicht ohne weiteres in die Realität umzusetzen, weil man viel zu sehr am Gas herumspielt um eine Höhe zu erreichen. Ausserdem ist der Copter träge, und die Werte des BMP085 sind zappelig.
Deswegen folgende Lösung:
Es werden 64 Baro- und Gaskanalwerte gemittelt. Wenn sich in dieser Zeit der Baro um 60cm und der Gaskanal um 20 "Ticks" verändert haben, wird von einer gewollten Höhenänderung ausgegangen und die neue Höhe wird zur Referenzhöhe. Das ist natürlich nicht perfekt, aber auf jeden Fall besser als die ursprüngliche Lösung (sofort bei Stickänderung den neuen Barowert als Referenzhöhe einloggen, also noch bevor der Copter seine Höhe geändert haben kann)! Ausserdem wird der Gaskanal jetzt nicht mehr in 21er Raster zerlegt, sondern sauber wiedergegeben.
Der Code ist recht simpel und leicht zu verstehen. Wenn man die beiden Debugs auskommentiert, bekommt man in der GUI unter Debug3 die Änderung des Gaskanals seit der letzten festgesetzten Höhe und unter Debug4 die Höhenänderung (in cm) seit der letzten festgesetzten Höhe. Der BMP085 liefert schon bei mir auf dem Schreibtisch Werte von -x bis 50cm daher habe ich den Wert 60 im code verwendet. Andere Barosensoren können eine höhere Auflösung haben, also ermittelt den Wert, den euer Baro schafft und tragt ihn in den Code ein.
In der MultiWii_dev_20120504 müsst ihr folgendes machen:

1.Das hier vor die anderen statics packen:
Code:
static uint8_t baroloopcounter=0;
static int32_t thrsticksum=0;
static int16_t thrstickmw=0;
static int32_t estaltsum=0;
static int32_t estaltmw=0;
2. Den Originalcode finden und durch den neuen ersetzen

Original:
Code:
 #if BARO
    if (baroMode) {
      if (abs(rcCommand[THROTTLE]-initialThrottleHold)>20) {
         baroMode = 0; // so that a new althold reference is defined
      }
      rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
    }
  #endif
Neuer Code:
Code:
  #if BARO
    if (baroMode)
    {
      if (baroloopcounter <64)
      {
        estaltsum=estaltsum+EstAlt;
        thrsticksum=thrsticksum+rcCommand[THROTTLE];
        thrstickmw=0;
        estaltmw=0;
        baroloopcounter=baroloopcounter+1;
      }
      else
      {
        baroloopcounter=0;
        estaltmw=estaltsum>>6;
        thrstickmw=thrsticksum>>6;
        estaltsum=0;
        thrsticksum=0;
        
//        debug3=thrstickmw - initialThrottleHold;
//        debug4=estaltmw - AltHold;
        
        if (abs(estaltmw - AltHold)>60 && abs(thrstickmw - initialThrottleHold)>20) //Did the hight significant change over time on purpose?
        {
          baroMode = 0; // so that a new althold reference is defined
        }
       }
     rcCommand[THROTTLE] = rcCommand[THROTTLE] + BaroPID;
    }
  #endif
So, dann viel Spass beim Ausprobieren! Keine Angst, wegen der Codeänderung schmiert er euch nicht ab. Der Code ist in wenigen cycles erledigt und hat keine zeitraubenden Schleifen.

LG

Rob
 

micha59

Erfahrener Benutzer
#15
Hi Rob,
sieht auf den ersen Blick sehr, sehr gut aus. Werde ich demnächst mal testen (obwohl 1m oder 0,5 m eigentlich "Wurst" ist). Genial sieht das aber erst mal aus (warum komme ich da eigentlich nicht drauf :)) . . . Super!
VG Micha
 

Sledge

lonesome Cowboy
#16
Warum loggt man die Referenzhöhe nicht einfach in dem Moment in dem man den Höhenschalter aktiviert. Wenn man eine neue Höhe wünscht muss man einfach den Schalter rausnehmen und später wieder einschalten. Oder bin ich gerade auf dem Holzweg?
 

Roberto

Erfahrener Benutzer
#17
@Sledge
Genau das habe ich heute auch programmiert und getestet. Das ist die einfachste Lösung, nur das steuert sich absolut besch..eiden. Der Baroschalter ist umgelegt und Dein Gaskanal ist ausser Betrieb - nur noch Gier. Beim Zurückschalten muss man darauf achten, genug "Gas" vorgewählt zu haben. Sehr gewöhnungsbedürftig, und nur in grösserer Höhe praktikabel/fliegbar.

@micha59:
Die bisherige Auflösung Deiner Barolösung wird dadurch nicht schlechter.
 
Zuletzt bearbeitet:

micha59

Erfahrener Benutzer
#18
@Roberto:
. . . stimmt, aber die "Reaktion" auf Veränderungen in der Höhe" vielleicht . . .?! :) Beim ganz normalen "Foto(Video)-Fliegen stört mich persöhnlich sogar das Höhe halten, fühlt sich immer an wie ein "geh weg von der Erde" oder so an . . . lach . . .! Bin einfach Acro-Flächenflieger im "möchte gern 3D Modus" . . . :)

Gerne hier, Micha
 

Roberto

Erfahrener Benutzer
#19
" stimmt, aber die "Reaktion" auf Veränderungen in der Höhe" vielleicht " - genau, und der Baro Pid Kontroller wird nicht dauernd mit vollkommen verrückten Throttle- und Höhenkombinationen gefüttert. Aktuell schaue ich mal, ob sich die ACCZ Werte (Beschleunigung nach oben/unten) zur Unterstützung des Baros eignen.
 
RCLogger

FPV1

Banggood

Banggood

Oben