Funktionieren bei Euch Kompass und Baro vernünftig ?
- Themenstarter Joachim08
- Beginndatum
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
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?
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
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
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.
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.
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.)
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
) einen Tipp ?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
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
Ich hab gerade bei Hobbyking gesehen, dass diese Schrauben als Ersatzteil zu den Rahmen angeboten werden.
http://www.hobbyking.com/hobbyking/...n_V2_Screw_Set_4pcs_M3_x_12_4pcs_M3_x_8_.html
Vielleicht haben die das Problem selbst schon erkannt...
Gruß
Martin
http://www.hobbyking.com/hobbyking/...n_V2_Screw_Set_4pcs_M3_x_12_4pcs_M3_x_8_.html
Vielleicht haben die das Problem selbst schon erkannt...
Gruß
Martin
@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
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
ä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):
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)
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:
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:
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!
ä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;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;
......Info: Der BMP liefert so alle 14ms, der MS alle 10ms neue Werte.
Ach, ja diese Zeile:
Code:
BaroPID = constrain(BaroPID,-150,+150);
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!
Ach, ja diese Zeile:
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:
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
Code:
BaroPID = constrain(BaroPID,-150,+150);
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
