@Jürgen: Es sicherlich eine schöne Gewissheit, den grössten zu haben. Die Frage ist nur ob, und wie er zum Einsatz kommt!
@Alle:
Mittlerweile habe ich mir die Multiwii Geschichte (natürlich nur in den wesentlichen Teilen) nochmal unter dem Timingaspekt angeschaut, und erstaunliches zu Tage gefördert.
Klar, Accelerometerdaten (m/s*s) müssen natürlich auf die aktuelle Zeit, und die vergangene Zeit bezogen werden ("DeltaT"). Bisher habe ich dazu einfach die "cycletime" verwendet, Alexmos und Mahowik nehmen dazu die Zeit bei Ausführung des Barocodes. Die eigentlich korrekte Zeitbasis ist allerdings die, wenn die ACC Daten auch tatsächlich vom Sensor ausgelesen werden, weil der Unterschied zwischen den ACC Werten sich auch nur auf diesen Zeitunterschied beziehen kann. (EDIT: Eigentlich sollte man annehemen, dass es relativ egal ist, wann man den Zeitunterschied bestimmt. Wenn man sich aber die tatsächliche Zeit, und Schwankungen durch Interrupts und verschiedene Laufzeiten des Codes ausgeben lässt, gehen einem die Augen auf/über. Zufälligerweise lag sogar die Cycletime-Methode näher an der Wahrheit.) Das Vorgehen von oben lässt sich also, ohne viel Aufwand, optimieren. Bei der Berechnung der Copterlage (ACC & Gyro werden ausgelesen und verarbeitet) wird schon das benötigte, relevante "DeltaT" bestimmt! Aus Spar - Gründen wird die Auflösung des Timers allerdings von 32Bit auf 16Bit reduziert, was zu Rechenfehlern führt, wenn die 16Bit über Null "durchrollen" und die vergangene Zeit aus der Differenz, dann z.B negativ werden kann, wenn der erste Wert noch vor dem "Durchrollen" bestimmt wurde und die aktuelle Zeit danach (aktuelle Zeit - letzte Zeit). Es wird also 15 mal in der Sekunde Lotto gespielt, statt 1 mal in 76 Minuten (32 Bit). Irgendwann steht natürlich der Hauptgewinn an, das kann einer guten Fluglage nicht förderlich sein. Ich finde, in so einer Kernroutine sollte man schon die volle Auflösung beibehalten. Die Änderung kostet letztlich nur 10 Byte! Wer das auch so sieht, kann die Änderung selbst einfach durchführen: (unabhängig vom Baromod)
(EDIT: oder sehe ich das komplett falsch??)
Original "IMU" bei "void getEstimatedAttitude()" steht ab Zeile 185:
Änderung:
Zurück zum Thema. Das Verwenden der korrekten Zeitbasis für die Baro/Acc Fusion hat deutlich genauere Werte gebracht!!
Ich bin mal gespannt, wie sich das in der Realität auswirkt!
LG
Rob
P.s.: Regentage können auch nützlich sein....
EDIT: In diesen Zeitreise - science - fiction Raumschiffen ist immer alles klar. Die multiwii würde auf jeden Fall schwersten Ärger während des Zeitsprungs machen, da nur eine gleichmässig fortschreitende Zeit berücksichtigt wird
. Deswegen sollte man mit seinem Copter auch nicht im Bereich der Lichtgeschwindigkeit fliegen .
@Alle:
Mittlerweile habe ich mir die Multiwii Geschichte (natürlich nur in den wesentlichen Teilen) nochmal unter dem Timingaspekt angeschaut, und erstaunliches zu Tage gefördert.
Klar, Accelerometerdaten (m/s*s) müssen natürlich auf die aktuelle Zeit, und die vergangene Zeit bezogen werden ("DeltaT"). Bisher habe ich dazu einfach die "cycletime" verwendet, Alexmos und Mahowik nehmen dazu die Zeit bei Ausführung des Barocodes. Die eigentlich korrekte Zeitbasis ist allerdings die, wenn die ACC Daten auch tatsächlich vom Sensor ausgelesen werden, weil der Unterschied zwischen den ACC Werten sich auch nur auf diesen Zeitunterschied beziehen kann. (EDIT: Eigentlich sollte man annehemen, dass es relativ egal ist, wann man den Zeitunterschied bestimmt. Wenn man sich aber die tatsächliche Zeit, und Schwankungen durch Interrupts und verschiedene Laufzeiten des Codes ausgeben lässt, gehen einem die Augen auf/über. Zufälligerweise lag sogar die Cycletime-Methode näher an der Wahrheit.) Das Vorgehen von oben lässt sich also, ohne viel Aufwand, optimieren. Bei der Berechnung der Copterlage (ACC & Gyro werden ausgelesen und verarbeitet) wird schon das benötigte, relevante "DeltaT" bestimmt! Aus Spar - Gründen wird die Auflösung des Timers allerdings von 32Bit auf 16Bit reduziert, was zu Rechenfehlern führt, wenn die 16Bit über Null "durchrollen" und die vergangene Zeit aus der Differenz, dann z.B negativ werden kann, wenn der erste Wert noch vor dem "Durchrollen" bestimmt wurde und die aktuelle Zeit danach (aktuelle Zeit - letzte Zeit). Es wird also 15 mal in der Sekunde Lotto gespielt, statt 1 mal in 76 Minuten (32 Bit). Irgendwann steht natürlich der Hauptgewinn an, das kann einer guten Fluglage nicht förderlich sein. Ich finde, in so einer Kernroutine sollte man schon die volle Auflösung beibehalten. Die Änderung kostet letztlich nur 10 Byte! Wer das auch so sieht, kann die Änderung selbst einfach durchführen: (unabhängig vom Baromod)
(EDIT: oder sehe ich das komplett falsch??)
Original "IMU" bei "void getEstimatedAttitude()" steht ab Zeile 185:
Code:
static uint16_t previousT;
uint16_t currentT = micros();
Code:
static uint32_t previousT;
uint32_t currentT = micros();Ich bin mal gespannt, wie sich das in der Realität auswirkt!
LG
Rob
P.s.: Regentage können auch nützlich sein....
EDIT: In diesen Zeitreise - science - fiction Raumschiffen ist immer alles klar. Die multiwii würde auf jeden Fall schwersten Ärger während des Zeitsprungs machen, da nur eine gleichmässig fortschreitende Zeit berücksichtigt wird
. Deswegen sollte man mit seinem Copter auch nicht im Bereich der Lichtgeschwindigkeit fliegen .
