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

[MaxWin]

Ich werf hier mal ein Phänomen in den Raum, vielleicht hat ja jemand was davon gehört:

Auf meinem ZMR ist nun der neuste Build vom 25.9. Drauf. Er fliegt super, Stable und Acro sind hammer, doch der Horizon verhält sich ganz anders.
Bei meinem Cleanflight Coptern ist das Zurückstellen auf Level im Level und Horizon gleich, bei dem ZMR mit Betaflight ist das zurückstellen auf gerade vie träger und Langsamer.

Hat sich da was geändert das ich nicht mitbekommen habe?

 

[schnellmaleben]

Zufällig PIDController 1 ? Schau mal hier, im Horizon mappt LevelI auf eigentlich P. Wenn die Defaults (im betaflight) anders sind, passt es vielleicht so nicht.

 

[goOse]

Er sagte, dass du das OSD ziehen mussst, damit USB mit Akku weiterhin geht (sonst ist RX/TX durch das OSD in Benutzung)

Ja Yordan, ich hab es gestern schon entfernt und getestet nachdem du mir den Tipp gegeben hast. Es scheint als würden alle motoren in der Mittelstellung 1500) starke viberationen haben. Ich habe heute schon vier neue bestellt. Insofern scheint es ein Hardware Problem zu sein und hat wohl weniger mit dem PIDs zu tun wie ich eigentlich vermutet hatte.

btw. Das beschriebene Verhalten von MaxWin habe ich bei PIDC2 auch beobachtet. Im Anglemode kommt er schnell wieder in die Waagerechte, im Horizon braucht er deutlich länger um sich wieder auszurichten.

 

[Arakon]

Die Vibrationen in Mittelstellung sind mehr von den ESCs abhängig, bzw. ein generelles Problem.. die Motoren fangen in dem Bereich an harmonisch zu schwingen. Das wird mit neuen Motoren nicht besser, nur der genaue Punkt dafür wird sich verschieben.

 

[puk]

btw. Das beschriebene Verhalten von MaxWin habe ich bei PIDC2 auch beobachtet. Im Anglemode kommt er schnell wieder in die Waagerechte, im Horizon braucht er deutlich länger um sich wieder auszurichten.

Das hätte ich so auch als "by design" verstanden. Unter den LEVEL PIDs konfiguriert man mit P die Stabilisierungskraft des Angle-Modes (zB 6), mit I die Kraft im Horizon Mode (zB 0,030 == 3, also zB die Hälfte des Angle Modes) und mit D stellt man ein, wieviel "Selbststabilisierung" überhaupt im Steuerbefehl, abhängig vom aktuellen Stick Ausschlag, bei Horizon sein soll.

Soweit ich das im Kopf habe, wurde der C2 Horizon Mode auch relativ schnell in Betaflight überarbeitet, kann gut sein, dass er sich anders anfühlt als in der Cleanflight -> kann aber wie schon geschrieben mit den LEVEL PIDS ( I und D ) angepasst werden.

Github

puk

 

[MaxWin]

Das hätte ich so auch als "by design" verstanden. Unter den LEVEL PIDs konfiguriert man mit P die Stabilisierungskraft des Angle-Modes (zB 6), mit I die Kraft im Horizon Mode (zB 0,030 == 3, also zB die Hälfte des Angle Modes) und mit D stellt man ein, wieviel "Selbststabilisierung" überhaupt im Steuerbefehl, abhängig vom aktuellen Stick Ausschlag, bei Horizon sein soll.

Soweit ich das im Kopf habe, wurde der C2 Horizon Mode auch relativ schnell in Betaflight überarbeitet, kann gut sein, dass er sich anders anfühlt als in der Cleanflight -> kann aber wie schon geschrieben mit den LEVEL PIDS ( I und D ) angepasst werden.

Github

puk

Danke puk & schnellmaleben, das erklärt es natürlich. Und auch warum das Level-Pid-Tuning sich so komisch angefühlt hat. Doku lesen hilft halt doch

Werd es die Tage mal testen und - vorausgesetzt ich erinnre mich dran - rück melden.

 

[goOse]

Danke sehr für den Hinweis. Das ist eine recht interessante Information. Yordan, schrieb mir sowas die Tage auch schon, dass wohl da ein Fehler (oder irreführend bezeichnend) GUI ist. Sobald mein Vibration (hochfrequentes YAW Zittern) beseitigt ist, probiere ich mal ein wenig mit den LEVEL Werten rum.

@Arakon:
Wie gesagt, ich hab gestern recht lange mit den Motor-Tab in CF probiert. Im unteren Drehzahlbereich war bei jedem Motor die Vibration relativ gering, um 1500 war sie bei fast allen Motoren am stärksten und oberhalb von 1500 wurde sie mit zunehmender Drehzahl wieder geringer. Das deckt sich also sehr gut mit einer Aussage. Dabei waren die Schwingungen der Motoren mehr oder weniger in alle Richtungen. Gegen Schwingungen der Z&X Achse habe ich versucht was zu machen, indem ich Klebenbandstreifen/Teasfilm an die Außenseite der Gondel geklebt hatte. Das reduzierte auch etwas die Schwingungen. Jedoch löste sich das Band relativ schnell wieder. Jedoch wüsste ich nicht, was ich gegen die Schwingung der Y Achse machen sollte.

Des Weiteren ist mit der Gedanke gekommen, dass die Logs der Blackbox im Anhängigkeit der Looptime aufgenommen werden. Sprich, schnelle looptime, mehr Daten in kürzerer Zeit. Kann es auch sein, dass die angezeigten Vibrationen im Logfile so zackig waren weil halt mehr Details/sek. aufgezeichnet werden, wie wenn zB ne looptime von 2000 eingestellt wäre? Weniger Daten/sek. würde ja auch weniger Details bedeuten und automatisch glatter wirken...

 

[KenshiHH]

Genau das gleiche Problem mit den Vibrationen hab ich auch mit mein 250er

ZMR250
DYS SN20A
Dys BE1806

1500us fangen die vibrationen an, 1550us sind die am stärksten und bei 1600us sind sie fast weg.

Betrifft alle 4 Motoren.

goOse, würde mir freuen wenn du mich auf den laufenden hälst ob neue Motoren das problem lösen.

 

[puk]

Genau das gleiche Problem mit den Vibrationen hab ich auch mit mein 250er

ZMR250
DYS SN20A
Dys BE1806

1500us fangen die vibrationen an, 1550us sind die am stärksten und bei 1600us sind sie fast weg.

Betrifft alle 4 Motoren.

goOse, würde mir freuen wenn du mich auf den laufenden hälst ob neue Motoren das problem lösen.

Ihr dürft bei der Betrachtung des Themas nicht den Rahmen vernachlässigen, dieses Verhalten klingt sehr stark nach einer vom Motor getroffenen Resonanz-Frequenz des Rahmens.

puk

 

[lysie]

Der Rahmen hat dabei definitiv einen Einfluss.. konnte das bei mir auch über verschiedene Motoren hinweg festellen. Zudem hat aber auch das aktivieren und deaktivieren von active breaking diesen Vibrationspunkt verschoben. Seitdem ich aber von den billig 3mm Armen an meinem Zmr250 auf etwas hochwertigere 4mm Arme gewechselt habe, ist das Problem komplett weg.

 

[KenshiHH]

Ok danke, hab mich schon so etwas ähnliches gedacht, werde am kommendes wochenende mal nen wenig rumtesten.

 

[goOse]

@PUK: Ja, sorry. Da hast du völlig Recht. Das eigentliche Tema wird/wurde völlig verwässert. Aber zu meiner Verteidigung möchte ich sagen, dass wir dazu gekommen sind, weil falsche Werte im PIDC2 im Verdacht waren.

Aber vielleicht kann ja nen Mod nen neues Thema erstellen und die Beiträge verschieben. Denn die Problematik besteht ja weiterhin und dem entsprechend auch ein Klärungsbedarf.

 

[puk]

...sorry...

ist doch alles i.O.

@topic (Boris am 29.09.2015)

guys the standard filters are merged into new CF 1.10 RC3 and luxfloat changes included!
That;s good news for those who like to use default CF

Quelle

Quote:
Originally Posted by StefanQX View Post
Yay! Are there any changes that didn't make it to CF?

Well betaflight v1 is actually pretty much there. A few minor things like TPA on iterm for PID1 didn't get into it, but not a big deal.
Betaflight v2 is something to work for the future CF releases.

Quelle

würde das dahingehend verstehen, dass nun jüngste Errungenschaften hinsichtilch -> "wir brauchen die Filter und die Looptime nicht mehr und verstecken sie daher"<- nun nicht in die 1.10 kommen.

Dieses V1 und V2 gerede finde ich recht verwirrend -> soweit ich das verstanden habe, muss/sollte man dadurch nun bei der Beta bleiben, wenn man "1khz mit ACC auf F1 Targets" nicht verzichten will -> verstehen ich das richtig?

puk

 

[Arakon]

So ist es. Der gesamte Gyro Sync Kram ist nicht in CF drin.

 

[Mayk]

Moin,


mit dem Board http://seriouslypro.com/spracingf3 sollte man doch genug Leistung haben für 8khz oder?

 

[olex]

Der F3 hat nicht wirklich viel mehr Leistung in dem Sinne als der F1. Der Hauptvorteil davon ist der Float-Coprozessor, der zB den Luxfloat PID Regler deutlich beschleunigt. Boris meinte in dem RCGroups Thread, dass die Beschleunigung auf 8kHz an sich denkbar möglich wäre, aber nur mit seeehr viel Optimierung vom aktuellen Code.

 

[kopinke]

Ich finde den Hype um die F3 Boards auch über bewertet.
Okay,
Inverter f. Frsky
und onboard black
ganz nett, aber für die full featured Version ~80 Euro - nee danke, dann warte ich lieber auf die F4 & SPI Sensor Anbindung ...

 

[Arakon]

Onboard Blackbox hat man beim CC3D auch, und da ist dank SPI Anbindung der MPU auch mehr rauszuholen an Geschwindigkeit.

 

[StefanQX]

Arakon, wie macht man denn Onboard Blackbox am CC3D?

Andere Frage: Ich habe ein Problem mit meinem Failsafe. Betaflight ist mein erster Ausflug weg von OP, daher weiß ich nicht, ob es an meinen Settings, Cleanflight oder Betaflight liegt. Eventuell hat hier jemand eine Idee dazu, da ich mittlerweile nicht mehr weiß, was ich noch probieren soll:

Mein D4R-II ist so eingestellt, dass er bei Failsafe kein Signal mehr ausgibt. Das funktioniert in folgendem Szenario auch wie erwartet:

Kopter armen (Motoren laufen an), TX ausschalten
Ergebnis: CF stoppt die Motoren

In folgendem Szenario funktioniert es aber nicht:

Kopter armen (Motoren laufen an), etwas Gas geben, TX ausschalten
Ergebnis: CF geht laut RX-Tab auf 885, springt dann auf 1000 und bleibt dort, die Motoren laufen aber auf min_throttle weiter

Hier meine Einstellungen für Gas, RX und Failsafe:

set min_check = 1020
set max_check = 1950
set min_throttle = 1050
set max_throttle = 1980
set min_command = 1000

set failsafe_delay = 10
set failsafe_off_delay = 200
set failsafe_throttle = 1000
set failsafe_kill_switch = 0
set failsafe_throttle_low_delay = 100
set rx_min_usec = 885
set rx_max_usec = 2115

rxfail 3 a

Der D4R-II gibt als Kanal-Output 1000 bis 2000 aus.

Ich habe bereits neu gebunden (da so angeblich die Failsafe-Einstellungen im RX resettet werden) und per kurzem Klick auf den FS-Button dem D4R-II erneut mitgeteilt, dass er bei Failsafe kein Signal mehr ausgeben soll. Hilft alles nix.

Was könnte das Problem sein?

 

[Arakon]

set blackbox_device = 1 und den Haken bei Blackbox natürlich setzen. Das ist alles.