Boris-Flight - QuoVadis ... Erfahrungen mit der Beta von CleanFlight 1.10

Beta-Flight - Erfahrungen mit der Beta von CleanFlight 1.10 (BorisB Version)

EDIT 22.09.2015
Aktuelles Update der neuersten Versionen:
BorisB zum Setup am eigenen Copter (21.09.15)
BorisB Video mit dterm Noise
----------------------------------------------------------------------------

Ahoi,

Da das Thema in vielen Threads als Offtopic auftaucht, dachte ich mir, dass ein eigener Thread zu der Beta-Flight 1.10 vielleicht für manche hilfreich wäre.

Letzten Endes scheint es um die Einstellung folgender Parameter zu gehen:

set sync_gyro_to_loop = 1
// Boris Haupt Feature

set rc_smoothing = 1
// Boris Feature .. Interpolation des RC-Signales um für jeden Gyro-Berechnungszyklus einen validen PPM Signalpunkt zu haben

set gyro_lpf = 188
// -->siehe Post #3 und weitere von p911 hier ist ev. ein Setting von 188 realistischer hinsichtlich Möglichkeiten des FC ->saubereres Signal

set gyro_cut_hz = 60-100 // Filter Startwert gut... anpassen nach persönlichen Bedürfnissen (siehe Post #5,#6)
set pterm_cut_hz =40-60 // Filter Startwert gut... anpassen nach persönlichen Bedürfnissen (siehe Post #5,#6)
set dterm_cut_hz = 8-15 // Filter Startwert gut... anpassen nach persönlichen Bedürfnissen (siehe Post #5,#6)
// bei den Filtern gilt: ->Exec: "sollte so klein wie nötig aber so groß wie möglich gewählt werden"

set looptime = 0
// mit dem wert "0" sagst du dem System, dass es "so schnell wie möglich" soll... in Verbindung mit dem sync_gyro_to_loop, gibt somit der gyro das Tempo vor --> Update looptime=0 bzw. kleiner 1000 kann derzeit Probleme mit den Dys Reglern bringen (siehe post #6)

set acc_hardware=1/0
// accelerometer mit Wert "1" ausschalten für looptimes so schnell es das System bzw. der gyro schafft (etwa 600+), dann aber nur acro... sonst etwa looptime bei 1600

zumindest hätte ich das so verstanden ... man möge mich bitte korrigieren, sollte das nicht passen.. bei mir fliegt er so sehr gut (controller luxfloat).

Quelle: Boris-Flight Thread RcGroups

!Wichtig!
- Die Filter (cut_hz) Werte sind keine globalen Variablen und binden sich jeweils an das PID-Profil (1,2,3)
- Wer früher einen cmix in Cleanflight eingegeben hatte, kann das auch weiterhin -> doch wird der "cmix" Befehl zu einem "mmix" und die Nummerierung der Motoren startet mit "0" und nicht wie bisher mit "1".
!Wichtig!

Wie sind eure Erfahrungen mit der Boris-Beta-Flight Version von CL 1.10?
Wie geht ihr mit den Filtern um?

puk

EDIT: Update aus User-Inputs in OP

spitzen Zusammenfassung puk, danke erstmal dafür, werd ich gleich mal umsetzen und meine Erfahrung hier anhängen

Mit "set gyro_lpf = 0" läuft die MPU mit 8kHz und mit "set sync_gyro_to_loop = 1" und "set looptime = 0" versucht die FC auch das zu machen.
Nur dürfte keines der momentan offiziell unterstützten targets die 8kHz schaffen. Die meisten haben die MPU mit I2C angebunden, und/oder der µC ist zu langsam.

Ich denke wenn man es trotzdem so einstellt, werden beim auslesen der Samples bzw. der Regelung einfach Samples übersprungen.
Das kann zu jitter und aliasing Problemen führen.

Ich entwickel zwar für Taulabs, hatte aber mit BorisB bezüglich seiner Gyro Sync Entwicklung Kontakt, da ich für Taulabs gerade 8kHz Gyro sampling mit anti-aliased down-samling implementiere (das Gyro Sync ist in Taulabs schon lange drinne).

Für cleanflight / Betaflight ist glaube ich die aktuelle Empfehlung "set gyro_lpf = 188" (dann läuft die MPU mit 1kHz, bzw. hat intern ein anti-aliased down-samling auf eine 1kHz Ausgangs Rate).

Um in cleanflight mit einer FC mit F1 µC, wie z.B. Naze32, die 1kHz zu schaffen muss glaube ich der/das ACC ausgeschaltet werden. F3 targets schaffen die 1kHz auch mit ACC:
- https://github.com/cleanflight/cleanflight/pull/1186#issuecomment-128503031
- https://github.com/cleanflight/cleanflight/pull/1173#issuecomment-127727504

Hi Exec,

Danke dir für den fundierten Input ... werde das mit dem lpf berücksichtigen und testen.
Zusammenfassend: Wenn man mit set = 0 für looptime und lpf den "so schnell wie möglich Modus" mit 8khz Target aktiviert, könnte das zu übersprungenen Samples und somit Jitter führen -> ein Setting von lpf=188 und fixierter Looptime wäre somit vorzuziehen? Habe ich das richtig verstanden?

puk

BorisB empfiehlt aktuell auch gyro_lpf=188. Bei RcGroups hat J. Bardwell ein sehr interessantes Frequenzsspekrum gepostet an dem man den unterschied krass erkennt - mit 188 ist das Signal seeeehr viel ruhiger und vor allem viel weniger Aliasingfrequenzen im Bild. Quelle


gyro_lpf=256 (8 kHz sampling, limited by i2c bus to something like 2 kHz at most)
looptime=1200 (833 Hz)

Laut BorisB sind für den Copterflug grundsätzlich nur Frequenzen bis etwa 50Hz relevant. Der einzige Grund für gyro_lpf=0 ist bisher die zusätzliche Verringerung von Latenzen durch den Hardwarefilter. Ob das spürbar ist wage ich mal zu bezweifeln




gyro_lpf=188 (1 kHz sampling)
looptime=2000 (500 Hz)

P_term_cut_hz würde ich nicht 40 als "default" bezeichen. Lieber etwas höher ansetzen (60) und bei Bedarf kleiner wählen. Bei zu niedrigem cut hz ist es möglich dass der Copter sehr schnell anfängt zu schwingen obwohl die PIDs super niedrig sind. War bei mir auch so.

Zur Looptime: 0 oder <1000 führt derzeit zu Problemen mit den DYS ESCs. Es gibt dafür eine modifizierte .hex, ich warte aber noch bis das ganze offiziell wird. Looptime=2000 und gyro sync=1 funktioniert bei mir aber sehr gut.

d_term_cut_hz: Hier ist nicht unbedingt "desto kleiner, desto besser". Auch wenn das von manchen Nutzern so interpretiert wird. Es stimmt, dass die D Werte größer gewählt werden können bei niedrigerer Grenzfrequenz. Allerdings kann es zu Problemem mit Propwash kommen. Bei mir hat sich das mit Oszillationen beim schnellen Sinken geäußert. Eine Änderung von 12 auf 15 hat das gelöst.

gyro_cut_hz: Auch hier wird von BorisB 60-100 empfohlen und man sollte sich von oben nach unten arbeiten. Kannst du vielleicht oben ergänzen. 60 wäre eher die untere Grenze.

Ermittlung von gyro_cut_hz: Blackbox log anschauen, auf 10% zoomen und die Gyrospuren anschauen. Wenn sie sehr sauber sind etwas erhöhen, wenn viele feine Spitzen (Oszillationen) vorhanden sind etwas absenken. Ich kann in den nächsten Tagen mal Beispielbilder ergänzen.

Ich lasse mich gerne korrigieren, ich befinde mich auch noch in der Lernphase was die Filter angeht.
Super Idee hier einen Thread zu starten! Hatte ich auch schon überlegt.

Und zur weiteren Info kann ich nur den Kanal von Joshua Bardwell auf YT empfehlen: Klick. Einfach mal ein paar Videos anschauen und man bekommt ein gutes Gefühl für "gute" und "schlechte" Setups anhand der Blackbox-Logs.

Allgemein hat die aktuelle BlHeli Version mit OneShot125 Signalen wohl Probelme wenn die prinzpielle Rate 1kHz oder 2kHz ist, aber dann Jitter drauf ist.
Dann funktioniert die auto signal detection wohl nicht, und der ESC armed nicht.
Prinzipiell scheint das in beta Versionen inzwischen gefixed zu sein, und BorisB hatte für ein paar ESC die Beta Version veröffentlicht.

Mit KISS ESC sollte es aber funktionieren.


Bezüglich der übersprungenen Abtastwerte bei 8KHz:
Jitter sollte vor allem dann auftreten wenn das "überspringen ungleichmäßig ist".
Aber auch wenn das ganze sehr regelmäßig wäre und exakt immer z.B. jedes 5te sample nur gelesen/ausgewertet wird, entspricht das einem neuem Sampling und man muß wieder die Nyquist Regel beachten.
Sonst kann es zu aliasing Problemen kommen.

Und auch die Software Tiefpass Filter haben meinem Verständnis/Untersuchungen nach Latenzen, nicht nur der DLPF in der MPU.
Und die Latenz ist um so größer, je kleiner die Cutoff Frequenz des Filters gewählt wird.

Die Latenzen haben dann natürlich auch einen negativen Einfluss auf die Regelung.
Daher würde ich sagen, "xyz_cut_hz" sollte so klein wie nötig aber so groß wie möglich gewählt werden.
Aber wie gesagt habe ich mit cleanflight keine praktischen Erfahrung.

Das kann ich nur so bestätigen. Hat sich auch beim testen gezeigt.

full ack.
die ganze implementation ist noch nicht ganz ausgegoren.

Ja super alles sehr toll erklärt , evtl. Kann man ja auch seine Videos (auch mit Blackbox) hier posten

Und so mit Hilfe der anderen die perfekten Einstellungen finden !
Was meint ihr ?

Bezüglich cut_hz und Verzögerungen fand ich folgendes Bild ganz Informativ.


Verzögerungstechnisch kann man da auch ganz schnell wieder bei dem alten gyro_lpf=42 landen.

Das stammt von mir
Hatte es im rcgroups Forum mal gepostet: http://www.rcgroups.com/forums/showpost.php?p=32475691&postcount=1108

Keine Verbindung nach Flashen der Firmware

Ich hoffe hier richtig zu sein...könnte mir wer von Euch "Kracks" helfen?
Habe folgende Hex-Datei geladen und es kommt auch die Meldung, dass die Firmware erfolgreich geflasht wurde. Beim connetcten leuchtet jedoch nur eine blaue LED und der port schliesst dauernd wieder. Folgende HEX-Datei habe ich geflasht:
https://github.com/borisbstyle/cleanflight/blob/betaflight/obj/betaflight_NAZE32PRO.hex

Zu erwähnen ist vielleicht noch, dass die FC eine Naze32 Clone mit einer MW32 ist. Nach einem zurückflashen mit der "Original" Datei in Cleanflight, ist die FC jedoch wieder voll funktionstüchtig.
Ich bedanke mich im voraus!
Beste Grüsse, Terry

Falsche Firmware, du brauchst die Naze.hex. Naze Pro ist was ganz anderes.

OP ergänzt

puk

Ist auch gut so, dann kann man z.b. bei einem 4s Profil stärker filtern, falls die vibriert stärker sind.

Vielen dank! ....hat nun geklappt... ich hab gedacht die Naze.hex wäre nur für die Acro.

Das ganze Thema ist heute wohl hinfällig geworden: RcGroups

Betaflight V2 muss nur noch bezüglich PID getuned werden. Alles andere soll defaultmäßig schon so gut sein dass keine Änderung mehr nötig ist.

Wo gibt es die v2 ? Würde ich gerne mal testen

liest sich sehr gut.. ein wasserfester Copter muss her.

Boris aktualisiert eigentlich immer fix seinen Start Post ... der führt zu Github

puk

Ich hab mit der neuen Version ziemlich wilde D-Term Sprünge.. da sah die Version von vor 2 Tagen noch erheblich besser aus.