Brushless Gimbal Controller - SOFTWARE

Status
Nicht offen für weitere Antworten.
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
Keiner ne Idee wie ich weiter vorgehen kann?
Muss der Wert der Z Achse sich verändern?
MFG
 

ahahn

Erfahrener Benutzer
Kannst du mit der GUI verbinden?
Wenn ja, dann sollte links unten die Firmware Nummer erscheinen, GruGu 50 r191

Schalte dann die Chart Anzeige ein, mit "Start".
Es werden dann die Winkelwerte für Roll und Nick angezeigt.
Also wenn der Senso waagrecht liegt, etwas 0 Grad, und z.B. bei 30 Grad Neigung 30.0

Das wäre der erste Funktionscheck. Falls es nicht passt, die Sensoreinstellung ändern (ReverseZ und Swap XY).
Dabei immer kurz warten, 4-5sec, weil es einschwingen muss.
 

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
Achtung: Änderung (14.12.2013)
im swapXY Sensor Modus war noch ein weiterer Bug.
Er wirkt sich so aus, dass beim Pitch nach unten, etwa ab 30 Grad die Roll Achse nicht mehr richtig stabilisiert.
Dieser Bug ist nicht neu, sondern er war schon in 049, seit es swapXY gibt.

"many thanks to Sebastiaan from Netherlands for the support" :D

Der Fehler ist ab v50 r197 behoben.

Für r191 kann man die IMU.ino ersetzen.
http://code.google.com/p/brushless-gimbal/downloads/detail?name=IMU.ino


lg
Alois
 
Zuletzt bearbeitet:
Hab da möglicherweise mal eine doofe Frage:
Kann man mit der Brugi auf einem Martinez Board einen Analog Joystick (PS2) verwenden um z.B. die Pitch-Achse zu steuern?
Und wenn ja wie? ich habe dazu nichts in diesem Thread gefunden und auch in den Releasenotes steht dazu nix (in dem FPV.1 pro dingens ist es als feature erwähnt - aber welche softwareversion nutzt das Teil?)

Schöne Grüße und ein feines Bastelwochenende
 

ahahn

Erfahrener Benutzer
In der ganz neuesten Version (r195) kann man anstatt der RC Eingänge analoge Signale zum Steuern benutzen.

Die Version ist im SVN aber noch nicht als Download Package.

Wenn du sie testen möchtest, hier wäre Mal eine Vorabversion.
https://www.dropbox.com/s/lsps6jt7xwltb09/BruGi_050_r195.zip

Im Auxiliary Tab kannst du für jeden Eingang A0/A1/A2 einstellen, wie der Eingang zu verwenden ist.
0 ... ausgeschalten
1 ... digitaler RC Eingang (wie bisher)
2 ... analog Eingang

Wenn Du einen Eingang eine analog Potentiometer verwenden möchtest:
Den Eingang im Aux Tab auf Analog stelllen.
Im RC Pitch so einstellen als ob es ein normaler PWM Kanal wäre, so wie bisher.

Mit LiveView kannst kontrollieren, ob der Kanal funktioniert. Der analoge Kanal wird wie ein RC Kanal angezeigt

Erzähl wie es funktioniert.

Alois
 
Hello all,
I apologize if my question has already being discussed but It is not easy to read this thread with google translate.
here is my question : Gimball motor with a lot of poles may cause problems ?
in the software version I'm actually using , BETA Version 049 r161 , there is no more the option to set the number of motor poles.
I'm having some problems setting up the gimball when I use motors with a lot of poles, in my case 48 .
I notice that it is very difficult to obtain power from the motor, this did not happened with motr with less poles.
I choose a motor with lot of poles because I thought it should be more smooth. I'm I wrong ?

I'm a bit ashame but I confess that I have test teh same set up with an old "free" version of Alexmos and it work much better so I suspect it is not an hardware problem but rather a software problem.
I would prefer to use the open source software and I hope that someome have a good suggestion .
Thanks !
 

ahahn

Erfahrener Benutzer
Hi,
regarding number of motor poles: this is a good question :)

I personally did not do any experiments with more motor poles, up to now.

So my assumption up to now was, that more motor poles will just change the gain of the control loop.
It would be addressed, just by other values for PID.

Did you try a recent Version, e.g v50 r191 already ?
048 I forgot already :)

Alois

Hello all,
I apologize if my question has already being discussed but It is not easy to read this thread with google translate.
here is my question : Gimball motor with a lot of poles may cause problems ?
in the software version I'm actually using , BETA Version 049 r161 , there is no more the option to set the number of motor poles.
I'm having some problems setting up the gimball when I use motors with a lot of poles, in my case 48 .
I notice that it is very difficult to obtain power from the motor, this did not happened with motr with less poles.
I choose a motor with lot of poles because I thought it should be more smooth. I'm I wrong ?

I'm a bit ashame but I confess that I have test teh same set up with an old "free" version of Alexmos and it work much better so I suspect it is not an hardware problem but rather a software problem.
I would prefer to use the open source software and I hope that someome have a good suggestion .
Thanks !
 
Thanks for reply !
I have just download the v50 r191 , and I will tested in the next days, I hope it will solve my problem .
With these motors I'm using with 48 poles I can see that the power is very low , so for the roll axis it is not enough to drive it.
I do not remember exactly but with Alexmos software total power for the two motors was around 200ma while with 049 r16, perhaps 60ma @12 volts
 

ahahn

Erfahrener Benutzer
If you turn power to 100%, it will drive the motor with maximum voltage, depending on the supply voltage.
I can't imagine that there is so much difference in the motor currents, on the same hardware.
The only option could be the switching frequency, which could make the difference.
In BruGi it's 32khz and Alex can use either 8kHz or 32kHz, I guess.
So if there is a current difference, this would mean the the inductance of the motor windings is to high.

Make an experiment and change to switching frequeny at Alexmos, and watch the current.

Alois


Thanks for reply !
I have just download the v50 r191 , and I will tested in the next days, I hope it will solve my problem .
With these motors I'm using with 48 poles I can see that the power is very low , so for the roll axis it is not enough to drive it.
I do not remember exactly but with Alexmos software total power for the two motors was around 200ma while with 049 r16, perhaps 60ma @12 volts
 

Moerg

Erfahrener Benutzer
Hi Leute, ich habe das rctimer ASP Gimbal für die nex 5.
Als Controller benutze ich einen martinez v3 fw 0.49

Jetzt erzeugt das Gimbal bei manchen, eher steilen Neigungen ein wobbeln, also er steuert über, gleicht aus und das war auch wieder zu viel, kann mir jemand seine Vermutung sagen?

Einstellungen bei roll

P 10
I 10
D 60

Power 100

DANKE!
 

ahahn

Erfahrener Benutzer
Hallo BruGi Fans !

es gibt schon wieder ein Update :)
http://code.google.com/p/brushless-gimbal/downloads/detail?name=BruGi_050_r198.zip

Als eine wichtige Funktion ist jetzt auch ein I2C Check hinzugekommen.
Ich hoffe, dass damit die Ursachenforschung bei Problemfällen etwas erleichtert wird.

Mich würde interessieren ob die I2C Fehler tatsächlich auftreten. Mit meinen beiden Testgimbals treten im Normalbetrieb tatsächlich keine Fehler auf.
Ich bitte also um Rückmeldung, ob I2C Fehler bei euren Aufbauten vorkommen.

Zum Testen habe ich I2C Signale mit einer Pinzette kurzzeitig mit Masse verbunden, bitte nicht nachmachen, obwohl unkritisch, außer man rutscht ab ;-)


Die Anzeige der I2C Fehler ist ganz einfach zu aktivieren, mit der GUI verbinden und den "Live View" Button drücken.
Die I2C Fehleranzahl wird im Settings Tab unter Sensor angezeigt. Dieser Wert sollte immer auf 0 stehen.

Hier sollte ein Bild stehen ....



Vielleicht funktionierts mit einem Link ?
https://www.dropbox.com/s/7thriw86hu62pbk/GUI-50-r198-Live-View-1.png

Mittels "Live View" können übrigens auch die echten Werte der RC Kanäle und die Aux Schalter angezeigt werden.
Die Einstellarbeiten sollten damit etwas leichter fallen.

Als Neuerung können jetzt auch Analog Eingänge, alternativ zu den RC Kanälen, zum Steuern der Kamera verwendet werden.
Ich denke da war eine Anfrage ob man PS2 Joysticks verwenden kann, das sollte jetzt möglich sein.

Die Zuordnung und die Verwendung der Eingänge A0/A1/A2 ist selbstverständlich frei wählbar.
Sogar eine Kombination von Analog, PWM und PPM wäre möglich, vermutlich aber nicht sinnvoll :)

lg
Alois
 
Zuletzt bearbeitet:

fdoe

Neuer Benutzer
Hallo Alois,

danke auch mal von meiner Seite an dich für die Weiterentwicklung. Ich habe eines der ersten Martinez Boards (direkt vom Meister ;-)) und den Thread lange nicht mehr mitverfolgt. Meine alte Version 049 funktioniert gut, "never change a running system"…

Es scheint ja einige neue "Features" zu geben, wie von dir hier aufgelistet: http://fpv-community.de/showthread....oller-SOFTWARE&p=480311&viewfull=1#post480311

Ich habe allerdings nirgendwo weitere Erläuterungen zu den einzelnen Punkten gefunden, insbesondere "Auxilary Schaltkanal". Auch mit der Forumsuche bin ich nicht recht weitergekommen. Hoffe ich habe nichts offensichtliches übersehen..

Gruss,
Florian
 

ahahn

Erfahrener Benutzer
Hallo Florian,
für die neuen Features gibt es leider noch keine Dokumentation. Auch im Forum wurde noch nicht sehr viel drüber diskutiert.
Die FPV Features sind neu, sie funktionieren grundsätzlich. Erfahrungswerte aus dem praktischen Betrieb sind mir noch nicht bekannt. Hab es auch selbst noch nicht im Flug probiert, es ist zu kalt ;-)

Ich werde sicher eine Kurzsanleitung machen, ich denke der Softwarestand wäre jetzt wieder stabil genug.
Oder vielleicht findet sich jemand, der mithelfen möchte :)

Ganz kurz zum Aux Kanal:
Diese dient zum Ansteuern von zwei allgemeinen Schaltfunktionen, auxSW1 und auxSW2.
Als Aux Kanal kann ein beliebiger RC Kanal selektiert werden.
auxSW1 spricht an, wenn die Pulsbreite der Aux RC Kanal über 1.8 ms ist.
auxSW2 spricht an, wenn die Pulsbreite der Aux RC Kanal unter 1.2 ms ist.

zur Kontrolle den "Live Button" aktivieren.
Bei betätigung des AUX RC Kanals, sieht man einerseits die tatsächlich Pulsbreite in usec Einheiten.
Und bei Ansprechen eines Schalters ändert sich der angezeigte Wert und das Feld wird grün angezeigt.

Die auxSW1 und auxSW2 Schalter können nun verwendet werden.
Als FPV Schalter, oder zum Umschalten der ACC Zeitkonstante.
Dazu wird im Schalter Feld z.B. beim FPV die Nummer des Schalters, den man verwenden möchte, angeben.
1 oder 2 (Das Menü müsste man noch mit Textfeldern versehen ...).
Auch hier kann man wieder "Live View" zu funktionskontrolle verwenden.

Hinweise: Die Help Texte in der GUI (? Buttons) sollten ziemlich aktuell sein.


lg
Alois

















Hallo Alois,

danke auch mal von meiner Seite an dich für die Weiterentwicklung. Ich habe eines der ersten Martinez Boards (direkt vom Meister ;-)) und den Thread lange nicht mehr mitverfolgt. Meine alte Version 049 funktioniert gut, "never change a running system"…

Es scheint ja einige neue "Features" zu geben, wie von dir hier aufgelistet: http://fpv-community.de/showthread....oller-SOFTWARE&p=480311&viewfull=1#post480311

Ich habe allerdings nirgendwo weitere Erläuterungen zu den einzelnen Punkten gefunden, insbesondere "Auxilary Schaltkanal". Auch mit der Forumsuche bin ich nicht recht weitergekommen. Hoffe ich habe nichts offensichtliches übersehen..

Gruss,
Florian
 
Hallo, mein Martinezboard hängt sich bei folgenden Motoren immer auf:
(im Leerlauf funktionieren sie, jedoch im Gimbal nicht mehr !)

iPower Gimbal Brushless Motor GBM3506-130T
Specs:
Model NO.:GBM3506-130T
Weight:64g
Motor Dimensions:42x14mm
Stator Dimensions:35x6mm
Copper wire(OD):0.21mm
Configuration:12N14P
Resistance:14.3 ohms

Gemessener Widerstand = 11,6 Ohm

Wind type and termination method:Star style
Pre-wounded with 130 turns,3.17mm shaft / Hollow Shaft available
Bottom mounting holes: 16 and 19mm center to center
Top mounting holes: 12mm center to center
Camera range: 200-400grams

Laufen tut es mit diesen grossen Motoren (allerdings passen diese nicht in mein Gimbal):
Gimbal Brushless Motor 5010 / 0.21mm / 150T / 14.65ohms(Appr.)

Gemessener Widerstand = 13,8 Ohm

Liegt das daran, dass der Innenwiderstand zu gering ist?

Hilft es hier ein paar Windungen zusätzlich auf zu wickeln?

Die IMU ist mit verdrillten Leitungen angeschlossen.

Kann es daran liegen, daß das Gimbal aus Carbon ist und irgendwie leitet?

Gruß Stefan
 

ahahn

Erfahrener Benutzer
@Stefan
so spontan fällt mir ein:

probier einmal die Motor Leistung (PWM) zu reduzieren, nur um zu sehen ob der Absturz noch vorkommt.
Spätestens mit 0% sollte nichts mehr passieren.

Falls eine Motorwicklung Kontakt mit dem Gehäuse hätte, dann könnte das leitende Carbon eine Rolle spielen.

Falls der Computer über USB dranhängt, dieser ist of mit der Schutzerde verbunden. Über ein Netzgerät o.ä. könnte es eine Masseschleife geben.

Ein Wackelkontakt bei den Motorleitungen könnte auch die Ursache sein, bei Unterbrechung der Motorströme kommt es zu Induktionsspitzen die den Rechner zum Absturz bringen können.

Der Sensor hat eh keinen Kontakt zur Carbonfläche ?

Denkbar wäre das auch I2C Fehler die Regelung zum Absturz bringen.
Mit der I2C Error Anzeige in der GUI könnte man zumindest eine Indikation bekommen, siehe mein Post von gestern (Live View)

Oder wenn die Spannungsversorgung einbrechen würde ?

Bei den Motortypen weiß ich nicht so Bescheid.

lg
Alois
 

321mir

Neuer Benutzer
@Stefan
so spontan fällt mir ein:

probier einmal die Motor Leistung (PWM) zu reduzieren, nur um zu sehen ob der Absturz noch vorkommt.
Spätestens mit 0% sollte nichts mehr passieren.

Falls eine Motorwicklung Kontakt mit dem Gehäuse hätte, dann könnte das leitende Carbon eine Rolle spielen.

Falls der Computer über USB dranhängt, dieser ist of mit der Schutzerde verbunden. Über ein Netzgerät o.ä. könnte es eine Masseschleife geben.

Ein Wackelkontakt bei den Motorleitungen könnte auch die Ursache sein, bei Unterbrechung der Motorströme kommt es zu Induktionsspitzen die den Rechner zum Absturz bringen können.

Der Sensor hat eh keinen Kontakt zur Carbonfläche ?

Denkbar wäre das auch I2C Fehler die Regelung zum Absturz bringen.
Mit der I2C Error Anzeige in der GUI könnte man zumindest eine Indikation bekommen, siehe mein Post von gestern (Live View)

Oder wenn die Spannungsversorgung einbrechen würde ?

Bei den Motortypen weiß ich nicht so Bescheid.

lg
Alois

Hi Alois
Da besteht wirklich ein Problem. Bei mir genau das selbe Fehlerbild.
Leider stürzt das komplette Gimbal ab so das eine I2C Error auslese unmöglich ist.
Motoren ziehen in der letzten Position an und bleiben unter Spannung.
Setzt man die PWM auf 0 funktioniert das ganze (nur Softwareseitig)

Komischerweise funktioniert das ganze mit standart PWM wenn man nur das 5V USB angeschlossen hat. Die Motoren zittern vor sich hin, der Controller gibt alle Signale sauber aus ohne Fehlermeldung.

Hängst du jetzt aber einen 3S LiPo an schmiert der Controller sofort ab, egal ob Standalone oder am PC angeschlossen.

Habe das grosse Gimbal (Motor GBM 5010) von RC Timer und heute geupdatet. Vorher war R49 161 drauf, lief einwandfrei.

Gruss

Tino
 

ahahn

Erfahrener Benutzer
Hallo Tino,

ist ein merkwürdiges Problem.
Es wäre interessant zu sehen, ob zuvor I2C Fehler auftreten. Als das "Live View" anschalten und beobachten ob der I2C Fehler Tatsächlich auf Null bleibt. Falls es nicht sofort abstürzt.

Soweit ich gehört habe passiert das Ganze auch ohne zutun der RC Kanäle.
Eventuell unter Aux-> mode of Input alle Kanäle auf OFF stellen, damit sicher keine RC Interrupts auftreten

Ich habs bei mir mit einem RC-Timer Board und Gimbal für GoPro stundenlang (10h ununterbrochen) ohne Probleme in Betrieb.
Wenn es mit höherer Spannung auftritt würde ich ein elektrisches Problem vermuten.

Am wahrscheinlichsten halte ich Störungen am I2C als Ursache.
Die neue Software ist tendenziell schneller bei der I2C Abfrage, weil dier Rechner nun weniger Interrupt Last hat.
Das könnte erklären warum das Problem jetzt gehäuft auftritt.

Das RC-Timer Board benutzt 2k2 Pullupwiderständer, im Gegensatz zu vielen anderen Sensore die 10K Widerständer verbaut haben.
Daher wäre interessant, ob das Problem auch bei RC-Timer Boards auftritt oder ob es auf betimmte Typen beschränkt bleibt?

Die Anstiegszeiten der I2C Signale sind bei 10k definitiv an der Grenze.
Nach meiner Ansicht sollten man bis 1k runtergehen können (laut Datenblätter der beteiligten Chips geht das).
Ich habe bei einem Sensor auf 1k Pullups umgebaut, die Signale sind dann eindeutig Top.

Am besten würden wir weiterkommen wenn ich das Problem bei mir Nachstellen könnte.
Ein möglichst einfacher Aufbau, bei dem der Fehler häufig auftritt.

Ich probiers es selbst nachzustellen, falls ich es nicht schaffe, vieleicht kann mir jemand ein solches Problemgimbal borgen.

lg
Alois
 

ahahn

Erfahrener Benutzer
Stimmt, 1k Pullup macht Sinn.

Martinez mit 1k Pullup, hier reicht die die Anstiegszeit locker.


Martinez mit 10k Pullup, hier ist die Anstiegszeit knapp.





Alois
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten