Funktionieren bei Euch Kompass und Baro vernünftig ?

[r0sewhite]

Rob, ich signalisiere hier jetzt Einsatzbereitschaft. Der große X8 hat heute wieder seinen Flyduino-Turm gekriegt und morgen werde ich erstmal mit der DEV 20120504 PIDs erfliegen und hier Feedback geben. Die Kurve des MS5611, die ich hier neulich gepostet habe, sah ja schon extrem vielversprechend aus. Leichte Höhenveränderungen der FC mit der Hand wurden durch sauber steigende oder fallende Kurven in der GUI angezeigt.

Dass Du Dich nun doch des ACCs annimmst, finde ich klasse. Ich glaube, dass in der Kombination ein großes Potential steckt, da der ACC schon von der physikalischen Logik her eine ideale Ergänzung zum Baro ist.

Jetzt hoffe ich mal, dass morgen das Wetter halbwegs brauchbar ist. Ich bin echt neugierig.

 

[El-dentiste]

Hi Roberto

ich klink mich die nächsten Tage auch mit ein.
Freu mich drauf. Hab mir nochn Kopter nur für GPS Tests gebaut und der wird auch fur deine BaroTests missbraucht

 

[Roberto]

@r0sewhite, @El-dentiste

Danke, dass Ihr auch mit einsteigen wollt!

Ich bin zu der bitteren Erkenntnis gekommen, dass meine bisherigen Versionen leider alle Scheixx sind. Sorry, wenn man so über seine eigene Arbeit urteilen muss.
Das Hauptproblem sind der BaroPID Controller und der gleitende Mittelwert und der dadurch entstehende Zeitverzug.
Ich habe jetzt einen reinen P Kontroller für den Baro programmiert mit einfachem Mittelwert zwischen dem aktuellen und dem Vorgängerwert. D.h. es kommt ein Haufen Kraut & Rüben mit in die Steuerung, der jedoch durch die Gesamtträgheit des Copters nivelliert wird. Mein kleiner Gaui macht damit in der Wohnung schon ein passables Bild, leider haben die Maurer unschöne Begrenzungen gesetz...
Ich glaube wenn ich diesen code mit meinem ACC Z Code zusammenpacke, könnte das wirklich eine Lösung werden.

Es würde dann 2 Parameter geben. Ein P für den Baro und quasi ein D für den ACC Z, der zu wilde Änderungen (von aussen&innen) unterdrückt.

LG

ROB

 

[r0sewhite]

Okay, das kriegen wir alle zusammen schon hin. Ich hab heute den erste Testflug mit der Multiwii abbrechen müssen: einer der neu getauschten Smartdrones setzt schon wieder ständig aus. Nach ner halben Minute schaltet der Regler einfach ab. Aber zumindest habe ich mit der MultiWii eine richtig gute Ausgangsbasis: Der X8 steht selbst bei Motorausfall wie eine eins. Nicht einmal Drift. Würde man nicht hören, dass der andere Motor an dem Arm auf einmal fast doppelt so schnell läuft, würde man nichts merken. Soviel zur Stabilität vom WKM.

Morgen wird der Motor nochmal ersetzt und dann wird getestet.

 

[helste]

Das hört sich ja gut an.
Ich bin in der Zwischenzeit auf jemanden gestoßen, der auf der Uni an einem Kopterprojekt mit Arduino arbeitet. Hat leider momentan nicht viel Zeit, aber ab Ende Juni, Anfang Juli will er sich das mal ansehen.
Vielleicht kann der ja auch mal helfen.

 

[Roberto]

Erster Test garnicht übel.
Die Kurve sieht zwar jetzt zum Abgewöhnen aus, aber irgendwie scheint es zu gehen. Der I2C Baroauslesecode macht immer noch Fehler, sobald ein RC Signal anliegt. Ob da irgendwelche Interrupts dazwischen gehen? Z.zt Teile ich die Werte durch die potentielle Sensorauflösung (BMP 30 cm). Das bringt etwas Ruhe in die Sache. Ich habe jetzt noch einen 3. Parameter hinzu genommen. Die Abwärtsbewegungen können jetzt prozentual abgeschwächt werden. Dafür habe ich das "I" zweckentfremdet. I = 0.100 bedeutet, das Gaswegnehmen kommt zu 100% durch.
@Helste: Der soll gleich den ganzen Code "rüberwachsen" lassen........mit Baro!
@rOsewhite: Lass Dir Zeit!

LG

ROB

 

[helste]

Ja, werde versuchen ihn für das Projekt zu begeistern.

 

[ra-home]

Hallo ich lese hier ja schon die ganze Zeit mit und hoffe, das die Höhenreglung noch weiter verbessert wird.
Bezüglich der ACC-Reglung ist mir auch noch etwas eingefallen und hoffe jetzt mal, das meine Gedanken nicht ganz so falsch sind.
Wenn man ACC kalibriert, einspicht das ja den Wert der Erdbeschleunigung. Dieser sollte ja im Idealfall immer gleich bleiben.
Wird der Copter durch eine Kraft nach unten Beschleunigt sinkt der Wert. Beim anschließenden Abfangen steigt der Wert über die Erdbeschleunigung. Diese Beschleunigung (durch mehr Motorleistung) muss so lange bestehen bis der Copter sich nicht mehr nach unten bewegt. Danach müßte die Gasstellung wieder zurück auf die Schwebekraft gestellt werden.
Wenn man nun die einzelen Beschleunigungswerte, von kalibrierten ACC abzieht und immer die Summe aus allen Werten bildet sollte immer null herauskommen.
Betrachet man noch die Zeit in der die Beschleunigung wirkt, könnte man auch noch den Weg, den der Copter zurückgelegt hat mit einbeziehen um ihn wieder auf Ausgangshöhe zu bringen.
Ich hoffe mal das ich jetzt nicht zuviel Müll geschrieben habe und man vielleicht etwas davon verwenden kann.

Rene

 

[Roberto]

@ra-home:

Du hast vollkommen Recht!
Mit genauen und verlässlichen ACC Werten braucht man im Prinzip überhaupt kein Barometer. Die Idee lässt sich natürlich noch weiter entwickeln zu einem Trägheitsnavigationssystem, dass z.B bei Ausfall des GPS ein RTH über den bis dahin zurückgelegten, vektorisierten Weg (ACC & GYRO) berechnen kann + Abkürzungen. Bei perfekten ACC & Gyrowerten würde der Copter wie angenagelt in der Luft stehen können , ohne GPS/Baro/Magnetfeldsensor. Die ACCZ Werte bei dem jetzigen Multiwii Code sind leider zu ungenau. Alexmos hat in seinem Mod die Auflösung erhöht und die Bewegungsvektoren auf die Z Achse projiziert. Das überschreitet aktuell noch deutlich meinen Horizont. Und offensichtlich auch den Horizont meiner Sensoren (WMP&BMA020), da der Code dort einfach nicht funktioniert. Im Multiwii Forum versucht "Magnetron" alle Probleme mit seinem Moving Average Code (getEstimatedAltitude nach Magnetron: http://www.multiwii.com/forum/viewtopic.php?f=8&t=1290&p=11094#p11094) zu erledigen. Die Magnetron Variante den ACC zu integrieren hat bei mir überhaupt nichts gebracht.

LG

ROB

P.s.: Ich lade gleich mal meine neue Version mit neuem "P" Kontroller und ACC Z hoch.

 

[Roberto]

Moin, Moin!

Da das Wetter mich die letzten Tage vom Testen abgehalten hat (Regen&Wind), kommt hier eine Version die nur bei starkem, böigem Wind getestet ist. Ich habe zumindest gemerkt, dass er sich gegen den Wind durchsetzen wollte. Ob und wie es bei wenig Wind funktioniert, kann ich noch nicht sagen. Da der Code aber zu funktionieren scheint, wollte ich ihn Euch nicht vorenthalten. Die Basis ist die aktuelle MultiWii_dev_20120606. Die config.h ist nicht verändert. Die neue Dev macht bei mir zur Begrüssung immer einen einzigen I2C Fehler, ich denke, dass ist eine Fehlanzeige. Der Barocode wird jetzt bei jedem Durchlauf ausgeführt, wenn ihr mehr als GYRO/ACC & BARO habt, achtet auf die Cycletime. Ab wieviel ms ein Copter nicht mehr anständig regelt und fliegt, kann ich leider nicht sagen. Mein Tri ist mit WMP und nunchuk auf 6 bis fast 7ms gekommen und war sehr gut zu fliegen. Dieser Code braucht mit WMP&BMA020&BMP085 ca. 4ms.
Änderungen:
1.: Der Code bezieht jetzt den ACC mit ein und bekämpft schnelle, starke Höhenänderungen. Dieses funktioniert nur im LEVEL Mode.

2.: Die Barokurve ist jetzt nur noch eine Linie, da EstAlt nicht mehr in cm, sondern in 1/30 cm (BMP Sensorauflösung) bestimmt wird. EstAlt wird momentan noch nicht von GPS etc verwendet, so dass ich diese Zukunfts - Inkompatibilität zunächst belassen habe.

3.: Der Code zum Auslesen der Barosensoren wurde für den BMP, und analog dazu auch für den MS geändert. Diese Version ist nur auf dem BMP085 getestet. Die Höhenauflösung ist daher für beide Sensoren zunächst auf 30cm festgesetzt. Sollte es mit dem MS Probleme geben, kann ich den alten MS Code wieder herstellen.

4.: Die, in der GUI verstellbaren, ALT "P I D" haben jetzt ganz andere Bedeutungen!

Grundsätzlich: Die in der Gui sichtbaren "Kommawerte" sind in der internen Weiterverarbeitung immer ganzzahlige Werte. Z.B I=0,100 ist tatsächlich 100, P=5,0 ist 50 etc.

P: (Default:5,0) Nur noch mit P wird die Stärke der Baroregelung eingestellt. Intern werden die Werte durch "50" geteilt, d.h. bei einem P von "5,0" kommt der errechnete Wert zu 100% durch. Da dieser errechnete Wert auf einem Barowert/30 basiert, dürften P Werte von unter "5,0" eigentlich witzlos sein. Ich schätze, ab P von "10,0" wird die Sache interessant.

I: (Default:0,100) Das I ist kein I mehr! In der Regelung werden positive und negative Werte errechnet, die dem aktuellen Gaswert hinzugefügt werden. Die Überlegung ist nun: Ein Kopter wird durch die Erdanziehung vermutlich leichter fallen als steigen können, d.h. negative Gaswerte könnten sich stärker bemerkbar machen. Mit dem neuen "I" könnt Ihr jetzt die Auswirkungen negativer Gaswerte prozentual abschwächen oder auch steigern. Standardmässig steht der Wert auf "0,100" d.h. 100% d.h. alle errechneten Gasreduktionen werden voll durchgegeben. Will man 20% weniger Gasreduktion ist I = "0,80", will man 20% mehr Gasreduktion ist I = "0,120". Ich bin gespannt, ob das tatsächlich einen praktischen Nutzen hat.
Ach ja, wer aus Versehen I auf 0 stellt, bekommt eine Regelung nur noch nach oben .

D: (Default:20) Auch das D ist kein D mehr! Dieser Wert bezeichnet die Stärke der ACC Z Gegenwehr, gegenüber plötzlichen, starken Höhenänderungen. Dabei ist es egal, ob die Höhenänderung von aussen (Wind) oder von innen (Regelung) kommt. (Vielleicht sollte ich die "Gegenwehr" gegenüber internen Steuerbefehlen reduzieren/abschalten?)
Diese Funktion wird, weil es einfacher ist, nur bei eingeschaltetem "LEVEL" Modus aktiv. (d.h. Baromodus & Levelmodus müssen eingeschaltet sein). Der Standardwert ist 20. Bei D="40" werden 100% des errechneten Wertes an die Motoren durchgegeben, was ich im Handtest schon als zu stark empfand. Ein D von 0 schaltet die ACC Z Regelung ab. D.h. auch im Baromodus+Levelmodus kein ACCZ Einfluss mehr. Umgekehrt kann man auch versuchen nur mit dem ACC die Höhe zu halten d.h. P=0.

5.: Einloggen einer neuen Höhe:
Am Besten mit dem Baroschalter! Den Copter ruhig halten und Schalter umlegen. Man kann den Regelkreis jedoch sofort durch stärkere Gasknüppelbewegungen(+-"40") überspringen. Es würde dann bei Überschreiten einer Höhenänderung von ca 1m sofort (Abfragefrequenz ca. 2Hz) wieder eine neue zu haltende Höhe definiert, nur wenn das im starken Steigen oder Sinken ist, dürfte das nicht viel bringen. Also besser mit dem Baroschalter arbeiten.

Freiwillige vor! Ich bin sehr gespannt auf euer Feedback! Ausserdem brauche ich anständiges Wetter zum selber - testen!

LG

ROB

 

[Roberto]

Jetzt kommen die Code - Änderungen:

1: Änderungen im Hauptprogramm:
==========================

Neue globale Byte Variablen:

static uint8_t newbaroalt=0;
static uint8_t newestalt=0;

Der geänderte "Task scheduler"

...
    static uint8_t taskOrder=0; // never call all functions in the same loop, to avoid high delay spikes
    switch (taskOrder++ % 3) {
      case 0:
        #if MAG
          Mag_getADC();
        #endif
        break;
      case 1:
        #if GPS
          if(GPS_Enable) GPS_NewData();
        #endif
        break;
      case 2:
        #if SONAR
          Sonar_update();debug3 = sonarAlt;
        #endif
        #ifdef LANDING_LIGHTS_DDR
          auto_switch_landing_lights();
        #endif
        break;
    }
...

Der geänderte "was ist zu tun, wenn Baroschalter umgelegt ist" Code:

  #if BARO
    Baro_update();                                                                   // Do Baro every time!
    getEstimatedAltitude();

    if (rcOptions[BOXBARO])
     {
      if (newestalt==1){                                                             //is there a new barovalue?
        newestalt=0;
        if (abs(EstAlt*30 - AltHold*30) >100 && abs(rcCommand[THROTTLE] - initialThrottleHold) >40) baroMode = 0; // so that a new althold reference is defined
       }
      if (abs(rcCommand[THROTTLE] - initialThrottleHold) <40){                       // If Stick movement exceeds 40 - dont do BAROPID
        rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
        rcCommand[THROTTLE] = constrain(rcCommand[THROTTLE],MINTHROTTLE+1,MAXTHROTTLE-50);
       }
     }
  #endif

2: Änderungen bei "IMU"
==================
Komplett neue getEstimatedAltitude()

///////////////////////////////////////////////
//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)/50;               // P of Baro a P of 5 in the GUI means 50
    BaroP = constrain(BaroP,-150,+150);                         // Limit Baro P to +/- 150

    // ACCZ
    if (rcOptions[BOXACC]){                                     // Only do ACCZ in Level Mode
      ACCZD -= (int32_t)conf.D8[PIDALT]*(abs(AccZHighest)+abs(AccZLowest))*(AccZHighest-abs(AccZLowest))/40; // conf.D8[PIDALT] Is scalefactor for ACCZ, if it is = 40 then this is 1:1 Passthrough
      ACCZD = constrain(ACCZD,-150,+150);                       // Limit ACC Z to +/- 150
     }

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

3: Änderungen unter "Sensors"
=======================

BMP085:

void Baro_update()
{
 if (micros() < bmp085_ctx.deadline) return; 
 TWBR = ((16000000L / 400000L) - 16) / 2;                                // change the I2C clock rate to 400kHz, BMP085 is ok with this speed
 switch (bmp085_ctx.state)
 {
  case 0: 
   i2c_BMP085_UT_Start(); 
   bmp085_ctx.deadline=micros()+4500-1; 
   bmp085_ctx.state++;
   break;
  case 1: 
   i2c_BMP085_UT_Read(); 
   i2c_BMP085_UP_Start(); 
   bmp085_ctx.deadline=micros()+13500-1; 
   bmp085_ctx.state++;
   break;
  case 2: 
   i2c_BMP085_UP_Read(); 
   i2c_BMP085_Calculate(); 
   BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 4433000.0f; //centimeter
   newbaroalt=1;
   bmp085_ctx.state=0;
   break;
 } 
}

MS561101BA:
(Lässt sich bestimmt noch optimieren!)

void Baro_update() {
  if (micros() < ms561101ba_ctx.deadline) return; 
  TWBR = ((16000000L / 400000L) - 16) / 2; // change the I2C clock rate to 400kHz, MS5611 is ok with this speed
  switch (ms561101ba_ctx.state) {
    case 0: 
      i2c_MS561101BA_UT_Start(); 
      ms561101ba_ctx.deadline = micros()+10000-1; //according to the specs, the pause should be at least 8.22ms
      ms561101ba_ctx.state++;
      break;
    case 1: 
      i2c_MS561101BA_UT_Read(); 
      ms561101ba_ctx.state++;
      break;
    case 2: 
      i2c_MS561101BA_UP_Start(); 
      ms561101ba_ctx.deadline = micros()+10000-1; //according to the specs, the pause should be at least 8.22ms
      ms561101ba_ctx.state++;
      break;
    case 3: 
      i2c_MS561101BA_UP_Read();
      i2c_MS561101BA_Calculate();
      ms561101ba_ctx.deadline = micros()+4000-1;
      BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 4433000.0f; //centimeter
      newbaroalt=1;
      ms561101ba_ctx.state = 0;
      break;
  } 
}

LG

ROB

 

[IntruderEvil]

Boah das ist fies. Ich hab alles Wii Platinen mit Baro verscheppert - Kann also net testen.

 

[helste]

Nachdem ich gestern meinem Wiikopter die Ausleger massiv gekürzt habe und dann Mühe hatte die PID Werte so einzustellen, dass er vernünftig flog (dev0528), war ich so verwegen und habe nun die neue Dev rauf und mal die Werte von gestern übernommen. Das Teil ist unfliegbar. Zuckt nur so rum. Auch mit Standardwerten geht da nix.
Sowohl im Acromode, als auch im Level Mode ist der Kopter kaum zu kontrollieren. Am ärgsten ist, dass er so zuckt. Habe gar noch nicht auf Baro geschalten.
Kann also damit nicht testen. Muss erst die Ursache für das komische Verhalten finden.
Dazu habe ich aber jetzt keine Zeit, weil ich dann zu tun habe.

 

[martinez]

Spannung!

Guten Morgen!

Das ist echt so was von spannend ich kannst kaum erwarten neue Codes zu testen....

Eine kleine Offtopic Frage:
Warum bekomm ich bei der DEV 20120528 ein Fehler beim Kompilieren, ist das bei euch auch so? Die DEV 20120606 geht wieder.... Hab die Zipps auch schon mal neu geladen, kein Erfolg.

Fehler sieht so aus:

 

[Roberto]

@martinez: Du hast in der config.h die "#define INFLIGHT_ACC_CALIBRATION" aktiviert, die Dev hat da offensichtlich eine Macke, die seit dem hier http://code.google.com/p/multiwii/source/detail?r=845 gefixt ist. Ich bin auch schon heiss aufs Testen.

@Helste: Mein aufrichtiges Beileid zu Deinem Crash! Moment - Die Kürzung war absichtlich! Wahrscheinlich ist er pünktlich zum passenden Testwetter wieder einsatzklar! Die neue Dev fliegt bei mir mit den gleichen PIDs wie die alte. Vielleicht wurde etwas an Deinen Sensoren im code geändert?

@ IntruderEvil: So was verkauft man doch nicht!


LG

ROB

 

[helste]

Roberto, danke für das Beileid, aber dem Kopter geht es gut. Er ist nur nahezu unfliegbar. Das heißt nicht, dass er gecrasht ist.
Wenn er abhebt, dann beginnt er zu zucken und zu wobbeln. Habe echt Mühe ihn halbwegs vernünftig unter Kontrolle zu haben.
Muss mal nachher wieder die 0528er Dev rauf und schauen, ob es damit zu tun hat.
Habe aber erst am späteren Nachmittag Zeit. Muss jetzt zum Sportplatz, weil meine Jungs (ich trainiere die U10) heute das entscheidende Spiel um die Meisterschaft haben. Wenn wir gewinnen, sind wir Meister. Es geht gegen die U10 des Bundesligavereins SV Mattersburg. Auswärts haben wir sie 11:3 geschlagen, also bin ich guter Dinge, aber man weiß ja nie. Der Ball ist bekanntlich rund.

Melde mich also am Abend wieder, wenn ich Zeit hatte mich um meinen zickigen Quad zu kümmern.
Wenn er so eingekürzt nicht mag, dann verpasse ich ihm einen neuen Rahmen. Habe eh ein paar gesehen, die mir gefallen würden.

 

[Wollez]

@helste Das hatte ich bei mir auch. Schau mal ob einer von diesen Werten aktiviert ist:

/**************************************************************************************/
/******** Gyro filters ********************/
/**************************************************************************************/

/********************* Lowpass filter for some gyros ****************************/

/* ITG3200 & ITG3205 Low pass filter setting. In case you cannot eliminate all vibrations to the Gyro, you can try
to decrease the LPF frequency, only one step per try. As soon as twitching gone, stick with that setting.
It will not help on feedback wobbles, so change only when copter is randomly twiching and all dampening and
balancing options ran out. Uncomment only one option!
IMPORTANT! Change low pass filter setting changes PID behaviour, so retune your PID's after changing LPF.*/
//#define ITG3200_LPF_256HZ // This is the default setting, no need to uncomment, just for reference
//#define ITG3200_LPF_188HZ
//#define ITG3200_LPF_98HZ
//#define ITG3200_LPF_42HZ
//#define ITG3200_LPF_20HZ
//#define ITG3200_LPF_10HZ // Use this only in extreme cases, rather change motors and/or props

/* MPU6050 Low pass filter setting. In case you cannot eliminate all vibrations to the Gyro, you can try
to decrease the LPF frequency, only one step per try. As soon as twitching gone, stick with that setting.
It will not help on feedback wobbles, so change only when copter is randomly twiching and all dampening and
balancing options ran out. Uncomment only one option!
IMPORTANT! Change low pass filter setting changes PID behaviour, so retune your PID's after changing LPF.*/
//#define MPU6050_LPF_256HZ // This is the default setting, no need to uncomment, just for reference
//#define MPU6050_LPF_188HZ
//#define MPU6050_LPF_98HZ
//#define MPU6050_LPF_42HZ
//#define MPU6050_LPF_20HZ
//#define MPU6050_LPF_10HZ
//#define MPU6050_LPF_5HZ // Use this only in extreme cases, rather change motors and/or props



wenn ja, dann deaktiviere ihn. Das hat meiner nicht gemocht.

Gruß Wolfgang

 

[Roberto]

@Helste: Du warst schneller, als ich meinen Post ändern konnte.. Ich drücke Dir, und Deinem Team alle Fussballdaumen!
@Wollez: Das ist eine gute Idee! Ich weiss, Du meinst das Gegenteil, aber vielleicht hat er durch die Kürzungen jetzt Vibrationen, die man so ggf. filtern kann.

LG

Rob

 

[martinez]

@martinez: Du hast in der config.h die "#define INFLIGHT_ACC_CALIBRATION" aktiviert, die Dev hat da offensichtlich eine Macke, die seit dem hier http://code.google.com/p/multiwii/source/detail?r=845 gefixt ist. Ich bin auch schon heiss aufs Testen.

LG

ROB

Ah, okay. Stimmt, ohne "#define INFLIGHT_ACC_CALIBRATION" geht die Version
Ich hab schon gedacht ich spinne.... Die Funktion "Inflight ACC Cal." ist "subber" cool


Das Wetter ist einfach nur doof hier in Bayern

 

[helste]

Danke fürs Daumendrücken. Hat geholfen. Wir haben 13:0 gewonnen. Jetzt sind wir Meister.

Aber zurück zum Multiwii.
Ich habe normalerweise #define ITG3200_LPF_42HZ aktiviert. Habe ich aber vergessen zu aktivieren. Bin mir aber nicht sicher, ob das noch passt. Jedenfalls ist aktuell gar kein LPF aktiviert. Werde mal mit 188Hz anfangen und mich langsam nach unten vorarbeiten bis es passt. Durch die Kürzung hat es bestimmt eine Änderung in den Vibrationen gegeben. Habe immerhin 11cm je Ausleger weggeschnitten.