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.
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.
:
