Funktionieren bei Euch Kompass und Baro vernünftig ?

helste

Erfahrener Benutzer
Rob, das kann ich verstehen. Irgendwann will man den Code nicht mehr sehen. Du hast das aber eh gut hinbekommen.
Möchte mich noch herzlich bei Dir für Deine Mühe bedanken.
Heute ist Flugwetter. Werde dann mal alle meine Kopter einpacken und ein paar Runden drehen.
 

Joachim08

Erfahrener Benutzer
komme gerade vom Schweben. Leider tritt der Effekt mit der neuesten Dev von Rob immer noch auf dass der
Kopter nahezu zwei Meter absackt. Nach oben regelt er gut...
Keine Ahnung wie ich das verbessern kann. Der Sensor ist auch gut eingepackt....
 

Paraglider58

Erfahrener Benutzer
Hallo helste,

Das kommt darauf an was man will. Ich habe mir ein fertiges APM1 mit Baro, Mag, GPS gekauft und zusätzlich noch Sonar und OSD dazu genommen. Das OSD habe ich noch nicht ausprobiert. Muss da erst meine FPV Teile drauf montieren.
ich bin auch am testen des Sonar. Merke da aber keinen Unterschied. Kannst du mir behilflich sein? Was muß alles im Code geändert werden dass Sonar erkannt wird bzw. funzt?

Gruß Paraglider58
 

helste

Erfahrener Benutzer
Paraglider, ich habe das Sonar am APM1 und nicht am MultiWii. Reden wir da eh von der selben FS?
Ich habe da im Code gar nix geändert. Lediglich im Missionplanner die Verwendung von Sonar und das entsprechende Sonar ausgewählt. Dann sollte das klappen.
 

Paraglider58

Erfahrener Benutzer
Gerade komme ich von der Wiese. Hab meine Kopter wieder mit der Drotek 10DOF mit MPU6050 getestet. Gut geflogen, aber immer noch Höhenunterschiede von ca. 2mtr. waren ohne die Hände an der Steuerung zu haben, zu bemerken. Ich denke das da auch der Fallwind eine bedeutende Rolle spielt. Wenn der Seitenwind etwas stärker war, war der Höhenunterschied gering. Ohne Seitenwind stärker. Man müßte das mal in der Halle ausprobieren wo es 100% Windstill ist.

Gruß Paraglider58
 
Gibt es jemanden der mit einem BMP085 eine gescheite Höhenregelung hinbekommen hat?? Ich habe einen BMP in einen verschlossen Eimer betrieben und war entsetzt das ich auch dort Schwankungen in der Höhe bis zu 150cm min-max gemessen bekommen habe. Damit scheint dieses Teil nicht brauchbar zu sein.

Im MikrokopterForum hat sich ein Nutzer die Mühe gemacht und den BMP mit einen MPXA6115A verglichen. Die Vergleichsmessungen waren vom Ergebniss erschreckend. Der Link dazu >> http://forum.mikrokopter.de/topic-17082.html

Das sagt alles über den BMP. Alles Geglätte der Sensorwerte ist zwecklos. Der Höhenfehler des Sensors bleibt. (Oder der Messwert wird so träge das er zur Regelung nicht mehr taugt) BTW >> EstAlt ist der BaroAlt nach einem Tiefpassfilter, also ein schon geglätteter Wert. Schon in originalen Version.

@ALL >> Mit welchem Sensor wurden gute Regelungen hinbekommen?

Gruß DeaconBlues

@Paraglider >> was fliegst du für eine Tüte?
 

Wollez

Erfahrener Benutzer
Gibt es jemanden der mit einem BMP085 eine gescheite Höhenregelung hinbekommen hat?? Ich habe einen BMP in einen verschlossen Eimer betrieben und war entsetzt das ich auch dort Schwankungen in der Höhe bis zu 150cm min-max gemessen bekommen habe. Damit scheint dieses Teil nicht brauchbar zu sein.

Im MikrokopterForum hat sich ein Nutzer die Mühe gemacht und den BMP mit einen MPXA6115A verglichen. Die Vergleichsmessungen waren vom Ergebniss erschreckend. Der Link dazu >> http://forum.mikrokopter.de/topic-17082.html

Das sagt alles über den BMP. Alles Geglätte der Sensorwerte ist zwecklos. Der Höhenfehler des Sensors bleibt. (Oder der Messwert wird so träge das er zur Regelung nicht mehr taugt) BTW >> EstAlt ist der BaroAlt nach einem Tiefpassfilter, also ein schon geglätteter Wert. Schon in originalen Version.

@ALL >> Mit welchem Sensor wurden gute Regelungen hinbekommen?

Gruß DeaconBlues

@Paraglider >> was fliegst du für eine Tüte?
Hallo DeaconBlues,

ja, ich habe mit dem BMP085 gute Erfahrungen gemacht. Er wird bei mir auch NICHT abgedeckt! Man muss sich unbedingt die Mühe machen, die PID Werte sauber einzustellen. Auch der i2c muss Top sein. Wenn da Störungen drauf sind, kann der Sensor nichts dafür. Bei meinem Controller ist der BMP auf der Unterseite und nicht oben. Dadurch bekommt er keinen, bzw. nur ganz wenig, Wind ab. Auf solche Auswertungen, die irgendjemand in irgendwelchen Foren veröffentlicht, würde ich mich nicht versteifen. Der ADXL345 wurde auch überall schlecht gemacht, doch er ist absolut Top und kann es auch mit den anderen aufnehmen. Es war die ganze Zeit nur ein Zahlendreher im Code. Alle haben ihn nur schlecht gemacht, statt sich mal den Code anzuschauen.

Unbedingt erst die Sensoren 100 % sauber einstellen. Erst Gyro, dann ACC, dann Mag und danach den Baro. Wenn diese sauber eingestellt sind, wirst Du auch mit dem BMP085 zufrieden sein.

Gruß Wolfgang

P.s. ich bin noch nicht dazugekommen den Code zu testen. Werde ich aber in den nächsten Tagen machen
 

helste

Erfahrener Benutzer
Was den Test in einem windfreien Raum anbelangt, so wird man da sicher gute Ergebnisse bekommen. Wenn ich bei mir im Haus den Baro einschalte, dann schwankt da gar nix. Tut es auch nicht, wenn ich den Baro ausschalte und mich mit dem Gashebel spiele um ihn auf eine Schwebeposition zu bekommen. Auch da bleibt er auf konstanter Höhe. Zumindest solange ich ihn einfach nur schweben lasse. Wenn man den Kopter vor und zurück oder links und rechts fliegt oder ihn um die Gierachse dreht, dann muss man die Höhe nachregeln. Das sollte der Baro machen.
Was die Höhenhaltung im Freien bei Wind anbelangt, glaube ich fast, dass die Erwartungshaltung da zu hoch ist. Man sollte sich nicht von de Werbevideos von Naza und Wookong zu sehr beeinflussen lassen. So ein Video kriege ich auch hin, wenn ich mir genügend Zeit dafür nehme.

Wenn der Kopter in einer Höhe von z.B. 20m dann 2 m in der Höhe schwankt, finde ich das nicht für so schlimm. In niedriger Höhe kann man ja mit einem Sonar bessere Ergebnisse erzielen. Der Vorteil von Sonar ist auch, dass er immer den Abstand zum Untergrund misst und sich daher auch der Geländeform anpassen kann. Kommt ein Hügel, hält er den Abstand zum Untergrund. Das kann der Baro naturgemäß nicht.
Eine Kombination Sonar für Bodennähe und Baro für Höhen, die außerhalb der Reichweite des Sonars sind, wird wohl die beste Lösung sein.

Was nun wirklich die technisch machbare Genauigkeit ist, wäre natürlich schon interessant. Wenn man nicht genau weiß, was möglich ist und was nicht, wird man nie wissen, ob man sich nicht zu viel erwartet oder ob man noch mehr Genauigkeit raus holen kann.
 

martinez

Erfahrener Benutzer
Ich biete hier zum Download den Mod für die DEV 20120504 an. Ich habe genau diese Version getestet und sie fliegt gut!
Ich kann vor der 522 nur warnen.
Ohne Testmöglichkeit, aber auf besonderen Wunsch von Wollez gibts die I2C_GPS_NAV-MultiwiiDev-NAVr33 als Mod Version.

LG

ROB

Ps.: Ich kann den schxxx Baro Code nicht mehr sehen - jetzt wird geflogen!
Hi,

ich hab heute dein MOD auf mein Quad (Hab den Rahmen von HK http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=22781 ) draufgespielt und war eben auf der Wiese.

Man das funktioniert doch richtig gut!!
Auf ca. 5m Höhe kann man mit ACC und BARO super hin und her fliegen. Ein Eingriff auf den Gaskanal ist nicht nötig. Der Copter schwankt ca. 1m, das ist doch super!
Was auch bedeutet besser geht: Die Höhe ändern, dass war meiner Meinung ohne den MOD nur ohne den BARO möglich.
Vielen, vielen Dank Rob, dass du dir so viel Arbeit gemacht hast!!!!


Ich häng mal eben noch meine PID Werte an, vielleicht hilft es jemand!
(Zu mein BARO: Ich hab den BMA085. Den eigentlichen Sensor habe ich mit sehr dichten schwarzen Schaumstoff fast "Luftdicht" gemacht. Sodass wirklich nur der Luftdruck und nicht irgend ein Luftstrom ankommt.)
 

Anhänge

helste

Erfahrener Benutzer
Sag mal, wie bist Du denn mit dem HK Rahmen zufrieden? Sieht nicht schlecht aus. Ich frage mich nur, ob die Ausleger stabil genug in der Centerplate sitzen. Vielleicht kannst ja mal ein paar Worte über den Rahmen verlieren.
 

Joachim08

Erfahrener Benutzer
... wenn das mit dem BMA Sensor so gut funktioniert muß es im Sketch vielleicht irgendwo eine Möglichkeit geben die Sache für den MS5611 weiter zu optimieren.
Hat vielleicht jemand (Roberto ? :) ) einen Tipp ?

Grüße

Joachim
 

martinez

Erfahrener Benutzer
Sag mal, wie bist Du denn mit dem HK Rahmen zufrieden? Sieht nicht schlecht aus. Ich frage mich nur, ob die Ausleger stabil genug in der Centerplate sitzen. Vielleicht kannst ja mal ein paar Worte über den Rahmen verlieren.
Ich werde die nächsten Tage noch eine kleine Review zu den Rahmen hier im Forum machen....
Das vorweg: Für den Preis ist das Teil TOPP!
Die Alu- und Carbonteil sind sehr gut verarbeitet.
Der Rahmen ist steif, das wichtigste ist dass man die Schrauben richtig fest anzieht. Sind diese nicht 100% fest ist er nicht steif. Und dass ist das Problem bei den Rahmen. Die Senkschrauben haben ein Kreuzkopf, der erstens leicht abrutscht und 2. ist es nicht möglich diese Schrauben mit einen normalen Schraubenzieher so fest wie NÖTIG zu ziehen.
Ich habe dazu eine Ratsche mit Kreuzbit benutzt.
Ich werde mir aber noch passende Schrauben mit IMBUS oder TORX Kopf besorgen.

Gruß
Martin
 

Roberto

Erfahrener Benutzer
@Danke an alle für euer Feedback!
Ich bin froh, dass es doch bei vielen jetzt auch besser läuft!
@Joachim:
Diese Änderung ist nicht für ein bestimmtes Barometer. Wie man die Baros jetzt selbst optimiert, weiss ich leider nicht genau.
Wenn Du weiterhin abartige Schwankungen hast, kann es auch an dem hohen I (0,045 standardmässig für YAW!) für Yaw und ACC liegen. Früher gabs per Standard ein I von 0 auf YAW! Die Yaw Achse wird häufig unterschätzt. Bei meinen beiden MWII Coptern (Quad&Tri) reichen für Yaw P Werte von 5-6 und I Werte von 0-0,014 vollkommen aus. Versuche doch zunächst die Yaw Werte deutlich herunter zu drehen, dann teste den Baro zunächst nur im Gyromodus. Jetzt kannst Du die Baro PIDs ggf. ändern.

LG

Rob

EDIT:29.5.12 6Uhr: Ich habe eben noch einen logischen Ablauffehler in der Baro Routine (IMU & Sensors) gefunden. Betrifft BMP und MS. Fehler beseitigt (und Auflösung vom BMP 1 Stufe höher geschaltet) und ich sehe jetzt endlich eine SAUBERERE Barokurve, also nicht mehr dieses Megagezackel. Da zählten wieder 2 timer fröhlich aneinander vorbei mit dem Ergebnis, dass die Auswertroutine entweder doppelte Barowerte einbezogen hat, oder einige garnicht mitbekommen hat. Ich habe es jetzt so gemacht, dass die Harware-Baroausleseroutine den Takt vorgibt und die Auswertroutine keinen Timer mehr hat - d.h. die Auswertroutine wird erst tätig, wenn es auch wirklich einen neuen Wert von der Hardware gibt, und nicht mehr auf eigene Faust. Wenn ich jetzt noch die Auswertroutine "getEstimatedAltitude()" komplett verstehen würde...

Mein altes Laptop kann leider nur in Zeitlupe den Bildschirm aufzeichnen (5FPS). Wer bei dieser Baro Kurve (BMP085) keine feuchten Augen bekommt, dem kann ich auch nicht mehr helfen....
http://youtu.be/tYam_n6IBaw
 

Joachim08

Erfahrener Benutzer
äh 6 Uhr früh ? Sag mal Rob wann schläfst Du ? :)

Die Kurve sieht allererste Sahne aus ! Ich hoffe Du stellst die Änderung ein,
daran sind bestimmt viele interessiert !

Super Rob !!!!
 

Roberto

Erfahrener Benutzer
@Joachim08
äh 6 Uhr früh ? Sag mal Rob wann schläfst Du ?

Von 0100 - 0530 war sehr knapp heute - habe mich durch den Tag geschleppt.

So jetzt Butter bei die Fische.
Die Baros (BMP & MS) haben verschiedene Modi mit verschiedenen Auflösungen. D.h wenn ich eine bessere Höhenauflösung will, braucht der Sensor mehr Bedenkzeit, d.h ich kann ihn weniger häufig/Sek abfragen, die Mittelwertberechnung (ich glaube, MWII macht einen gleitenden "moving average" Mittelwert) bringt noch mehr Zeitverzögerung in die Regelung.
1. Fehler der aktuellen Version:
In MWII Version 1.9 wurde der BMP in den Ultra high resolution Modus geschaltet, d.h. 25cm Genauigkeit, 25,5ms Latenz - dabei wurden in der Auswertroutine 25 ms angenommen. Ab Version 2.0 wurde vernünftigerweise auf den high resoltution Modus zurückgeschaltet d.h. 30cm Genauigkeit, 13,5ms Latenz, um schneller mehr Werte zu bekommen. Gute Idee, doch leider wurde die Auswertroutine bei 25ms, also 40Hz Auswertfrequenz belassen. D.h. ab Version 2.0 gibt es für den BMP nur 5 cm weniger Genauigkeit!
2.Fehler aller Versionen ab 1.9:
Die Auswertroutine holt sich alle 25ms neue Daten, egal ob es schon neue gibt oder nicht. Dazwischen liegende Werte (ca alle 14ms) gehen vollkommen an ihr vorbei.
Das sieht dann so aus (IMU):

Code:
#define UPDATE_INTERVAL 25000    // 40hz update rate (20hz LPF on acc)
#define INIT_DELAY      4000000  // 4 sec initialization delay
#define BARO_TAB_SIZE   40

void getEstimatedAltitude(){
  uint8_t index;
  static uint32_t deadLine = INIT_DELAY;

  static int16_t BaroHistTab[BARO_TAB_SIZE];
  static int8_t BaroHistIdx;
  static int32_t BaroHigh,BaroLow;
  int32_t temp32;
  int16_t last;
  
  if (currentTime < deadLine) return;
  deadLine = currentTime + UPDATE_INTERVAL;
Das Problem lässt sich leicht umgehen, indem man im Hauptprogramm eine Variable definiert (z.B newbaroalt) die von "Sensors / Baro_update" einfach auf 1 gesetzt wird, wenn es wieder einen neuen BaroAlt Wert gibt, der dann weiter verarbeitet werden kann. Nach der Verarbeitung muss man die Variable natürlich wieder auf 0 setzten, um einen neuen Wert zu erkennen.
Die Lösung kann so aussehen: (Eine Unsauberkeit: nach ca 71 Minuten Flugzeit mit einem Akku, fällt der Baro für 4 Sec aus)

Code:
Im Hauptprogramm:

static uint8_t newbaroalt=0;


Unter IMU getEstimatedAltitude:

#define BARO_TAB_SIZE   40
#define INIT_DELAY      4000000  // 4 sec initialization delay

void getEstimatedAltitude(){
  uint8_t index;
  static int16_t BaroHistTab[BARO_TAB_SIZE];
  static int8_t BaroHistIdx;
  static int32_t BaroHigh,BaroLow;
  int32_t temp32;
  int16_t last;

  if (newbaroalt==0 || currentTime < INIT_DELAY) return; // Possible Problem after 71 Minutes Flighttime
  newbaroalt=0;
  newestalt=1; 

  //**** Alt. Set Point stabilization PID ****
  //calculate speed for D calculation
  last = BaroHistTab[BaroHistIdx];
  BaroHistTab[BaroHistIdx] = BaroAlt/10;
  BaroHigh += BaroHistTab[BaroHistIdx];
  index = (BaroHistIdx + (BARO_TAB_SIZE/2))%BARO_TAB_SIZE;
  BaroHigh -= BaroHistTab[index];
  BaroLow  += BaroHistTab[index];
  BaroLow  -= last;

  BaroHistIdx++;
  if (BaroHistIdx == BARO_TAB_SIZE) BaroHistIdx = 0;

  BaroPID = 0;
  //D
  temp32 = D8[PIDALT]*(BaroHigh - BaroLow) / BARO_TAB_SIZE;
  BaroPID-=temp32;

  EstAlt = BaroHigh*10/(BARO_TAB_SIZE/2);
  
  temp32 = AltHold - EstAlt;
  if (abs(temp32) < 10 && abs(BaroPID) < 10) BaroPID = 0;  //remove small D parametr to reduce noise near zero position
  
  //P
  BaroPID += P8[PIDALT]*constrain(temp32,(-2)*P8[PIDALT],2*P8[PIDALT])/100;   
  BaroPID = constrain(BaroPID,-150,+150); //sum of P and D should be in range 150 Crashpilot1000

  //I
  errorAltitudeI += temp32*I8[PIDALT]/50;
  errorAltitudeI = constrain(errorAltitudeI,-30000,30000);
  temp32 = errorAltitudeI / 500; //I in range +/-60
  BaroPID+=temp32;
}

Unter Sensors Baro_update()

Für den BMP:

....
    case 3: 
      i2c_BMP085_UP_Read(); 
      i2c_BMP085_Calculate(); 
      BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 4433000.0f; //centimeter
      bmp085_ctx.state = 0; bmp085_ctx.deadline += 5000; 
      newbaroalt=1;
      break;
.....

Für den MS:
......
      case 3: 
      i2c_MS561101BA_UP_Read();
      i2c_MS561101BA_Calculate();
      BaroAlt = (1.0f - pow(pressure/101325.0f, 0.190295f)) * 4433000.0f; //centimeter
      ms561101ba_ctx.state = 0; ms561101ba_ctx.deadline += 4000;
      newbaroalt=1;
      break;
......
Im Ergebnis hat das getEstimatedAltitude Unterprogramm jetzt anständigere Werte, aus denen der gleitende MW berechnet werden kann. Da die Werte jetzt konsistenter sind, kann man die Konstante BARO_TAB_SIZE 40 erniedrigen auf z.B 20. D.h. der MW wird jetzt immer nur noch über 20 Werte gebildet, d.h. ein Änderung schlägt jetzt schneller durch.
Info: Der BMP liefert so alle 14ms, der MS alle 10ms neue Werte.

Ach, ja diese Zeile:
Code:
BaroPID = constrain(BaroPID,-150,+150);
Bereitet mir auch noch Kopfzerbrechen. Der "BaroPID" wird nacher zum Gaskanal addiert. Beim Sinken/Fallen wird dem Copter schliesslich von der Gravitation geholfen, kann es daher sinnvoll sein, die Negativwerte weiter zu limitieren um Aufschwingen zu verhindern? Also z.B so:
Code:
BaroPID = constrain(BaroPID,-100,+150);

Nachteil: Die aktuellen PID Werte für den Baro kann man jetzt vergessen, die müssen neu erflogen werden. Vielleicht muss der Baro Pid Kontroller jetzt noch überarbeitet werden. Mit den aktuellen Änderungen hält mein Copter die Höhe jetzt SCHLECHTER, obwohl der Code m.E ein Schritt in die richtige Richtung ist - mal sehen, was man mit den PIDS noch machen kann.

Anbei die Datei mit den Änderungen - nur für sehr EXPERIMENTIERFREUDIGE ! WARNUNG! DANGER!

LG

ROB

P.s.:MultiWii_dev_20120528.zip gesichtet, KEINE Änderung am Baro Code!
 

Anhänge

Ach, ja diese Zeile:
Code:
BaroPID = constrain(BaroPID,-150,+150);
Bereitet mir auch noch Kopfzerbrechen. Der "BaroPID" wird nacher zum Gaskanal addiert. Beim Sinken/Fallen wird dem Copter schliesslich von der Gravitation geholfen, kann es daher sinnvoll sein, die Negativwerte weiter zu limitieren um Aufschwingen zu verhindern? Also z.B so:
Code:
BaroPID = constrain(BaroPID,-100,+150);

Hi Roberto,

der Gedanke war Gold wert. Ich habe die negativen Ergebnisse von P I und D durch einen Faktor geteilt, die positiven gelassen. Der Testflug auf dem Hof war vielversprechend. (Die Pflanzen haben leider etwas gelitten, auch die Tanne sorgte für einen Absturz) Jetzt macht es Sinn die Regelwerte auszuprobieren, ebenso einen geeigneten Faktor fürs sinken zu finden. Prototyp war die neuste Dev. Änderungen nur in der Routine getEstimatedAltitude()

Gruß DeaconBlues
 
FPV1

Banggood

Oben Unten