Brushless Gimbal Controller - SOFTWARE

[prima]

Hallo,
heißt das jetzt das ich mit 8.8 Ohm in einen nicht optimalen Bereich liege. Mir fehlt immer ein Stück bis zum Endpunkt egal ob ich Dir umdrehe. Es macht auch keinen Unterschied ob ich 2s oder 4s Akku verwende. Dir bewirkt bei mir nur einmal Vorlauf und bei reverse Nachlauf und bei beiden Einstellungen komme ich mit P32 nicht auf dem Endpunkt. Wo liegt denn jetzt der optimale Ohm Bereich beim Motor?

 

[Klempnertommy]

Hallo,
heißt das jetzt das ich mit 8.8 Ohm in einen nicht optimalen Bereich liege. Mir fehlt immer ein Stück bis zum Endpunkt egal ob ich Dir umdrehe. Es macht auch keinen Unterschied ob ich 2s oder 4s Akku verwende. Dir bewirkt bei mir nur einmal Vorlauf und bei reverse Nachlauf und bei beiden Einstellungen komme ich mit P32 nicht auf dem Endpunkt. Wo liegt denn jetzt der optimale Ohm Bereich beim Motor?

Wenn P32 zu wenig ist, wieso nimmst Du nicht mehr?
Wenn es hinterher hängt, muss P hoch,
wenn es dann zittert, Strom runter,
I erst mal null
und D minimal dazu, schnelles zittern< D zu hoch, langsames Zittern< D zu klein.
Wenn Du überhaupt keinen bereich findest,
eventuell einfach die pol anzahl "falsch" verstellen, damit die Geschwindigkeit passt.
welche Nut/Magnet Kombination hat der Motor den?
Wie hoch ist den der Strangstrom momentan?

 

[smuggler]

Also mehr als p32 habe ich auch nicht geschafft ist wohl so ne grenz .

 

[nico_99]

Moin.

Ist das nicht geil?: http://www.youtube.com/watch?feature=player_embedded&v=P7DAixjAqnk#!

 

[Lonestar78]

Ist das unser Projekt?

 

[nico_99]

Jep...Nachbau aus Polen

PS: mit deiner Software! ;-))

 

[martinez]

Sehr geil!!!

 

[Klempnertommy]

Sehr schöne Bilder... Polen hatte ich irgendwie anders in Erinnerung

 

[Alveran]

Sehr schöne Bilder... Polen hatte ich irgendwie anders in Erinnerung

wie? noch nichts über Global warming gehört?^^

 

[nico_99]

wie? noch nichts über Global warming gehört?^^

Das war gut... ;-)

 

[Lonestar78]

zum Thema P max bei 32:
das liegt daran, dass im Code Kp und Co mit int16 deklariert werden und dann durch 1000 geteilt sind.
Erste Abhilfe ist auf unsigned int zu gehen (uint16_t), dann gehts bis 65,535.

Benutzt jemand die dritte Nachkommastelle bei Kp und Co?
Wenn nicht, dann ändere ich den Skalierungsfaktor auf 100, dann geht der Wertebereich von 0,00 bis ~655,35

Das kann ich in die nächste Version alles einbauen, das wird ehh nur ein Bugfix-Release

Grüße
Christian

 

[Klempnertommy]

Nachkomma? was ist das denn?... Handwerker runden eh immer auf
Jetzt versteh ich aber auch das "32" Problem erst

 

[RC FAN2]

ich verwende nur eine nachkommestelle , das reicht
Das video mit der Nex ist ja HAMMER !
Haben wir gut gemacht ....

 

[nico_99]

Vor allem, man sieht endlich mal, wie der Controller im Flug stabilisiert...

 

[digi45]

Gibt es eine genaue erläuterung was PID hier beim Brushless gimbal bewirken?
Gerne -Die Anleitung auf Englisch und Deutsch ist gerade in der Mache - also noch Pre - Beta ;-)

Viele Grüße
Henry/QUOTE]

wie weit ist jetzt das ganze?..könnte so eine Anleitung gut gebrauchen..komme einfach ohne nicht klar..

 

[prima]

Hallo,
(uint16_t) habe ich geändert aber wo finde ich im Code den Skalierungsfaktor?

Gruß
Werner

 

[Lonestar78]

Quick and Dirty in der PID Routine:

float out = (Kp * error + SampleTimeInSecs * Ki * *errorSum + Kd * (error - *errorOld) / (SampleTimeInSecs + 0.000001))/1000.0;

von 1000.0 auf 100.0 hochsetzen.
Im TCL Gui Code nach der 1000.0 suchen und ebenfalls auf 100.0 hochsetzen.

Fertig ;-)

 

[OlliW]

ich würde evtl auch Ki und Kd mit Kp skalieren, der Art Kp*( Pterm + Ki* Iterm + Kd * Dterm ) anstatt Kp*Pterm + Ki* Iterm + Kd * DTerm, dann wird Ki und Kd etwas unabhängiger von der Schleifenverstärkung (und sind dann nicht mehr Ki und Kd im strikten Sinn)(hat sich bei mir bei einem Heli CP Gyro Projekt sehr bewährt).

 

[Lonestar78]

Hmm, das kling nicht schlecht.
Probier ich mal aus.

 

[OlliW]

nicht dass du dir jetzt was falsches erwartest... das Verhalten des Reglers ändert sich dadurch natürlich nicht, wird also weder besser noch schlechter, nur das Übertragen der Werte von I&D (z.B. ähnliches Gimbal aber andere KV des Motors), und das Tunen der PIDs wird etwas einfacher

Noch eine Frage bitte zum seriellen Protokoll. Sendet man SE, wird die Motortabelle neu berechnet (calcSinusArray). Sendet man SD, werden jedoch nur die Parameter geändert. Kein calcSinusArray?

Eine kleine, nicht wirklich wichtige, Anmerkung. Es gab wahrscheinlich gute Gründe das so zu machen, aber es ist etwas unpraktisch dass die Setz-Befehle nichts zurückmelden; calcSinusArray (und auch die EEPROM Funktionen) brauchen ja doch einiges an Zeit bis ein neuer Befehl verarbeitet werden kann... mit einer Rückmeldung hätte man einfach aufs Ende warten können, so muss man raten... (und ich hätte nicht einen Abend damit verbracht rauszufinden warum meine Box bei einigen Werten nicht geht LOL)(meine Box läuft schon im Wesentlichen, nur noch ein bischen Kosmetik)