OpenX Sensor mit Imu 6050 Kalibrierung

Deleted member 51580 · Feb 12, 2017

In der oXs_config_description.h steht das man den 6050 Kalibrieren soll.

1. so wie ich es verstanden habe, den Seriellen Monitor aktivieren, um die Offsets aus zu lesen, dazu soll der Sensor plan auf dem Tisch liegen.
So weit ok, die ausgelesenen Werte für X,Y und Z werden dann in die config.h eingetragen, ergibt sinn.
Das Problem ist egal welche Werte ich dort eintrage, negativ oder positiv, egal ob 10 oder 16000 es ändert sich die Ausgabe in der Telemetrie nicht.

2. Ein Weiteres Problem ist mir aufgefallen, der AccZ verringert langsam ca. jede Minute seinen Wert um 1 dass ist fortlaufend, der Sensor liegt weiter auf dem plan Tisch.

Fehlersuche was ich bis jetzt versucht habe:
OXS Config nach weiteren Möglichkeiten durchsucht, aber nichts gefunden was die Probleme erklärt.
Einen neunen Arduino Pro Mini, eine neue IMU 6050, alle weiteren Sensoren erst mal ab geklemmt, also im Moment ist der Pro Mini nur mit der Imu 6050 verbunden und dem Empfänger.

Wenn das mal jemand verifizieren könnte, oder ist das bei mir nur so?

Bin ganz Ohr für Ideen.

Hier mal die oXs_config_description.h

Carbonator · Feb 12, 2017

Hier steht alles Wissenswerte dazu drin. Geht zwar mit GPS los, aber dann ist "nigelsheffield" an der yaw-Geschichte dran.

Du trägst in die oXs_config.h neue Kalibrierwerte ein, kompilierst neu und lädst den Sketch hoch, ohne dass sich etwas an den ACC Werten ändert?

Kurze Zusammenfassung: yaw wandert immer aus, Nigel hat sich dann damit beholfen dass er yaw mit GPS-heading regelmäßig "eingenordet" hat. Das muss man letztlich in der konkreten Anwendung lösen. Gibt es eine, oder machst du Grundlagenforschung?

Deleted member 51580 · Feb 12, 2017

Carbonator hat gesagt.:

Ja, ich trage die neuen Offset Werte ein und und übertrage den Sketch auf den Ardu.

Ja und nein,

Ich möchte gerne wie in deinem Thread beschrieben die Leistungsermittlung von Modellseglern mit openXsensor realisieren.

Dann bin ich auch in der description.h über diesen Text gestolpert:

When IMU is activated, this version of oXs calculates a vertical speed in a different way merging the altitude from baro sensor with vertical acceleration (in Earth reference).
* This other type of vertical speed is available in the field "VERTICAL_SPEED_I". In Frsky protocol, it is possible to transmit it e.g. as Vspd.

Irgendwo steht auch noch was das mit dem 6050 die Zeit um 0,4 Sekunden meine ich verbessert wird (allerdings finde ich das gerade nicht )

Also,
1. das eine ist wenn ich das richtig verstehe es bringt vorteile den 6050 mit in die Leitungsvermittlung und in die Vario Daten mit ein zu beziehen.

2. ich kann gar nicht gut damit umgehen, wenn etwas nicht so funktioniert wie es soll oder wie ich es mir vorstelle, genauso was die Genauigkeit betrifft und die ist hier in dem Fall nicht gegeben, auch wenn sonst alles super gut ist und auch verzögerungsfrei übertragen wird, die Genauigkeit vom restlichen Sensor finde ich bis jetzt sehr gut, verglichen mit dem was ich vorher hatte.

Nur das die Offsets keine Wirkung zeigen und das die Z Achse immer in eine Richtung "driftet" (ich nenne das jetzt einfach mal Driften) sonst ist alles soweit super, wesentlich besser als ich es mir erhofft habe.

Hier mal ein Paar Fotos von dem Drift der Z Achse man beachte die Zeit am Sender.

So sieht es kurz nach dem einschalten aus, erst stehen die Werte alle nahe 0,00 nach einem kurzen Augenblick sieht es so aus als würde irgendetwas berechnet, evt die Offsets und X,Y und Z ändern die Werte immer in die im ersten Foto angezeigten.
In den weiteren Fotos kann man dann gut den Drift der Z-Achse sehen. Es fängt mit -0,28g an und letzten Foto steht der Wert nach gut 2 Stunden bei +10,37g und das ist echt viel daneben. Irgendwas stimmt da nicht.

Carbonator · Feb 12, 2017

Der Test mit den 0,4 s ist von mir und zwar bei Standardempfindlichkeit 50 des normalen Vario. Das muss auch in dem GPS Thread irgendwo vergraben sein. Bei höherer Empfindlichkeit, ich fliege 200, ist der Unterschied geringer.

IMU Vario ist das Baby von mstrens, da hat er viel Energie reingesteckt und das ist seine programmtechnische Meisterleistung. In den 0,4 s fliegt ein Segler etwa 4 m weit, so groß ist der räumliche Unterschied bei der Erkennung der Thermik. Meine Streuung beim Auskreisen der Thermik ist vielleicht 5 mal so groß. Und das Schlimmste ist, dass diese blöde Thermik, wenn man wieder an die gleiche Stelle kommt, inzwischen weitergezogen ist. Einen praktischen Vorteil kann ich nur bei sehr leichten Modellen wie DLG/RES erahnen.
Für die Leistungsmessung darf das Vario nicht IMU beschleunigt sein. Der IMU Einfluss wurde nie nachgemessen und kann das Ergebnis nur verfälschen, niemals verbessern.

Deswegen frage ich so hartnäckig nach der Anwendung des IMU6050. Die Kalibrierung muss ich mal bei mir durchführen, so genau habe ich das nämlich nie überprüft, weil ich keine reale Anwendung hatte.

Deleted member 51580 · Feb 12, 2017

Seit dem die Arduinos und Sensoren da sind, habe ich mich die ganze Zeit mit dem "Standard" dingen rumgeschlagen (alles neuland für mich, das was ich vom Programmieren verstehe, kann ich nur aus Basic Zeiten und vom Fanuc Roboter Progen ableiten, passt aber nicht viel bei dem Sketch), den Geschmack an dem OXS habe ich mir in den letzten Wochen in deinem Thread geholt. Allerdings muss ich gestehen, das ich den Thread nur mehrmals grob und an den wichtigen Stellen (was brauche ich dafür, überflogen habe).
Mit der Leistungsmessung wollte ich mich erst beschäftigen wenn alles soweit läuft, dachte ja auch das es soweit ist, habe aber beim laaangen rumspielen mit dem Sensor, das Problem mit dem drift entdeckt, wäre mir sonst nicht aufgefallen, denn so funktioniert ja alles wie es soll, bis auf die Kalibrierung des 6050.

Ok so viel zur Geschichte, jetzt wieder zum wesentlichen....

So wie ich dich jetzt verstanden habe ist der 6050 eigentlich überflüssiger Ballast, weil die Auswirkungen nicht wirklich Spürbar sind.
Das ist natürlich schade, habe mir vor ein paar tagen noch mal GY-86 10DOF MS5611 HMC5883L MPU6050 bestellt damit ich alles schön auf einer Platine habe und nicht für jeden Sensor ein einzelnes Board (ansonsten finde ich schon einen Verwendungszweck).
Wobei ich es nicht als soo tragisch bezeichnen würde, aber wenn es sich machen lässt würde ich schon ein oder zwei Komplette OXS Module mit allem auch 6050 realisieren und für die restlichen Modelle die "normal" Ausführung also nur Vario, Vfas, Current und GPS aber ohne Airspeed und 6050.

Die Leistungsmessung macht du ja auch nur solange bis du mit dem Ergebnis
zufrieden bist, ab da kann ja der 6050 wieder mit werkeln oder habe ich das falsch verstanden ?

Wenn du die Kalibrierung mal gegen testen könntest wär das natürlich super und ich etwas weiter bei der suche.
Vielleicht muss ich sogar mal mstrens auf den Zeiger gehen und fragen wie das richtig funktioniert mit der Kalibrierung oder wie er sich das gedacht hat, denke schon das es funktioniert, ist bestimmt ein Fehler meiner seits drinnen, oder ein Bug im Sketch den bis jetzt keiner bemerkt hat, man muss schon nee ganze Zeit den Sensor auf einem Fleck liegen lassen und sich die Werte merken.

Carbonator · Feb 13, 2017

devil hat gesagt.:

Probier es einfach aus, wenn du einen PWM-Kanal frei hast, kannst du damit zwischen zwei verschiedenen Varios umschalten, mit IMU/ohne IMU, oder energiekompensiert/nicht kompensiert zum Beispiel.

devil hat gesagt.:

Die geänderte Kalibrierung wirkt sich nur im Normalbetrieb aus, hast du die Kalibrierfunktion wieder kommentiert?

* - set line #define DISPLAY_ACC_OFFSET as comment (adding "//" in front)
* - upload again oXs firmware in arduino

Man muss mal vergleichen, was der Yaw-Sensor leistet: Man wird mit verbundenen Augen und ohne Hörsinn auf einem Bürostuhl beliebig hin- und hergedreht und weiß immer genau die aktuelle Richtung......Da ist ein kleiner Drift über Stunden doch drin, meine ich. Ich finde es faszinierend, was die Dinger können, auch wenn es mir beim Thermikfliegen jetzt nicht soviel bringt.

Mstrens beantwortet übrigens gerne Fragen und man lernt immer was dazu.

Edit: Im oXs liegen ja intern beide VSpeed vor, mit IMU und ohne. Vermutlich kann man den IMU VSpeed gar nicht für die Leistungsmessung nutzen, weil es auch keinen Sinn macht. Ich habe nicht in den Code geschaut, aber so wie ich Mstrens kenne, ist es genau so.

Die Leistungsmessung lasse ich immer aktiv, das sind nur ein paar harmlose Rechnungen im Hintergrund. Kein Grund, den Sketch zu ändern, außer, wenn man den Traffic auf dem SPort so niedrig wie möglich halten will.

Deleted member 51580 · Feb 13, 2017

Carbonator hat gesagt.:

Ja die Zeile habe ich nach der Kalibrierung wieder auskommentiert so wie es beschrieben ist, dann den Sketch neu auf den Arduino geladen.

Die Sensoren faszinieren mich genauso, erst recht in der Größe, ich kenne auch noch die Bauteile vor den SMD.

Das der Drift klein ist würde ich jetzt nicht sagen, das sind immerhin fast 11g.
Im SM Looger den ich bisher geflogen habe ist auch eine IMU verbaut und da kam ich selbst bei den Wildesten Manövern was mein Segler so verträgt nicht über 8g und das ist dann schon heftig (Flächen biegen sich dann und das Gefühl ist etwas "mulmig"

) ich bin mir sicher das meine bisherigen Segler keine 11g vertragen ohne sich in Einzelteile zu zerlegen

Den Log mit 8g find ich jetzt grad nicht aber hier mal einer von 5g da war ich nur am toben weil mit Thermik war einfach nix, dann war mir einfach danach...

und so sieht das bei Thermik fliegen aus mit einem kleinen Anfall...

Kannst du mal deine IMU gegen prüfen zwecks drift und Kalibrierung ?

Howie · Feb 13, 2017

Hallo,

würde mich gerne hier mit einklinken da ich auch gerade versuche einen openXSensor mit 6050 zum laufen zu bekommen...
Hab dallerdings noch ein Verständnis-Problem :
Kalibrierung habe ich auch versucht, mit unterschiedlichsten Ergebnissen...
Ich bekomme schon bei der Debug-Ausgabe der Kalibrierung stark schwankende Werte, obwohl der Sensor auf dem Tisch liegt und nicht bewegt wird.
Dazu dann allerdings auch meine Frage : wenn ich den Sensor bewege sollten sich dei Werte ja nur in einem bestimmten Rahmen ändern.
Also Sensor liegt platt auf dem Tisch, z ungefähr bei 1g, x und y bei 0.
Wenn ich den Sensor jetzt in eine Richtung um 90° kippe sollten ja z.B. x auf 1 gehen und y und z auf 0 bleiben
das klappt aber schon nicht, da bekomme ich Werte von über 10g... wohlgemerkt nachdem der Sensor nicht mehr bewegt wird...

Kann das mal jemand ausprobieren ?

Ach so, openXSensor ist die aktuellste von von GitHub (commit 902e46c)

Andreas

Carbonator · Feb 13, 2017

Ich hatte hier diese Werte:

Nick and Roll give -9.81 to +9.81 and yaw -18.0 to + 18.0 (=-180° to +180°)

Nick und Roll sind die Erdbeschleunigung in m/s², Yaw ist die ausgewertete Rotationsbeschleunigung um die Z-Achse umgerechnet in Grad, vermute ich.

Nick und Roll könnte aber auch g x 10 sein, das hatte mich aber in dem Zusammenhang nicht interessiert. Vielleicht mal Mstrens ansprechen.

Norbert · Feb 14, 2017

devil hat gesagt.:

Hallo,
meiner Ansicht sind 11g Drift nicht schlecht sondern dann wäre er unbrauchbar.
Entweder
1)liegt da ein Kommafehler vor oder
2) der Baustein ist defekt.

Zu 1:: Sehr leicht auszuprobieren: Lege ihn flauch hin und notiere den Wert, dann drehe ihn auf den Rücken und notiere ebenfalls den Wert. Es müssen 2g dazwischen liegen ( 1g und -1g ). Das kannst du für alle Achsen machen. Wenn Werte zb 20 ( Faktor 10 ) oder 200) raus kommen, dann liegt ein Kommafehler vor.

Wenn 1) ok ( Diff~ 2g) Dann driften lassen und mit der entsprechenden Achse den Test wiederholen. Wenn dann in Lage horizontal zB +4g ist und umgedreht +2g dann ist der Baustein defekt.

Norbert

Carbonator · Feb 14, 2017

Norbert hat gesagt.:

Bei mir gibt die yaw-Achse keine Beschleunigung aus, deswegen kann man m. E. den Test bei yaw so nicht machen. Ein Auswandern von Yaw über Stunden um 110° halte ich für akzeptabel. Der ausgegebene Wert beruht nicht auf einem Kompass, sondern es wird eine Beschleunigungsmessung der z-Rotationsachse in eine Winkelabweichung umgerechnet. Dass das überhaupt funktioniert, ist schon ein Wunder.

Norbert · Feb 14, 2017

Hallo,

vielleicht sollten wir uns darüber einigen, über was wir reden.

Ein Wert in "g" ist Beschleunigung, der ändert sich je nach Lage des Sensors, wenn der Sensor ruhig liegt bleibt er konstant.
ein Wert in °/sec ist Gyroscop also Drehwinkel. Ein auswandern von 110° über Stunden ist mehr als ok.

Der 6050 hat beides. Meines Wissens nach wir im Vario für OpenSensor nur der Beschleunigungsmesser verwendet, um eine Thermik ( Hüpfer, wenn die Thermik den Segler hebt ) schneller anzuzeigen. Da wäre der Gyro sinnlos.

Devil schreibt von seinem Segler, dass er beim Rumturnen max 8G erreicht, das ist Beschleunigung, nicht Drehwinkel.

Daher nochmals die Eingangsfrage: Wovon reden wir - Drehwinkel oder BEschleunigung?

Norbert

Carbonator · Feb 14, 2017

Norbert hat gesagt.:

Der IMU 6050 kann nur Beschleunigung der x,y,z Achse und der dazugehörigen Rotationsachsen messen. Der openXsensor gibt für Pitch und Roll die Beschleunigung x und y Achse aus, für Yaw rechnet er die Rotationsbeschleunigung der z-Achse in einen Drehwinkel um.

So habe ich mir das zusammengereimt, als ich den IMU 6050 als Eingabeoption (TX-Tracker) für die Tara benutzt habe.

Howie · Feb 20, 2017

Hallo,

ich wwollte am Wochenende noch mal ein wenig testen und habe einen zweiten Arduino mit 6050 zusammengelötet.
Leider krieg ich im Arduino IDE Monitor nur die Debug-Werte angezeigt, nicht die umgerechneten Werte die zur Taranis übertragen werden, egal was ich in der oXs_out_frsky.cpp aktiviere an DEBUG-Ausgabe

Das ganze noch mit Empfänger verkabeln und an der Tarnis einrichten hatte ich jetzt keine Lust zu...

Andreas

Carbonator · Feb 22, 2017

Norbert hat gesagt.:

Mstrens hat gerade die Möglichkeit geschaffen, für alle Achsen die lineare Beschleunigung (bis 4g) zu übermitteln.

Howie · Mrz 4, 2017

Carbonator hat gesagt.:

hast du das schon mal ausprobiert ?
Ich bekomme es nicht zum laufen, die ACC-Werte werden dann bei mir garnicht mehr übertragen...

Carbonator · Mrz 5, 2017

Howie hat gesagt.:

Mit der V8 sollte es klappen, in der config_h müssen aber die Test_1,2,3 Variablen eingestellt werden, nicht AccX,Y,Z.

Code:

#define ACCX_SOURCE     TEST_1                   //  select between TEST_1, TEST_2, TEST_3, GLIDER_RATIO , SECONDS_SINCE_T0 ,AVERAGE_VSPEED_SINCE_TO , VOLT_1, VOLT_2, VOLT_3, VOLT_4, VOLT_5, VOLT_6, PITCH, ROLL , YAW, ADS_VOLT_1, ADS_VOLT_2, ADS_VOLT_3, ADS_VOLT_4 
#define ACCY_SOURCE     TEST_2                 //  select between TEST_1, TEST_2, TEST_3, GLIDER_RATIO , SECONDS_SINCE_T0 ,AVERAGE_VSPEED_SINCE_TO , VOLT_1, VOLT_2, VOLT_3, VOLT_4, VOLT_5, VOLT_6, PITCH, ROLL , YAW, ADS_VOLT_1, ADS_VOLT_2, ADS_VOLT_3, ADS_VOLT_4
#define ACCZ_SOURCE     TEST_3                 //  select between TEST_1, TEST_2, TEST_3, GLIDER_RATIO , SECONDS_SINCE_T0 ,AVERAGE_VSPEED_SINCE_TO , VOLT_1, VOLT_2, VOLT_3, VOLT_4, VOLT_5, VOLT_6, PITCH, ROLL , YAW, ADS_VOLT_1, ADS_VOLT_2, ADS_VOLT_3, ADS_VOLT_4

Und Zeile 872 in der .ino muss entkommentiert werden:

#define SEND_LINEAR_ACC

Howie · Mrz 12, 2017

ich bekomme es nicht zum laufen...
mit dem angehängten Sketch bekomme ich nur ACC_Y und AZZ_Z, ACC_X taucht nicht mal als Telemetrie-Sensor auf.
Wenn ich in der config (Zeile 125) dann PITCH statt TEST_1 eintrage kommt auch ACC_X

Schaut mir so aus als ob mit der Zuweisung der test-Werte zu den FrSky Ausgabe-Variablen was nicht stimmt...
Aber soweit blick ich da noch nicht durch...

Carbonator · Mrz 12, 2017

Probier mal diese - ist aber nicht getestet, ohne Garantie

Anhang anzeigen oXs_ACC_linear.zip

Howie · Mrz 13, 2017

OK, ich hab's auch bei mir gefunden...
die SEND_LINEAR_ACC hat als Bedingung vorher VARIO und USE_6050 (openXsensor.ino so ab Zeile 814)...
Für ein bodengebundenes Fahrzeug ohne Baro hatte ich den VARIO rauskommentiert...
daher keine Zuweisung der linear_acceleration an die test1-3 Werte und dementsprechend auch keine Ausgabe über den Sender...

OpenX Sensor mit Imu 6050 Kalibrierung

Deleted member 51580

Gast

Allerhopp ;)

Deleted member 51580

Gast

Allerhopp ;)

Deleted member 51580

Gast

Allerhopp ;)

Deleted member 51580

Gast

Benutzer

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Benutzer

Allerhopp ;)

Benutzer

Allerhopp ;)

Benutzer

Anhänge

Allerhopp ;)

Benutzer