Brushless Gimbal Controller - SOFTWARE

Status
Nicht offen für weitere Antworten.
Ja, genau das war gemeint ... lässt sich also nicht so leicht in die software intergrieren :(

... aber warum würde es keinen sinn machen das zu tun? Bei der zenmuse wird das doch auch genutzt. Ich gehe davon aus, dass die encoder sehr viel mit der super genauigkeit zu tun haben. Warum sollte das hier keinen sinn machen? Danke für die antwort!

rené
 
..und ein wesentlich komplexeres System.

Ein Encoderring mit ausreichend hoher Auflösung kostet etwa 70€ pro Achse (MPU 6050 etwa 7€) Um den Encoder sinnvoll nutzen zu können, müsste das Gimbal perfekt gebaut sein, darf keinerlei Spiel haben. Als drittes müßte die entsprechende Software geschrieben werden. Wenn man nun Videos vom Alexmoscontroller sieht, fragt man sich zu Recht wozu man diesen Aufwand betreiben sollte?! - Für HighEndSysteme mag es Sinn machen, für GoPro oder NEX-Gimbals braucht es die zusätzliche Komplexität definitiv nicht. My 50 cents..
 
Ich bin mir fast sicher, das es durch die Encoder wesendlich weniger probleme mit der Stellgenauigkeit, Ruckeln, Drehmoment etc. geben würde.
Die Mechanik des Gimbals wäre auf jedenfall kein Problem. ;-)
Nur meine wenigkeit kommt da mit der Elektronik nicht weiter. Leider.
 

OlliW

Erfahrener Benutzer
sorry, wenn ich da jetzt nachfrage
Warum bist du dir
fast sicher, das es durch die Encoder wesendlich weniger probleme mit der Stellgenauigkeit, Ruckeln, Drehmoment etc. geben würde
wenn
meine wenigkeit ...da mit der Elektronik nicht weiter
kommt?? Wie kommst du ohne 2 auf 1? Ich bin da neutral und lasse mich gerne von dir überzeugen, aber ein überzeugendes Argument würde ich mir dann schon wünschen.

PS: ob irgendetwas für irgendwenn Sinn macht kann natürlich vom Irgendwenn beantwortet werden; in diesem Sinne ist jede Frage nach dem Sinn ohne einen "Massstab" per se sinnlos... daher habe ich als Massstab vermutet dass Ihr zwar BruGi verbessern aber aufwandsmässig nicht gleich Lichtjahre davonstechen wollt... wenn meine Vermutumg falsch war, dann ist es auch meine Antwort.
 

biele01

Erfahrener Benutzer
möchte mal was einwerfen. Encoder für 70€ ist doch quatsch. Zb ein Hochauflösender Linear Magnetencoder könnte zb auf einer kleinen platine direkt hinter den Magnetring eines BLMotors "geklebt" werden. er zählt jeweils von Plus zu minuspol und so weiter. also zb ein 12 bit linear magnet encoder von AMS (http://www.ams.com/eng/Products/Mag.../Linear-Incremental-Magnetic-Position-Sensors ) kostet um die 5€ und löst 1024 steps von magnet zu magnet auf. also bei einem 14 pol Motor. 14336 steps. Das wären 39 einheiten je Grad! Also ich weiss nicht an welche encoder du für 70€ gedacht hast aber ich hab auch schon die magnetencoder verwendet und das funktioniert perfekt. .. ein encoder am rand hinter jeder motorglocke und das würde den ACC zum lage korrigieren überflüssig machen...
 
Zuletzt bearbeitet:
Nun Fakt ist das zwei recht gute System mit Encoder arbeiten:
DJI und Freefly!
Warum?
Nun ich denke, dass gerade der Encoder den relativ kleinen Motoren eine Hilfe ist, sie genauer zu positionieren und entsprechend zu bestromen. (Laienhaft von mir ausgedrückt).
Daher ist es, denke ich angebracht, darüber nachzudenken, ob dies so auch in den BruGi mit einzubinden wäre.
Nicht mehr und nicht weniger.
 
Bevor ich von AlexMos erfuhr hatte ich versucht zu verstehen wie das Zenmuse funktioniert. Bin dann über 7 Ecken auf Hall-Encoder gekommen die, glaube ich, 4096 Schritte auf 360° auflösten - ich konnte damals nichts günstigeres finden und wußte bis heute nicht das Magnet-Encoder so hoch auflösen - man die Polmagneten als "Geber" nutzen kann.

Nachtrag: Wenn die Entwickler über den Spendenbutton soviel verdienen das sie Ihren regulären Job schmeissen können, dann wären solche komplexen Regelungen vielleicht zu realisieren. ;)
 
Zuletzt bearbeitet:
Ich versuch´s mal "laienhaft" zu erklären...
Der Encoder wird benötigt um den Winkelfehler des Gimbals bei geneigtem oder gekipptem Trägersystem (schiefer Kopter) bei der Berechnug der Winkel mit berücksichtigen zu können.
Nicht mehr und nicht weiger ;)
Beispiel, wenn der Gimbal-Träger nach vorne geneigt wird, stimmt Roll nicht mehr, also 15 Grad Vorgabe am Motor ergeben auf der Horizontal gehaltenen Wippe nur vielleicht noch 10 Grad Auslenkung.
Das verändert neben dem Schwerpunkt, auch die Masseverschiebung und die gesamten PID würden auch nicht mehr passen.
Einige Systeme verwenden da eben Winkelgeber, andere eine zweite IMU wieder andere sogar alles zusammen.
Dann hat man natürlich auch einen Gimbal der relativ aufwändig, aber und auch mit Sicherheit seinen Preis wert ist ;)
...
Also ich wäre ja schon froh, wenn das Martinez überhaupt die Lage der Wippe im Raum richtig auswerten würde ;)
Glaubt mir, dann vermisst niemand mehr einen Drehgeber... nicht auf dem Level, wo wir hier basteln ;)
 

OlliW

Erfahrener Benutzer
wieso sollten Encoder fundamental nötig sein?
das Brugi/AlexMos weiss doch schon Dank der IMU zu jedem Zeitpunkt genau wie der Winkel am Motor ist!!!
(die wissen also genau "den Winkelfehler des Gimbals bei geneigtem oder gekipptem Trägersystem (schiefer Kopter)"!)
es kann also "nur" um bessere Auflösung, bessere Regelung, ausnutzen redundanter Messwerte (data fusing) etc gehen...


ein encoder am rand hinter jeder motorglocke und das würde den ACC zum lage korrigieren überflüssig machen...
das ist falsch
das würde nur gehen wenn du die Lage des Copters exakt kennen würdest... dann braucht's aber entweder ein zweites Inertialsystem oder man zapft das Inertialsystem der Flightcontrollers an... (KT's zweites IMU)

geht natürlich alles... aber ich denke die meisten gehen lieber fliegen und lassen Euch derweil gerne daran basteln... ;)

Nun ich denke, dass gerade der Encoder den relativ kleinen Motoren eine Hilfe ist, sie genauer zu positionieren und entsprechend zu bestromen.
tatsächlich sehe ich das sogar nicht so ganz anders... und habe mich bei den kleinen Motoren für mein nicht-funktionieren-wollendes Mikrogimbal selber bereits gefragt ob man das nicht sinnvoll nutzen könnte (da kommen die Hallsensoren nämlich schon kostenlos mit dem Motor mit).

Zunächst: Die Auflösung würde man IMHO nicht wesentlich verbessern, also das ist IMHO nicht der entscheidende Aspekt, sondern man würde (1) die Ansteuercharakteristik linearisieren (also im dem Sinne genauer werden) und (2) den Lag zwischen dem angesteuerten Winkel bei der sine-wave Ansteurung und dem tatsächlichen Winkel vermeiden/verkleinern (scheint mir gerade bei kleinen Motoren ein riesen Problem... habe ich ein Video auf YouTube zu).

Und jetzt das ABER: Wie du selber erkannt hast muss man dazu die Ströme regeln. Dazu müsste man aber auch die Ströme messen, einen passenden eigenen, schnellen (!) Regler drumrum bauen, und dann würde es gehen. Der Regler müsste deutlich schneller als BruGi sein, damit das Sinn macht. Diese Konzepte gibt es (DTC, FOC, blablabla). Aber ich hoffe du erkennst, dass man das nicht mal eben mit nem Martinez Board hinbekommt, den dem fehlt sozusagen alles was man dazu benötigen würde, an Rechenleistung, an Messwerten, etc. pp. Auch wenn man nur (1) realisieren wollte müsste man einen Regler implementieren der deutlich schneller als Brugi ist damit das Sinn macht.

So ein bischen hat es schon seinen Grund warum die "besseren" Systeme teurer sind... muss jetzt halt jeder für sich wissen wieviel Investment (Zeit und/oder Geld) er für welches Ergebnis einsetzten will...
ich persönlich finde das Aufwand/Leistungs-Verhältnis des AlexMos-Konzepts faszinierend... aber ist natürlich nur meine Meinung
 
..und ein wesentlich komplexeres System.

Ein Encoderring mit ausreichend hoher Auflösung kostet etwa 70€ pro Achse (MPU 6050 etwa 7€) Um den Encoder sinnvoll nutzen zu können, müsste das Gimbal perfekt gebaut sein, darf keinerlei Spiel haben. Als drittes müßte die entsprechende Software geschrieben werden. Wenn man nun Videos vom Alexmoscontroller sieht, fragt man sich zu Recht wozu man diesen Aufwand betreiben sollte?! - Für HighEndSysteme mag es Sinn machen, für GoPro oder NEX-Gimbals braucht es die zusätzliche Komplexität definitiv nicht. My 50 cents..

hallo,

ich habe auch, wie andere vorredner, günstigere gefunden. die die für die zenmuse benutzt werden kosten etwa 23 dollar ...

preislich definitiv nichts was bei einem vermeintlichem qualitätssprung richtung zenmuse bei mir aufstößt.

mein wunsch ist die qualität einer zenmuse zu erreichen. ich habe mitbekommen, dass es einen topf für spenden gibt, um die entwicklung voranzutreiben - jedoch woher weiss ich, dass es in die richtung geht, die ich mir vorstelle? kann man dazu etwas sagen?

ein anderer weg:

gibt es eventuell personen hier im kreis, die sich eine umsetzung in diese richtung vorstellen können und das knowhow haben? ist es möglich ein projekt jenseits von diesem zu verwirklichen, dass sich mit der einbindung von encodern beschäftigt, um zenmuse-vergleichbare ergebnisse zu erzielen?

sollte es von euch leute geben, die sich dieses projekt vorstellen können, würde ich mich freuen, wenn ihr euch per PN meldet! mit welchen groben entwicklungskosten ist dabei zu rechnen?

hoffe dabei nicht kontraproduktiv für diesen hiesigen weg zu sein!


danke,

rené
 

quadraf

Erfahrener Benutzer
Das man die Werte auch über das keyboard eingeben kann.
Hat mich 2 h gekostet, dachte meine USB Verbindung sei hin, bis ich gemerkt hab, es nimmt nur Änderungen am Schieberegler.
Ist kein Superfeature, hält aber die Foren mit Hilferufen frei.
Oder deaktiviert die Editierung im Wertefenster, dann kommt auch keiner auf die doofe Idee da was reinzuschreiben.

P.S.
Supertolles Projekt mit fähigen Leuten.
@ LFX: Danke fur dein tip! Hatte mich nicht daran gedacht via tastatur ein zu geben...
@ Meister : Sorry fur den mistverstande weil es um "Grunen Gui" geht.
In folgenden update von B-Gimbal soll tastatur eingabe moglich sein.
Auch soll dan mehr resolution geben in alle graphic daten und zoom moglichkeit auf grafischen vortgang in x und y richtung.
Ich erwartte den update um montag...?

Hans
 
Die Eier trennen und das Eiweiß schaumig schlagen. Alle weiteren Zutaten außer dem Apfel in eine Schüssel geben und mit einem Mixer mischen, anschließend den Eischnee unterheben.

Jetzt den Apfel schälen und in kleine Scheiben schneiden und zum Teig geben. Nun etwas Öl in einer Pfanne erhitzen und den Teig beidseitig ausbacken, bis der Pfannkuchen goldbraun ist. Der Apfel kann natürlich auch weggelassen werden.
 
Hallo
ich habe aktuell das Problem das wenn ich mit der 048er GUI Werte in mein verbundenes Board übertrage.
Ich bekomme eine grüne Erfolgsmeldung, aber wenn ich dann der Controller erneut verbinde sind immernoch die alten Werte im Board.

Hat jemand einen Tip?
 

nico_99

Erfahrener Benutzer
Bei der Suche nach den richtigen Einstellungen ist es nicht notwendig immer in den EEPROM zu schreiben, das ist nämlich begrenzt...selbst wenn bis auf 100000 Zyklen.
Man könnte vielleicht darauf verzichten den EEPROM zu schonen und mit einem Save-Button arbeiten aber ob das wirklich so lästig ist?
 

ray_tracer

Erfahrener Benutzer
Mal was anderes, dieses schief stehen bei Gimbal Nick und Kopter Yaw...
Kann da der DMP Mode oder wie das beim MPU6050 heißt helfen?
Wenn ja, kann mir und allen anderen mal jemand erklären, was man im sorce dazu umstellen muss?
Die 046 sollte das noch können. In _046.ino config.useACC = false; setzen und dann sollte es aktiv sein.
Muß ich heute auch noch mal testen.

Ich bin leider ein schlechter Programmierer, aber ich habe mich ein wenig mit 3D Motion Tracking etc. beschäftigt und muß sagen, daß alle Systeme, die eine Sensorlageunabhängige Raumorientierung errechnen können dafür Rechenleistung benötigen, die der 328P nicht liefert.

Z.B. UM6-LT (STM32) oder X-IMU (keine Ahnung)

Vielleicht würde es ja auch helfen, die jetzige Hardware auf einen Kontroller pro Achse zu ändern?
 
O.K. das kann ich mal testen, aber den ACC wollte ich eigentlich nicht abschalten.
Das mit der Rechenleistung bzw Mathematischen Fähigkeiten ist wohl wahr... mit nem STM32 ist da einiges einfacher.
Wir haben ja Jahre mit dem CorvusM3 Projekt "verschwendet" verbracht und auch wenn es bis heute nur ein "rudimentäre billig IMU" geworden und geblieben ist, so haben wir doch genug Grundlagen um einen Gimbal in kürzester Zeit mit dieser Plattform aufzubauen.
Sachen wie Quaternion und Kalmann sind zudem auf einer 32Bit Umgebung eigentlich mehr ein Puzzeln als Programmieren.

Wie auch immer, ein Controller eine Achse, darüber habe ich schon nach gedacht. Da fallen viele Mathematischen Probleme weg, Das kann man sogar schon "Analog" lösen, ohne Prozessor, ohne Software ;)... Aber die Vorteile einer Achskopplung hat man dann leider auch nicht.
Ich weis nicht, Aber ich denke lieber richtig Rechenleistung und dann nur mit einem Sensor arbeiten ist dann am ende doch die einfacherer Lösung, zumindest von der Hardware... Und Software ist ja einfach, wenn man keinen Arduino nehmen muss ;)

Den einzelnen Motor Controller mit STM32, Uart und I2C kannst Du schon fertig kaufen, da musst Du eigentlich "nur" noch die Software passend schreiben ;)
http://autoquad.org/esc32/
(habe ich sogar welche hier )
;)
Hab ich auch schon dran gedacht, aber wie gesagt, bin mir noch nicht genau sicher ob dieses Einzelcontroller Konzept sinnig ist.
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten