Basecam SimpleBGC 32 Extended

Status
Nicht offen für weitere Antworten.

r0sewhite

Erfahrener Benutzer
#1
Da der Dragon II nun mit Encodern demnächst in den Regalen stehen wird, habe ich mich in letzter Zeit mal etwas ausführlicher auf dem Controller-Markt umgeschaut. Der SimpleBGC 32 Extended wäre mir fast durch die Lappen gegangen, weil ich Basecam-Controller irgendwie bisher immer nur von Paul (Flyduino) bezogen habe und Paul die Extended Version gar nicht führt. Also kurzerhand direkt bei basecamelectronics.com bestellt.

Die Unterschiede zum normalen SimpleBGC 32 erscheinen auf den ersten Blick gering, wirken sich aber extrem positiv aus: Für den Anschluss der Encoder stehen auf der Unterseite 6-polige JST SH-Buchsen als PWM- oder SPI-Eingang bereit, so dass man die normalen PWM-Eingänge nicht mit den Encodern belegen muss. Vermutlich für Viele eine Erlösung: Den Controller gibt es wahlweise auch mit CAN-Bus IMU, so dass endlich eine verlässliche Verbindung besteht.

Die bisherigen Tests sind echt vielversprechend: Sobald man die Encoder in der GUI einmal aktiviert und kalibriert hat, schaltet der BGC die Ansteuerung der Motoren auf Field Oriented Control um. Die Motoren verlieren keine Kommutierung mehr und die Kraft der Motoren wird ab nun geregelt. Der Controller gibt innerhalb seines vorgegebenen Spielraums die Kraft auf den Motor, die nötig ist, um die Achse in ihrer Sollposition zu halten. Vereinfacht ausgedrückt: Je stärker man eine Achse aus ihrer Position drückt, desto stärker drückt der Motor dagegen.

Noch nicht ganz eindeutig im Manual erklärt ist, dass man für einen hohen Effekt auch den Power-Wert jedes Motors auf ein vergleichsweise überhohes Maß anheben muss. Allerdings erst nach dem Aktivieren der Encoder, was eigentlich nochmal ein neues PID-Tuning erfordert, wenn man es ganz präzise haben will. Sorge vor überhitzten Motoren muss man nicht haben, da die Kraft ab nun geregelt wird und im Normalfall minimal ist.

Selbst mit 12-Bit PWM habe ich schon mit etwas manuellem Nachtunen eine schnellere und bessere Rückstellung der Winkelfehler beobachtet. Ohne Encoder habe ich im Regelfall kaum Winkelfehler kleiner 0,02 Grad erreicht und selbst dazu brauchte es ein paar Sekunden Ruhephase. Mit den Encodern über PWM sind 0,01 Grad und selbst 0,00 Grad durchaus möglich und das mit schnelleren Stellzeit und auch im Realbetrieb, sofern man den Gimbal nicht gerade wild herumschaukelt. Da mir klar ist, dass 0,00 nicht tatsächlich 0 Grad entspricht, würde ich mich hier in der GUI über eine Nachkommastelle mehr freuen.

Interessanterweise habe ich zumindest in der Theorie keine besseren Ergebnisse mit Encodern an SPI erreicht, obwohl hier die Auflösung bei 14 Bit liegt. Ob es an einem höheren Rauschen liegt oder nur an den fehlenden Nachkommastellen der GUI, kann ich nicht sagen. Da meine höchstauflösende Kamera eine Alpha 6000 ist, kann ich faktisch am Bildmaterial auch keinen Unterschied ausmachen. Beides funktioniert problemlos.

Ein nettes Feature in der GUI sind die Balkenanzeigen, die die Balance jeder Achse grafisch darstellen. Das dürfte so manchem das mechanische Trimmen erleichtern. Auf der anderen Seite bietet der Betrieb mit Encodern und Field Oriented Control auch eine größere Fehlertoleranz, was die Balance angeht. Der Betrieb mit einer Sony SEL P1650 Zoomlinse ist z.B. problemlos möglich, wenn auch mit Einschränkungen. Das hochfrequente Aufschwingen der Tilt-Achse beim Schwenken nach unten kommt vom konstruktionsbedingten Spiel im Bajonett-Verschluss. Um das zu verhindern, hat der DII die Objektivstütze der Jordana geerbt. Allerdings haben wir nun eine Zoomlinse mit beweglichem Tubus, die genau die gleiche Problematik auslöst. Mit hohen PID-Werten steil nach unten filmen geht daher nur, wenn man den Tubus in seiner Zoom-Position mit einer Umwicklung Isoband fixiert hat.

Dennoch ist das ganze System deutlich unempfindlicher und ich denke, dass wir bei der Handheld-Version des DII, die komplett montiert mit BGC kommt, in der Lage sein werden, ein Default PID-Set draufzuladen, das zumindest mit den meisten durchschnittlichen Kameras funktionieren wird.

Einzig etwas nachteilig sehe ich die 6-poligen JST SH-Buchsen für die Encoder. Dem BGC liegen zwar etwa 10cm lange Kabelpeitschen bei, doch ohne Fummel-Lötarbeit geht es wohl nicht. Allerdings muss man fairerweise dazu sagen, dass größere Buchsen wohl kaum auf das Board gepasst hätten.

 
#2
Hallo Leute.

Ich möchte mir dieses Gimbal anschaffen. Mir wurde auch geraten, dass dieser Controller dafür ganz gut sein soll.
Meine Frage ist jetzt aber. Wenn ich auf diese Seite vom Controller gehe, was muss ich für einen Typ des IMU-Sensors aussuchen? Ist das die 12C Rev/B oder Kann?

Ich hoffe es kann mir hier wer einen Rat dazu geben.
Über eure Hilfe wäre ich sehr dankbar.

LG Michael
 

r0sewhite

Erfahrener Benutzer
#3
Ich würde auf jeden Fall mit CAN-Bus IMU kaufen. Mit I2C gab es immer mehr oder weniger Probleme. Meistens erst ab Leitungslängen, die beim Dragon nicht zum Tragen kommen aber wenn es schon eine IMU mit CAN-Bus gibt, sollte man die in jedem Fall bevorzugen.
 
#4
Hallo Timan

Danke für die Infos. Was mich zur Zeit noch Kopfzerbrechen bereitet ist wie schließe ich den Controller dann an. Nick, Roll und Yaw ist mir klar, aner da sind noch die Anschlüsse für den oder die Encoder auf der rechten Seite. Gibt's da irgendeinen Anschußßplan oder sowas? Weißt du da was?

LG Michael
 

r0sewhite

Erfahrener Benutzer
#5
Dem Basecam Controller liegt ein Blatt mit einer ordentlich beschrifteten Grafik von Ober- und Unterseite des Boards bei. Da ist eigentlich alles bestens erklärt. Zum Dragon gibt's ein Manual, in dem die Encoder-Anschlüsse ebenfalls dokumentiert sind.

Im Grunde genommen musst Du neben den drei Motorleitungen und der IMU nur die drei Encoder an die drei Encoder-Anschlüsse des Controllers anschließen. Das ist kein Hexenwerk. Dem Controller liegen drei 10cm lange Kabelpeitschen mit JST SH Stecker für die Encoder bei, die wahlweise SPI- oder PWM-Anschluss erlauben. Um die Encoder des Dragon per PWM anzuschließen, brauchst Du im Grunde genommen nur drei einfache Servokabel mit den Peitschen zu verbinden. Willst Du SPI nutzen, brauchst Du 6-polige oder pro Encoder zwei normale Servokabel. Das dürfte aber ein bisschen viel Kabelsalat sein.

Wir sollten eigentlich schon lange spezielle SPI-Kabel im Shop haben, doch leider lässt uns der Hersteller warten. Nach eigener Erfahrung kann ich Dir aber bestätigen, dass Du keinen spürbaren Unterschied zwischen PWM und SPI feststellen wirst. In beiden Fällen ist zumindest mit der aktuellen Basecam GUI (Winkelfehler werden in Grad mit zwei Nachkommastellen angezeigt) kein messbarer Unterschied vorhanden. Vielleicht würde man einen sehen, wenn drei Nachkommastellen angezeigt werden.
 
#6
Vielen Dank für deine Infos. Sobald das Projekt startet werde ich mich wieder melden.

Eine Frage habe ich dann aber noch.
Wie kann ich das lösen. Ich möchte eine Sony Nex dafür verwenden. Die wäre ja nicht das Problem, aber da ich ja auch dieses Teil dazu verwende, um zwischen Foto und Video umzuschalten, stellt sich jetzt bei mir die Frage wie kann ich da die Kamera 360° drehen ohne dass ich die Kabel dann abdrehe bzw. kaputt mache? Was ich so gesehen habe, hat das Gimbal keinen Schleifring beim Yaw-Motor. Ich verwende ein elektrisches Landegestell.
Hast du da eine Idee?

Gruß Michael
 
Zuletzt bearbeitet:

r0sewhite

Erfahrener Benutzer
#7
Der Dragon war eigentlich nie ein freier 360-Grad-Gimbal. Brauchst Du das denn, weil Du im Team fliegst? Wenn Du alleine fliegst, würde ich darin keinen Sinn sehen.

Es gäbe zwar den GB4106 auch als Hohlwellenmotor, doch die einzige Encoder-Lösung würde aus einer mittels einem dünnen Alurohr verlängerten Hohlwelle und dem AMT203 Ring-Encoder bestehen. Machbar ist es also, jedoch mit etwas Gebastel.
 
#8
Hallo Tilman.

Nein ich fliege nicht in einem Team, aber für schöne Luftaufnahmen finde ich ein 3Achs Gimbal besser. Sicher man kann den ganzen Copter auch drehen. Von daher ginge ein 2Achs auch.

Gruß Michael
 

r0sewhite

Erfahrener Benutzer
#9
3 Achsen für eine schöne Stabilisierung ist ja auch völlig in Ordnung. Ich hab mich nur gefragt, wofür er 360 Grad drehbar sein muss.
 
#10
Hallo Tilman.

Diese Frage würden sich sicher mehrere stellen, aber für mich war es von Anfang an klar, dass es ein 3Achs Gimbal werden soll. Das Dragon ist ja ein 3Achs und würde für mich und meine Kamera ganz gut passen.

Gruß Michael
 
#11
Hi,
Eine Frage, da ich mit Encoder noch keine Erfahrung habe: Den Dragon 2 kann man aber schon auch herkömmlich bzw. ohne Encoder verwenden oder?
Danke, lg
 
#12
Hi,

so nachdem ich mich jetzt mit dem extended controller etwas "gespielt" habe, möcht ich da mal einen kleinen Bericht abgeben.

Zuerst hatte ich ja etwas Bammel, dass ich mich wieder nur ärgern muß und das Ganze nicht so hinhaut, wie ich mir das vorstelle. Da bin ich wohl falsch gelegen... Ich hatte vor Jahren mal das 8bit-AlexMos getestet, das war alles für nix. In letzter Zeit hab ich nur Phobotic verwendet... (bzw. auch das Zenmuse Z15)

Natürlich hatte ich mich zuvor im Manual etwas eingelesen und hab nach YT-Videos gesucht, die halbwegs brauchbar sind (da hab ich 2 gefunden, siehe unten). Über den extended Controller findet man zwar nicht viel, aber das Meiste kann man von den anderen boards/Versionen übernehmen. Die Menüs sind in der neuesten Version etwas anders, aber das findet man dann schon.

Evtl. weiß der Eine oder Andere schon, was ich hier von mir gebe, aber ich schreibe hier für evtl. Neulinge, so wie ich es vor kurzem auch war.

Zuerst hab ich also mal die ganzen Kalibrierungen von der IMU und dem Frame gemacht (+Acc + Gyro); da bin ich wie folgt vorgegangen, also die IMU und das board nicht verbaut, sondern mal mit Strom versorgt und alles kalibriert. Da ist jedenfalls wichtig, dass man die IMU während der Kalibrierung keinen Millimeter bewegt - also Hände weg :):
https://www.youtube.com/watch?v=qXeSiIgVP2w&t=112s&index=2&list=PL0udpmaR3WVgrvbJqAvZblzL50cGigRsp

Dann hab ich die Locations von main und frame IMUs (hardware tab) festgelegt. Das geht recht einfach mit dem "auto" button und ist eigentlich selbsterklärend. Was dann noch folgt und recht wichtig ist, ist die Motorconfiguration, also Poles und Invert - da gibts wieder einen auto-button.

Ja und dann gehts eigentlich schon ans Motor-Power und PID-Tuning. Es gibt beim PID-Tuning zwar wieder einen auto button, aber die Motorpower muß man zuerst selbst festlegen (hardware-tab). Das autotuning ist zwar nicht schlecht, allerdings sind die Werte da meiner Meinung etwas zu hoch und man muß sie dann noch runterdrosseln. Im Endeffekt hab ichs dann händisch gemacht - zB so:
https://www.youtube.com/watch?v=-yFmsqQOgsA&t=1431s&index=1&list=PL0udpmaR3WVgrvbJqAvZblzL50cGigRsp
Wenn man ein wenig Gefühl entwickelt, dann wird man jedenfalls bald die richtigen PIDs finden...

Ja und jetzt zu den Encodern: Wie in einem anderen Fred erwähnt, hab ich ja den Dragon II mit Encodern verbaut. Ja und spätestens ab dem Zeitpunkt, wo man die Encoder aktiviert und kalibriert (+offset), bekommt man mal große Augen. Das Gimbal bzw. die Motoren haben plötzlich ein ganz anderes Verhalten. Alles läuft total smooth und solft ab, kein Rattern und Ecken von den Motoren mehr, wenn man eine Achse anstupst bzw. aus der Balancierung bringt - einfach genial. So kannte ich das nur vom Z15, allerdings jetzt noch etwas weicher!

So, ich dachte, das gibts ja nicht, wie cool das Ganze abläuft, bis ich einen Kam-Tilt nach unten versucht habe. Da bekam ich gleich mal volle Vibrationen. Sch*, ist also doch so, wie man es halt kennt. Da ich im Netz keine Lösung gefunden habe, hat mir Tilman dann eine super wertvolle Info gegeben: In der Software von SimpleBGC gibts einen Punkt mit "Notch-Filters". Man stellt das Gimbal also auf die Position, an der die Vibrationen auftreten und liest dann im "Monitoring" die Frequenz von den Vibrationen aus - und ab damit zu den Notch-Filtern. Das steht im Manual sehr gut beschrieben, wie man vorgehen muß. Innerhalb von 5 Minuten hatte ich alle Vibrationen weg; bei mir waren es Roll und Pitch, selbe Frequenz...

Follow-Yaw funktioniert auch sehr gut: Mit den Werten muß man sich bissl spielen, bis es einem passt (speed usw.) - jedenfalls richtet sich Yaw wieder komplett am Ausgangspunkt aus, wenn man es zur Seite stupst (zB 90°)

Der einzige Nachteil mit Encodern: Abgesehen von der ganzen Lötarbeit ist, dass man pro Motor 2x3 Kabeln zum Controller verlegen muß + die IMU Kabeln; im Großen und Ganzen also ein ganz schöner Kabelsalat, aber wenn man es sauber verlegt, dann fällts nicht mehr so auf - wegen der Balancierung mit den Kabeln muß man sich keine großen Gedanken machen, da die Motoren + Encoder die Kraft dementsprechend regeln...

Gut, das wars mal fürs Erste...
lg
Tom
 

Anhänge

#13
Ich hätte dazu bitte auch ein paar Fragen:
1.) Muss es das BaseCam SimpleBGC 32-bit Extended sein, oder kann ich das SimpleBGC 32-bit Tiny
B auch sein? Hier werde ich ja die Kabel anders belegen müssen, wenn mit Encoder arbeiter, da z.B. RC Roll schon besetzt ist. Gibt es von euch mit dem SimpleBGC 32-bit Tiny B mit Encodern und SPI schon Erfahrungen?
2.) Kann ich auch mischen, z.b. YAW (die ja die 360 Grad überschreitet) SPI und Roll und Pitch nur PWM?
3.) Wie habt ihr eurer Gimbal aufgehängt - welche Gummi etc.?

Danke. mfg Karl
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten