Brushless Gimbal Controller - SOFTWARE

Status
Nicht offen für weitere Antworten.

Daninho

Neuer Benutzer
@Daninho

mit einem GoPro Gimbal hätte ich keine Schwierigkeiten erwartet.
Verwendest du eine aktuellle Frimware ? Zumindest ab r161 sollte es sein.

Grundsätzlich Frage:
Stürtzt das Gimbal ab, sodass es nicht mehr reagiert und nur mehr durch Ausschalten wiederkommt ?
Oder ist ist die Regelung nicht stabil ?

Eine Ursache, warum sich die Einstellungen ändern, könnte eine schwankende Versorgungsspannnung sein.
Im Flug ändert sich Akkuspannung der Antriebsakkus ganz kräftig.
Ich hab für mich eine Stabiliserung auf 8V eingebaut (JETI BEC), damit sollte dieser Effekt ausgeschlossens sein.

Zum Ruckeln über Pitch.
Probier auch einmal die RC Eingänge komplett abzuhängen, und schau ob das Ruckeln immer noch passiert.

Checke auf jeden Fall auch die Laufrichtung der Motore extra sorgfälltig.
Das Gimbal rastet auch bei falscher Laufrichtung ein, es funktioniert vordergründig, aber in Wirklichkeit funktioniert die Regelung nicht sauber (ich denke in diesem Thread sollte man etwas dazu finden können, leider ist es nicht mehr übersichlich ...)


lg
Alois
Also der Gimbal stürzt nie ab, das Problem ist dass ich bei sanfter Einstellung des Gimbals keine guten Reultate bekomme, dann springt das Bild ab und zu ganz schnell nach oben und unten aber nur um ein paar mm, das ruiniert aber die ganze Aufnahme, wenn diese Sprünge im Bild nicht wären würde ich sagen der Gimbal funktioniert. Wenn ich mehr PWM und P drauf gebe und diese so justiere das kein brummen oder vibrieren auftritt habe ich das Problem dass der Gimbal dann aber vibriert wenn der Copter die Nase unten hat oder oben, in Mittelstellung vibriert er nicht. Sobald der Copter dann aber geneigt wird beginnt er zu vibrieren und schaukelt sich manchmal sogar auf.

Die Firmware habe ich nicht verändert aber ich benutze das Programm Brugi 049B_R161

Was mir noch aufgefallen ist, es gibt bei den PWR und P Einstellungen einen Punkt bei dem man die Motoren nicht mehr hört, sie gleiten dann wie auf Luft, das ist aber leider dann wenn zuviel PWM und P da ist, dann kommen beim tilten die Vibrationen. Wenn ich weniger PWM und P gebe höre ich die Motoren, sie geben dann so ein metallisches sirren ab bei jeder Bewegung, hört sich an wie ein Kratzen.

Wegen den RC Eingängen, die sind beim Phantom an der Naza angeschlossen, also dieser Flugsteuereinheit, ich habe in der Naza Software die Gains auf 0 gesetzt, so dass die Naza nicht eingreift in den Gimbal. Die Winkelbegrenzung habe ich auch nur in der Brugi Software eingestellt, nicht in der Naza
 
Zuletzt bearbeitet:

ahahn

Erfahrener Benutzer
@Daninho
Ich hatte immer wieder leichte Ruckler auf Pitch beobachtet, wobei diese sehr selten waren, haben aber ähnlich wie bei dir ausgesehen. Nur ein paar Mal pro 10 min.
Die Störungen waren nur da, wenn der RC Kanal angeschlossen war. Es wäre denkbar dass die Impulse am RC Eingang das Regelverhalten stören. Um sicher zu sein würde ich einmal den RC Kanal tatsächlich vom Gimbal abklemmen.
Falls es ohne RC Kanal nicht mehr ruckeln sollte, dann solltest auf 050_r191 aktualisieren.

Auf jeden Fall Laufrichtungen checken, ich wiederhole mich :)
Der Effekt ist wirklich fies, die Regelung funktioniert, aber mit schlechter Qualität und sonderbaren Effekten ....

lg
Alois
 

Daninho

Neuer Benutzer
@Daninho
Ich hatte immer wieder leichte Ruckler auf Pitch beobachtet, wobei diese sehr selten waren, haben aber ähnlich wie bei dir ausgesehen. Nur ein paar Mal pro 10 min.
Die Störungen waren nur da, wenn der RC Kanal angeschlossen war. Es wäre denkbar dass die Impulse am RC Eingang das Regelverhalten stören. Um sicher zu sein würde ich einmal den RC Kanal tatsächlich vom Gimbal abklemmen.
Falls es ohne RC Kanal nicht mehr ruckeln sollte, dann solltest auf 050_r191 aktualisieren.

Auf jeden Fall Laufrichtungen checken, ich wiederhole mich :)
Der Effekt ist wirklich fies, die Regelung funktioniert, aber mit schlechter Qualität und sonderbaren Effekten ....

lg
Alois
ok, ich werde es gleich mal testen und das Kabel der Naza abklemmen am Gimbal Board. Bei mir ist es so dass die Bewegungen des Gimbals wenn er pitch ausgleicht, also die Neigung der Nase nach unten oder oben ein leichtes springen im späteren Video erkennen lässt, also nicht flüssig wie Wasser sondern die Bewegung enthält feine Sprünge wie eine Ratsche ungefähr, das Video wird dadurch schlecht.

Die Spannung nehme ich von der internen Boardspannung, also ein 3S Lipo, dafür liegt ein Kabel im Inneren des Quadcopters ab Werk bereit, an dieses Kabel habe ich allerdings dann ein Y Kabel angelötet, das eine Ende ist der JST Stecker für den/das? Gimbal und das andere Ende hat einen Balancer Stecker für spätere Video TX. Kann sowas auch von einem schlechten Lötpunkt kommen oder dürfte sich dann gar nichts bewegen?

Was genau bedeutet Laufrichtung beachten? Ich habe darauf geachtet dass dem Gimbal nichts im Weg steht, also kein Kabel daran zerrt und das der Gimbal schön balanciert ist, die IMU gerade, kommt allerdings ab Werk auf einem Schaumstoffklebeband, also nicht verschraubt.

In extremeren Winkeln fängt der Gimbal an zu brummen und vibrieren, das verstehe ich leider gar nicht wieso das so ist, er schlägt ja nicht an. Ich bin Anfänger und ich habe mir gedacht dass dieses Sprünge vielleicht durch zu wenig P und PWM kommen können, als wenn die Motoren nicht genügenf Kraft und Drehmoment liefern um eine weiche Bewegung zu erzielen.

Edit:
Habe es mal abgeklemmt aber hat nichts geändert :(
 
Zuletzt bearbeitet:

ahahn

Erfahrener Benutzer
@Daninho:

Also am RC kann es nicht liegen.

Es könnte sein, dass die Spannung einbricht, vielleicht zu dünne Kabel oder schlechte Lötstelle.
Wäre zumindest denkbar.
Probier eventuell das Gimbal extra zu versorgen, z.B. mit einem 2S Akku.


Und zur Einstellung der Motorlaufrichtung.

Für jeden Motor kann man die Laufrichtung einstellen.
Direction->Reverse
Damit wird die Wirkrichtung der Regelung umgedreht.

Die Regelung soll in ihrer Grundfunktion eine Abweichung des Gimbals korrigieren.
D.h. sobald das Gimbal von seine Solllage abweicht, wird der Motor solange angesteuert bis sich das Gimbal zurückbewegt und wieder seine Sollpostion einnimmt.
Wenn sich z.B. die Kamera nach unten dreht, dann muss der Motor entsprechend dagegen steuern.
Wenn die Lauftrichtung des Motor falsch eingestellt ist, dann würde sich die Kamera weiter nach unten bewegen, und die Abweichung wird immer größer.

Man würde erwarten, dass bei einer falsche Einstellung das Gimbal überhaupt nicht stabilisieren würde.
Aus verschiedenen Gründen ist das nicht so und es kann sein dass es trotz falscher Einstellung grob funktioniert.

Du kannst die Laufrichtung versuchsweise einfach umdrehen.
Aber besser ist die Laufrichtung genau zu prüfen.

Dazu gibt es mehrere Möglichkeiten, ich würde dir diese empfehlen.
Dazu gibts auch viele Diskussionen :)

Falls du den Sensor runternehmen kannst:
PID Werte auf Null stellen, nur P auf einen geringen Wert (1.0) stellen.
Den Sensor drehen und beobachten wie sich der Motor dreht.
Der Motor muss sich immer in die jeweils entgegengesetzte Richtung drehen.

Oder man schraubt den Motor raus, statt den Sensor runterzunehmen, geht auch.

ich hoffe es war nicht zu verwirrend.

lg
Alois
 

fmhobby

Neuer Benutzer
Hallo Fritz,

probiers Mal mit dieser, das Windows ist jetzt ...................
lg
Alois
wow, super schnelle arbeit. am tab alles super, werde morgen das board anschliessen.

habe heute mit dem pc die r191 aufgespielt und folgendes problem.
egal ob die PID-Werte gross oder klein sind die gopro steht wie eine 1, aber es friert immer wieder nach kurzen handtests ein und kommt erst nach einem neustart, aus- einschalten, wieder in schwung.
spannungsversorgung mit regler auf 12V eingestellt, bei der 161er ist alles ok.
wollte mein neues gimbal aus dem 3D-drucker mit der neuen soft testen.
vl. finde ich noch die optimalen werte. werde mal die versorgungsspannung auf 9V runter drehen, vl hilft das.
danke noch für deine mühe.
fritz
 

ahahn

Erfahrener Benutzer
Hallo Fritz,
die Sache mit dem Einfrieren gefällt mir nicht :-(
Es gab schon ein paar Berichte dass es im Flug passiert.
Wenn es schon am Tisch passiert, dann wäre die Fehlersuche leichter
Passiert es auch ohne RC Eingang, also wenn nichts dransteckt?

Zusatz:
Die Anstiegszeit der I2C Signale zum Sensor sind mir schon länger suspekt.
Eigentlich verwunderlich dass es überhaupt geht.
Könnte sein, dass die Sache bei r191 kritischer geworden ist. Da die CPU weniger durch Interrupts unterbrochen wird und dadurch die I2C Zeiten tendenziell kürzer wurden.
Werde ich mir bei Gelegenheit genauer ansehen.

Greif Mal mit mit den Fingern auf die I2C Leitungen, dann stürzt es vermutlich gleich ab.


Welches Board bzw. welchen Sensor verwendest du ?
Wie lange sind die I2C und laufen die Kabel in der Nähe der Motorleitungen?

Am RC-Timer Board sind die Signale etwas besser als mit meinem Martinez mit selbstgebastelter Verkabelung. Ich denke es verwendet 2.2k Pullups anstelle von 10k bei den anderen ....



Alois
 
Zuletzt bearbeitet:

ahahn

Erfahrener Benutzer
Hallo Fritz,

die RC Eingänge als alleinige Ursache wäre damit ausgeschlossen (Interrupt nesting o.ä.)

Ich bin ziemlich sicher, dass es ein I2C Problem ist.
Die Software läuft auf einem RC-Timer Board viele Stunden ununterbrochen ohne Probleme.
Das RC-Timer Board verwendet 2.2K Pullup Widerstände und die I2C Signale sind so halbwegs akzeptabel.

Ich habe bei meinem Martinez Board, mit einem Flyduino Sensor die 10k Pullups gegen 1k Widerstände getauscht.
Mit 10k Pullup sind die Signale grausam, es ist verwunderlich dass es überhaupt so gut funktioniert.
(mit 400kHz statt 800kHz I2C Takt wäre es ja OK)
I2C Kabel sollte man daher nicht parallel zu den Motorzuleitungen verlegen, versteht sich von selbst ...

Mit den 1k Pullups sehen die Signale gleich besser aus. 1k sollte eigentlich kein Problem sein, weil der MPU6050 schafft am I2C bis 6mA und der ATMega328 kann so wie so mehr.

Das erklärt aber nicht, warum das Problem bei r161 nicht auftritt.... vieleicht findest dazu mehr raus.

Ich nehms zum Anlass die I2C Abfragen einmal anzusehen, vielleicht kann man es so bauen, dass es sich das System zumindest erholt, wenn ein Fehler auftritt.

lg
Alois


leider JA.
mache meine trockentests immer ohne kopter, also ohne rc-eingang.
gimbal > board > stromversorgung = spannungsregler an S4.

werde morgen nochmal die r191 aufspielen und weitere tests machen.
lg
fritz
 
An der Laufrichtung lag es wohl auch nicht, ich bin jetzt zu der interessanten Erkenntnis gekommen dass es wohl ein Bug oder eine Eigenart dieser Martinez Boards ist, da ich plötzlich in einem amerikanischen Forum enorm viel Zuspruch auf dieses Problem bekam, das immer nur den Pitch betrifft, egal ob man die Motoren tauscht oder die Laufrichtung ändert. Es wird als "ratcheting" (Knarre) bezeichnet.

Hier ein Video davon aus den USA mit dem gleichen Gimbal
http://www.youtube.com/watch?v=09G2jTwrl2k

Bei meinem Gimbal das gleiche Phänomen
https://vimeo.com/80914915

Dagegen das gleiche opensource Board, komplett gleiche Hardware des Gimbals mit alexmos Firmware siehe in meinem früheren Beitrag oben.
 

ahahn

Erfahrener Benutzer
Welches Board verwendet ihr da genau bzw. welcher Sensor wird verwendet? Kannst mit eventuell ein Bild vom Aufbau schicken?
Verwendet Nick Defelici die gleiche Hardware?

Ich könnte mir vorstellen, dass das beschriebene Problem durch I2C Fehler beim Auslesen der ACC/Gyro Werte entsteht.
Alex Mos liest den Sensor mit 400kHz und die BruGi Firmware taktet "traditionell" mit 800kHz. Das könnte auch erklären warum trotz gleicher Hardware Unterschiede bestehen.

Das Problem scheint reproduzierbar zu sein. Das ist an und für sich eine gute Nachricht.
Verwendet ihr den gleichen Aufbau ? Kabelführung Motoren und Kabelführung für Sensor?

Für die Fehlersuche wäre für mich natürlich wichtig, wenn ich das Problem bei mir am Tisch nachstellen könnte.

lg
Alois
 
Welches Board verwendet ihr da genau bzw. welcher Sensor wird verwendet? Kannst mit eventuell ein Bild vom Aufbau schicken?
Verwendet Nick Defelici die gleiche Hardware?

Ich könnte mir vorstellen, dass das beschriebene Problem durch I2C Fehler beim Auslesen der ACC/Gyro Werte entsteht.
Alex Mos liest den Sensor mit 400kHz und die BruGi Firmware taktet "traditionell" mit 800kHz. Das könnte auch erklären warum trotz gleicher Hardware Unterschiede bestehen.

Das Problem scheint reproduzierbar zu sein. Das ist an und für sich eine gute Nachricht.
Verwendet ihr den gleichen Aufbau ? Kabelführung Motoren und Kabelführung für Sensor?

Für die Fehlersuche wäre für mich natürlich wichtig, wenn ich das Problem bei mir am Tisch nachstellen könnte.

lg
Alois
Es ist mein erster Gimbal und auch mein erster Quadcopter, ganz genaue Informationen werde ich glaube ich nicht zusammen bekommen aber ich versuche es. Die Boards sind bei allen identisch, es ist das neue "open source V2" Board, die ersten Boards wurden erst vor ein paar Wochen ausgeliefert, vorher hatte der Hersteller blaue Boards und IMU Boards. Das gleiche open source V2 Board gibt es aber auch mit alexmos und da funktioniert es deutlich besser bei den pitch Bewegungen, die Hardware ist also identisch.

Ich kenne jetzt die Firmware des Boards nicht, ich weiss nicht wie man diese auslesen kann aber vielleicht hilft es wenn ich zum Einstellen der PID Werte das Program Brugi 049B_r161 nehme.

Jetzt du den Fotos, ich hoffe ich konnte das Controller Board und das Imu Board gut einfangen:

http://imageshack.us/a/img209/4144/v7cz.jpg

IMU:
http://imageshack.us/a/img59/7651/6tmq.jpg
 
Zuletzt bearbeitet:

ahahn

Erfahrener Benutzer
OK, habe schon eine Vorstellung wie es aussieht. Ich kenne das Board (noch) nicht. Mit Nick bin ich in Kontakt, bin neugierig ob er die gleiche Hardware verwendet.
Hast eventuell einen link wo ich genaueres zum "open Source v2" finde =
Danke
Alois
 
OK, habe schon eine Vorstellung wie es aussieht. Ich kenne das Board (noch) nicht. Mit Nick bin ich in Kontakt, bin neugierig ob er die gleiche Hardware verwendet.
Hast eventuell einen link wo ich genaueres zum "open Source v2" finde =
Danke
Alois
Konnte zu dem neuen V2 board nichts finden im Netz, im manual wurde es jetzt nachgetragen auf meine Bitte.
http://www.cnchelicopter.com/11012013/Beholder_Lite_Manual_V2.pdf
Der Unterschied zu dem alten blauen Board ist nur dass das Board irgendwie überfüllter aussieht als vorher und das alte wurde als "Blue V1, lagacy (OSBruGi ver fw)" bezeichnet, das neue als "GreenV2 current version, mosfet based (OSBruGi ver fw)"
 

ahahn

Erfahrener Benutzer
Die Info reicht soweit, an der Hardware dürfte nichts Ungewöhnliches sein, gegenüber den bisherigen Boards.
Die Green V2 hat andere Motor Treiber, was keine besonderen Auswirkungen auf die Funktion haben sollte.

Am Sensor würden mich die Werte der Pullups interssieren (meist 10k oder 2.2k ?). Könntest Du mir eventuell ein Detailfoto vom Sensor machen, falls man die Widersände erkennen kann, oder eventuell mit dem Ohmmeter messen.

Danke
Alois
 
Die Info reicht soweit, an der Hardware dürfte nichts Ungewöhnliches sein, gegenüber den bisherigen Boards.
Die Green V2 hat andere Motor Treiber, was keine besonderen Auswirkungen auf die Funktion haben sollte.

Am Sensor würden mich die Werte der Pullups interssieren (meist 10k oder 2.2k ?). Könntest Du mir eventuell ein Detailfoto vom Sensor machen, falls man die Widersände erkennen kann, oder eventuell mit dem Ohmmeter messen.

Danke
Alois
Hi, hatte dir schon eine PM geschrieben, wo genau liegt der Sensor? Ich dachte auf der IMU? Ich habe die IMU oben in dem Bild ziemlich nah aufgenommen oder ist das auf dem Hauptboard?
 

ahahn

Erfahrener Benutzer
Ein ganz aktueller Hinweis

Bei der Version 50r191 funktioniert die Sensoreinstellung SwapXY nicht richtig.

Also, falls jemand ein Häckchen bei SwapXY verwendet, bitte um etwas Geduld.
Es kommt ein Bugfix, vielleicht noch heute, ist nur eine Kleinigkeit.

Alois
 
Habe ein Problem mit meinem Gimbal bekomme es einfach nicht eingestellt!
Bei angestecktem Akku fängt es wie wild in alle richtungen zu drehen!
Ist das Ebay Gimbal mit dem Board hier:
http://www.ebay.com/itm/Universal-2-axis-2-axle-Brushless-Gimbal-Controller-Open-Source-V049-Martinez-/271267081425?pt=Radio_Control_Parts_Accessories&hash=item3f28c72cd1
Firmware ist z.Z. die V50 R191 drauf ( 46/48 usw. alle durchprobiert)!
Was mir aufgefallen ist das die Z-Achse beim ACC-Cal. den Wert nicht verändert und auf 0 stehen bleibt ist ggf. die IMU defekt?
MFG
 
Hallo Fritz,
die Sache mit dem Einfrieren gefällt mir nicht :-(
...................
Greif Mal mit mit den Fingern auf die I2C Leitungen, dann stürzt es vermutlich gleich ab.

Welches Board bzw. welchen Sensor verwendest du ?
Wie lange sind die I2C und laufen die Kabel in der Nähe der Motorleitungen?

Am RC-Timer Board sind die Signale etwas besser als mit meinem Martinez mit selbstgebastelter Verkabelung. Ich denke es verwendet 2.2k Pullups anstelle von 10k bei den anderen ....

Alois
hallo alois,

danke für die tipps.
habe jetzt nach deinem vorschlag, motorkabel und i2c-leitung getrennt (leitung ist jetzt von einem stereohrhörer kurz gehalten, wenig gewicht und sehr flexibel).
handtests verlaufen jetzt bei der r191 optimal, kein einfrieren mehr.
für flugtest muss ich noch aufs we warten.

habe das martinez-board aus der sammelbestellung, sensor ich aus der bucht.

programmieren und einstellungen laufen jetzt am asus transformer t100t einfach super, danke nochmal für die tolle arbeit.
lg
fritz
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten