Brushless Gimbal Controller - SOFTWARE

Status
Nicht offen für weitere Antworten.
Leute Leute…..
dieser Tred sollte einzig und allein der Software-Entwicklung zum Brushless Gimbal Projekt dienen siehe Post #1
In diesem Thread soll über Software und Algorithmen zur Brushless Gimbal Controller Hardware von Ludwig/RCFAN2 diskutiert werden
1400 Einträge und ich schätze mal 50% gehören nicht hier her.
Postet eure Probleme mit Installations und Inbetriebnahme Problemen in den dafür vorgesehenen Tred’s um die Sache hier übersichtlicher zu halten.
So das musste mal raus...
So Long
Gruß aus der grünen Hölle
 

nico_99

Erfahrener Benutzer
Meine Worte...!
 
Ich habe noch etwas zum Thema Achsentkopplung. Seit der Version 48 geht ja das senkrechte nach unten schwenken, das sehr gut funktioniert, wenn man nur diese eine Bewegung macht.

Dreht man aber den Gimbal dabei über die Pan-Achse, wird der Horizont schief. Das passiert auch, wenn die Kamera nur leicht nach unten geschwenkt ist. Man sieht das sehr gut in Matalas Video, der auch die Version 48 verwendet (beispielsweise bei 0.38 min.):

http://www.youtube.com/watch?v=M5jmKw3KIV0

Diesen Effekt hat man vor allem bei geringen Iacc Werten. Dreht man das Gimbal zurück in die Ausgangsposition, wird der Horizont wieder gerade. Durch Erhöhung des Iacc kann man den Effekt verändern, ich habe aber auch durch schrittweise Erhöhung des Wertes kein stabiles Ergebnis erziehlen können. Statt dessen beginnt die Roll-Achse zu flattern.

Ist die Kamera nicht geneigt sondern waagerecht ausgerichtet, ist die Kamera eigentlich immer stabil, fast gleichgültig welcher Iacc Wert eingestellt ist.
 

RC FAN2

Erfahrener Benutzer
Hab dazu noch keine genauen tests gemacht , aber das wird daher kommen das der ACC nicht mit Achsentkoppelt wird .
Werde es die Tage mal testen und ggf. im Code anpassen ....
 
Super!! Eine andere Sache wäre, ob man die strenge Prüfung bei der Initialisierung der MPU wieder entschärfen könnte, falls sie nicht zwingend notwendig ist. Ich hatte den Gimbal zwar jetzt nur zu Testzwecken an einem Seil aufgehängt, und auf dem Balkon bei ohne wirklich spürbaren Wind wollte er bereits nicht initialisieren "Motion detected...".

http://www.youtube.com/watch?v=Arjw2_zay_U&feature=player_embedded

Eine denkbare Anwendung wäre beispielsweise am Gummiseil für Fahraufnahmen oder an meiner Cablecam. Das würde jetzt im Moment nicht gehen...
 

Karsten J.

Erfahrener Benutzer
Genau das wollte ich jetzt schreiben, dass das gerade von mir auch so beobachtet wurde.
Weiterhin habe ich immer noch das Problem, dass sich das Gimbal selbständig um ca 5grad dreht und nicht mehr in die waagerechte zurück geht...

Gruss Karsten

Ich habe noch etwas zum Thema Achsentkopplung. Seit der Version 48 geht ja das senkrechte nach unten schwenken, das sehr gut funktioniert, wenn man nur diese eine Bewegung macht.

Dreht man aber den Gimbal dabei über die Pan-Achse, wird der Horizont schief. Das passiert auch, wenn die Kamera nur leicht nach unten geschwenkt ist. Man sieht das sehr gut in Matalas Video, der auch die Version 48 verwendet (beispielsweise bei 0.38 min.):

http://www.youtube.com/watch?v=M5jmKw3KIV0

Diesen Effekt hat man vor allem bei geringen Iacc Werten. Dreht man das Gimbal zurück in die Ausgangsposition, wird der Horizont wieder gerade. Durch Erhöhung des Iacc kann man den Effekt verändern, ich habe aber auch durch schrittweise Erhöhung des Wertes kein stabiles Ergebnis erziehlen können. Statt dessen beginnt die Roll-Achse zu flattern.

Ist die Kamera nicht geneigt sondern waagerecht ausgerichtet, ist die Kamera eigentlich immer stabil, fast gleichgültig welcher Iacc Wert eingestellt ist.
 

spreecopter

Erfahrener Benutzer
jemand von euch eine idee woher dieses komische stottern kommen kann? motoren und props sind gewuchtet, ein wobbeln ist es auch eher nicht das ein grossteil des video ohne diese probleme sind. kann es sein das der motor der roll-achse zu wenig power hat und das gimbal deshalb aus den tritt kommt?

[video=youtube;iNesx_TnsVI]http://www.youtube.com/watch?v=iNesx_TnsVI&feature=youtu.be[/video]
 

Kienzle

Erfahrener Benutzer
Denke ich auch, du fliegst ja recht zügige Kurven wobei dann schon ein paar fliegkräfte zusammen kommen und es dann doch wohl bissel eng wird mit der Haltekraft.
gruss
 

martinez

Erfahrener Benutzer
Problem mit den ACC Werten???

So! Guten Abend.

bzgl. dem unkontrollierten wegkippen, was ich immer noch habe…..

Ich war am Mittwoch bei einen guten Freund der auf den Gebiet Mikrocontroller echt fit ist. Er hat früher (über 10 Jahre her) auch mal bei Eurocopter entwickelt, unteranderen auch an Stabilisierungssystem…. (Er ist mittlerweile fast begeistert wie gut das mit den kleinen 8bit Atmel läuft, er meinte von Anfang an „da muss ein ARM rein“ ;) Hihi )
Um mein Problem zu simulieren habe ich eine sehr gute Methode gefunden. Es geht ja meiner Meinung um zu hohe Beschleunigungsmesswerte vom acc Sensor und nicht um die Haltekraft von meinen Motoren.
Wenn man den Copter in die Hand nimmt, Vorn zeigt weg und Hinten zeigt auf den Körper und sich um die eigene Achse dreht, kann man recht hohe Fliehkräfte erzeugen.
Bei dieser Aktion (Test) wirkt eigentlich keine Kraft auf die Roll- und Pitch Achse und das Gimbal sollte einfach in der Mitte stehen bleiben.
Ab einer bestimmten (nicht gemessen) Fliehkraft tickt das Gimbal auf einmal voll aus.
Probiert das mal aus, ob das bei euch auch so ist.

Mir ist bewusst, dass ein Copter so nicht fliegt, mir geht es hier um Beschleunigungswerte die im Flug (enge Kurven) und vor allem bei Wind vorkommen können.

Leider ist der Code, vor allem gewisse Berechnungen und Limits nicht Dokumentiert, sodass es ihm, auf die 2 Stunden nicht ganz klar geworden ist wie die Regelung zu 100% funktioniert / berechnet wird, aber wir haben trotzdem etwas herausgefunden.

Wir haben uns bei den „um die Eigene Achse drehen Test“ die Variable rollAngleACC und pitchAngleACC über den seriellen Monitor angeschaut. (orientationRoutines.h)
Diese sind bei langsamen Drehen bei sehr klein (0-3) Messwerten, wenn das Gimbal austikt werden Werte von über 50 angezeigt.
Daraufhin haben wir zum Test die Variable ACC Werte auf 20 limitiert, also jeder Messwert über 20 ist gleich 20.
Die Aussetzer bei den "Testdrehen" sind zu 100% weg! Ich habe mit so schnell um die eigene Achse gedreht das mir Hundeelend wurde, das Gimbal stand aber sicher genau gerade.


Das Problem an dieser quick and dirty Änderung ist, das es jetzt nicht mehr möglich ist das Gimbal über 20° nach unten zu schwenken. Hierfür werden diese höheren acc Werte wohl wieder benötigt. Das Gimbal dreht sich einfach immer weiter nach unten.
Ich will hier nur aufzeigen, dass es wohl im Flug durch äußere Einwirkungen (Absagen, Windstöße, schnelle Kurven mit hohen Fliehkräften) kurzzeitig zu erhöhten acc Werte kommen kann und dadurch die Gimbal Steuerung aussetzt. Was sich dann in diesen kompletten Wegkippen äußert.
Der Beschleunigungsmesswert ist doch eigentlich in 1. Beziehung dafür da um den Drift des Gyros zu kompensieren und 2. um das Gimbal nach unten neigen zu können. Oder?
Vielleicht könnte man ja bei der Driftberechnung den ACC Wert filtern, oder eben auf einen Wert limitieren, um den Drift zu kompensieren reichen doch eigentlich ganz kleinen Messwerte….

Hier die Codeänderungen in der orientationRoutines.h
Wir haben das Limit bei den count == 13 eingefügt, das Limit kann man ändern indem man die 20 und -20 in z.B. 30 -30 ändert.

Code:
if(count == 13) { rollAngleACC = (rollAngleACC >  20.0) ?  20.0 : 0.9 * rollAngleACC + 0.1 * ultraFastAtan2(-y_val,-z_val); 
                      rollAngleACC = (rollAngleACC < -20.0) ? -20.0 : 0.9 * rollAngleACC + 0.1 * ultraFastAtan2(-y_val,-z_val);
                    } 
    if(count == 14) { pitchAngleACC = (pitchAngleACC >  20.0) ?  20.0 : 0.9 * pitchAngleACC + 0.1 * (-ultraFastAtan2(-x_val,-z_val));
                      pitchAngleACC = (pitchAngleACC < -20.0) ? -20.0 : 0.9 * pitchAngleACC + 0.1 * (-ultraFastAtan2(-x_val,-z_val));
Das ist wie gesagt nur zum aufzeigen des Problems, das ist keine Lösung!


Ich bin mit diesen Einstellungen, erst 30 und dann mit 20 mit mein Y6 mal ein bisschen schneller geflogen, Standard PIDs MaxPMW auf jeweils 80.
Es funktioniert sau gut!!! (also bezogen auf das Wegkippen)

Was sagen die Softwareentwickler dazu?

Ab 2:09 Min hab ich auf 20 limitiert.
Ab 3:25 Uhr fliege ich ziemlich rasant...
http://www.youtube.com/watch?v=rCWH9aswMiY

Das Video wird gerade noch von Youtube bearbeitet....

Viele Grüße
Martinez
 
Zuletzt bearbeitet:

WingsOfThunder

Erfahrener Benutzer
Da ist unser Plattinenbauermeister dem Problem wohl dicht auf den Fersen. Muss ich morgen gleich mal ausprobieren... Danke dir.(Wolltest du nicht eigentlich nach Tobago oder so in Urlaub fahren??? gg )

lg Andre
 

Tiggr

Read Only Account
HIho!

@martinez:
Schöner konstruktiver Beitrag, find ich gut, dass sich mal wer genauer alles ansieht! Nicht, weil das bisher erreichte schlecht ist, sondern weil mehr Augen mehr sehen, und mehr Köpfe mehr Ideen haben!

Ich hab als ehemaliger Physiker ja nichts mit Regeltechnik am Hut gehabt, aber ich versuch mich gerade einzulesen. Und nichts von dem was ich lese erkenne ich im Code wieder! Da stecken wohl viele Optimierungen drin, die ich einfach nicht sehe!

Ich fände es sehr lehrreich, wenn das mal einer in einfache Worte fassen könnte, oder mich auf die richtige Literatur (bezahlbar) stuppst! Ich bekomme auch bald Bücher von einem E-Technik-Freund! ;)

ich will doch verstehen, was ihr da macht!

Tschüss
Marcus (aka Tiggr)
 
gimbal lock über 2 IMUs lösen !?

War die Sache mit dem gimbal lock Problem eigendlich schon zufriedenstellend über die Achskopplung gelöst?

Könnte man das Problem nicht ganz einfach umgehen, indem man dem controller zwei IMUs "spendiert"?
Also ein IMU, das nur die Lage der Roll-Achse misst und somit den Horizont gerade hält... während die zweite IMU auf der Nickwippe unabhängig davon den pitch kontrolliert... ???

Beim Servogimbal mit externen Potis gehts ja auch.. da hat auch jede Achse eine eigene Lagerückmeldung..

Und falls das Sinn macht...
Muß der controller hardwaremäßig stark geändert werden, oder lassen sich auch zwei IMUS über i²C getrennt auslesen?.. ist doch i²C, oder..?
 
Zuletzt bearbeitet:

Kienzle

Erfahrener Benutzer
Das sieht doch schon gut aus, in deiner Version ist es schon geändert? Ich kann keine sonderliche Veränderung bei mir feststellen (NEX5 Gimbal)

gruss
 

Kienzle

Erfahrener Benutzer
kommt drauf an bei einem flip kommt es ins schwitzen. ;-) ansonsten habe ich gerade nochmal ein bissel "getuned" es sieht schon gut aus.

Ich will es gleich nochmal testen, sollte man ansonsten von 20 noch ein bissel runter gehn?

gruss
 

Karsten J.

Erfahrener Benutzer
Nabend !

So, nun hab ich mir auch mal die geänderte Software von Martinez draufgespielt und ich muss sagen
DAT KIPPEN IST WEG !! Auch das Schiefstehen des Roll um 5-10° hat sich veringert auf max. 3-5°
Es scheint wirklich was mit der Winkelberechnung zu tun haben...
Leider kann man, wie Martinez schon erwähnte, Pitch nicht nach unten neigen.
Könnte man hier nicht einen Wert finden, der Roll stabilisiert und es dennoch erlaubt ca. 70-80° nach unten zu blicken ?

Gruß Karsten

am Montag geht´s los und mein Gimbal muss noch besser werden ;)

Hier mal die Software mit der Änderungen, only for test!
Anhang anzeigen 55980

Gruß
Martinez
 

raceagain

Erfahrener Benutzer
kurz frage mal an die experten hier. was kann ich noch ändern um bessere Ergebnisse zu bekommen? Was müsst ihr dazu wissen? Mayday Gimbal, SD20 Camera, Martinez Board 048,

http://youtu.be/SQfmyOReYzY

werte:

SP 15000.0 3000.0 3000.0
SR 23000.0 5000.0 4000.0
SA 0.0
SF 14 14
SE 60 80
SM 1 1 1 0
SRC -45 45 -45 45
UAC 1
SCA 1
SRG 1
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten