Funktionieren bei Euch Kompass und Baro vernünftig ?
- Themenstarter Joachim08
- Beginndatum
@martinez: Soll das eine "Hupe" sein? Jau, Du kannst auch konfigurieren, über welchen Pin Du sie angeschlossen hast (Transistor dazwischen zur Entlastung der Arduino Ports!) usw. Ich habe sie nicht verkabelt, da ich FrSky Telemetrie am Start habe, und so immer weiss, wann der Lipo durch ist.
@Helste: "Wenn ich Baro aktiviere, dann steigt der Kopter mal ein paar Meter auf. Dann kommt er wieder auf die Höhe, wo ich Baro aktiviert habe runter..." "So, ich habe wieder die 0606 drauf und bin nun super zufrieden. "
Den Eindruck hatte ich auch, habe es allerdings auf das windige Wetter geschoben. Wenn man im Gyromodus startet, dann alt hold macht und dann den ACC einschaltet ging er erst rauf und dann wieder herunter auf die alte Höhe. Ich habe dann Alt "D" auf 10 gesetzt und es wurde besser. komisch.
@Joachim08
" Ich habe auch subjektiv den Eindruck, daß die 0606 besser ist beim Höhehalten als die neueste Version.
Habe die neueste mal draufgepsielt, den Wert für den MS auf 10 cm geändert und in der Hand geschwebt.
Mit aktiviertem Baro konnte ich den Quad nen halben Meter rauf oder runter nehmen ohne daß es eine
Reaktion gab. Das war komischerweise bei de 0606 anders.
Leider blicke ich auch bei den PID Werten jetzt nicht mehr durch was ich da versuchen soll. Sind die Werte
bei beiden Baros gleich oder ist die Auswirkung irgendwo stärker ???"
Die Logik hinter den Alt PID Werten ist gleich geblieben. Ich habe nur versucht den Code mathematisch richtiger und universeller (MS/BMP/verschiedene ACC/kompatibles EstAlt) zu machen. Tja, kaum versucht man es richtig zu machen, wirds schlechter. *Grummel*. Da muss ich wohl noch mal ran, heute absolut keinen Nerv mehr.
LG
Rob
Ps.: Durch dieses neue Bitfeld in der aktuellen Dev, kann es durchaus sein, dass einige Abfragen (nicht in meiner Änderung, habe ich gecheckt), ob irgendwas initialisiert ist noch vor die Wand laufen, das würde ggf ein schlechteres MAG-Verhalten erklären.
@Helste: "Wenn ich Baro aktiviere, dann steigt der Kopter mal ein paar Meter auf. Dann kommt er wieder auf die Höhe, wo ich Baro aktiviert habe runter..." "So, ich habe wieder die 0606 drauf und bin nun super zufrieden. "
Den Eindruck hatte ich auch, habe es allerdings auf das windige Wetter geschoben. Wenn man im Gyromodus startet, dann alt hold macht und dann den ACC einschaltet ging er erst rauf und dann wieder herunter auf die alte Höhe. Ich habe dann Alt "D" auf 10 gesetzt und es wurde besser. komisch.
@Joachim08
" Ich habe auch subjektiv den Eindruck, daß die 0606 besser ist beim Höhehalten als die neueste Version.
Habe die neueste mal draufgepsielt, den Wert für den MS auf 10 cm geändert und in der Hand geschwebt.
Mit aktiviertem Baro konnte ich den Quad nen halben Meter rauf oder runter nehmen ohne daß es eine
Reaktion gab. Das war komischerweise bei de 0606 anders.
Leider blicke ich auch bei den PID Werten jetzt nicht mehr durch was ich da versuchen soll. Sind die Werte
bei beiden Baros gleich oder ist die Auswirkung irgendwo stärker ???"
Die Logik hinter den Alt PID Werten ist gleich geblieben. Ich habe nur versucht den Code mathematisch richtiger und universeller (MS/BMP/verschiedene ACC/kompatibles EstAlt) zu machen. Tja, kaum versucht man es richtig zu machen, wirds schlechter. *Grummel*. Da muss ich wohl noch mal ran, heute absolut keinen Nerv mehr.
LG
Rob
Ps.: Durch dieses neue Bitfeld in der aktuellen Dev, kann es durchaus sein, dass einige Abfragen (nicht in meiner Änderung, habe ich gecheckt), ob irgendwas initialisiert ist noch vor die Wand laufen, das würde ggf ein schlechteres MAG-Verhalten erklären.
Nein, da noch nicht. Aber bei mir ist das bereits so eingetragen beim Crius SE in der def.h
Ich habe da auch bereits alle Vorzeichen ein Mal invertiert, ohne Verbesserung. Dann wird es schlimmer und "schlägt" richtig um.
Was mir auffällt, ist dass mein MAG_PITCH-Wert bei ca. 45° Pitch auf 0 liegt, während MAG_ROLL bei ca. 0° Roll auf 0 liegt.
Ich habe da auch bereits alle Vorzeichen ein Mal invertiert, ohne Verbesserung. Dann wird es schlimmer und "schlägt" richtig um.
Was mir auffällt, ist dass mein MAG_PITCH-Wert bei ca. 45° Pitch auf 0 liegt, während MAG_ROLL bei ca. 0° Roll auf 0 liegt.
@Roberto u. @upapa,
danke, hab den Fehler gefunden. Hab ein Buchstabe nicht mit eingegeben, deshalb konnte mein Board nicht erkannt werden. Frage an Roberto: Wird bei deinen Veränderungen auch in der Config etwas verändert? Denn ich gebe jedes Mal meine Daten da neu ein, und dabei ist mir der Fehler passiert.
Gruß Paraglider58
danke, hab den Fehler gefunden. Hab ein Buchstabe nicht mit eingegeben, deshalb konnte mein Board nicht erkannt werden. Frage an Roberto: Wird bei deinen Veränderungen auch in der Config etwas verändert? Denn ich gebe jedes Mal meine Daten da neu ein, und dabei ist mir der Fehler passiert.
Gruß Paraglider58
So, der Regen hat kurz für einige Zeit aufgehört- schnell den Copter nacheinander mit vier LiPos gesattelt und ein paar Testrunden mit der "MultiWii_dev_20120618_NewBaroPID" geflogen.
Ich konnte (subjektiv) keine spürbare Verschlechterung gegenüber der 20120606 feststellen. Musste lediglich bei ALT den Wert für P auf 15 erhöhen, den für I auf 0.020 und den D-Wert auf 8 absenken. Mit dieser Einstellung hielt mein CriusSE innerhalb eines 1m-Korridors (oft auch nur ca 50 cm Schwankungen) sehr ordentlich die Höhe. Nachdem ich ihn per Hand zwangsweise herabgedrückt hatte, pendelte er sich mit leichten Jo-Jo-Bewegungen wieder auf die alte Höhe ein.
Roberto, was mir aufgefallen ist:
1.
Fixiere ich den Copter mit Throttle auf eine bestimmte Höhe und schalte dann Baro hinzu, hält er diese Höhe dann auch sehr gut.
2.
Schalte ich den Baro während einer Steigbewegung zu, dann lässt er sich scheinbar gar nicht beeindrucken und steigt weiter bis die Höhe passend zum Throttle-Wert erreicht ist. Auf welcher Höhe er sich dann tatsächlich einpegelt, ist nicht wirklich voraussehbar.
3.
Schalte ich den Baro bei einer Sinkbewegung hinzu, greift die Regelung sofort und stabilsiert den Copter auf dieser Höhe.
Jedenfalls bleibe ich erst einmal dei der MultiWii_dev_20120618_NewBaroPID, ein Downgrade auf die 20120606 ist nicht erforderlich.
upapa
Ich konnte (subjektiv) keine spürbare Verschlechterung gegenüber der 20120606 feststellen. Musste lediglich bei ALT den Wert für P auf 15 erhöhen, den für I auf 0.020 und den D-Wert auf 8 absenken. Mit dieser Einstellung hielt mein CriusSE innerhalb eines 1m-Korridors (oft auch nur ca 50 cm Schwankungen) sehr ordentlich die Höhe. Nachdem ich ihn per Hand zwangsweise herabgedrückt hatte, pendelte er sich mit leichten Jo-Jo-Bewegungen wieder auf die alte Höhe ein.
Roberto, was mir aufgefallen ist:
1.
Fixiere ich den Copter mit Throttle auf eine bestimmte Höhe und schalte dann Baro hinzu, hält er diese Höhe dann auch sehr gut.
2.
Schalte ich den Baro während einer Steigbewegung zu, dann lässt er sich scheinbar gar nicht beeindrucken und steigt weiter bis die Höhe passend zum Throttle-Wert erreicht ist. Auf welcher Höhe er sich dann tatsächlich einpegelt, ist nicht wirklich voraussehbar.
3.
Schalte ich den Baro bei einer Sinkbewegung hinzu, greift die Regelung sofort und stabilsiert den Copter auf dieser Höhe.
Jedenfalls bleibe ich erst einmal dei der MultiWii_dev_20120618_NewBaroPID, ein Downgrade auf die 20120606 ist nicht erforderlich.
upapa
Anhänge
Mein Bericht:
4 Akkuladungen mit der MultiWii_dev_20120618_NewBaroPID Version geflogen. Altwerte auf P=15; i=0,050; D=5;
Beim Starten bin ich so vorgegangen: Motoren gestartet. Drehzahl erhöht bis knapp unter die Abhebedrehzahl. MAG dazu geschaltet. Nach ca. 5 Sek. Baro dazu geschaltet. Nach weiterne 5 Sek. Gas gegeben und den Kopter auf ca. 5mtr. Höhe gebracht. Er hat die Höhe recht gut gehalten, auch die Richtung hat er gehalten. Aufgefallen ist mir, wenn er mal so kurz durchgesackt ist, und auf dem Punkt stand, hat er leichte Probleme gezeigt und sackte weiter durch, ca. 2-3mtr. aber er stieg dann wieder auf die Ausgangshöhe. Ich gehe davon aus das war der Fallwind der Rotoren. Bin ich dann stetig nach rechts, links,vor und zurück geschwebt, da war das durchsacken viel weniger. Möglich das man da noch ein wenig durch verändern der PID-Werte verbessern kann.
Es wird weiter getestet.
Gruß Paraglider58
4 Akkuladungen mit der MultiWii_dev_20120618_NewBaroPID Version geflogen. Altwerte auf P=15; i=0,050; D=5;
Beim Starten bin ich so vorgegangen: Motoren gestartet. Drehzahl erhöht bis knapp unter die Abhebedrehzahl. MAG dazu geschaltet. Nach ca. 5 Sek. Baro dazu geschaltet. Nach weiterne 5 Sek. Gas gegeben und den Kopter auf ca. 5mtr. Höhe gebracht. Er hat die Höhe recht gut gehalten, auch die Richtung hat er gehalten. Aufgefallen ist mir, wenn er mal so kurz durchgesackt ist, und auf dem Punkt stand, hat er leichte Probleme gezeigt und sackte weiter durch, ca. 2-3mtr. aber er stieg dann wieder auf die Ausgangshöhe. Ich gehe davon aus das war der Fallwind der Rotoren. Bin ich dann stetig nach rechts, links,vor und zurück geschwebt, da war das durchsacken viel weniger. Möglich das man da noch ein wenig durch verändern der PID-Werte verbessern kann.
Es wird weiter getestet.
Gruß Paraglider58
Zum Thema Mag:
Ich habe jetzt die FC mal mit deutlich mehr Abstand zu Kabeln und Schrauben befestigt. Leider noch immer ohne Erfolg.
Das ist ziemlich nervig, er dreht immernoch weg bei Pitch.
Irgendwie verstehe ich auch noch nicht, wie sich die Werte der drei Mag-Richtungen verhalten, wenn ich den Copter bewege.
Es gibt keine Mag-Richtung, die bei horizontalem Copter dem reinen Heading-Wert entspricht, oder?
Ich habe jetzt die FC mal mit deutlich mehr Abstand zu Kabeln und Schrauben befestigt. Leider noch immer ohne Erfolg.
Das ist ziemlich nervig, er dreht immernoch weg bei Pitch.
Irgendwie verstehe ich auch noch nicht, wie sich die Werte der drei Mag-Richtungen verhalten, wenn ich den Copter bewege.
Es gibt keine Mag-Richtung, die bei horizontalem Copter dem reinen Heading-Wert entspricht, oder?
@upapa: Deine Beobachtungen sind absolut korrekt.
"
1.
Fixiere ich den Copter mit Throttle auf eine bestimmte Höhe und schalte dann Baro hinzu, hält er diese Höhe dann auch sehr gut. "
So sollte man es gegenwärtig am besten machen.
"
2.
Schalte ich den Baro während einer Steigbewegung zu, dann lässt er sich scheinbar gar nicht beeindrucken und steigt weiter bis die Höhe passend zum Throttle-Wert erreicht ist. Auf welcher Höhe er sich dann tatsächlich einpegelt, ist nicht wirklich voraussehbar."
Das ist leider noch so, solange ich es mit den relativen Steig/Sinkraten (wie beim Naza) nicht gebacken bekomme. Wenn Du beim Steigen den Baroschalter umlegst, passiert folgendes: Der aktuelle Gaswert wird sofort als Referenzwert für die Höhenregelung genommen (egal ob die Gipfelhöhe bei dem Throttle schon erreicht ist - kann er ja nicht wissen) und der aktuelle Höhenwert, der 0,5 sec alt sein kann (siehe Tetriskurve in der GUI). Deswegen: " Auf welcher Höhe er sich dann tatsächlich einpegelt, ist nicht wirklich voraussehbar."
"3.
Schalte ich den Baro bei einer Sinkbewegung hinzu, greift die Regelung sofort und stabilsiert den Copter auf dieser Höhe."
Das hat folgende Gründe: Zum einen ist der Unterschied Deiner Gas-Eingabe zu einer guten "Höhehalten Gasvorwahl" beim Sinken deutlich kleiner als beim Steigen (kleinere Stickbewegung). Zum Anderen wird das ACC aktuell nur gegen Fallbewegungen aktiv.
@Paraglider58: "Möglich das man da noch ein wenig durch verändern der PID-Werte verbessern kann." ... Und vor allem am Programm..... Ich versuche aktuell folgendes: Das "P" giftiger interpretieren, den ACC weicher gestalten mit weniger Einfluss.
Leider war bei meinem Hauptrechner, wo meine aktuellen MWII Dateien sind, die GFX Karte abgefackelt (GTX 8800). Habe jetzt grad meine neue drin (Asus GTX 670 DC2T ....) und bin auch schon wieder am Codebasteln. Das Wetter hier verhindert allerdings Testflüge.
@JinGej: Ja, die neue Dev! Wie man hier (http://code.google.com/p/multiwii/source/list) lesen kann hatte die 618 einen zarten GPS Rechenfehler von 2KM (!) und einen "freeze" im seriellen Protokoll, daher auch die GUI Probleme.
"..tja, und wieder alles umsonst" Umsonst ist nichts, höchstens vergebens....
LG
Rob
P.s.: Ach bevor ich es vergesse: Könnt Ihr bei Euren sehr detaillierten Rückmeldungen eben kurz den ACC und den Baro mit angeben? Also z.B BMA20/BMP oder FreeimuX oder Crius oder ITG/MS oder MPU/MS etc.
"
1.
Fixiere ich den Copter mit Throttle auf eine bestimmte Höhe und schalte dann Baro hinzu, hält er diese Höhe dann auch sehr gut. "
So sollte man es gegenwärtig am besten machen.
"
2.
Schalte ich den Baro während einer Steigbewegung zu, dann lässt er sich scheinbar gar nicht beeindrucken und steigt weiter bis die Höhe passend zum Throttle-Wert erreicht ist. Auf welcher Höhe er sich dann tatsächlich einpegelt, ist nicht wirklich voraussehbar."
Das ist leider noch so, solange ich es mit den relativen Steig/Sinkraten (wie beim Naza) nicht gebacken bekomme. Wenn Du beim Steigen den Baroschalter umlegst, passiert folgendes: Der aktuelle Gaswert wird sofort als Referenzwert für die Höhenregelung genommen (egal ob die Gipfelhöhe bei dem Throttle schon erreicht ist - kann er ja nicht wissen) und der aktuelle Höhenwert, der 0,5 sec alt sein kann (siehe Tetriskurve in der GUI). Deswegen: " Auf welcher Höhe er sich dann tatsächlich einpegelt, ist nicht wirklich voraussehbar."
"3.
Schalte ich den Baro bei einer Sinkbewegung hinzu, greift die Regelung sofort und stabilsiert den Copter auf dieser Höhe."
Das hat folgende Gründe: Zum einen ist der Unterschied Deiner Gas-Eingabe zu einer guten "Höhehalten Gasvorwahl" beim Sinken deutlich kleiner als beim Steigen (kleinere Stickbewegung). Zum Anderen wird das ACC aktuell nur gegen Fallbewegungen aktiv.
@Paraglider58: "Möglich das man da noch ein wenig durch verändern der PID-Werte verbessern kann." ... Und vor allem am Programm..... Ich versuche aktuell folgendes: Das "P" giftiger interpretieren, den ACC weicher gestalten mit weniger Einfluss.
Leider war bei meinem Hauptrechner, wo meine aktuellen MWII Dateien sind, die GFX Karte abgefackelt (GTX 8800). Habe jetzt grad meine neue drin (Asus GTX 670 DC2T ....) und bin auch schon wieder am Codebasteln. Das Wetter hier verhindert allerdings Testflüge.
@JinGej: Ja, die neue Dev! Wie man hier (http://code.google.com/p/multiwii/source/list) lesen kann hatte die 618 einen zarten GPS Rechenfehler von 2KM (!) und einen "freeze" im seriellen Protokoll, daher auch die GUI Probleme.
"..tja, und wieder alles umsonst" Umsonst ist nichts, höchstens vergebens....
LG
Rob
P.s.: Ach bevor ich es vergesse: Könnt Ihr bei Euren sehr detaillierten Rückmeldungen eben kurz den ACC und den Baro mit angeben? Also z.B BMA20/BMP oder FreeimuX oder Crius oder ITG/MS oder MPU/MS etc.
Gestern abend habe ich zwei Akkus leergeflogen. Beim 2. Akku, nach ca. 3 Minuten sackte der Kopter aus ca. 15mtr. durch ohne erkennbaren Grund. Er reagierte nicht auf "mehr Gas". Er hat sich exact in der Waage gehalten, aber leider hat er die Höhe nicht gehalten. Ich hatte eine Kamera am Kopter die alles aufgezeichnet hat. Kann aber auch keine Ursache dabei erkennen.
Hat jemand von euch event. eine Antwort?
Gruß Paraglider58
Hat jemand von euch event. eine Antwort?
Gruß Paraglider58
Hallo Testpiloten
20 Zeilen Code und der Copter hält die Höhe? Ein Problem von dem man eigentlich erwartet das es sich einfach lösen läßt. Doch kurzzeitiger Erfolg und Rückschritt liegen wohl immer dicht beianander. Heute denke ich es klappt, morgen lehrt mich dieses dämliche Stück Programm auf dem ATMega das die Wirklichkeit ganz anders aussieht.
Zwischenschritt war eine persönliche Weiterbildung in Exxcel um einen Regler per Tabellenkalkulation nachzubilden. Geht ganz wunderbar, man erhält auch gleich schöne Linien. Diese zeigen aber auch, das so ein Regler ganz schöne Zicken machen kann. Zwischen regeln und aufschaukelnder Ozzilator geht alles.
Doch zum Kern des Problems, der PID Regler. Ich hol einfach mal ein wenig aus, damit wir die Schwachstellen im jetzigen im Originalcode erkennen können.
Der P-Anteil
PidP = DeltaAlt * Anpassungfaktor;
ist problemlos, er wird 40 mal die Sekunde aktualisiert.
Der I-Anteil ist schon schwieriger
errorAltitudeI += DeltaAlt * Anpassungfaktor;
PidI = errorAltitudeI;
Der I-Anteil wird mit zum Motorsteller gegeben, der generiert ein Signal für den Motor, dieser ändert die Drehzahl, beschleunigt die Luftschraube mit...... und das dauert seine Zeit.... in der Zwischenzeit wird die PID Routine mehrfach aufgerufen..... errorAltitudeI weiter erhöht (oder erniedrigt) .... Bis der Motor die Steig/Sinkleistung gebracht hat, hat sich errorAltitudeI meist so weit aufgebaut das der Copter weit über die Mittellinie schiesst..... Dann der Weg in die andere Richtung... (Es wird immer ein gewisses Überschieße geben müssen, sonst klappt es nicht.... aber nicht zu stark)
Die Verzögerung bis die Luftschraube ihre Wirkung zeigt ist das Problem.
Dann gehen wir zum D-Anteil
DeltaAltOld = DeltaAlt;
DeltaAlt = AltHold - EstAlt;
velocity = DeltaAlt - DeltaAltOld;
PidD = velocity * Anpassungsfaktor;
Rechnen tun wir mit Integer. Die Reglerroutine wird 40 mal die Sekunde aufgerufen. Ein Wert von 1 entspricht jezt schon einer Sink/Steiggeschwindigkeit von 40cm/sec. Bei einem Wert von 5 kommt der Copter mit 2m/sec vom Himmel gesaust.
Verstanden habe ich den D-Anteil als Bremse, das heißt es soll schnellen Bewegungen entgegenwirken. Feinfühligkeit ist mit diesen mächtigen Steig/Sinkleistungen die hinter diesen kleinen Zahlen stehen nicht mehr gegeben. Eher schon ein Fall für Grobmotoriker.
Ausweg aus diesem Dilemma ist eine Anpassung der Aufrufrate der Pid-Reglers. Mit 4 Aufrufen / Sekunde zeigt mein Copter ein Regelverhalten welches ich nachvollziehen konnte, keine wilden Orgien mehr am Gassteller. Ob einer Verringerung auf drei oder gar zwei Aufrufe / Sekunde noch eine Verbesserung bringt habe ich noch nicht probiert, wäre dann vermutlich immer noch besser bzw schneller als ich selber am Steuerknüppel. Eine Unteruchung darauf hin ist aber Sinnvoll.
Ein Versuch außerhalb des Messbereichs des US-Sensors hat mich wegen des Pendelns um ca 4m nicht begeistert, doch zum einen war es böig, zum anderen weder der D-Wert optimiert. Routinen die den WindUp des I-Reglers verhinden sollen habe ich erst mal wieder weggelassen, evtl machen sie doch Sinn. Ebenfalls bin ich noch nicht dazu gekommen den Baro gegen Umwelteinflüße besser zu kapseln. Trotzdem hat sich die Regelung im BaroMode nachhaltig verbessert.
Wer probieren will, ich habe meine Routine unten einkopiert. Den Baromittelwert macht eine Routine die ich Bei Alex Mos geklaut habe, wie ich finde super smart programmiert. Den US-SensorCode (auch Mos) soll rausschmeissen wer ihn nicht braucht. Die EstAlt wird noch 40 mal / Sekunde aufgerufen, das ist bestimmt kein Fehler. Ich hoffe das ich beim Bereinigen des Codes nicht zuviel gelöscht habe, das sind aber eh nur Klammern und Semikolions.
Gruß Deacon Blues
typedef struct avg_var16 {
int32_t buf; // internal bufer to store non-rounded average value
int16_t res; // result (rounded to int)
} t_avg_var16;
/* n=(1..16) */
void average16(struct avg_var16 *avg, int16_t cur, int8_t n) {
avg->buf+= cur - avg->res;
avg->res = avg->buf >> n;
}
#define UPDATE_INTERVAL 25000 // 25000 = 40hz update rate (20hz LPF on acc)
#define UPDATE_INTERVAL2 250000 // 250000 = 4hz Rate für den Regler
#define INIT_DELAY 4000000 // 4 sec initialization delay
void getEstimatedAltitude(){
static uint32_t deadLine = INIT_DELAY,deadLine2 = INIT_DELAY;
static t_avg_var16 baroSonarDiff = {0,0};
static t_avg_var16 avgAlt = {0,0};
static int32_t BaroAltGround; // baro for 'ground level'
static int32_t DeltaAlt, DeltaAltOld; // Regelabweichung alt für PID-D
static int32_t velocity; // Geschwindigkeit Höhenänderung
static float alt = 0; // cm
int32_t sensorAlt; // Höhe gemischt aus Sonar und Baro
int16_t PidP = 0, PidI = 0, PidD;
static uint8_t blinker = 0;
static uint8_t blinkerI = 0;
if (currentTime < deadLine) return;
deadLine = currentTime + UPDATE_INTERVAL;
average16(&avgAlt, BaroAlt, 5); // / 4 = 16 = 0,375 sec 5 = 32 = 0,75 sec 6 = 64 = 1,5 sek // Mittelwert der Höhe
BaroAltMw = avgAlt.res;
#ifdef SONAR
if (SonarErrors == 0)
{alt = SonarAlt; BaroAltGround = BaroAltMw - alt;}
#else BaroAltGround = BaroAltMw; alt = 0;
#endif
sensorAlt = BaroAltMw - BaroAltGround;
#ifdef SONAR
sonarUpdate(); // get sonar data and trigger next measure
if(SONAR_USED) { // Get difference between sonar and baro and slightly average it in time
average16(&baroSonarDiff, constrain(SonarAlt - sensorAlt, -32000, 32000), 6);
}
// Check if sonar is not crazy: its value compared to baro should not go outside window +/-3m
if(abs(baroSonarDiff.res) < 300) { //
00
sensorAlt += baroSonarDiff.res;
// Sonar gives precise values, use it
if(SonarErrors == 0) {
sensorAlt = SonarAlt;
// Sonar gives some errors: use cross-section of SONAR and BARO altitudes to softly switch to baro
} else if(SONAR_USED) { //(SonarErrors < SONAR_ERROR_MAX)
sensorAlt = (SonarAlt * (SONAR_ERROR_MAX - SonarErrors) + sensorAlt * SonarErrors)/SONAR_ERROR_MAX;
}
} else {
// Sonar is crasy, so use baro only + sonar value on the end of limits
sensorAlt += constrain(baroSonarDiff.res, -300, 300);
}
#endif
EstAlt = sensorAlt;
if (currentTime < deadLine2) return;
deadLine2 = currentTime + UPDATE_INTERVAL2;
// Dieser Teil der Routine wird nur 4 mal in der Sekunde ausgeführt
DeltaAltOld = DeltaAlt;
DeltaAlt = AltHold - EstAlt; // ist positiv bei zu niedrig
velocity = DeltaAlt - DeltaAltOld; // ist positiv bei sinken, negativ beim Steigen
//D
PidD = conf.D8[PIDALT] * (velocity) / 16; // ist positiv bei sinken // soll der schnellen Bewegung engegenwirken
BaroPID = PidD;
//P
PidP = conf.P8[PIDALT] * constrain(DeltaAlt,-100,100)/100;
BaroPID += PidP;
BaroPID = constrain(BaroPID,-150,+150);
//I
errorAltitudeI += DeltaAlt * conf.I8[PIDALT] / 16;
errorAltitudeI = constrain(errorAltitudeI,-3000,3000); // war 30000 erhöht auf 3750 max range dann +/- 75
PidI = errorAltitudeI / 75; //500 I in range +/-40
BaroPID += PidI;
//AnzeigeLeds zum Anzeigen der Regelabweichung
if (blinkerI == 4) {blinkerI = 0; if (blinker == 1) blinker = 0; else blinker = 1;} blinkerI++;
if ((EstAlt - AltHold) > 0) { digitalWrite(LEDup,LOW);digitalWrite(LEDmid,LOW);digitalWrite(LEDdown,blinker);}
if ((EstAlt - AltHold) > 30) { digitalWrite(LEDup,LOW);digitalWrite(LEDmid,LOW);digitalWrite(LEDdown,HIGH);}
if ((EstAlt - AltHold) < 0) { digitalWrite(LEDup,blinker);digitalWrite(LEDmid,LOW);digitalWrite(LEDdown,LOW);}
if ((EstAlt - AltHold) < -30) { digitalWrite(LEDup,HIGH);digitalWrite(LEDmid,LOW);digitalWrite(LEDdown,LOW);}
if (abs(EstAlt - AltHold) < 15) { digitalWrite(LEDmid,HIGH);}
if (abs(EstAlt - AltHold) < 5) { digitalWrite(LEDmid,blinker);digitalWrite(LEDup,blinker);digitalWrite(LEDdown,blinker);}
debug1 = DeltaAlt;
debug2 = PidP;
debug3 = PidI;
debug4 = PidD;
}
20 Zeilen Code und der Copter hält die Höhe? Ein Problem von dem man eigentlich erwartet das es sich einfach lösen läßt. Doch kurzzeitiger Erfolg und Rückschritt liegen wohl immer dicht beianander. Heute denke ich es klappt, morgen lehrt mich dieses dämliche Stück Programm auf dem ATMega das die Wirklichkeit ganz anders aussieht.
Zwischenschritt war eine persönliche Weiterbildung in Exxcel um einen Regler per Tabellenkalkulation nachzubilden. Geht ganz wunderbar, man erhält auch gleich schöne Linien. Diese zeigen aber auch, das so ein Regler ganz schöne Zicken machen kann. Zwischen regeln und aufschaukelnder Ozzilator geht alles.
Doch zum Kern des Problems, der PID Regler. Ich hol einfach mal ein wenig aus, damit wir die Schwachstellen im jetzigen im Originalcode erkennen können.
Der P-Anteil
PidP = DeltaAlt * Anpassungfaktor;
ist problemlos, er wird 40 mal die Sekunde aktualisiert.
Der I-Anteil ist schon schwieriger
errorAltitudeI += DeltaAlt * Anpassungfaktor;
PidI = errorAltitudeI;
Der I-Anteil wird mit zum Motorsteller gegeben, der generiert ein Signal für den Motor, dieser ändert die Drehzahl, beschleunigt die Luftschraube mit...... und das dauert seine Zeit.... in der Zwischenzeit wird die PID Routine mehrfach aufgerufen..... errorAltitudeI weiter erhöht (oder erniedrigt) .... Bis der Motor die Steig/Sinkleistung gebracht hat, hat sich errorAltitudeI meist so weit aufgebaut das der Copter weit über die Mittellinie schiesst..... Dann der Weg in die andere Richtung... (Es wird immer ein gewisses Überschieße geben müssen, sonst klappt es nicht.... aber nicht zu stark)
Die Verzögerung bis die Luftschraube ihre Wirkung zeigt ist das Problem.
Dann gehen wir zum D-Anteil
DeltaAltOld = DeltaAlt;
DeltaAlt = AltHold - EstAlt;
velocity = DeltaAlt - DeltaAltOld;
PidD = velocity * Anpassungsfaktor;
Rechnen tun wir mit Integer. Die Reglerroutine wird 40 mal die Sekunde aufgerufen. Ein Wert von 1 entspricht jezt schon einer Sink/Steiggeschwindigkeit von 40cm/sec. Bei einem Wert von 5 kommt der Copter mit 2m/sec vom Himmel gesaust.
Verstanden habe ich den D-Anteil als Bremse, das heißt es soll schnellen Bewegungen entgegenwirken. Feinfühligkeit ist mit diesen mächtigen Steig/Sinkleistungen die hinter diesen kleinen Zahlen stehen nicht mehr gegeben. Eher schon ein Fall für Grobmotoriker.
Ausweg aus diesem Dilemma ist eine Anpassung der Aufrufrate der Pid-Reglers. Mit 4 Aufrufen / Sekunde zeigt mein Copter ein Regelverhalten welches ich nachvollziehen konnte, keine wilden Orgien mehr am Gassteller. Ob einer Verringerung auf drei oder gar zwei Aufrufe / Sekunde noch eine Verbesserung bringt habe ich noch nicht probiert, wäre dann vermutlich immer noch besser bzw schneller als ich selber am Steuerknüppel. Eine Unteruchung darauf hin ist aber Sinnvoll.
Ein Versuch außerhalb des Messbereichs des US-Sensors hat mich wegen des Pendelns um ca 4m nicht begeistert, doch zum einen war es böig, zum anderen weder der D-Wert optimiert. Routinen die den WindUp des I-Reglers verhinden sollen habe ich erst mal wieder weggelassen, evtl machen sie doch Sinn. Ebenfalls bin ich noch nicht dazu gekommen den Baro gegen Umwelteinflüße besser zu kapseln. Trotzdem hat sich die Regelung im BaroMode nachhaltig verbessert.
Wer probieren will, ich habe meine Routine unten einkopiert. Den Baromittelwert macht eine Routine die ich Bei Alex Mos geklaut habe, wie ich finde super smart programmiert. Den US-SensorCode (auch Mos) soll rausschmeissen wer ihn nicht braucht. Die EstAlt wird noch 40 mal / Sekunde aufgerufen, das ist bestimmt kein Fehler. Ich hoffe das ich beim Bereinigen des Codes nicht zuviel gelöscht habe, das sind aber eh nur Klammern und Semikolions.
Gruß Deacon Blues
typedef struct avg_var16 {
int32_t buf; // internal bufer to store non-rounded average value
int16_t res; // result (rounded to int)
} t_avg_var16;
/* n=(1..16) */
void average16(struct avg_var16 *avg, int16_t cur, int8_t n) {
avg->buf+= cur - avg->res;
avg->res = avg->buf >> n;
}
#define UPDATE_INTERVAL 25000 // 25000 = 40hz update rate (20hz LPF on acc)
#define UPDATE_INTERVAL2 250000 // 250000 = 4hz Rate für den Regler
#define INIT_DELAY 4000000 // 4 sec initialization delay
void getEstimatedAltitude(){
static uint32_t deadLine = INIT_DELAY,deadLine2 = INIT_DELAY;
static t_avg_var16 baroSonarDiff = {0,0};
static t_avg_var16 avgAlt = {0,0};
static int32_t BaroAltGround; // baro for 'ground level'
static int32_t DeltaAlt, DeltaAltOld; // Regelabweichung alt für PID-D
static int32_t velocity; // Geschwindigkeit Höhenänderung
static float alt = 0; // cm
int32_t sensorAlt; // Höhe gemischt aus Sonar und Baro
int16_t PidP = 0, PidI = 0, PidD;
static uint8_t blinker = 0;
static uint8_t blinkerI = 0;
if (currentTime < deadLine) return;
deadLine = currentTime + UPDATE_INTERVAL;
average16(&avgAlt, BaroAlt, 5); // / 4 = 16 = 0,375 sec 5 = 32 = 0,75 sec 6 = 64 = 1,5 sek // Mittelwert der Höhe
BaroAltMw = avgAlt.res;
#ifdef SONAR
if (SonarErrors == 0)
{alt = SonarAlt; BaroAltGround = BaroAltMw - alt;}
#else BaroAltGround = BaroAltMw; alt = 0;
#endif
sensorAlt = BaroAltMw - BaroAltGround;
#ifdef SONAR
sonarUpdate(); // get sonar data and trigger next measure
if(SONAR_USED) { // Get difference between sonar and baro and slightly average it in time
average16(&baroSonarDiff, constrain(SonarAlt - sensorAlt, -32000, 32000), 6);
}
// Check if sonar is not crazy: its value compared to baro should not go outside window +/-3m
if(abs(baroSonarDiff.res) < 300) { //
00sensorAlt += baroSonarDiff.res;
// Sonar gives precise values, use it
if(SonarErrors == 0) {
sensorAlt = SonarAlt;
// Sonar gives some errors: use cross-section of SONAR and BARO altitudes to softly switch to baro
} else if(SONAR_USED) { //(SonarErrors < SONAR_ERROR_MAX)
sensorAlt = (SonarAlt * (SONAR_ERROR_MAX - SonarErrors) + sensorAlt * SonarErrors)/SONAR_ERROR_MAX;
}
} else {
// Sonar is crasy, so use baro only + sonar value on the end of limits
sensorAlt += constrain(baroSonarDiff.res, -300, 300);
}
#endif
EstAlt = sensorAlt;
if (currentTime < deadLine2) return;
deadLine2 = currentTime + UPDATE_INTERVAL2;
// Dieser Teil der Routine wird nur 4 mal in der Sekunde ausgeführt
DeltaAltOld = DeltaAlt;
DeltaAlt = AltHold - EstAlt; // ist positiv bei zu niedrig
velocity = DeltaAlt - DeltaAltOld; // ist positiv bei sinken, negativ beim Steigen
//D
PidD = conf.D8[PIDALT] * (velocity) / 16; // ist positiv bei sinken // soll der schnellen Bewegung engegenwirken
BaroPID = PidD;
//P
PidP = conf.P8[PIDALT] * constrain(DeltaAlt,-100,100)/100;
BaroPID += PidP;
BaroPID = constrain(BaroPID,-150,+150);
//I
errorAltitudeI += DeltaAlt * conf.I8[PIDALT] / 16;
errorAltitudeI = constrain(errorAltitudeI,-3000,3000); // war 30000 erhöht auf 3750 max range dann +/- 75
PidI = errorAltitudeI / 75; //500 I in range +/-40
BaroPID += PidI;
//AnzeigeLeds zum Anzeigen der Regelabweichung
if (blinkerI == 4) {blinkerI = 0; if (blinker == 1) blinker = 0; else blinker = 1;} blinkerI++;
if ((EstAlt - AltHold) > 0) { digitalWrite(LEDup,LOW);digitalWrite(LEDmid,LOW);digitalWrite(LEDdown,blinker);}
if ((EstAlt - AltHold) > 30) { digitalWrite(LEDup,LOW);digitalWrite(LEDmid,LOW);digitalWrite(LEDdown,HIGH);}
if ((EstAlt - AltHold) < 0) { digitalWrite(LEDup,blinker);digitalWrite(LEDmid,LOW);digitalWrite(LEDdown,LOW);}
if ((EstAlt - AltHold) < -30) { digitalWrite(LEDup,HIGH);digitalWrite(LEDmid,LOW);digitalWrite(LEDdown,LOW);}
if (abs(EstAlt - AltHold) < 15) { digitalWrite(LEDmid,HIGH);}
if (abs(EstAlt - AltHold) < 5) { digitalWrite(LEDmid,blinker);digitalWrite(LEDup,blinker);digitalWrite(LEDdown,blinker);}
debug1 = DeltaAlt;
debug2 = PidP;
debug3 = PidI;
debug4 = PidD;
}
Hallo DeaconBlues,
So wie ich das verstehe muß ich nach void getEstimatedAltitude() alles löschen und deinen Text eingeben. Da tauchen beim verifizieren danach Fehler auf, diese hier:
MultiWii_dev_20120622:-1: error: expected unqualified-id before 'else'
MultiWii_dev_20120622:203: error: 'NUMBER_MOTOR' was not declared in this scope
MultiWii_dev_20120622.cpp: In function 'void getEstimatedAltitude()':
IMU:268: error: a function-definition is not allowed here before '{' token
IMU:277: error: a function-definition is not allowed here before '{' token
Serial:509: error: expected `}' at end of input
Meine Tüte ist im Moment ein X-Kopter m. Flyduino-Mega Board, Drotek 10DOF m. Mpu. Hab noch andere Sachen wie GPS u. Sonar, nur soll der Kopter erst mal anständig fliegen bevor er diese Leckerli bekommt.
Gruß Paraglider58
So wie ich das verstehe muß ich nach void getEstimatedAltitude() alles löschen und deinen Text eingeben. Da tauchen beim verifizieren danach Fehler auf, diese hier:
MultiWii_dev_20120622:-1: error: expected unqualified-id before 'else'
MultiWii_dev_20120622:203: error: 'NUMBER_MOTOR' was not declared in this scope
MultiWii_dev_20120622.cpp: In function 'void getEstimatedAltitude()':
IMU:268: error: a function-definition is not allowed here before '{' token
IMU:277: error: a function-definition is not allowed here before '{' token
Serial:509: error: expected `}' at end of input
Meine Tüte ist im Moment ein X-Kopter m. Flyduino-Mega Board, Drotek 10DOF m. Mpu. Hab noch andere Sachen wie GPS u. Sonar, nur soll der Kopter erst mal anständig fliegen bevor er diese Leckerli bekommt.
Gruß Paraglider58
ersetzten geht vor der void getEstimatedAltitude() los,,, bei einer neuen dev fängst du an und löscht ab
#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;
bis zum Ende, dann den Code einfügen und die übergelassene prüfroutine rausschmeissen.
//AnzeigeLeds zum Anzeigen der Regelabweichung
if (blinkerI == 4) {blinkerI = 0; if (blinker == 1) blinker = 0; else blinker = 1;} blinkerI++;
if ((EstAlt - AltHold) > 0) { digitalWrite(LEDup,LOW);digitalWrite(LEDmid,LOW);d igitalWrite(LEDdown,blinker);}
if ((EstAlt - AltHold) > 30) { digitalWrite(LEDup,LOW);digitalWrite(LEDmid,LOW);d igitalWrite(LEDdown,HIGH);}
if ((EstAlt - AltHold) < 0) { digitalWrite(LEDup,blinker);digitalWrite(LEDmid,LO W);digitalWrite(LEDdown,LOW);}
if ((EstAlt - AltHold) < -30) { digitalWrite(LEDup,HIGH);digitalWrite(LEDmid,LOW); digitalWrite(LEDdown,LOW);}
if (abs(EstAlt - AltHold) < 15) { digitalWrite(LEDmid,HIGH);}
if (abs(EstAlt - AltHold) < 5) { digitalWrite(LEDmid,blinker);digitalWrite(LEDup,bl inker);digitalWrite(LEDdown,blinker);}
ggf schaun ob noch ne variable fehlt
Gruß Deacon Blues mit nen alten Astral im Schrank
#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;
bis zum Ende, dann den Code einfügen und die übergelassene prüfroutine rausschmeissen.
//AnzeigeLeds zum Anzeigen der Regelabweichung
if (blinkerI == 4) {blinkerI = 0; if (blinker == 1) blinker = 0; else blinker = 1;} blinkerI++;
if ((EstAlt - AltHold) > 0) { digitalWrite(LEDup,LOW);digitalWrite(LEDmid,LOW);d igitalWrite(LEDdown,blinker);}
if ((EstAlt - AltHold) > 30) { digitalWrite(LEDup,LOW);digitalWrite(LEDmid,LOW);d igitalWrite(LEDdown,HIGH);}
if ((EstAlt - AltHold) < 0) { digitalWrite(LEDup,blinker);digitalWrite(LEDmid,LO W);digitalWrite(LEDdown,LOW);}
if ((EstAlt - AltHold) < -30) { digitalWrite(LEDup,HIGH);digitalWrite(LEDmid,LOW); digitalWrite(LEDdown,LOW);}
if (abs(EstAlt - AltHold) < 15) { digitalWrite(LEDmid,HIGH);}
if (abs(EstAlt - AltHold) < 5) { digitalWrite(LEDmid,blinker);digitalWrite(LEDup,bl inker);digitalWrite(LEDdown,blinker);}
ggf schaun ob noch ne variable fehlt
Gruß Deacon Blues mit nen alten Astral im Schrank
Hallo DeaconBlues,
ich nehme an wir sprechen von unterschiedlichen Versionen. Nach deinem letztem Post und einpflegen in den Sketch bekomme ich noch mehr Fehler. Da haut was nicht hin. Trotzdem danke, aber so komme ich nicht weiter. Super wäre es wenn du mir eine Version geben könntest, die ich auf mein System abstimmen kann. Danach kann ich testen wie es funzt.
Gruß Paraglider58
ich nehme an wir sprechen von unterschiedlichen Versionen. Nach deinem letztem Post und einpflegen in den Sketch bekomme ich noch mehr Fehler. Da haut was nicht hin. Trotzdem danke, aber so komme ich nicht weiter. Super wäre es wenn du mir eine Version geben könntest, die ich auf mein System abstimmen kann. Danach kann ich testen wie es funzt.
Gruß Paraglider58
