Ergänzend zu meinem Beitrag über Looptime im Allgemeinen, erkläre ich diesmal, warum man das Auslesen der Gyro-Werte und das Berechnen der PID-Korrektur in Betaflight scheinbar unabhängig regeln kann.
Die in der Warnmeldung geforderte Überprüfung führt ihr mit „status” und „tasks” aus.
Inhalt
Begriffe
Gyro update frequency bezieht sich auf das Auslesen der MPU, also des Chips, der Gyro, Accelerometer und eventuell noch andere Sensoren beeinhaltet. Die Frequenz wird in kHz angegeben und besagt, wie oft pro Sekunde die CPU einen neuen Wert von der MPU abholen soll
PID loop frequency ist die Rate, mit der die Werte der MPU mit den PID-Algorithmen verrechnet werden, um letztendlich zu den Werten zu kommen, die an die ESCs (und somit an die Motoren) weitergegeben werden.
Flaschenhals I²C
Die kleinen Chips auf unseren Flugsteuerungen sind leider nicht beliebig schnell. Die maximal mögliche Ausleserate der MPU hängt davon ab, mit welcher Datenleitung diese angebunden ist. Naze32, KISS und SP Racing F3 Mini haben an dieser Stelle einen I²C Bus, der die Update-Frequenz auf 1kHz beschränkt. Mit SPI sind 8kHz und mehr möglich. Hier begrenzt eher die CPU. Wird öfter PID durchgerechnet, sind weniger Gyro-Updates möglich. Flugsteuerungen mit SPI sind unter anderem CC3D und SP Racing F3 (ohne „Mini” und inkl. „Evo”).
Die zur Zeit noch seltenen F4 Flugsteueurungen sind angeblich so schnell, dass sie alles mit jeweils 32kHz schaffen. Hier sieht man, wie flott SPI sein kann.
Zähler und Nenner
Die Beide Werte sind abhängig voneinander. Das liegt daran, dass die eingangs erklärten Operationen immer nacheinander ausgeführt werden. Sind die beiden Frequenzen gleich, wird einmal Gyro ausgelesen, danach einmal PID berechnet.
Ist der erste Wert dopppelt so hoch, wird zweimal Gyro ausgelesen, dann einmal PID berechnet usw…
Die Frequenz der PID-Berechnung kann nicht höher gesetzt werden als das Auslesen der MPU, da man dann ja mit den selben Werten (oder ganz ohne) rechnen würde. Das wäre entweder Zeitverschwendung oder würde zu vollkommen falschen Ergebnissen führen.
Wer schonmal versucht hat, die Frequenzen per CLI einzustellen, wird gesehen haben, dass die Variablen was mit Bruchrechnung zu tun haben. Das liegt daran, dass man sich für die umgekehrte Ausdrucksweise von „lies n mal die MPU aus vor dem Gyro Update” entschieden hat.
Maximale Frequenz ermitteln
Damit wir die beste Performance aus unseren Flugsteuerungen rauskitzeln können, wollen wir möglichst hohe Frequenzen haben, aber nicht zu hoch, sodass die CPU nicht mehr in Echtzeit arbeiten kann. Denn dann kämen die Korrekturen zeitlich stark verzögert (Betaflight verbietet es sinnvollerweise, die Motoren zu entsperren, wenn die CPU überlastet ist).
Die reine CPU-Last erfahren wir mit dem Befehl status im CLI. Mehr als 20% sollte es nicht sein.
Sowohl das MPU-Auslesen, als auch die PID-Berechnung brauchen CPU Zeit, die letztendlich als Load auch im Status angezeigt werden. Um differenzierter sehen zu können, welcher Teil der Berechnung jetzt wie viel Zeit in Anspruch nimmt, kann man tasks eingeben.
Öfter Auslesen als PID Berechnen?
Insbesondere bei dynamischen Flügen können schnelle Oszillationen auftreten, zum Beispiel durch den Downwash der Props. Wenn ich so etwas mit einer niedrigen Sample Rate auslese, sehe ich die Oszillationen falsch, wenn sie schneller sind als meine Sample Rate (Aliasing). Anstatt auf eigentliche hochfrequente Schwingung zu reagieren, wird die fälschlicherweise gemessene Alias-Schwingung korrigiert. Das passt natürlich nicht zusammen und der Kopter fügt noch mehr Unruhe hinzu, anstatt sie zu dämpfen.
Mit entsprechend hoher Abtastrate entsteht diese Alias-Kurve nicht. Stattdessen reagiert der PID-Controller wie gewünscht auf die Abweichung, die sich in der Zeit aufsummiert hat. Das kann unter Umständen auch bedeuten, dass gar nicht korrigiert wird, weil die Abweichung zwischen zwei PID-Loops in beide Richtungen gleichstark war.
OneShot125, OneShot42, MultiShot
Welche PWM Variante für das Ansteuern der ESCs notwendig ist, damit die Werte schnell genug von den Motoren umgesetzt werden, hängt von der PID loop frequency ab. Ab 1kHz braucht man OneShot125. Schneller als 4kHz mindestens OneShot42. Oberhalb von 12kHz schafft es zur Zeit nur MultiShot.
Flugfähige Kombinationen bei Walkera
Alle Walkeras, die wir bisher auf Betaflight flashen konnten (Zur Zeit Rodeo 150 und F210), haben eine SP Racing F3 mit SPI.
Optimiert man die Einstellungen, indem man die Anzahl der Aux-Kanäle auf 2 reduziert und Accelerometer abschaltet, sind 4/4 kHz bei 13% CPU-Last möglich. Bei aktivem Acc und ggf. auch ein paar zusätzlichen Steuerkanälen sind 4⁄2 kHz problemlos möglich, was auch schon hervorragend fliegt und nebenbei Angle und Horizon Mode erlaubt.
Fazit
Das getrennte Einstellen der beiden Frequenzen sorgt dafür, dass man das meiste aus seiner Flugsteuerung rausholen kann. Wenn man verstanden hat, wie es funktioniert, ist es recht einfach, die richtigen Werte zu finden und man kann zum Glück nicht viel falsch machen.
was bringt es eine looptime bei 2 khz oder 4 khz zu haben wenn der ESC eh nur 50 hz oder 400 hz schalten kann ? der ESC / Motor ist doch viel zu träge als so schnell auf die Datenmassen reagieren zu können.
Moderne ESCs mit SimonK oder BlHeli sind wesentlich schneller als 500Hz. In Kombination mit Multishot können die problemlos mit 32kHz angesteuert werden.