Brushless Gimbal Controller - SOFTWARE
- Themenstarter Lonestar78
- Beginndatum
- Status
Hier ein Video :
Übrigens : @rc fan2 Deine Motoren sind einfach super. Sehr grosses Haltemoment.
http://www.youtube.com/watch?v=_2l7q2ZPwxM&feature=youtu.be
Übrigens : @rc fan2 Deine Motoren sind einfach super. Sehr grosses Haltemoment.
http://www.youtube.com/watch?v=_2l7q2ZPwxM&feature=youtu.be
Hallo Jungs
Kennt Ihr Debugging? :=)
Ich kann euch aus Erfahrung sagen das der DMP des 6050er kein solches aufschwingen hat wie in euren Videos, auch haben die fusionierten Daten keinen Drift, selbst in der Z Achse (Gier) praktisch nicht.
Die extreme Verzögerung und das übers Ziel hinausschiessen ist ja mal extrem bei eurem Videos?!
Wenn man den DMP richtig ausliesst Funktioniert das.
Ich selber Fliege damit einen Quatro, mit eigene Soft, und der liegt in der Luft wie ein schweizer Uhrwerk. :=)
Für die Skeptiker unter euch habe ich schnell ein Video gemacht, mithilfe einer Teekanne. :=)
Video:
https://vimeo.com/57947092
Der lange delay kommt durch das Tool, hat nichts mit dem DMP zu tun!
Wer dennoch meint es liege am DMP, soll doch einen Komplementärfilter benutzen.
Die Kopter fliegen natürlich auch damit astrein.
Solch ein Filter ist sehr einfach aufgebaut:
Der ACC wird Tiefbassgefiltert, der Gyro mit einem Hochpass, und mit verschiedener Gewichtung zusammen verrechnet.
So, ein Beispiel:
Winkel = (0.98 )*(Winkel + gyro * dt) + (0.02)*(Winkel_acc);
Kommt bitte nicht mit "Kalman", das hat auf solch einem popeligen Proz nichts zu suchen, und ist auch gar nicht nötig.
Was gar nicht geht ist das vermischen von DMP Daten und Rohdaten.
Beste Grüsse
Nitro
Kennt Ihr Debugging? :=)
Ich kann euch aus Erfahrung sagen das der DMP des 6050er kein solches aufschwingen hat wie in euren Videos, auch haben die fusionierten Daten keinen Drift, selbst in der Z Achse (Gier) praktisch nicht.
Die extreme Verzögerung und das übers Ziel hinausschiessen ist ja mal extrem bei eurem Videos?!
Wenn man den DMP richtig ausliesst Funktioniert das.
Ich selber Fliege damit einen Quatro, mit eigene Soft, und der liegt in der Luft wie ein schweizer Uhrwerk. :=)
Für die Skeptiker unter euch habe ich schnell ein Video gemacht, mithilfe einer Teekanne. :=)
Video:
https://vimeo.com/57947092
Der lange delay kommt durch das Tool, hat nichts mit dem DMP zu tun!
Wer dennoch meint es liege am DMP, soll doch einen Komplementärfilter benutzen.
Die Kopter fliegen natürlich auch damit astrein.
Solch ein Filter ist sehr einfach aufgebaut:
Der ACC wird Tiefbassgefiltert, der Gyro mit einem Hochpass, und mit verschiedener Gewichtung zusammen verrechnet.
So, ein Beispiel:
Winkel = (0.98 )*(Winkel + gyro * dt) + (0.02)*(Winkel_acc);
Kommt bitte nicht mit "Kalman", das hat auf solch einem popeligen Proz nichts zu suchen, und ist auch gar nicht nötig.
Was gar nicht geht ist das vermischen von DMP Daten und Rohdaten.
Beste Grüsse
Nitro
Zuletzt bearbeitet:
Wer sagt denn das sich der DMP aufschwingt ?
Wenn du bei deinem quad die PID Werte falsch einstellst , schwingt der sich mit sicherheit auch auf .
Wir haben bislang nochkeine ertesteten PID werte , das dauert halt eine weile die passenden zu finden .
Nur mit DMP Daten arbeiten ist viel viel viel zu langsam , genau aus diesem Grund verwenden wir die Rohdaten vom Gyro .
Drift gibt es auch keinen
Also PID werte suchen ist angesagt .....
Wenn du bei deinem quad die PID Werte falsch einstellst , schwingt der sich mit sicherheit auch auf .
Wir haben bislang nochkeine ertesteten PID werte , das dauert halt eine weile die passenden zu finden .
Nur mit DMP Daten arbeiten ist viel viel viel zu langsam , genau aus diesem Grund verwenden wir die Rohdaten vom Gyro .
Drift gibt es auch keinen
Also PID werte suchen ist angesagt .....
Hallo,
ich habe leider meinen Controller noch nicht und kann es nicht selbst testen aber ich habe mir heute mal die Version 3.6 mit der Auswahl zwischen DMP und und RAW_GYRO vorgenommen. In den RAW_GYRO Loop habe ich den Low-Pass-Filter aus Version 3.7 reingenommen.
Die Datei kannst Du von hier runterladen, wenn Du möchtest: www.andreaskielb.de/_036A_2.rar
Im Moment steht die config.h auf DMP für P, I und D. Wenn Du die reine RAW_GYRO Variante testen möchtest, musst Du nur folgendes ändern:
/**********************************************/
/* Configure Control Algorithm */
/**********************************************/
// Use DMP or raw Gyro only
#define USE_RAW_GYRO
//#define USE_DMP
Vielleicht macht es ja Sinn, bis Sonntag wenn Lonestar wieder Zeit hat, nochmal die beiden Signalarten getrennt zu testen.
Außerdem habe ich noch in MPU6050.cpp den Aufruf der Sensibilität verallgemeinert, so dass auch diese Einstellung über config.h greift. Da könntest Du ja auch mal verschiedene Einstellungen testen.
setFullScaleGyroRange(MPU6050_GYRO_FS);
statt setFullScaleGyroRange(MPU6050_GYRO_FS_250);
Herzliche Grüße,
Andreas
ich habe leider meinen Controller noch nicht und kann es nicht selbst testen aber ich habe mir heute mal die Version 3.6 mit der Auswahl zwischen DMP und und RAW_GYRO vorgenommen. In den RAW_GYRO Loop habe ich den Low-Pass-Filter aus Version 3.7 reingenommen.
Die Datei kannst Du von hier runterladen, wenn Du möchtest: www.andreaskielb.de/_036A_2.rar
Im Moment steht die config.h auf DMP für P, I und D. Wenn Du die reine RAW_GYRO Variante testen möchtest, musst Du nur folgendes ändern:
/**********************************************/
/* Configure Control Algorithm */
/**********************************************/
// Use DMP or raw Gyro only
#define USE_RAW_GYRO
//#define USE_DMP
Vielleicht macht es ja Sinn, bis Sonntag wenn Lonestar wieder Zeit hat, nochmal die beiden Signalarten getrennt zu testen.
Außerdem habe ich noch in MPU6050.cpp den Aufruf der Sensibilität verallgemeinert, so dass auch diese Einstellung über config.h greift. Da könntest Du ja auch mal verschiedene Einstellungen testen
.setFullScaleGyroRange(MPU6050_GYRO_FS);
statt setFullScaleGyroRange(MPU6050_GYRO_FS_250);
Herzliche Grüße,
Andreas
Zuletzt bearbeitet:
void initResolutionDevider()
{
if(MPU6050_GYRO_FS == 0x00) resolutionDevider = 131.0;
if(MPU6050_GYRO_FS == 0x01) resolutionDevider = 65.5;
if(MPU6050_GYRO_FS == 0x02) resolutionDevider = 32.8;
if(MPU6050_GYRO_FS == 0x03) resolutionDevider = 16.4;
}
Kommt der ResolutionDivider im Moment auch für DMP zum Einsatz? Ich habe es in 3.7 bisher nur beim Roh-Gyro-Code finden können...
_________________________________________________________________
Bei dem Code für die Ardu-IMU, den ich benutze und der alles über DMP macht, passe ich das auf ähnliche Weise über einen Gyro-Gain-Faktor an:
// MPU6000 sensibility ( theorical 0.0076 => 1/131.2LSB/deg/s at 500deg/s, 0.0152 => 1/65.6LSB/deg/s at 500deg/s, 0.0305 => 1/32.8LSB/deg/s at 1000deg/s, 0.0609 => 1/16.4LSB/deg/s at 2000deg/s)
#define Gyro_Gain 0.0152
... ohne die Anpassung funktioniert es auch da nicht richtig.
{
if(MPU6050_GYRO_FS == 0x00) resolutionDevider = 131.0;
if(MPU6050_GYRO_FS == 0x01) resolutionDevider = 65.5;
if(MPU6050_GYRO_FS == 0x02) resolutionDevider = 32.8;
if(MPU6050_GYRO_FS == 0x03) resolutionDevider = 16.4;
}
Kommt der ResolutionDivider im Moment auch für DMP zum Einsatz? Ich habe es in 3.7 bisher nur beim Roh-Gyro-Code finden können...
_________________________________________________________________
Bei dem Code für die Ardu-IMU, den ich benutze und der alles über DMP macht, passe ich das auf ähnliche Weise über einen Gyro-Gain-Faktor an:
// MPU6000 sensibility ( theorical 0.0076 => 1/131.2LSB/deg/s at 500deg/s, 0.0152 => 1/65.6LSB/deg/s at 500deg/s, 0.0305 => 1/32.8LSB/deg/s at 1000deg/s, 0.0609 => 1/16.4LSB/deg/s at 2000deg/s)
#define Gyro_Gain 0.0152
... ohne die Anpassung funktioniert es auch da nicht richtig.
Zuletzt bearbeitet:
Das ist der Code für die Ardu-IMU mit dem MPU-6000, den ich verwende: www.andreaskielb.de/Gimbal(500).rar
Vielleicht kannst Du Dir den Eintrag ja dort abschauen - es ist ja wahrscheinlich ganz ähnlich...
500 deg/sec läuft stabil, 250 deg/sec allerdings überhaupt nicht ?!
Vielleicht kannst Du Dir den Eintrag ja dort abschauen - es ist ja wahrscheinlich ganz ähnlich...
500 deg/sec läuft stabil, 250 deg/sec allerdings überhaupt nicht ?!
Von dererlei Feinheiten sind wir zwar noch weit entfernt, aber bevor ich es vergesse:
Feature Flugzeugsimulation
Ein parametrierbarer Grenzwert ab dem nicht mehr geregelt wird, um geglättete Kurven fliegen zu können.
Feature Beschleunigungskurve
Parametrierbare Kurve (neg log -> lin -> pos log) um das Ansteuerverhalten durch die Fernbedienung beeinflussen zu können.
Das FB-Signal sollte über einen Wert glätt- und verzögerbar sein, damit bei Leute mit zittrigen Fingern nicht die Kamera wackelt.
Grüße, Ray
Feature Flugzeugsimulation
Ein parametrierbarer Grenzwert ab dem nicht mehr geregelt wird, um geglättete Kurven fliegen zu können.
Feature Beschleunigungskurve
Parametrierbare Kurve (neg log -> lin -> pos log) um das Ansteuerverhalten durch die Fernbedienung beeinflussen zu können.
Das FB-Signal sollte über einen Wert glätt- und verzögerbar sein, damit bei Leute mit zittrigen Fingern nicht die Kamera wackelt.
Grüße, Ray
Hallo zusammen,
hier mal eine kurze Zusammenfassung meiner gestrigen Tests mit der 37 Software. Ich habe dabei ein Minimalsystem und vorerst nur die Rollachse betrachtet.
Egal mit welchen PID- Einstellungen ich es probiere: der Ausgleich auf der Rollachse funktioniert gut solange das Gimbal in Bewegung ist. Am Endpunkt angekommen wird dieser nicht sauber angefahren und der Rollmotor schwingt bei nidrigem P- Wert um ca. 10°.
Mit höherem P-Wert schwingt sich die Rollachse dann komplett auf.
Sobald das Gimbal bwewegt wird, funktioniert der Ausgleich scheinbar gut. Der Motor wird sauber nachgeführt und es sieht so aus, als würde er dort stoppen wollen, wo er soll.
Ältere Versionen:
Bei reiner Verwendung des Gyro funktioniert die Regelung super. Bei langsamen Bewegungen gibt es ein paar Ruckler. Bei schnellen Bewegungen wird die Kamera sauber nachgeführt.
Das einzige Problem ist der Gyrodrift, welcher mal mehr und mal weniger stark ausfällt. Bei Verwendung der Quaternationsdaten ergibt sich wieder das gleiche Phänomen wie bei der 37`ger Software.
Am besten funktioniert bei mir immer noch eine 1/1 Regelung mit Sensor an der Gimbalhalterung unter Verwendung der Quaternationsdaten.
PS: ich benutze übrigens die Flyduino MPU.
Viele Grüße
Henry
hier mal eine kurze Zusammenfassung meiner gestrigen Tests mit der 37 Software. Ich habe dabei ein Minimalsystem und vorerst nur die Rollachse betrachtet.
Egal mit welchen PID- Einstellungen ich es probiere: der Ausgleich auf der Rollachse funktioniert gut solange das Gimbal in Bewegung ist. Am Endpunkt angekommen wird dieser nicht sauber angefahren und der Rollmotor schwingt bei nidrigem P- Wert um ca. 10°.
Mit höherem P-Wert schwingt sich die Rollachse dann komplett auf.
Sobald das Gimbal bwewegt wird, funktioniert der Ausgleich scheinbar gut. Der Motor wird sauber nachgeführt und es sieht so aus, als würde er dort stoppen wollen, wo er soll.
Ältere Versionen:
Bei reiner Verwendung des Gyro funktioniert die Regelung super. Bei langsamen Bewegungen gibt es ein paar Ruckler. Bei schnellen Bewegungen wird die Kamera sauber nachgeführt.
Das einzige Problem ist der Gyrodrift, welcher mal mehr und mal weniger stark ausfällt. Bei Verwendung der Quaternationsdaten ergibt sich wieder das gleiche Phänomen wie bei der 37`ger Software.
Am besten funktioniert bei mir immer noch eine 1/1 Regelung mit Sensor an der Gimbalhalterung unter Verwendung der Quaternationsdaten.
PS: ich benutze übrigens die Flyduino MPU.
Viele Grüße
Henry
- Status
