Brushless Gimbal Controller - SOFTWARE

Status
Nicht offen für weitere Antworten.
Here is a video of my problem, As you can see it starts the motor's turn a few degrees and stop. They get power but only to hold position.

http://www.youtube.com/watch?v=j0Lg_pddfgo&feature=youtu.be

What am I doing wrong in this case? I cannot find the cause of the problem. I downloaded the firmware again from the googlecode site and it still does not work. Before the firmware upgrade it did work, but after changing the PIDS it stopped working. The cables are connected correctly.
 
Zuletzt bearbeitet:

KOPPI2

Neuer Benutzer
Hallo Jungs,

ich hab den Kontroller bekommen und bin am Testen !

Danke für euren Einsatz !!


Frage 1 :
bei mir funzt nur die 36 Version ? warum ?
( bei der 37er dreht der Motor weg und ruckelt ! )

Frage 2 :
ist die Soft so geschriben das der Sensor auf der Wippe sitzt ?

Frage 3 :
wenn ich den Sensor auf den Motor platziere, dreht der Motor den Sensor nicht weit genug zurüch damit die Sensorplatiene wieder in der wage ist.

Frage 4 :
die Anzahl der Pole ? geht auch 28

Bin auf die Antworten gespannt !

Grüße aus München
 

MiniOlli

Erfahrener Benutzer
Hallo Lonestar78,
hallo Ludwig,
wie ist eigentlich der Stand zum Thema harmonische Rotation - also mal ganz abgesehen von der Lageregelung?
Ich hatte meine Ansteuerung damals mit einem umbegauten BLDC-Regler realisiert und festgestellt, dass eine "ruckelfreie" Rotation nur mit angeschlossenem Sternpunkt zu realisieren ist. Ludwig konnte das Verhalten mit dem ST6234 nicht nachvollziehen.
Nun habe ich den Bldc-Regler gegen die Treiberplatine von Ludwig getauscht, die PWM´s auf Bipolar umgestellt und mir die Rundlaufeigenschaft angeschaut. Das Ergebnis ist nicht besonders gut. Ungefähr mit meinen Versuchen ohne angeschlossenen Sternpunkt zu vergleichen.
Hat jemand mal ein Video indem man eine saubere Drehung sieht? (so ca. 40s - 1min pro Umdrehung)
Grüße,
Olli
 

RC FAN2

Erfahrener Benutzer
Hi Olli ,
genau , ob mit oder ohne Sternpunkt hat bei mir keine Änderung gebracht ....
Ich hatte tatsächlich schon das ein oder andere mal einen ruhigen lauf , nur dann wahr die Regelung zu langsam .
Soweit ich das verstanden habe , macht Alexmos das so das er nicht den vollen Sinusbereich fährt , sondern mit der Powereinstellunng in seiner GUI variable limitieren kann .
Hab nochnich getestet ob das was bringt ?
 
Hallo,

ich hatte die letzten Tage viel Zeit mit testen zugebracht. Die Version der 3.6 mit RAW_Gyro und Low-Pass-Filter, die ich vor einigen Tagen gepostet habe, taugt allerdings nur, um sie abgesetzt von der Kameraplattform vom Kopter aus einzusetzen, so wie Henry das schon gezeigt hat. Mit der IMU direkt auf der Kamera läuft der Horizont in Sekundenbruchteilen weg. Um die RAW-Gyro-Version von der Kameraplattform aus einzusetzen, müsste man die Daten von Gyro und ACC zuerst per Software fusionieren. Danach werden die Ergebnisse aber auf keinen Fall schneller vorliegen als mit dem DMP, der genau diese Fusion per Hardware macht.

Ich habe mich also drangemacht zu testen, ob man doch die "langsamen" DMP-Realwinkel mit einer höheren Motorgeschwindigkeit ausgleichen kann ( über höhere PID-Werte für P). Bei den PID-Einstellungen habe ich mich an die Beschreibung von Alexmos von seiner Seite gehalten: http://translate.googleusercontent....us.pdf&usg=ALkJrhh7YQeSTwD_OHpn_3BBitLYZMTJBQ (Seite 3).

Bei Vibrationen im Gesamtsystem habe ich also nicht P reduziert sondern D erhöht. Die Werte für I sollen möglichst klein sein, um einen stabilen Horizont zu bekommen. Das deckt sich auch mit der GUI des SimpleBGC, wo nur für den I-Wert Dezimalstellen einstellbar sind.

Wie Alexmos es beschreibt gibt es bei der Such nach PID-Werten drei Zustände, die ich inzwischen alle kenne ;). Zuerst kommt mit einer Erhöhung von P ein niederfrequentes Schütteln im gesamten Gimbal. Wenn man P nicht wieder senken möchte, weil man die Geschwindigkeit braucht, kann man alternativ auch D erhöhen. Dadurch reduziert sich die mechanische Vibration wieder und wenn sonst alles passt kann eine komplette Stabilisierung bei stabilem System erreicht werden.

Das Spiel kann man allerdings nur so weit treiben, bis der Motor mit einer hochfrequenten Schwingung komplett blockiert. Das ist der dritte Zustand und hier muss man dann D wieder auf einen funktionierenden Wert senken. Vor dem kompletten Stillstand kann es allerdings auch schon zu einem ruckligen Lauf kommen. Deshalb ist es am Besten, die eingestellten Werte mit einem dritten frei drehenden Motor immer wieder zu überprüfen. Sonst weiß man nicht, woher die stärker werdenden Vibrationen im Gimbal kommt und die Trägheit und Schwerkraft des Gimbal versteckt sonst die tatsächlichen Motorbewegungen.

Ich hab zu diesen Versuchen mal ein Video gemacht:

http://www.youtube.com/watch?v=irOOlCVbDqw

Am Anfang habe ich mit einer auf DMP eingestellten 3.6er Version getestet. Hier hatte ich noch ein anderes Gimbal nur mit den Baumarkt Aluwinkeln und -profilen, die im Video zu sehen sind. Hier konnte ich über einen kleinen Winkel auch die IMU drehen und so die Neutrallage der IMU mit der des ausbalanzierten Gimbals abgleichen. Mit diesem Gimbal und der 3.6 habe ich bei hohen P-Werten durch Erhöhung von D tatsächlich einen Zustand erreicht, wo das Gimbal von allein nicht mehr schwingt. Allerdings hatte ich mit den hochgedrehten P und D Werten dann übelste Nebeneffekte, weil das Magnetfeld zwischen Motoranker und Magneten so groß wurde, dass der Motor sich nur sehr schwer über eine Ankerstellung hinwegdrehen wollte. Dann war es für ein paar Grad wieder OK und die Stabilisierung hat gepasst, bis dann eben der nächste Anker kam...

Enttäuscht habe ich das Ganze dann nicht gefilmt und später, als das Gimbal von Mayday kam,
mein improvisiertes Baumarkt-Gimbal zerlegt. Die Teile habe ich für die Befestigung der Kamera gebraucht, da ich gar keine GoPro besitze... Das alles sage ich nur um darzulegen warum ich überzeugt bin, dass man mit diesen PID-Justierungen auch komplett stabile Ergebnisse bekommen kann.... sie waren ja schon vibrationsfrei und genau, bis auf die Sache mit der Ankeranziehung.

Später habe ich die Probleme dann mit der eher plötzlichen und "klickenden" Richtungsänderung der Motoren in einer auf DMP eingestellten Version 3.6 zurückgeführt. Bei Einstellung auf Gyro sind die Richtungswechsel ungleich sanfter. Ich habe mich dann erinnert, dass jemand im Forum beschrieben hat, dass bis zur Version 3.3 (... also mit DMP) die Richtungsänderung sanfter ging, was ich dann ebenfalls feststellen konnte. Bei der 3.3 hatte ich allerdings öfter das oben beschriebene hochfrequente Stocken und so versuchte ich, die BL-Regelung aus 3.5 und die PID-Regelung aus 3.3 zu kombinieren.

Das hat letztlich am Besten funktioniert und da sie eine Kombination aus 3.3 und 3.5 ist habe ich diese Codeversion 3.4 genannt :)
 
Zuletzt bearbeitet:

MiniOlli

Erfahrener Benutzer
Hi Ludwig,
das ging ja schnell:D
Ich meine auch nur die Motorsteuerung ganz ohne Regelung. Denn wenn das Stellglied schon nicht genau das macht was es soll und die Regelung die Nichtlinearitäten ausgleichen muss wirds ruckelig.
Ich denke auch, dass man am Sinus ansetzen muss. Ich hatte damals die dritte harmonische in versch. Amplituden aufgeprägt mit kleinen Verbesserungen bei unterschiedlichen Geschwindigkeiten.
Ich schaue mir morgen mal die resultierenden Motorströme mit dem Oszi an.
Grüße,
Olli
 
Die modifizierte Version habe ich auf meine Internetseite geladen und bitte darum, sie mal zu testen: www.andreaskielb.de/_034.rar

Ich denke, dass man mit DMP und einer schärfer eingestellten PID-Regelung sehr gute Ergebnisse erzielen kann. Vorraussetzung ist allerdings, dass die Neutrallage der IMU und die mechanische Balance des Gimbal identisch ist, weil sonst beide Faktoren gegeneinander arbeiten und so neue Vibrationen enstehen. Mit der direkt auf die Kamera geklebten IMU im Video klappt das nicht.

Da es davor mit der am separaten Winkel drehbaren IMU besser funktionierte, werde ich mein Mayday und Baumarkt-Kombinationsgimbal, das mechanisch eine ziemliche Katastophe ist und sich ständig verstellt, noch einmal ändern müssen und melde mich dann nach weiteren Tests...

Sind eigentlich die RC-Eingänge schon aktiv und wo liegen die denn beim 12pol Stecker der neuen Boardversion? Mit Überschreibung der Steuerung, die man später sowieso braucht, könnte man auch die Neutrallage der IMU trimmen und das wäre die bequemste Variante zur Einstellung...
 
Zuletzt bearbeitet:

rc-action_de

Erfahrener Benutzer
Hallo Andeas,

Fleißig Fleißig ;-)

Hast du die _33 verwendet um davon ausgehend eine _34 zu bauen ?! Ich habe Gestern auch etwas getestet und bin dabei ebenfalls bei der _33 hängen geblieben- da sie bei mir bisher die besten Resultate bringt. Momentan funktioniert die Regelung nur mit Nachlauf ruckelfrei.
Deine _34 habe ich soeben getestet. Mit IMU am Kameragehäuse kann ich leider nur bis P=20 hoch gehen. Danach beginnt das System sich aufzuschwingen. Eine Erhöhung bis 1000 auf D bringt leider keine Besserung.
relativ ruckelfrei läuft der Gimbal nur bis zu einem P- Wert von 8, ist allerdings auch recht träge.

Schön das es voran geht. Da ich Gestern meine Gimbalaufhängung fertig gestellt habe, konnte ich Heute bereits mal fliegen. Das Bild ist zwar weit entfernt von Zenmuse und der russischen Variante, jedoch sieht man schon in welche Richtung es gehen soll.

Viele Grüße
Henry
 
Vielen Dank für die schnelle Rückmeldung und das Testen! Ich habe die Version eigentlich nicht so richtig gebaut. Es ist einfach der Text der _033.ino, den ich direkt statt dem der 35er genommen hatte, der Rest ist alles komplett Version _35. Ich hatte das selbe davor mit dem Text der BL_Controller.ino gemacht. Das hat zwar kompiliert aber immer noch den härteren Richtungswechsel der Version 35 gehabt... sehr praktisch, wenn die Versionen noch so dicht beisammen sind.

Hast Du die Möglichkeit durch einen zweiten Motor zu testen, ob die IMU auf der Kamera auch elektronisch in Neutralstellung ist (...also keine Soll-Richtung ausgibt), wenn das Gimbal ausbalanciert ist?

Eine Differgenz zwischen IMU-Neutral und der mechanischen Balance des Gimbal erzeugt eher ein seitliches Aufschwingen bei höherem P, wärend das niederfrequente Vibrieren, das sich über D besänftigen lässt, sich bei mehr Gas (...höheres P) eher wie ein Hämmern anfühlt.
 
Zuletzt bearbeitet:

rc-action_de

Erfahrener Benutzer
Hast Du die Möglichkeit durch einen zweiten Motor zu testen, ob die IMU auf der Kamera auch elektronisch in Neutralstellung ist (...also keine Soll-Richtung ausgibt), wenn das Gimbal ausbalanciert ist?

Eine Differgenz zwischen IMU-Neutral und der mechanischen Balance des Gimbal erzeugt eher ein seitliches Aufschwingen bei höherem P, wärend das niederfrequente Vibrieren, das sich über D besänftigen lässt, sich bei mehr Gas (...höheres P) eher wie ein Hämmern anfühlt.
Leider nein :-(

Du meinst das die IMU sich im Optimalfall im Neutralpunkt sowie im COG der Kamera bzw. des Gimbal befinden sollte ?
Dann bin ich ganz weit weg davon. Bei meinen Copter bekomme ich auch nur hohe P- Werte hin, wenn sich die IMU im COG befindet.
Meine IMU ist auf der Unterseite des Kameragehäuses angeklebt und dreht sich somit nicht nur um sich selbst.


Kann das der Fehler sein ?

PS: ich sehe schon - ich muss mir auch noch ein Testsystem aufbauen. Meine alten Endstufen + weiteren Atmega 328 habe ich noch hier, nur der MPU 6050 aus Frankreich lässt auf sich warten.

Viele Grüße
Henry
 
Nein, das meine ich nicht. Der zweite Motor ist nur dazu da, um sicherzustellen, dass er genau in der Neutralstellung verharrt, wenn das Gimbal horizontal ausbalanziert ist. Wenn man die IMU beispielsweise mit Tesa auf das Kameragehäuse klebt, weiss man ja nicht, ob sie in ihrem augenscheinlichen gerade IMU auch elektronisch Null ausgibt - also den Motor nicht in irgendeine Richtung dreht. Auch durch die Lötstellen der Kabel an der IMU ist eine wirklich gerade Befestigung erschwert.

Zunächst mal wird das Gimbal durch diese kleine Unstimmigkeit auch nicht sichtbar ausgelenkt werden sondern die Schwerkraft hält das Gimbal in Position. Wenn man dann aber den P-Wert erhöht und durch die größere Kraft der Motoren alles irgendwie zu vibrieren beginnt, weiß man nicht, das die Ursache für einen Teil der Schwingungen von falschen elektronischen Signalen der IMU kommt. Dieser Teil der Schwingungen ist dann allerdings durch den D-Wert nicht zu korrigieren.

So ein System mit der IMU auf der Kamera ist eben auch um einiges empfindlicher gegen störende Einflüsse als ein IMU-System am Kopter. Nur mit der drehbaren IMU bei meinem ersten Test habe ich das gesamte System dann auch durch die PID-Einstellung vibrationsfrei hinbekommen (... ich hätte trotz des Problems der stockenden Anker ein Video machen sollen).
 
Zuletzt bearbeitet:

rc-action_de

Erfahrener Benutzer
Ahhh , schöne Erklärung - das meinst du ;-) Darum auch der zweite Motor. Ergo sollte ich auf der Nickachse einen höheren P- Wert einstellen können wenn die Kabel die IMU nicht so stark beeinflussen. Das ist eigentlich kein Problem, wenn man hier eine Zugentlastung mit verbaut. /das werde ich mal probieren). Eigentlich hat mein Gimbal allerdings ein hohes Dreh und Haltemoment. Davon sollte ich also nicht unbedingt betroffen sein. Die Nickachse hat mir schon mehr als einmal die IMU- Kabel abgedreht ;-)

Viele Grüße
Henry
 
Also ganz genau meine ich, was die IMU elektronisch ausgibt. Schau bitte noch mal im Video ab 0.27 min.. Da halte ich das Gimbal in der Luft und ziehe das eigentliche Roll-Motorkabel ab. An den Rollanschluss stecke ich statt dessen einen auf dem Tisch liegenden dritten Motor, der mechanisch nicht an das Gimbal angeschlossen ist. Wenn ich das Gimbal loslasse dreht der Motor noch leicht und kommt erst zum Stillstand wenn ich das Gimbal mit dem Finger leicht anhebe. Der Neutralpunkt der IMU stimmt also nicht mit dem der mechanischen Balance des Gimbals überein.

Das ist meiner Meinung nach der Grund für das seitliche Aufschaukeln und den häufigen schiefen Horizont im Video. Ich gehe jetzt mal noch Aluteile suchen und versuche, ein besseres Gimbal mit einer Schwenkeinrichtung für die IMU zu bauen.
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten