Funktionieren bei Euch Kompass und Baro vernünftig ?

helste · Jun 14, 2012

Roberto, ich kann natürlich nicht 100%ig sicher sagen, was nun die Verbesserung gebracht hat, aber ich habe die letzte Programmzeile von Dir noch eingespielt und dann die Werte, so wie sie auf dem Screenprint zu sehen sind erflogen.
Was die Akkulaufzeit anbelangt, kann ich ja mal testen. Ich weiß ja ungefähr, wie es vorher war.
Dann häng ich den Quad halt mal 20 Minuten in die Luft und schaue was dann rein geht in die Akkus.

Roberto · Jun 14, 2012

@Helste: Da mein ACC zu schrottig ist, könntest Du mal folgendes probieren?
P auf 0 (nur ACC Test), I auf 0 (Regelung nur nach oben) und jetzt ein "D" in der Hand testen. D.h. Copter mit dem Gaskanal in der Hand "leicht machen" ACC&Baromode zuschalten, und dann mit der Hand sacken lassen und schauen, ob er verzögert?

LG
Rob

helste · Jun 14, 2012

Und wie er das macht. Habe ihn auch mal so schweben lassen und von oben drauf gedrückt. Heftige Gegenwehr. Sieht genauso aus, wie in den Naza Videos, wo die von oben drauf drücken. Einfach genial.

Roberto · Jun 14, 2012

Hi Helste!

Ich habe jetzt hier die Forumsversion auf den letzten Stand gebracht und einige Lipoladungen gequält. So muss das funktionieren! Die Verbesserungen gehen vor allem auf Dich zurück! Mit der jetzigen Version bin ich sehr zufrieden. Durch einen kleinen Kunstgriff, beteiligt sich jetzt auch das ACC (sogar mein schäbiger BMA020) erfolgreich am Höhehalten! Natürlich könnten die Motorbefehle noch etwas "runder" rüberkommen, aber was ist schon perfekt?

@Alle
Die überarbeitete Version ist jetzt fertig!
Im Prinzip hat sich gegenüber meinem Post hier: http://fpv-community.de/showthread....o-vern%FCnftig&p=154297&viewfull=1#post154297 von der Logik her nicht viel verändert.
Die aktuelle "getEstimatedAltitude" sieht jetzt so aus:

Code:

///////////////////////////////////////////////
//Crashpilot1000 Mod getEstimatedAltitude ACC//
///////////////////////////////////////////////

#define UPDATE_INTERVAL 20000                                   // Means: Dont be faster (next Gen Sensors?) than this, because ACCZ needs values

void getEstimatedAltitude()
{
  static uint32_t deadLine=0;
  static int32_t LastBaroAlt,BaroAltSum;
  static int16_t AccZLowest,AccZHighest;     // ACCZ extremes
  static int8_t BaroCnt=0;

  int16_t ACCZD,BaroP;
  int32_t BaroDiff;
  
  ACCZD = accADC[YAW]-acc_1G;                                   // So UPacc is +, DWNacc is -
  if (ACCZD > AccZHighest) AccZHighest=ACCZD;                   // Set new ACC Extremes
  if (ACCZD < AccZLowest) AccZLowest=ACCZD;                     // Every run till next calc, at least while UPDATE_INTERVAL
  if (newbaroalt==1)                                            // Update only, if new Baro-values are available
   {
    newbaroalt = 0;                                             // Reset Boolean
    BaroAlt=BaroAlt/30;                                         // Limit Resolution to 30 cm

    BaroAltSum+=BaroAlt;                                        // do at least 340 ms average for Estalt
    BaroCnt++;
    if (BaroCnt==17){
      EstAlt=BaroAltSum/17;
      newestalt=1;                                              // Indicate, new EstAlt RDY
      BaroAltSum=0;
      BaroCnt=0;}
     
    BaroAlt = (BaroAlt+LastBaroAlt)/2;                          // Do Average with last BaroAlt
    LastBaroAlt = BaroAlt;
    
    BaroDiff = BaroAlt-AltHold;                                 // BaroDiff = Difference to locked hight pos if risen

    if (micros() < deadLine) return;                            // Break, if too fast
    deadLine = micros() + UPDATE_INTERVAL; 

    BaroPID = 0;                                                // Stores Result for mainroutine
    ACCZD = 0;
    BaroP = 0;

    // Baro P
    BaroP = conf.P8[PIDALT]*(BaroP-BaroDiff)/20;                // P of Baro a P of 2,5 in the GUI means 25
    BaroP = constrain(BaroP,-250,+250);                         // Limit Baro P to +/- 250

    // ACCZ
    if (rcOptions[BOXACC]){                                     // Only do ACCZ in Level Mode
      ACCZD -= (int32_t)conf.D8[PIDALT]*(abs(AccZHighest)+abs(AccZLowest))*(constrain (AccZHighest-abs(AccZLowest),-10,+10))/acc_1G; // conf.D8[PIDALT] Is scalefactor for ACCZ
      ACCZD = constrain(ACCZD,0,+200);                          // Limit ACC Z to only Upcorrection + 200
     }

    BaroPID = BaroP+ACCZD;
    if (BaroPID < 0){
     BaroPID = constrain((BaroPID*conf.I8[PIDALT])/100,-250,0); // Lower Dropping Values by a Factor stored in GUI I. Gui I=0.100 = 100.
    }
    AccZHighest=0;                                              // Reset Values anyway
    AccZLowest=0;
   }
}

Der ACC wirkt jetzt nur noch dem "Durchsacken" entgegen. D.h. ein Aufsteigen des Copters wird nicht vom ACC beeinflusst. Von der "Physik" her gesehen ist der Code sicherlich haarsträubend, aber er funktioniert! Meine anderen Versuche mittels physikalisch korrekterer Umrechnung u.s.w funktionierten bislang deutlich schlechter. Bei meinem BMA020 brauche ich ein ALT "D" von 80+ , damit es was bringt. Andere ACC Sensoren, die im MWII Code höhere Werte liefern, werden ein deutlich kleineres D brauchen (z.B Helste: D < 10). Mit dem "I" habe ich auch gespielt und bin zu dem Schluss gekommen, dass es doch etwas bringt. Momentan fliege ich z.B mit einem "I" von 0,010 d.h. ich lasse nur 10% der Negativimpulse ("nimm Gas weg") durch. Ihr seht schon, mein Copter braucht Unterstützung gegen das Durchsacken. Bei Coptern mit stärkerer Motorisierung kann das anders aussehen. Bei dem "P" bin ich, wie Helste auch, mit meinem BMP085 und meinem Quadrocopter bei "15" gelandet. Das sind natürlich nur Beispiele.

Viel Spass beim Testen! Die Config.h enthält keine Änderungen.
Versucht nicht die Defaultwerte bei ALT! Ich habe jetzt nicht nachgeschaut, was da eingetragen ist.

LG

ROB

helste · Jun 14, 2012

Rob, hast Du sonst noch was geändert, oder reicht es, wenn ich die getEstimatedAltitude einfach austausche?

Ich möchte Dir herzlich für Deine Arbeit danken. Ist echt genial.
Schön langsam wird das was.

Dafür habe ich mit meinem APM1 Hexa ein technisches Problem. Bin dem aber schon auf der Spur. Muss aber erst Propeller tauschen. Hat nämlich einen Rückwärtssaldo in eine Mauer gemacht, als sich plötzlich die vorderen Motoren dazu entschlossen haben, ordentlich Gas zu geben.

upapa · Jun 14, 2012

Roberto hat gesagt.:

@Helste:
Versuche doch mal bitte die alte "ACCZD" Zeile durch diese Variante zu ersetzen:

Code:

ACCZD -= (int32_t)conf.D8[PIDALT]*(abs(AccZHighest)+abs(AccZLowest))*(constrain (AccZHighest-abs(AccZLowest),-10,+10))/acc_1G;

ROB

Damit verschwindet das Zuckeln meines CriusSE bei Kombination von BARO- und LEVEL-Mod. Prima.

Ausserdem habe ich die ALT-Werte auf P=15, und D=10 geändert (I blieb unverändert). So hält der Copter mit Deiner 20120606_NewBaroPID hervorragend die Höhe. Mehrere LiPoFüllungen ist der Copter in einem Meter Höhe über dem Rasen schön sanft in einem 50 cm Höhenkorridor gependelt. Sehr beeindruckend.

upapa

helste · Jun 14, 2012

Upapa, versuche mal von oben auf den Kopter zu drücken, also ihn ruckartig nach unten zu stoßen, sofern es die Bauweise gefahrlos zulässt. Dann wird Dich das an die Naza Videos erinnern. Ich sage mal, Rob hat aus dem Multiwii SE ein Naza gezaubert;-)

upapa · Jun 14, 2012

helste hat gesagt.:

Helmut, deshalb hab ich ihn ja hauptsächlich einen Meter über dem Rasen schweben lassen. ;-)

helste hat gesagt.:

Und ich kann mich nur wiederholen: Beindruckend, Roberto!
(Dabei habe ich noch nicht einmal die neue 20120606_NewBaroPID2 ausprobiert...)

upapa

Roberto · Jun 15, 2012

Danke, für euer sehr positives Feedback!

@Helste:

Du kannst einfach die getEstimatedAltitude austauschen. Gegenüber Deiner jetzigen, "mitgewachsenen" Version gibt es allerdings bzgl. des Regelungs/Flugverhaltens etwas zu beachten:
@Helste & ALLE: Ich stehe natürlich vor dem Problem, dass ich nur mein Setup im Flug testen kann, aber möchte, dass die Änderungen möglichst vielen nützen. Über Parameter in der config.h (von der ich bisher - wie ich finde, aus gutem Grund - immer die Finger gelassen habe, obwohl es stark gejuckt hat) ist eine Anpassung auf verschiedene Setups realisierbar, deswegen ist euer Input mit verschiedenen Sensoren und Konfigurationen (Tri/Quad/Hexa) so wertvoll. Ich möchte euer Augenmerk auf die "rot" angezeigten "constrain"s in der IMU/getEstimatedAltitude lenken. In diesen wird festgelegt, in welcher Stärke die jeweilige Komponente in das Gesamtergebnis eingeht. Z.B steht in der jetzigen Version die Codezeile:

Code:

ACCZD = constrain(ACCZD,0,+200)                             // Limit ACC Z to only Upcorrection + 200

Damit wird das Ergebnis des Accelerometers um die negativen Werte kastriert, weil es bei mir ein besseres Ergebnis brachte.
D.h. aber nicht, dass es mit eurem Accelerometer mit meiner ursprünglichen Codezeile:

Code:

ACCZD = constrain(ACCZD,-150,+150);                       // Limit ACC Z to +/- 150

bei euch nicht besser funktionieren kann! Also spielt mit den Werten herum! Diese sind nicht vom Himmel gefallen! Es kann nichts passieren, wenn Ihr einen schnellen Finger am "Baro aus Schalter" habt, denn der deaktiviert sofort alles hier.
Der Teiler für Baro P ist jetzt z.B auch von 25 auf 20 reduziert.

@upapa

Auch Dir einen herzlichen Dank für Deine sehr freundlichen Rückmeldung! Ohne das Feedback von Helste wäre diese Zeile, die auch Dir etwas gebracht hat (BMA180/BMP085), nicht möglich gewesen!

Akkulaufzeit: Ich habe keine Messungen gemacht, aber ich fresse einen Besen, wenn sie sich nicht bei eingeschaltetem AltitudeHold verkürzt. Das müsste aber eigentlich meistens der Fall sein, sobald eine Automatik eingreift die weniger vorausschauend regeln kann als der Mensch.

Jetzt OT (rein persönliches NAZA Statement):
Da der "NAZA" hier erwähnt wurde. Ich bin nach der anfänglichen NAZA - Euphorie doch ziemlich schnell auf den Boden der Tatsachen zurückgekommen. Mir gefällt schlichtweg das Flugverhalten nicht. Im Gyromodus fliegt er für mich gut (mit EXPO/DR in der Funke), im Attimode wie eine Oma mit 4 Propellern (Orvillecopter

). Ausserdem macht der ATTI Mode bei mir immer noch Zicken - plötzlich tritt eine Schieflage auf. Früher hatte ich dann schnell mal Abstürze, die allerdings nach einigen Entstörmanövern jetzt nicht mehr auftreten. (Qualitaiv eher gutes Setup: Hacker Motoren & Robbe 930 ESC, und ja, die + Leitungen sind nicht verbunden) Egal, beim FPV Flug habe ich jetzt immer einen schwitzigen Finger am ATTI-Aus Schalter, entspanntes Fliegen sieht für mich anders aus. Weiterhin möchte ich FPV im Gyromode fliegen UND den Baro eingeschaltet haben, der mich rechtzeitig nach oben zieht bevor ich Ameisen zählen kann, weil ich in der 2D Ansicht häufig noch den Abstand zum Boden u/o meine Fallgeschwindigkeit unterschätze. Nur Gyro und Baro kann der NAZA mit der aktuellen Software eben nicht. Die MWII ist für mich berechenbarer, einstellbarer und macht mir mehr Spass zu fliegen.
OT GPS:
GPS ist für mich eher unnötiges Zusatzgewicht

, für meine Zwecke wäre kein RTH sondern eher ein Return zu meiner sicheren Steuerentfernung wichtiger. Durch "Headfree" mittels Compass weiss der Copter doch ungefähr wo ich stehe, warum nicht eine aktivierbare Funktion (Failsave u/o Schalter) mit der der Copter ohne GPS auf mich zu fliegt? Natürlich weiss er dann nicht wann er über mich hinweg ist, aber ich werde schon mit dem Steuern wieder anfangen, sobald ich wieder ein Videobild habe oder ihn sehe.

LG

ROB

r0sewhite · Jun 15, 2012

Rob, ich hab gestern und heute Deine "alte" MultiWii_dev_20120504BaroModNR5 auf dem X8 geflogen. Nachdem es in der letzten Zeit irgendwie immer geregnet hat, wenn ich Zeit hatte, wollte ich sie wenigstens einmal geflogen haben, nachdem ich sie geflasht hatte. Die Höhenschwankungen fielen bei meinem X8 sehr gering aus, ein sanftes Pendeln lag so etwa bei guten 2 Metern. Ob das jetzt am MS5611 oder der Trägheit des großen Copters allgemein liegt, kann ich nicht sagen. Die PID-Werte hatte ich nicht angerührt.

Allerdings habe ich immer noch meinen defekten Motor drauf und dabei heute diese Video gedreht. Am besten einfach mal Lautsprecher aufdrehen und dem Motorausfall lauschen. Ich finde das Ergebnis echt beeindruckend:

http://vimeo.com/44066195

Morgen werde ich das Flyduino mal fürs Wochenende auf den aktuellen Stand bringen. Es ist echt erstaunlich, was Du in so kurzer Zeit mit Helstes Unterstützung vollbracht hast und ich bin mächtig auf die MultiWii_dev_20120606_NewBaroPID2 gespannt. Endlich ist hier gutes Wetter und ich habe zudem ein freies Wochenende.

helste · Jun 15, 2012

Ja, so ein Octo hat schon Reserven.

Ich habe gestern das 2. Tor der Spanier versäumt, weil es mir wichtiger war die neue Version zu testen. Hat sich aber gelohnt. Es ist einfach genial. Habe versucht ziemlich genau 10 Minuten Flugzeit abzuspulen und das fast ausschließlich im alt hold Modus.
Ein Akku hängt gerade am Ladegerät. Mal sehen was rein geht.

Heute probier ich dann gleich mal ACCZD = constrain(ACCZD,-150,+150); aus und berichte dann, ob es passt.

Insgesamt muss ich sagen, dass mir das schon viel Spaß macht, neue Sachen zu testen. Nur herumfliegen ist auf Dauer eh langweilig, vorallem wenn ich keine Zeit habe auf die Wiese zu gehen und den Kopter nur im Garten bewege.
Nachdem mein Hexa mit dem APM1 momentan Probleme macht wird der Multiwii Quadro immer mehr zu meinem Liebling.
Dank Rob's Engagement wird das ein richtig lässiges Fluggerät. Wer hätte das gedacht, dass man aus einer €50,- Flugsteuerung so viel raus holen kann.

Sobald der Akku voll ist, gebe ich Bescheid wieviel in 10 Minuten an Saft gezogen wurde. Ich fliege den Quad ja immer mit 2 Stück 2200mAh Akkus parallel und damit kann ich ca. 22 Minuten problemlos ruhig umherfliegen. Es sollte also max. 900 - 1000 mA in den Akku rein gehen, wenn sich am Verbrauch nichts geändert hat. Mal sehen.

helste · Jun 15, 2012

So, der erste Akku ist schon wieder voll. Gingen genau 946 mA rein. Ich werde heute mal versuchen 20 Minuten am Stück im alt hold Modus zu schweben. Da muss ich mir aber einen Liegestuhl zu Hilfe nehmen. Gestern hatte ich nach den 10 Minuten ein steifes Genick;-)
Werde es mir also am Nachmittag auf einen Liegestuhl neben dem Pool gemütlich machen und dem Kopter zusehen, wie er 20 Minuten am Stück im Himmel hängt. Ich werde dann die Kamera mitlaufen lassen und am Kopter montier ich die kleine Keycam. Die wiegt nicht so viel, dass das einen großen Unterschied im Verbrauch machen sollte. Sicherheitshalber häng ich den LiPo Wächter an. Sollte aber nichts passieren. Einmal habe ich den Qaud bis zum Abschalten schweben lassen. Da ist er einfach sanft (habe soft cut off eingestellt) runter gekommen. Kann man fast schon als Landen bezeichnen.

helste · Jun 15, 2012

So, vorhin mal den Liegestuhl belegt und 15 Minuten Daueraltholdschweben. War aber etwas windig. Deshalb musste ich die Position ständig halten. Handsfree war also nicht. Egal. Mit dem Höhe halten war ich aber sehr zufrieden. Die früheren Versionen hatten bei so einem Wind wie heute nur die ganze Zeit Jojo. Diesmal sah es sehr gut aus. Zu Beginn war auch etwas Auf und Ab angesagt, aber halb so wild und in einem vernünftigen Bereich.
Wollte eigentlich 20 Minuten, aber nach 15 Minuten ist es mir zu langweilig geworden. Habe den Kopter dann runter geholt und ihn dann noch 5 Minuten manuell herumschwebn lassen. Deshalb habe ich jetzt 20 Minuten gemütliches Fliegen mit 3/4 davon Baro auf den Akkus.
Habe 2 Stück mit je 2200mAh drauf. Einer ist gerade wieder voll geladen worden und da gingen exakt 1815 mA rein. Also ziemlich wenig für 20 Minuten. Wenn ich das auf 2 Akkus hoch rechne, sind das in etwa 3600mAh für 20 Minuten. Damit erreiche ich dann locker die 22 Minuten, die ich mir schon mal ermittelt habe. Falls der Stromverbrauch also durch die neue Version höher geworden sein sollte, dann spielt sich das in einem Bereich ab, denn ich nicht feststellen kann.
Diesbezüglich also schon mal alles im grünen Bereich.

Video habe ich gemacht. Ist aber ziemlich langweilig. Werde es später mal nachbearbeiten (Zeitraffer) und dann online stellen, für den Fall, dass es jemanden interessiert.

r0sewhite · Jun 15, 2012

Ich war eben auch 4 Akku-Doppelpacks (je 15 Minuten) mit der MultiWii_dev_20120606_NewBaroPID2 unterwegs. Ich habe zunächst einfach mal Helstes PIDs übernommen und wollte auf dem Feld tunen, doch das geile Wetter hat einen entscheidenden Nachteil: Auf dem Schxxx Notebook-LCD sieht man gar nichts und an der DEV funktioniert mein ConfigLCD noch nicht.

De facto ist die Höhenkorrektur eine Sensation. Ich bin teilweise minutenlang mit Abweichungen von nicht mehr als 30cm geschwebt. Am ACC Z muss ich noch etwas drehen: Die Gasschübe sorgen zwar für eine kontinuierliche Höhe, greifen aber ziemlich hart in die Regelung ein. Für smoothe Filmaufnahmen müsste auf jeden Fall der Differentialanteil verringert werden, wenn nicht auch der Integralanteil. Lieber ein paar Zentimeter mehr absacken aber dafür sanfter abfangen, als "Mikrobocksprünge".

Ohne ACC habe ich etwa 3/4 aller Flugzeit mit Baro eine extrem präzise Höhenhaltung gehabt. Allerdings kam es einige wenige Male vor, dass ein sich aufschaukelnder Jojo-Effekt eingetreten ist.

Ich hab alles auf Video dokumentiert, muss das jetzt aber erst mal schneiden und hochladen. Das dürfte wohl das langweiligste Video sein, das ich je gedreht habe.

Hut ab, Rob, das ist allererste Sahne, was Du da produziert hast.

Joachim08 · Jun 15, 2012

Hallo Tilman,

welchen Baro setzt Du ein ? Ist das der MS ?

Wollte morgen mal die neueste Firmware von Rob aufspielen.
Habe die neueste 10DOF von Drotek

Grüße

Joachim

bubu10 · Jun 15, 2012

Ich muß erstmal sagen echt tolle arbeit euch beiden echt super ,klappt das mit allen wii boards ? ich selber habe folgendes imu drinne http://www.csgshop.com/product.php?id_product=46 und ich teste schon ne weile rum mit dem baro aber klappt nicht wirklich immer gut es sackt mal stärker ab dann mal weniger stark ist sporadisch wenn das mit meiner imu auch geht mache ich sie morgen auch mal drauf und teste es.

gruß bubu10

helste · Jun 15, 2012

Ja, muss Tilman zustimmen. Rob, Du bist mein Held. Echt genial.
Ich hatte heute zwar bei etwas mehr Wind teilweise etwas größere Schwankungen, als gestern, aber alles in dem Bereich, denn der Baro halt an Genauigkeit zulässt.
Das Video werde ich morgen mal sichten. Heute mag ich nicht mehr. Vorallem besteht die Gefahr, dass ich dabei einschlafe, so langweilig wie das ist;-)

Ich überlege mir nun, ob ich dem netten Board mit der geilen Software nicht nun doch einen schöneren Rahmen spendiere, als meine Trashkopter.
Wenn jemand eine Empfehlung für einen schönen, praktischen Quadframe hat, der idealerweise auch noch faltbar ist und auf den ich 11" Props unterkriege, dann nur her damit.
Schön wäre auch einer, wo man dann die Kabeln gleich in den Auslegern verlegen kann. Und wichtig, meine DT700 Motoren müssen drauf passen.
Am liebsten wäre mir einer in Spiderform, so wie mein AQ50 Quad. Sowas wie der Flyduspider, aber halt als Quad.

r0sewhite · Jun 16, 2012

So, hier das Video. Ich hab mich noch nie so bei einem Schnitt gelangweilt. 60 Minuten Filmmaterial, in dem ein Copter auf der Stelle steht.

http://vimeo.com/44128047

@Joachim: Jep, ist eine FreeIMU v0.4.1 (erstes Sample vor dem offiziellen Release) mit MPU6050, HMC5883 und MS5611

Roberto · Jun 16, 2012

Moin, Moin!

Kaum ist man mal einen Tag nicht da, knattert es im Thread!
Das ist der blanke Wahnsinn

!
Irgendwie beneide ich euch um euer Flugwetter, hier ist Dauerregen angesagt - fliegen hätte ich heute leider sowieso nicht können. Es ist schon ein ganz schöner Schlag, wenn man den Code, der auf einer "Gummischüssel" programmiert ist, plötzlich auf einem wahnsinnig motorisierten und stylischen r0sewhite - Octocopter sieht!
@Helste: Danke, dass Du einen so aufwändigen Akkucheck durchgeführt hast! Ich habe nämlich keine Ahnung, wie ich die tatsächlich geladenen mAh meinem Lader entlocken soll. Irgendwo hier im Forum bin ich da mal über eine Anleitung gestolpert, vielleicht sollte ich einfach mal die Gebrauchsanweisung lesen....
@bubu10: "Ich muß erstmal sagen echt tolle arbeit euch beiden echt super" Das kann man wohl laut sagen! Da ich Deine 10DOF IMU nicht habe, kann ich Dir nur sagen, dass sie mit 99.999% Wahrscheinlichkeit funktionieren wird.
@r0sewhite: Danke für Dein Vertrauen in die Änderungen und Deinen ausführlichenTest mit so einem beeindruckendem Coper! Durch Deine Rückmeldung weiss ich jetzt, dass der leicht geänderte MS-Baro Code bei "Sensors" (http://fpv-community.de/showthread....o-vern%FCnftig&p=154301&viewfull=1#post154301) funktioniert.
Der Code ist bislang nur für den alten BMP ausgelegt. Wenn Du die Sensorauflösung Deines MS nutzen möchtest, brauchst Du nur folgendes zu ändern:

Code:

    BaroAlt=BaroAlt/30;                                         // Limit Resolution to 30 cm

in

Code:

    BaroAlt=BaroAlt/10;                                         // Limit Resolution to 10 cm

Dadurch werden natürlich die "P" Werte 3 mal höher, d.h. Du müsstest dann Dein P entsprechend kleiner wählen (z.B P vorher 15,0 -> dann 5,0). Die Bocksprünge müssten sich dadurch auch reduzieren lassen. Der ACC Anteil wird dadurch nicht beeinflusst. Bei dem BMP habe ich nur durch 30 cm (Sensorauflösung) geteilt, weil ich so zu viel Unfug aus der Steuerung heraus nehmen wollte. Wenn das bei Dir mit dem MS eine Verbesserung ergibt, kommt noch eine Abfrage für den MS mit rein, so dass dann automatisch auf 10cm gestellt wird.
Tja, da ich beruflich nicht viel mit Mathematik und überhaupt nichts mit Programmieren am Hut habe, gibt es leider keine echten Integral oder Differentialanteile.... in dem jetzigen Code gibt es noch nicht einmal eine Fliesskommaberechnung..nur Milchmädchen - Mathematik.... Ich plane noch ein echtes "D" für den Baro in Anlehnung an den "D-Gyro-Code" der Version 1.8. Der hat mir so gut gefallen, weil ich ihn kapiert habe.
So eine FreeIMU muss ich mir auch noch zulegen. Der MS Barocode lässt sich bestimmt auch noch, wie der ursprüngliche BMP085 Code, pimpen. Ausserdem muss es doch möglich sein mit dem HMC5883 ein rudimentäres RTH ohne GPS zu machen.

LG

ROB

Roberto · Jun 16, 2012

Ach, ja:

Ich hatte mit meinem LCD - Display (die einfache Ur-Version) auch Anlaufprobleme mit den neuen DEVs.
Der LCD Configurations code wird jetzt nämlich standardmässig nicht mitcompiliert. Die Multiwii Junx spaaren sich jedes Byte für das kommende GPS.
Wenn man sein LCD nutzen möchte, muss es in der Config.h ziemlich weit unten aktiviert werden:

Code:

....

 /**************************************************************************************/
  /***********************        LCD/OLED - display settings       *********************/
  /**************************************************************************************/

    /* uncomment this line if you plan to use a LCD or OLED */
      #define LCD_CONF

    /* to include setting the aux switches for AUX1 -> AUX4 via LCD */ //to review (activate[] is now 16 bit long)
      //#define LCD_CONF_AUX

    /* if program gets too large (>32k), need to exclude some functionality */
      /* uncomment to suppress some unwanted aux3 aux4 items in config menu (only useful if LCD_CONF_AUX is enabled) */
      //#define SUPPRESS_LCD_CONF_AUX34

    /*****************************   The type of LCD     **********************************/
      /* choice of LCD attached for configuration and telemetry, see notes below */
      #define LCD_SERIAL3W    // Alex' initial variant with 3 wires, using rx-pin for transmission @9600 baud fixed
      /* serial (wired or wireless via BT etc.) */
......

LG

ROB

Funktionieren bei Euch Kompass und Baro vernünftig ?

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Anhänge

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer