Brushless Gimbal Controller - SOFTWARE
- Themenstarter Lonestar78
- Beginndatum
- Status
Jo, auch schon bei Engadget gesehen:
http://de.engadget.com/2013/06/18/diy-freefly-m-vi-im-eigenbau-fur-500-dollar-video/
Hauptsache noch den Sender um den Hals hängen ;_)
http://de.engadget.com/2013/06/18/diy-freefly-m-vi-im-eigenbau-fur-500-dollar-video/
Hauptsache noch den Sender um den Hals hängen ;_)
So, neue Werte, neues Video..... alte Symptome.
Schaut euch doch bitte noch das Video an, das ist jetzt mit neuen PIT Werten und mit einer ACC Zeit konstanten von 1 (im ersten Video war es 2).
Es hat sich kaum was geändert, eher verschlimmert.
Diesmal habe ich eine Zeitlupe in das Video eingefügt, damit man deutlicher erkennt wovon ich spreche.
Das Gimbal ist NICHT zu langsam, es reagiert erst mal genau richtig, und erst dann kippt der Horizont langsam ab. das geschieht aber nicht wenn ich den Kopter in der Hand bewege.
Folglich muss es etwas mit den Beschleunigungskräften zu tun haben, ich glaube das der ACC wert durch die Beschleunigung verfälscht wird, und auf genau den stellt sich das Gimbal dann nach der in der ACC Zeit konstante eingegebenen Zeit ein.
@RC FAN2
Der Hinweis auf die ACC Zeit konstante, war gut, jedoch denke ich das ich selbige eher deutlich erhöhen muss, das werde ich noch testen.
Weißt du zufällig auf was die ACC Zeit konstante in der 48er festgelegt war, die war ja nicht editierbar.
http://youtu.be/YEIm8N8g580
Schaut euch doch bitte noch das Video an, das ist jetzt mit neuen PIT Werten und mit einer ACC Zeit konstanten von 1 (im ersten Video war es 2).
Es hat sich kaum was geändert, eher verschlimmert.
Diesmal habe ich eine Zeitlupe in das Video eingefügt, damit man deutlicher erkennt wovon ich spreche.
Das Gimbal ist NICHT zu langsam, es reagiert erst mal genau richtig, und erst dann kippt der Horizont langsam ab. das geschieht aber nicht wenn ich den Kopter in der Hand bewege.
Folglich muss es etwas mit den Beschleunigungskräften zu tun haben, ich glaube das der ACC wert durch die Beschleunigung verfälscht wird, und auf genau den stellt sich das Gimbal dann nach der in der ACC Zeit konstante eingegebenen Zeit ein.
@RC FAN2
Der Hinweis auf die ACC Zeit konstante, war gut, jedoch denke ich das ich selbige eher deutlich erhöhen muss, das werde ich noch testen.
Weißt du zufällig auf was die ACC Zeit konstante in der 48er festgelegt war, die war ja nicht editierbar.
http://youtu.be/YEIm8N8g580
Anhänge
So, bin jetzt mit einer Zeitkonstanten (Zeitkonstante schreibt man natürlich zusammen) von 6 statt 1 geflogen, und das Ergebnis ist ganz DEUTLICH besser! Ein Video erspare ich euch diesmal.
Ich hab jetzt also den richtigen Knopf gefunden an dem ich drehen muss, die PID Werte waren nicht das Problem, danke RC FAN2 für deinen Hinweis.
So ganz habe ich das noch nicht durchschaut, zum Ausgleich der Bewegungen, verwendet der Controller ja den Gyro-Sensor, nehme ich an, und das ACC braucht er nur um seine Startposition zu finden.
Nachdem ich jetzt die Zeitkonstante um das 6fache erhöht habe, habe ich getestet ob das Gimbal, wenn ich es gewaltsam händisch verdrehe, länger braucht um wieder die Startposition einzunehmen. Da ändert sich aber nichts an der Geschwindigkeit.
Was es für ein Problem gibt wenn man die Zeitkonstante zu klein macht, weiß ich ja jetzt, aber welches Problem gibt es wenn ich sie zu groß mache?
Ich hab jetzt also den richtigen Knopf gefunden an dem ich drehen muss, die PID Werte waren nicht das Problem, danke RC FAN2 für deinen Hinweis.
So ganz habe ich das noch nicht durchschaut, zum Ausgleich der Bewegungen, verwendet der Controller ja den Gyro-Sensor, nehme ich an, und das ACC braucht er nur um seine Startposition zu finden.
Nachdem ich jetzt die Zeitkonstante um das 6fache erhöht habe, habe ich getestet ob das Gimbal, wenn ich es gewaltsam händisch verdrehe, länger braucht um wieder die Startposition einzunehmen. Da ändert sich aber nichts an der Geschwindigkeit.
Was es für ein Problem gibt wenn man die Zeitkonstante zu klein macht, weiß ich ja jetzt, aber welches Problem gibt es wenn ich sie zu groß mache?
Nach einigen Tests kann ich mir schon manches selber beantworten, und damit meine mühsam erlangte "Weisheit" allen von nutzen ist, schreibe ich mal was ich schon weiß, das ist ja schließlich der Sinn eines solchen Forums.
Die Aussagen und Vermutungen aus meinen vorigen Beitrag sind richtig, der Controller verwendet nur das Gyro für den Ausgleich, und das ACC ist nur dazu da das der Controller "weiß" was generell gerade ist.
In der neuen Gui von der v49B r77, die mir übrigens immer besser gefällt, gibt es die Möglichkeit ACC oder auch Gyro auszuschalten, dadurch konnte ich gut austesten was für was genutzt wird, für den normalen Betrieb sind die Schalter aber nutzlos und müssen immer an sein.
Die ACC Zeitkonstante legt fest wie schnell der Controller auf die Daten des ACC reagiert, das hat nichts damit zu tun wie schnell der Controller auf eine plötzliche Schräglage reagiert, also die Bewegungen des Kopters ausgleicht, das macht er über Gyro.
Das ACC ist wie ein Lot (schwerer Gegenstand der an einer Schnur hängt), es zeigt senkrecht nach unten und kann so "sagen" was horizontal gerade ist. Stellt man sich vor das so ein Lot in einem Auto montiert ist, und das Auto beschleunigt, so wird das Lot nicht mehr gerade nach unten zeigen und einen falschen wert liefern. Genau das macht das ACC auch, nur das es danach nicht pendelt, wie ein Lot im Auto es machen würde.
Sagt man dem Controller jetzt das er möglichst schnell auf die Daten von ACC reagieren soll, so reagiert der Controller auch auf die verfälschten Daten aus der Beschleunigungsphase und es kommt zu dem falsch liegenden Horizont wie er in meinen Videos zu sehen ist. Der Controller gleicht also erst mal mit dem Gyro richtig aus, wird dann aber vom ACC quasi Überstimmt und gezwungen etwas falsches zu machen.
Bei einer Höheren ACC Zeitkonstante "denkt" sich der Controller also "ich höre erst mal nur auf das Gyro, erst wenn das ACC lange genug den selben Wert schreit, mache ich was es sagt"
Ganz ohne ACC geht es aber auch nicht, denn da ist das Gyro "Dumm" und der Controller braucht schon hinweise was wirklich gerade ist. Das Maximum in meinem Setup ist eine ACC Zeitkonstante von 11, darüber ist dann das Gyro mit seinen Infos doch etwas einsam, und der Controller dann etwas ratlos.
Was mich jedoch wundert, warum hat das Problem sonst noch keiner gehabt, oder hat einfach noch keiner lange genug in eine Richtung beschleunigt?
Nun zu dem was mir noch nicht klar ist:
Was der P Wert macht ist mir klar.
Was der D Wert macht ist mir auch klar.
Aber der I Wert....., der sollte doch eine beruhigende Wirkung haben, also eher wie D nur ganzheitlicher, in der 48er war das auch so, auch wenn da anscheinend das ACC hineingemischt war. In der 49er ist das aber nicht so, oder ist der Regler einfach umgedreht?
(Ich denke in Multiwii)
Sorry für den lagen Text, knackiger hab ich es leider nicht hinbekommen, ich hoffe es ist trotzdem halbwegs verständlich.
Die Aussagen und Vermutungen aus meinen vorigen Beitrag sind richtig, der Controller verwendet nur das Gyro für den Ausgleich, und das ACC ist nur dazu da das der Controller "weiß" was generell gerade ist.
In der neuen Gui von der v49B r77, die mir übrigens immer besser gefällt, gibt es die Möglichkeit ACC oder auch Gyro auszuschalten, dadurch konnte ich gut austesten was für was genutzt wird, für den normalen Betrieb sind die Schalter aber nutzlos und müssen immer an sein.
Die ACC Zeitkonstante legt fest wie schnell der Controller auf die Daten des ACC reagiert, das hat nichts damit zu tun wie schnell der Controller auf eine plötzliche Schräglage reagiert, also die Bewegungen des Kopters ausgleicht, das macht er über Gyro.
Das ACC ist wie ein Lot (schwerer Gegenstand der an einer Schnur hängt), es zeigt senkrecht nach unten und kann so "sagen" was horizontal gerade ist. Stellt man sich vor das so ein Lot in einem Auto montiert ist, und das Auto beschleunigt, so wird das Lot nicht mehr gerade nach unten zeigen und einen falschen wert liefern. Genau das macht das ACC auch, nur das es danach nicht pendelt, wie ein Lot im Auto es machen würde.
Sagt man dem Controller jetzt das er möglichst schnell auf die Daten von ACC reagieren soll, so reagiert der Controller auch auf die verfälschten Daten aus der Beschleunigungsphase und es kommt zu dem falsch liegenden Horizont wie er in meinen Videos zu sehen ist. Der Controller gleicht also erst mal mit dem Gyro richtig aus, wird dann aber vom ACC quasi Überstimmt und gezwungen etwas falsches zu machen.
Bei einer Höheren ACC Zeitkonstante "denkt" sich der Controller also "ich höre erst mal nur auf das Gyro, erst wenn das ACC lange genug den selben Wert schreit, mache ich was es sagt"
Ganz ohne ACC geht es aber auch nicht, denn da ist das Gyro "Dumm" und der Controller braucht schon hinweise was wirklich gerade ist. Das Maximum in meinem Setup ist eine ACC Zeitkonstante von 11, darüber ist dann das Gyro mit seinen Infos doch etwas einsam, und der Controller dann etwas ratlos.
Was mich jedoch wundert, warum hat das Problem sonst noch keiner gehabt, oder hat einfach noch keiner lange genug in eine Richtung beschleunigt?
Nun zu dem was mir noch nicht klar ist:
Was der P Wert macht ist mir klar.
Was der D Wert macht ist mir auch klar.
Aber der I Wert....., der sollte doch eine beruhigende Wirkung haben, also eher wie D nur ganzheitlicher, in der 48er war das auch so, auch wenn da anscheinend das ACC hineingemischt war. In der 49er ist das aber nicht so, oder ist der Regler einfach umgedreht?
(Ich denke in Multiwii)
Sorry für den lagen Text, knackiger hab ich es leider nicht hinbekommen, ich hoffe es ist trotzdem halbwegs verständlich.
Was ich beim I parameter beobachted habe ist das wan du den Gimbal antipt und aus den horizontal lage bringt und gehen last, das den zeit um horizontal zu bekommen schneller geht wan du I hoher macht.
Aber wan I zuviel werd soll das gimbal zum leichten oscillieren gebracht werden. Meiner meinung nach soll diesen wert niedrig gehalten werden. Nimmt mit das diesen I wert um 10 fag erhoht ist deshalb niedrig genommen soll. deine 8 seht normal aus...
Ungeachted meine beobachtungen bleibt I fur mich ein bischen neblig...
Auch den PWM ist in B-Tool met factor 2.5 nach 100% umgerechned.
Deine wert von 56,8 ist deshalb eingentlich 142! Meine vorschlag ist den auch bringt etwa mehr in gleichgewicht mit P.
Vielleight PWM etwa 30 und P etwa 35...
Und ich klatsche weiter...
Hans
Aber wan I zuviel werd soll das gimbal zum leichten oscillieren gebracht werden. Meiner meinung nach soll diesen wert niedrig gehalten werden. Nimmt mit das diesen I wert um 10 fag erhoht ist deshalb niedrig genommen soll. deine 8 seht normal aus...
Ungeachted meine beobachtungen bleibt I fur mich ein bischen neblig...
Auch den PWM ist in B-Tool met factor 2.5 nach 100% umgerechned.
Deine wert von 56,8 ist deshalb eingentlich 142! Meine vorschlag ist den auch bringt etwa mehr in gleichgewicht mit P.
Vielleight PWM etwa 30 und P etwa 35...
Und ich klatsche weiter...
Hans
Hi, congrats with the great gimbal control firmware!
I like dissecting code and normally find some bugs and other improvement possibilities. In this case, none!! OK it does look funny that the pitch is derived in the range that is normally for roll and vice versa but of course.. pitch should keep increasing in the same direction beyond 90 degrees and roll does not need that.
Not much more to do (well - the newest TCL configuration soft reads zero everywhere after read?? but fortunately there is manual terminal mode) just enjoy
Great project, thanks again!
Regards
Soren
I like dissecting code and normally find some bugs and other improvement possibilities. In this case, none!! OK it does look funny that the pitch is derived in the range that is normally for roll and vice versa but of course.. pitch should keep increasing in the same direction beyond 90 degrees and roll does not need that.
Not much more to do (well - the newest TCL configuration soft reads zero everywhere after read?? but fortunately there is manual terminal mode) just enjoy
Great project, thanks again!
Regards
Soren
Der PWM Wert ist ja nur die Motorleistung, und die ist ja generell "Dumm" und so gering wie möglich, Bzw. so hoch wie nötig zu halten. Je besser das Gimbal ausbalanciert ist, desto weniger PWM ist nötig. Wobei sich das natürlich schon auch auf die PID Werte auswirkt, und auch von der bewegten Masse abhängt. Ich würde aber sagen das PWM in dem Zusammenhang eher eine untergeordnete Rolle spielt.
na, dann auch noch meine Weisheiten zum Thema P, I, D, Acc, Pwm, DLPF... LOL
alles was ich schreibe kann ich bei meinem (noch nicht ganz aber fast fertigen) (mikro) Gimbal beobachten, und auch theoretisch begründen... was aber Beides nicht heisst dass es bei jedem Gimbal so sein muss
PWM:
hat mehrere Effekte
- offensichtlich: PWM stellt ein wie "stark" der Motor ist...
=> PWM darf nicht zu niedrig sein, damit der Motor nicht zu schwach ist um die Kamera auszugleichen. Diese Kraft ist bei einem gut ausbalancierten und gut gelagertem Gimbal sehr klein - ABER: der Motor hat ein gewisses Koggen und das wird um so mehr "überspielt" je größer PWM, und dann bedenkt dass es auch noch Wind etc gibt, und auch die dadurch bewirkten Kräfte auf die Kamera soll der Motor ja packen
- stellt ein wie "schnell" und "gedämpft" die Einheit Motor-Kamera ist... je größer PWM desto schneller aber um so weniger gedämpft (= oszillierender)
=> schwach gedämpft ist nicht gut für PID Regler => weniger PWM macht's der Regelung einfacher
- ergibt sich aus dem obigen, aber trotzdem extra aufgeführt: PWM stellt ein wie "hartnäckig" das Gimbal oszilliert wenn es mal aus dem Tritt kommt
=> weniger PWM wirkt "gesünder"
Bemerkungen zu PWM:
- für ein und den selben Motor hängen diese Details natürlich STARK von der Lipo-Spannung UND der Wicklung des Motors ab...
- man mag denken dass PWM ähnlich zu P sein sollte, da er ja in selber Weise die Schleifenverstärkung verändert, allerdings ändert sich mit PWM auch wie "schnelle" und "gedämpft" die Motor-Gimbal-Einheit ist, und daher ist PWM eben NICHT das Selbe wie P
- bei meinem Aufbau ist PWM kein sehr wichtiger Wert... ich konnte bei allen Werten vergleichbar gute Regelung bekommen (ausser wenn natürlich PWM zu klein war LOL)
ACC:
- dieser Wert hat keinerlei Einfluss darauf wie gut oder schlecht das Gimbal regelt
- ACC bestimmt wie gut oder schlecht das Gimbal BESCHLEUNIGUNGEN des Gimbals/Kopters verträgt... bei Beschleunigungen "verrechnet" sich die Regelung sozusagen und die Kamera wird deswegen schief gehalten (z.B. bei schnellen Turns etc.), bei einem kleinen ACC-Wert ist das Gimbal sehr empfindlich auf Beschleunigungen, bei einem großen Wert praktisch gar nicht
- ACC bestimmt aber auch wie gut das Gimbal die unvermeidliche Drift des Gyros verträgt... durch die Drift "vergißt" die Regelung sozusagen mit der Zeit was eigentlich z.B. waagrecht heisst, und die Kamera wird zunehmend dauerhaft schief gehalten, bei einem kleinen ACC Wert wird die Gyro-Drift sehr gut ausgeblendet, bei einem großen Wert schlägt sie voll zu
=> ACC nicht zu klein und nicht zu groß, hier muss jeder seinen eigenen Kompromiss finden
Bemerkungen:
- der mit ACC einzugehende Kompromiss hängt vom eigenen Flugstil/Kameraführung ab... wer schnell rum fliegt mit wilden Turns braucht eine bessere Unterdrückung der Beschleunigungseffekte (ACC groß), wer nur in der Luft steht und den Gimbal sanft dreht kann sich mehr auf die Drift-Verminderung konzentrieren (ACC klein)
ACHTUNG: Was bei einer konkreten Firmware "groß" und "klein" heisst, hängt davon ab wie sie genau gestrickt ist, und das kann sich über verschiedene Versionen auch ändern (seht auch die Diskussion zum Wert von ACC unten, Dank an Jogijo). Die Aussagen sind für's BruGi _049B_r77.
DLPF etc.:
bei mir funktioniert das um so besser je mehr ich den DLPF ausschalte...
(lässt sich mit dem oszillierenden Verhalten der Motor-Kamera-Einheit begründen)
Vorbemerkung zu P, I, D:
Die Regeln zum Einstellen von PID sind beim Gimbal andere als die, die ihr in all den Standard-Texten findet... wer Euch also den Inhalt der Standard-Texte rezitiert oder auf diese verweist oder verlinkt... vergesst es..
(hängt mit dem oszillierenden Verhalten der Motor-Kamera-Einheit zuusammen, die üblichen Einstellregeln sind für sogenannte FOPT Systeme und dazu ähnlichen System...).
I:
Dies und NICHT P ist der "wichtige" Wert. Probiert es aus, ihr sollte eine recht gute Regelung nur mit I und D, also mit P = 0, hinbekommen! I hat zwei Effekte
- I bestimmt die Schleifenverstärkung, und damit wie "schnell" und "genau" die Regelung arbeitet, je größer I desto schneller, aber auch desto mehr die Gefahr dass die Regelung das Schwingen anfängt
- I bestimmt wie "robust" die Regelung ist, je größer I desto empfindlicher wird die Regelung auf Änderungen von z.B. der Motorspannung usw.
Bemerkung:
- weil nun I der "wichtige" Wert ist, geht die bei Regelungen ansonsten übliche Methode zum Erkennen der richtigen Motorrichtung nicht mehr (so gut). Es wirkt als ob die Regelung unabhängig von der Motorrichtung ähnlich gut funktioniert. Mit der richtigen Motorrichtung geht es aber besser.
D:
Dieser Wert unterdrückt - bis zu einer gewissen Grenze - eine Schwingneigung der Regelung. D.h. durch hochstellen von D lässt sich auch ein höhere Wert von I erreichen, und damit eine "schnellere" und "genauerer" Regelung. Ähnlich wie bei I gilt jedoch, wird D zu groß fängt's das schwingen an, egal was, so oder so.
P:
Mit diesem Wert kann die Regelung feingetunt werden.
(es kann sich - theoretisch gesehen - sogar lohnen negative Werte von P auszuprobieren, hat bei mir allerdings nicht's gebracht)
Nachbemerkung zu P, I, D:
Aus dem gesagten sollte sich eigentlich eine Einstellanleitung ergeben haben. Bei mir klappt das auf zweierlei Wegen gut
Weg A) I auf irgendeinen kleinen Wert (kann auch Null sein). Nun D und P gegenseitig möglichst hochstellen ohne dass das Gimbal schwingt. Nun I so hochstellen dass das Gimbal schwingt. Dann natürlich den Wert etwas zurückdrehen, und an allen drei Werten etwas rumspielen bis es passt, mit dem Ziel im Auge I möglichst groß zu bekommen.
Weg B) P auf Null stellen, und zunächst I und D einstellen, also I hoch, wenn es schwingt, D ein bischen hoch, solange bis man keines von Beiden mehr erhöhen kann ohne das es Schwingt. Nun P dazunehmen, zum Feintunen, und an allen drei Werten etwas rumspielen bis es passt, mit dem Ziel im Auge I möglichst groß zu bekommen.
Nachnachbemerkung:
Das Schwingen der Reglung kann so schwach sein dass man es mit dem Auge nicht sieht, und auch im Datenplot nicht, aber trotzdem so stark sein, dass man es wenn man das Gimbal in der Hand hält ganz deutlich spüren kann... und es dann insbesondere auftritt wenn man das Gimbal bewegt -> in der Hand halten ist also evtl ein "besserer" Weg zum Einstellen
alles was ich schreibe kann ich bei meinem (noch nicht ganz aber fast fertigen) (mikro) Gimbal beobachten, und auch theoretisch begründen... was aber Beides nicht heisst dass es bei jedem Gimbal so sein muss
PWM:
hat mehrere Effekte
- offensichtlich: PWM stellt ein wie "stark" der Motor ist...
=> PWM darf nicht zu niedrig sein, damit der Motor nicht zu schwach ist um die Kamera auszugleichen. Diese Kraft ist bei einem gut ausbalancierten und gut gelagertem Gimbal sehr klein - ABER: der Motor hat ein gewisses Koggen und das wird um so mehr "überspielt" je größer PWM, und dann bedenkt dass es auch noch Wind etc gibt, und auch die dadurch bewirkten Kräfte auf die Kamera soll der Motor ja packen
- stellt ein wie "schnell" und "gedämpft" die Einheit Motor-Kamera ist... je größer PWM desto schneller aber um so weniger gedämpft (= oszillierender)
=> schwach gedämpft ist nicht gut für PID Regler => weniger PWM macht's der Regelung einfacher
- ergibt sich aus dem obigen, aber trotzdem extra aufgeführt: PWM stellt ein wie "hartnäckig" das Gimbal oszilliert wenn es mal aus dem Tritt kommt
=> weniger PWM wirkt "gesünder"
Bemerkungen zu PWM:
- für ein und den selben Motor hängen diese Details natürlich STARK von der Lipo-Spannung UND der Wicklung des Motors ab...
- man mag denken dass PWM ähnlich zu P sein sollte, da er ja in selber Weise die Schleifenverstärkung verändert, allerdings ändert sich mit PWM auch wie "schnelle" und "gedämpft" die Motor-Gimbal-Einheit ist, und daher ist PWM eben NICHT das Selbe wie P
- bei meinem Aufbau ist PWM kein sehr wichtiger Wert... ich konnte bei allen Werten vergleichbar gute Regelung bekommen (ausser wenn natürlich PWM zu klein war LOL)
ACC:
- dieser Wert hat keinerlei Einfluss darauf wie gut oder schlecht das Gimbal regelt
- ACC bestimmt wie gut oder schlecht das Gimbal BESCHLEUNIGUNGEN des Gimbals/Kopters verträgt... bei Beschleunigungen "verrechnet" sich die Regelung sozusagen und die Kamera wird deswegen schief gehalten (z.B. bei schnellen Turns etc.), bei einem kleinen ACC-Wert ist das Gimbal sehr empfindlich auf Beschleunigungen, bei einem großen Wert praktisch gar nicht
- ACC bestimmt aber auch wie gut das Gimbal die unvermeidliche Drift des Gyros verträgt... durch die Drift "vergißt" die Regelung sozusagen mit der Zeit was eigentlich z.B. waagrecht heisst, und die Kamera wird zunehmend dauerhaft schief gehalten, bei einem kleinen ACC Wert wird die Gyro-Drift sehr gut ausgeblendet, bei einem großen Wert schlägt sie voll zu
=> ACC nicht zu klein und nicht zu groß, hier muss jeder seinen eigenen Kompromiss finden
Bemerkungen:
- der mit ACC einzugehende Kompromiss hängt vom eigenen Flugstil/Kameraführung ab... wer schnell rum fliegt mit wilden Turns braucht eine bessere Unterdrückung der Beschleunigungseffekte (ACC groß), wer nur in der Luft steht und den Gimbal sanft dreht kann sich mehr auf die Drift-Verminderung konzentrieren (ACC klein)
ACHTUNG: Was bei einer konkreten Firmware "groß" und "klein" heisst, hängt davon ab wie sie genau gestrickt ist, und das kann sich über verschiedene Versionen auch ändern (seht auch die Diskussion zum Wert von ACC unten, Dank an Jogijo). Die Aussagen sind für's BruGi _049B_r77.
DLPF etc.:
bei mir funktioniert das um so besser je mehr ich den DLPF ausschalte...
(lässt sich mit dem oszillierenden Verhalten der Motor-Kamera-Einheit begründen)
Vorbemerkung zu P, I, D:
Die Regeln zum Einstellen von PID sind beim Gimbal andere als die, die ihr in all den Standard-Texten findet... wer Euch also den Inhalt der Standard-Texte rezitiert oder auf diese verweist oder verlinkt... vergesst es..
(hängt mit dem oszillierenden Verhalten der Motor-Kamera-Einheit zuusammen, die üblichen Einstellregeln sind für sogenannte FOPT Systeme und dazu ähnlichen System...).
I:
Dies und NICHT P ist der "wichtige" Wert. Probiert es aus, ihr sollte eine recht gute Regelung nur mit I und D, also mit P = 0, hinbekommen! I hat zwei Effekte
- I bestimmt die Schleifenverstärkung, und damit wie "schnell" und "genau" die Regelung arbeitet, je größer I desto schneller, aber auch desto mehr die Gefahr dass die Regelung das Schwingen anfängt
- I bestimmt wie "robust" die Regelung ist, je größer I desto empfindlicher wird die Regelung auf Änderungen von z.B. der Motorspannung usw.
Bemerkung:
- weil nun I der "wichtige" Wert ist, geht die bei Regelungen ansonsten übliche Methode zum Erkennen der richtigen Motorrichtung nicht mehr (so gut). Es wirkt als ob die Regelung unabhängig von der Motorrichtung ähnlich gut funktioniert. Mit der richtigen Motorrichtung geht es aber besser.
D:
Dieser Wert unterdrückt - bis zu einer gewissen Grenze - eine Schwingneigung der Regelung. D.h. durch hochstellen von D lässt sich auch ein höhere Wert von I erreichen, und damit eine "schnellere" und "genauerer" Regelung. Ähnlich wie bei I gilt jedoch, wird D zu groß fängt's das schwingen an, egal was, so oder so.
P:
Mit diesem Wert kann die Regelung feingetunt werden.
(es kann sich - theoretisch gesehen - sogar lohnen negative Werte von P auszuprobieren, hat bei mir allerdings nicht's gebracht)
Nachbemerkung zu P, I, D:
Aus dem gesagten sollte sich eigentlich eine Einstellanleitung ergeben haben. Bei mir klappt das auf zweierlei Wegen gut
Weg A) I auf irgendeinen kleinen Wert (kann auch Null sein). Nun D und P gegenseitig möglichst hochstellen ohne dass das Gimbal schwingt. Nun I so hochstellen dass das Gimbal schwingt. Dann natürlich den Wert etwas zurückdrehen, und an allen drei Werten etwas rumspielen bis es passt, mit dem Ziel im Auge I möglichst groß zu bekommen.
Weg B) P auf Null stellen, und zunächst I und D einstellen, also I hoch, wenn es schwingt, D ein bischen hoch, solange bis man keines von Beiden mehr erhöhen kann ohne das es Schwingt. Nun P dazunehmen, zum Feintunen, und an allen drei Werten etwas rumspielen bis es passt, mit dem Ziel im Auge I möglichst groß zu bekommen.
Nachnachbemerkung:
Das Schwingen der Reglung kann so schwach sein dass man es mit dem Auge nicht sieht, und auch im Datenplot nicht, aber trotzdem so stark sein, dass man es wenn man das Gimbal in der Hand hält ganz deutlich spüren kann... und es dann insbesondere auftritt wenn man das Gimbal bewegt -> in der Hand halten ist also evtl ein "besserer" Weg zum Einstellen
Zuletzt bearbeitet:
Super OlliW!
Genau so einen Text hätte ich mir gewünscht, dann hätte ich nicht alles selber erforschen müssen, bzw. hätte ich dann schneller verstanden.
Es ist auch gut wenn mal zwei Personen das selbe, mit eigenen Worten beschreiben, das macht es leichter verständlich.
Dein Text hilft sicher vielen bei der Einstellerei.
Danke für deine Mühen!
Genau so einen Text hätte ich mir gewünscht, dann hätte ich nicht alles selber erforschen müssen, bzw. hätte ich dann schneller verstanden.
Es ist auch gut wenn mal zwei Personen das selbe, mit eigenen Worten beschreiben, das macht es leichter verständlich.
Dein Text hilft sicher vielen bei der Einstellerei.
Danke für deine Mühen!
jetzt habe ich erst gedacht du hast Recht, aber ich denke du hast doch nicht Recht... grrr, das hat man davon wenn sich verwirren läßt LOL
IMU.ino:
=> AccComplFilterConst hat den Wertebereich [0...1]
=> für AccComplFilterConst=0 spielt der Wert von acc keine Rolle, sondern nur EstG.A
=> für AccComplFilterConst=1 spielt der alte Wert von EstG.A keine Rolle, sondern nur acc
und acc ist der Beschleunigunsgsensor, EstG.A der Gyrowert
=> es sollte wie oben geschrieben richtig sein
IMU.ino:
=> AccComplFilterConst hat den Wertebereich [0...1]
=> für AccComplFilterConst=0 spielt der Wert von acc keine Rolle, sondern nur EstG.A
=> für AccComplFilterConst=1 spielt der alte Wert von EstG.A keine Rolle, sondern nur acc
und acc ist der Beschleunigunsgsensor, EstG.A der Gyrowert
=> es sollte wie oben geschrieben richtig sein
Zuletzt bearbeitet:
Ich will dir ja nicht auf die Nerven fallen, aber ich habe sicher recht, darauf verwette ich meinen A....
Die ACC Zeitkonstante ist von 0 bis 20 einstellbar und es steht ja sogar in der Gui "Controls how fast the gimbal follows ACC (sec)".
Und ich habe es in der Praxis ausführlich getestet, glaub mir.
Die ACC Zeitkonstante ist von 0 bis 20 einstellbar und es steht ja sogar in der Gui "Controls how fast the gimbal follows ACC (sec)".
Und ich habe es in der Praxis ausführlich getestet, glaub mir.
Hi zusammen,
ich hatte das schon im Sammelthread gepostet, aber ich weiß nicht, ob es nicht thematisch besser hier rein passt:
ich hatte mir noch einen Controller von einem deutschen Händler gekauft inkl. Sensor. Soll ein Martinez 3.1 sein
Wenn ich die 048 aufspiele klappt das, wenn ich aber versuche die aktuelle 049er aufzuspielen kommt vom Arduino Prog folgende Fehlermeldung
IMU:44: error: variable or field 'readACC' declared void
IMU:44: error: 'axisDef' was not declared in this scope
IMU.ino: In function 'void initSensorOrientationDefault()':
IMU:40: error: 'sensorDef' was not declared in this scope
IMU:40: error: 'ROLL' was not declared in this scope
IMU:41: error: 'PITCH' was not declared in this scope
IMU:42: error: 'YAW' was not declared in this scope
IMU.ino: In function 'void initSensorOrientation()':
IMU:85: error: 'config' was not declared in this scope
IMU:87: error: 'sensorDef' was not declared in this scope
IMU:87: error: 'YAW' was not declared in this scope
IMU:88: error: 'ROLL' was not declared in this scope
IMU:89: error: 'PITCH' was not declared in this scope
IMU:92: error: 'config' was not declared in this scope
IMU:94: error: 'sensorDef' was not declared in this scope
IMU:94: error: 'ROLL' was not declared in this scope
IMU:94: error: 'PITCH' was not declared in this scope
IMU.ino: In function 'void setACCFastMode(bool)':
IMU:104: error: 'AccComplFilterConst' was not declared in this scope
IMU:104: error: 'DT_FLOAT' was not declared in this scope
IMU:106: error: 'AccComplFilterConst' was not declared in this scope
IMU:106: error: 'DT_FLOAT' was not declared in this scope
IMU:106: error: 'config' was not declared in this scope
IMU.ino: In function 'void initIMU()':
IMU:114: error: 'gyroScale' was not declared in this scope
IMU:114: error: 'resolutionDevider' was not declared in this scope
IMU:119: error: 'EstG' was not declared in this scope
IMU.ino: In function 'void rotateV(fp_vector*, float*)':
IMU:128: error: variable 'fp_vector v_tmp' has initializer but incomplete type
IMU:129: error: invalid use of incomplete type 'struct fp_vector'
IMU:42: error: forward declaration of 'struct fp_vector'
IMU:129: error: 'ROLL' was not declared in this scope
IMU:129: error: 'PITCH' was not declared in this scope
IMU:130: error: invalid use of incomplete type 'struct fp_vector'
IMU:42: error: forward declaration of 'struct fp_vector'
IMU:130: error: 'YAW' was not declared in this scope
IMU:131: error: invalid use of incomplete type 'struct fp_vector'
IMU:42: error: forward declaration of 'struct fp_vector'
IMU.ino: In function 'void readGyros()':
IMU:140: error: 'mpu' was not declared in this scope
IMU:141: error: 'sensorDef' was not declared in this scope
IMU:142: error: 'gyroADC' was not declared in this scope
IMU:142: error: 'ROLL' was not declared in this scope
IMU:142: error: 'gyroOffset' was not declared in this scope
IMU:146: error: 'PITCH' was not declared in this scope
IMU:150: error: 'YAW' was not declared in this scope
IMU.ino: At global scope:
IMU:155: error: variable or field 'readACC' declared void
IMU:155: error: 'axisDef' was not declared in this scope
IMU.ino: In function 'void updateGyroAttitude()':
IMU:172: error: 'gyroADC' was not declared in this scope
IMU:172: error: 'gyroScale' was not declared in this scope
IMU:172: error: 'DT_FLOAT' was not declared in this scope
IMU:175: error: 'EstG' was not declared in this scope
IMU.ino: In function 'void updateACC()':
IMU:183: error: 'accLPF' was not declared in this scope
IMU:183: error: 'accADC' was not declared in this scope
IMU:184: error: 'accSmooth' was not declared in this scope
IMU:185: error: 'accMag' was not declared in this scope
IMU:191: error: 'accMag' was not declared in this scope
IMU:196: error: 'accSmooth' was not declared in this scope
IMU:196: error: 'ROLL' was not declared in this scope
IMU:196: error: 'acc_25deg' was not declared in this scope
IMU:196: error: 'PITCH' was not declared in this scope
IMU:196: error: 'YAW' was not declared in this scope
IMU:197: error: 'flags' was not declared in this scope
IMU:199: error: 'flags' was not declared in this scope
IMU.ino: In function 'void updateACCAttitude()':
IMU:212: error: 'accMag' was not declared in this scope
IMU:212: error: 'flags' was not declared in this scope
IMU:214: error: 'accSmooth' was not declared in this scope
IMU:215: error: 'EstG' was not declared in this scope
IMU:215: error: 'AccComplFilterConst' was not declared in this scope
IMU.ino: In function 'void getAttiduteAngles()':
IMU:226: error: 'angle' was not declared in this scope
IMU:226: error: 'ROLL' was not declared in this scope
IMU:226: error: 'config' was not declared in this scope
IMU:226: error: 'EstG' was not declared in this scope
IMU:226: error: 'Rajan_FastArcTan2_deg1000' was not declared in this scope
IMU:229: error: 'PITCH' was not declared in this scope
_BruGi.ino: In function 'void loop()':
_BruGi:275: error: 'readACC' was not declared in this scope
Der Händler meinte der "Jumper", der da komisch verlötet ist, hätte damit nichts zu tun. Jedes Board würde getestet und mit einem Bootloader versehen. Naja die 48er hat er ja auch angenommen...
Der Sensor ist noch nicht angeschlossen - was bei der 048 auch egal ist. Weiß jemand, wo der Fehler liegt? Oder kann es sein, dass das Board im Eimer ist?
LG
HKP
ich hatte das schon im Sammelthread gepostet, aber ich weiß nicht, ob es nicht thematisch besser hier rein passt:
ich hatte mir noch einen Controller von einem deutschen Händler gekauft inkl. Sensor. Soll ein Martinez 3.1 sein
Wenn ich die 048 aufspiele klappt das, wenn ich aber versuche die aktuelle 049er aufzuspielen kommt vom Arduino Prog folgende Fehlermeldung
IMU:44: error: variable or field 'readACC' declared void
IMU:44: error: 'axisDef' was not declared in this scope
IMU.ino: In function 'void initSensorOrientationDefault()':
IMU:40: error: 'sensorDef' was not declared in this scope
IMU:40: error: 'ROLL' was not declared in this scope
IMU:41: error: 'PITCH' was not declared in this scope
IMU:42: error: 'YAW' was not declared in this scope
IMU.ino: In function 'void initSensorOrientation()':
IMU:85: error: 'config' was not declared in this scope
IMU:87: error: 'sensorDef' was not declared in this scope
IMU:87: error: 'YAW' was not declared in this scope
IMU:88: error: 'ROLL' was not declared in this scope
IMU:89: error: 'PITCH' was not declared in this scope
IMU:92: error: 'config' was not declared in this scope
IMU:94: error: 'sensorDef' was not declared in this scope
IMU:94: error: 'ROLL' was not declared in this scope
IMU:94: error: 'PITCH' was not declared in this scope
IMU.ino: In function 'void setACCFastMode(bool)':
IMU:104: error: 'AccComplFilterConst' was not declared in this scope
IMU:104: error: 'DT_FLOAT' was not declared in this scope
IMU:106: error: 'AccComplFilterConst' was not declared in this scope
IMU:106: error: 'DT_FLOAT' was not declared in this scope
IMU:106: error: 'config' was not declared in this scope
IMU.ino: In function 'void initIMU()':
IMU:114: error: 'gyroScale' was not declared in this scope
IMU:114: error: 'resolutionDevider' was not declared in this scope
IMU:119: error: 'EstG' was not declared in this scope
IMU.ino: In function 'void rotateV(fp_vector*, float*)':
IMU:128: error: variable 'fp_vector v_tmp' has initializer but incomplete type
IMU:129: error: invalid use of incomplete type 'struct fp_vector'
IMU:42: error: forward declaration of 'struct fp_vector'
IMU:129: error: 'ROLL' was not declared in this scope
IMU:129: error: 'PITCH' was not declared in this scope
IMU:130: error: invalid use of incomplete type 'struct fp_vector'
IMU:42: error: forward declaration of 'struct fp_vector'
IMU:130: error: 'YAW' was not declared in this scope
IMU:131: error: invalid use of incomplete type 'struct fp_vector'
IMU:42: error: forward declaration of 'struct fp_vector'
IMU.ino: In function 'void readGyros()':
IMU:140: error: 'mpu' was not declared in this scope
IMU:141: error: 'sensorDef' was not declared in this scope
IMU:142: error: 'gyroADC' was not declared in this scope
IMU:142: error: 'ROLL' was not declared in this scope
IMU:142: error: 'gyroOffset' was not declared in this scope
IMU:146: error: 'PITCH' was not declared in this scope
IMU:150: error: 'YAW' was not declared in this scope
IMU.ino: At global scope:
IMU:155: error: variable or field 'readACC' declared void
IMU:155: error: 'axisDef' was not declared in this scope
IMU.ino: In function 'void updateGyroAttitude()':
IMU:172: error: 'gyroADC' was not declared in this scope
IMU:172: error: 'gyroScale' was not declared in this scope
IMU:172: error: 'DT_FLOAT' was not declared in this scope
IMU:175: error: 'EstG' was not declared in this scope
IMU.ino: In function 'void updateACC()':
IMU:183: error: 'accLPF' was not declared in this scope
IMU:183: error: 'accADC' was not declared in this scope
IMU:184: error: 'accSmooth' was not declared in this scope
IMU:185: error: 'accMag' was not declared in this scope
IMU:191: error: 'accMag' was not declared in this scope
IMU:196: error: 'accSmooth' was not declared in this scope
IMU:196: error: 'ROLL' was not declared in this scope
IMU:196: error: 'acc_25deg' was not declared in this scope
IMU:196: error: 'PITCH' was not declared in this scope
IMU:196: error: 'YAW' was not declared in this scope
IMU:197: error: 'flags' was not declared in this scope
IMU:199: error: 'flags' was not declared in this scope
IMU.ino: In function 'void updateACCAttitude()':
IMU:212: error: 'accMag' was not declared in this scope
IMU:212: error: 'flags' was not declared in this scope
IMU:214: error: 'accSmooth' was not declared in this scope
IMU:215: error: 'EstG' was not declared in this scope
IMU:215: error: 'AccComplFilterConst' was not declared in this scope
IMU.ino: In function 'void getAttiduteAngles()':
IMU:226: error: 'angle' was not declared in this scope
IMU:226: error: 'ROLL' was not declared in this scope
IMU:226: error: 'config' was not declared in this scope
IMU:226: error: 'EstG' was not declared in this scope
IMU:226: error: 'Rajan_FastArcTan2_deg1000' was not declared in this scope
IMU:229: error: 'PITCH' was not declared in this scope
_BruGi.ino: In function 'void loop()':
_BruGi:275: error: 'readACC' was not declared in this scope
Der Händler meinte der "Jumper", der da komisch verlötet ist, hätte damit nichts zu tun. Jedes Board würde getestet und mit einem Bootloader versehen. Naja die 48er hat er ja auch angenommen...
Der Sensor ist noch nicht angeschlossen - was bei der 048 auch egal ist. Weiß jemand, wo der Fehler liegt? Oder kann es sein, dass das Board im Eimer ist?
LG
HKP
- Status
