Boris-Flight - QuoVadis ... Erfahrungen mit der Beta von CleanFlight 1.10
- Themenstarter puk
- Beginndatum
- Status
Natürlich gibt es noch eine Looptime, aber die TuningFreaks brauchen/können nicht mehr am Parameter rumfummeln um sich gegenseitig zu unterbieten. Ist doch eigentlich nicht schlecht, oder wird der Parameter-Wegfall durch was negatives erkauft ? 
Das wiederum muss mit einem delayglied kompensiert werden.
500 Hz sind im - darueber hinaus müsste man die Daten oversampeln. Mit SPI und dem cc3d geht das gut.
Ok, ich stecke bei weitem nicht so tief in der Materie wie du sondern versuche nur zu verstehen. Aber wenn Betaflight jetzt die "schnellstmögliche" Looptime + "Delayglied" macht, müsste die breite Betatester-Masse jetzt flotte Looptimes ohne Jitter kriegen (zumindest besser als mit default=3500), oder macht Betaflight kein "Delayglied" und die DAUs werden jetzt alle mit Jitter kämpfen ?
Oder ist das nur schlecht weil die Experten jetzt nicht mehr manuell die letzten µs rauskitzeln können ?
Oder ist das nur schlecht weil die Experten jetzt nicht mehr manuell die letzten µs rauskitzeln können ?
Betaflight macht keine schnellstmögliche Looptime, sondern synchronisiert den Loopbeginn mit dem Datenupdate vom Gyro/ACC - ist damit implizit getaktet. Die effektive Looptime beträgt auf den F3 Targets (Sparky, SPRF3, Dodo etc.) 500µs, auf den F1 (Naze, CC3D) 1000µs (hier kann ich mich irren - habe selbst nur eine Naze, da sind's auf jeden Fall 1000µs, kann sein dass es auf den F3 jetzt auch so ist und nicht 500). Jitter gibt es keinen bzw. ist dieser insignifikant.
Ah ok, wie gesagt, habt Nachsicht mit einem DAU D.h. nicht die schnellstmögliche Looptime sondern nur so schnell wie das was der Gyro/ACC hergeben, (evtl. zzgl. einem Sicherheitspuffer (Delayglied?)). Aber was ist jetzt der Haken daran ? Machen noch kürzere Looptimes unter bestimmten Umständen Sinn und wird deswegen der Parameter von manchen Usern vermisst ?
D.h. nicht die schnellstmögliche Looptime sondern nur so schnell wie das was der Gyro/ACC hergeben, (evtl. zzgl. einem Sicherheitspuffer (Delayglied?)). Aber was ist jetzt der Haken daran ? Machen noch kürzere Looptimes unter bestimmten Umständen Sinn und wird deswegen der Parameter von manchen Usern vermisst ?Der Sinn dahinter sind nicht die kürzeren Looptimes an sich, sondern eben die Synchronisation auf den Takt von der IMU. Dadurch (und zusammen mit OneShot) wird der Zeitverzug in der Kette "neue IMU-Daten -> PID-Berechnung -> neue Motor-Sollwerte" minimiert und vor allem konstant gehalten. Das ist das Hauptfeature von Betaflight überhaupt, so nach Boris - die ganzen Filter sind zusätzlich.
Die anderen Parameter wurden weggeschafft, da die umgeschriebene Filterung mit den intern gehaltenen Default-Werten so gut wie perfekt läuft, und die meisten User durch Änderungen das ganze nur schlimmer machen.
Die anderen Parameter wurden weggeschafft, da die umgeschriebene Filterung mit den intern gehaltenen Default-Werten so gut wie perfekt läuft, und die meisten User durch Änderungen das ganze nur schlimmer machen.
Schnellere looptimes würde erst wieder ab 8khz Sinn machen da dort die schnellstmögliche Samplerate für den mpu6000 und mpu6050 liegt. Beim neueren mpu6500 sieht die sache wieder anders aus aber das lassen wir mal beiseite.
Sinn der ganzen sache war es das Aliasing zu verringern, das auftreten kann wenn mit unterschiedlichen Frequenzen gearbeitet wird. Schneller loopzeiten machen also momentan keinen sinn. Wichtig ist es aber vorallem dass die minimal mögliche Loopzeit geringer ist als die angesprochenen 1000us. Aber das habe ich ja bereits erwähnt.
Momentan sieht die Sache jetzt so aus:
interrupt funktion alle 1000us //die zeit mit der neue Daten zur verfügung gestellt werden
{
new data=true
}
main loop //entspricht der looptime
{
do stuff
if (new data==true)
{
new data=false
verarbeite neue sensordaten
schreibe motor-ausgänge
}
do some more stuff
}
so richtig jitterfrei ist die ganze Sache also noch nicht da wir momentan nicht sicher sein können dass sich die main loop nicht gerade mit etwas anderem beschäftigt. Merkt man vorallem wenn man noch den Kompass/Barometer aktiviert. Aber es ist schon mal ein Schritt in die richtige Richtung.
Sinn der ganzen sache war es das Aliasing zu verringern, das auftreten kann wenn mit unterschiedlichen Frequenzen gearbeitet wird. Schneller loopzeiten machen also momentan keinen sinn. Wichtig ist es aber vorallem dass die minimal mögliche Loopzeit geringer ist als die angesprochenen 1000us. Aber das habe ich ja bereits erwähnt.
Momentan sieht die Sache jetzt so aus:
interrupt funktion alle 1000us //die zeit mit der neue Daten zur verfügung gestellt werden
{
new data=true
}
main loop //entspricht der looptime
{
do stuff
if (new data==true)
{
new data=false
verarbeite neue sensordaten
schreibe motor-ausgänge
}
do some more stuff
}
so richtig jitterfrei ist die ganze Sache also noch nicht da wir momentan nicht sicher sein können dass sich die main loop nicht gerade mit etwas anderem beschäftigt. Merkt man vorallem wenn man noch den Kompass/Barometer aktiviert. Aber es ist schon mal ein Schritt in die richtige Richtung.
Zuletzt bearbeitet:
Ah ok, also sind die neuen Beta-Features von Boris solange ne feine Sache (weniger Einstellarbeit etc.) bis man Baro/Kompass nutzt, dort kommt dann evtl. Jitter ins Spiel. Für mich also im Moment kein Risiko falls ich mal auf die Idee kommen sollte das Betaflight auszutesten
Letzte Frage: Woran erkenne ich den "Jitter" ?
Letzte Frage: Woran erkenne ich den "Jitter" ?
Zudem kommen wir dann dabei auch wieder an die grenze von Oneshot das mit maximal 4khz (besser sind Werte etwas darunter - zb. 3.9khz) gesendet werden kann . Es kann dann also nur noch jeder zweite neue Wert an die escs gesendet werden.
Aber an die Reaktionszeiten der esc Ausgänge/der Motoren hat dabei aber auch noch keiner gedacht.
. Es kann dann also nur noch jeder zweite neue Wert an die escs gesendet werden. Aber an die Reaktionszeiten der esc Ausgänge/der Motoren hat dabei aber auch noch keiner gedacht.
Zudem kommen wir dann dabei auch wieder an die grenze von Oneshot das mit maximal 4khz (besser sind Werte etwas darunter - zb. 3.9khz) gesendet werden kann . Es kann dann also nur noch jeder zweite neue Wert an die escs gesendet werden.
Aber an die Reaktionszeiten der esc Ausgänge/der Motoren hat dabei aber auch noch keiner gedacht.
. Es kann dann also nur noch jeder zweite neue Wert an die escs gesendet werden. Aber an die Reaktionszeiten der esc Ausgänge/der Motoren hat dabei aber auch noch keiner gedacht.
bei 4 khz macht der atmel auf den billig esc wohl schlapp.
würde mich nicht wundern wenn noch weitere software probleme auftauchen ...
Ah ok, also sind die neuen Beta-Features von Boris solange ne feine Sache (weniger Einstellarbeit etc.) bis man Baro/Kompass nutzt, dort kommt dann evtl. Jitter ins Spiel. Für mich also im Moment kein Risiko falls ich mal auf die Idee kommen sollte das Betaflight auszutesten
Letzte Frage: Woran erkenne ich den "Jitter" ?
Letzte Frage: Woran erkenne ich den "Jitter" ?
Das ganze klingt natürlich alles Tragischer als es in Wirklich ist.. vor nem halben Jahr sind unsere Copter ja auch alle super geflogen
Schnellere Prozessoren f3/f4 Boards helfen hier natürlich auch ungemein. Aber die bessere Lösung wäre natürlich sich von dieser Loop komplett zu entfernen und mit interrupts zu arbeiten / stichwort RealtimeOS
Sprünge in der Loopzeit (erhöhte werte). Baro/Mag/GPS wird mit unterschiedlichen Frequenzen ausgelesen. Sie werden also nur in jedem x-ten Loopdurchlauf verarbeitet. Das führt zu längeren Loopzeiten was wiederum bedeutet, dass der nächste durchlauf nicht mehr Synchron ist und somit kann sich die ganze Sache verschieben und es wird mit veralteten Werten gearbeitet.
Das ganze klingt natürlich alles Tragischer als es in Wirklich ist.. vor nem halben Jahr sind unsere Copter ja auch alle super geflogen
Schnellere Prozessoren f3/f4 Boards helfen hier natürlich auch ungemein. Aber die bessere Lösung wäre natürlich sich von dieser Loop komplett zu entfernen und mit interrupts zu arbeiten / stichwort RealtimeOS
Das ganze klingt natürlich alles Tragischer als es in Wirklich ist.. vor nem halben Jahr sind unsere Copter ja auch alle super geflogen
Schnellere Prozessoren f3/f4 Boards helfen hier natürlich auch ungemein. Aber die bessere Lösung wäre natürlich sich von dieser Loop komplett zu entfernen und mit interrupts zu arbeiten / stichwort RealtimeOS
Ja, dass stimmt natürlich. Aber es muss ja auch nicht gleich ein RTOS sein. Dafür müsste man das Rad wahrscheinlich eh neu erfinden für cleanflight und dafür gibt es ja eh schon die Openpilot derivate. Es reicht ja auch schon sich so stark wie möglich von dieser while(1) Schleife zu entfernen und diese ganze Sensor/Input/output Verarbeitungen durch timer-gebundene Interrupts auszulösen. Natürlich muss man dabei dann auch auf die Prioritäten achten. Allerdings bin ich auch nicht so stark informiert über die ganze stm32 Architektur und weiß auch gar nicht ob dafür überhaupt noch Timer zur verfügung stehen.
Zuletzt bearbeitet:
Hehe, okok, da sind wir wieder bei "Das ist alles grundlegend im Eimer". Das die Architektur "suboptimal" ist hat ja TC schon vor Jahren gepredigt Sparky2/Taulabs soll da vom Konzept her bei den OS-Sachen im Moment ja halbwegs tauglich sein habe ich mir sagen lassen.
Aber das ist hier ja nicht das Topic. Ich wollte eigentlich nur wissen ob die leicht durchklingende Kritik an dem neumodischen Betaflight-Kram (neben den ganzen Lobpreisungen der Fans) mich evtl. davon abhalten sollte das auch mal auf nem kleinen flotten Copter zu testen
Sparky2/Taulabs soll da vom Konzept her bei den OS-Sachen im Moment ja halbwegs tauglich sein habe ich mir sagen lassen.Aber das ist hier ja nicht das Topic. Ich wollte eigentlich nur wissen ob die leicht durchklingende Kritik an dem neumodischen Betaflight-Kram (neben den ganzen Lobpreisungen der Fans) mich evtl. davon abhalten sollte das auch mal auf nem kleinen flotten Copter zu testen
Als neumodischen Kram würde ich es nicht bezeichnen. Vielleicht hatte ich mich zuvor da etwas unglücklich ausgedrückt Es hat schon seinen Mehrwert - wir müssen halt mit dem arbeiten was uns zur verfügung steht ^^.
Und mal von der Code-Architektur abgesehen - finde ich einfach dass es sich super fliegen lässt und auch ziemlich einfach zu tunen ist dank Blackbox . Eine Mehrheit der Top-Piloten (waran auch immer man sowas festlegt) fliegen ja auch mit cleanflight und haben teilweise auch von OP her gewechselt.
Und mal von der Code-Architektur abgesehen - finde ich einfach dass es sich super fliegen lässt und auch ziemlich einfach zu tunen ist dank Blackbox
. Eine Mehrheit der Top-Piloten (waran auch immer man sowas festlegt) fliegen ja auch mit cleanflight und haben teilweise auch von OP her gewechselt.
Zuletzt bearbeitet:
Man muss ja nicht zwangsweise die ganze Regelung dann auf 8kHz laufen lassen.
Für Taulabs mache ich es so, das ich den Gyro zwar mit 8kHz auslese dann aber ein down-sampling inkl. anti-aliasing auf die "Wunsch" Frequenz mache, mit der dann die Regelung läuft.
Also praktisch das was die MPU auch mit DLPF=188 macht (von 8kHz auf 1kHz).
Nur mache ich das in Software und bin dabei flexibler was z.B. die Filterung angeht und auch nicht nur auf 1kHz festgelegt, sondern kann auch Werte zwischen 1kHz und 8kHz einstellen.
Und BlHeli kann auch mit 0-100%PWM angesteuert werden.
Da kann man dann z.B. auch mit 4kHz (0-250µs) oder 8kHz (0-125µs) arbeiten anstatt OneShot125 (125µs-250µs).
Zumindest in Taulabs kann man die Ausgänge auch darauf konfigurieren.
Edit:
Ich selber habe kein Sparky2, aber von jemandem der meinen branch testet gab es feedback das beim down-sampling von 8kHz auf 4kHz die CPU last bei 40% liegt.
Bei 8kHz auf 1.6kHz nur noch 23-24%.
Für Taulabs mache ich es so, das ich den Gyro zwar mit 8kHz auslese dann aber ein down-sampling inkl. anti-aliasing auf die "Wunsch" Frequenz mache, mit der dann die Regelung läuft.
Also praktisch das was die MPU auch mit DLPF=188 macht (von 8kHz auf 1kHz).
Nur mache ich das in Software und bin dabei flexibler was z.B. die Filterung angeht und auch nicht nur auf 1kHz festgelegt, sondern kann auch Werte zwischen 1kHz und 8kHz einstellen.
Und BlHeli kann auch mit 0-100%PWM angesteuert werden.
Da kann man dann z.B. auch mit 4kHz (0-250µs) oder 8kHz (0-125µs) arbeiten anstatt OneShot125 (125µs-250µs).
Zumindest in Taulabs kann man die Ausgänge auch darauf konfigurieren.
Edit:
Ich selber habe kein Sparky2, aber von jemandem der meinen branch testet gab es feedback das beim down-sampling von 8kHz auf 4kHz die CPU last bei 40% liegt.
Bei 8kHz auf 1.6kHz nur noch 23-24%.
Zuletzt bearbeitet:
- Status
