MPU6050 Gyro / Accelerometer

  • ...Ich möchte aktuell ein GY-521 nutzen um einen Nudge-Sensor (Nudging/Tilt) für einen VirtualPin Cab nachzubauen... Sprich, die Kugel im virtuellen Flipper soll, wie bei einem realen Pin, auf mechanische Einwirkung (Anstossen / Rütteln) auf das Cabinet reagieren. Virtual Pinball stellt dafür schon die entsprechenden Schnittstellen zur Verfügung...

    GY_521.jpg
    Zum Anschluss werden nur 4 Pins benötigt:
    VCC -> 3V3
    GND -> GND
    SCL -> I2C_SCL
    SDA -> I2C_SDA

    Das soll später zwar über einen Arduino laufen aber entwickeln möchte ich das aus Bequemlichkeit am PI ;)

    Zur Veranschaulichung hab ich auch schon MPU6050 Demo genutzt aber das bringt mich nicht wirklich weiter..


    Ich tu mich ein bisschen schwer mit dem Umgang der bisher gefunden Anleitungen, ich steig da überhaupt nicht durch welcher Wert was darstellt, welche ich überhaupt brauche oder wie ich eine Kalibrierung vornehme :huh:

    Ein auslesen ergibt bei mir nämlich unterschiedliche Werte, jenachdem was beachtet werden soll:

    Code
    quat	0.99	0.01	-0.15	0.00
    euler	-0.20	17.68	-0.87
    ypr	-0.20	17.68	0.81
    areal	-1168	-56	-3379
    aworld	-86	-5	-3574

    quat = display quaternion values in easy matrix form: w x y z
    euler = display Euler angles in degrees
    ypr = display Euler angles in degrees
    areal = display real acceleration, adjusted to remove gravity
    aworld = display initial world-frame acceleration, adjusted to remove gravity and rotated based on known orientation from quaternion

    Verwendet hab ich http://www.i2cdevlib.com und den MPU6050_DMP6 Sketch


    Also: Welche Werte brauche ich?
    Und wie kann ich eine Kalibrierung vornehmen :huh:

    :helpnew:


    PS: Und das nächste Problem wird dann das ganze als Joystick ausgeben zu lassen (mit UnoJoy o.ä.), aber das ist ne spätere Baustelle :auslachen:


    /EDIT: Ein paar Datenblätter zum GY-521:
    http://invensense.com/mems/gyro/documents/RM-MPU-6000A.pdf
    http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Com…S-MPU-6000A.pdf

  • Die demo_3d sieht zwar toll aus aber der Code ist so umfangreich das ich bisher nicht raus finden konnte welche Werte dort ermittelt werden bzw wo das steht usw...

    Davon abgesehen zeigt die Demo ja nur den Neigungswinkel an aber nicht die Beschleunigung - wenn ich gegen's Cabinet hau dann neig ich's aber nicht ;)

    Einzig demo_raw scheint Werte auszugeben die interessant sein könnten, aber da weiß ich wie gesagt wieder nicht "wie" die ermittelt werden - bin in C nicht so gut wie gewünscht :D


    Vielen Dank für den Kalibrierungslink - das sieht schon sehr vielversprechend aus :)

    • Offizieller Beitrag

    Ich bin mir ziemlich sicher das du die demo_raw verstehst (oder wir schauen verschiedene an :) ) und so lang ist die auch nicht. Auf jedenfall kann man dort getmotion dort durch getacceleration ersetzen und kriegst somit nur die Beschleunigungswerte zurück.

    Bin grad nur mit Handy on, sonst hätte ich die Zeile schnell geändert.

    Edit: deine Ausgabe sieht anders aus als die demo_raw.cpp aus dem Github repo. Die sollte andere Werte zurückliefern. Deine oberen Werte verwirren mich auch xD

  • Ja für die Ausgabe hatte ich noch den Arduino dran und den MPU6050_DMP6 Sketch genutzt ;)

    Ich hab demo_raw.cpp nun etwas verändert und debugged:

    anschließend make demo_raw und ausführen...


    Die Ausgabe sieht jetzt bei mir wie folgt aus:

    Spoiler anzeigen

    Aber wenn ich jetzt den X gyro offset Werte auf -5 ( accelgyro.setXGyroOffset(-5); ) änder dann ist die Ausgabe nicht wie erwartet =(

    Spoiler anzeigen

    :s

    :helpnew:


    /EDIT2: Um nicht jedesmal den Code neu kompilieren zu müssen hab ich das noch mal umgeschrieben um die Offset Werte direkt beim ausführen zu übergeben:

    Spoiler anzeigen

    /EDIT: Hatte nen Dreher in den argv's ...

    • Offizieller Beitrag

    Wie der von -5 auf 59 kommt ist mir auch ein Rätsel. allerdings nähert sich gx der 0. wirklich verwirrend. Ich hab mich mal versucht rauszufinden wo getXgyroOffset seine Werte herkriegt (und vor allem wie) allerdings bin ich da auch überfragt. dreamshader ist doch unserer aller C specialist, der muss uns das erklären.

  • Moin ...

    junge junge, ihr grabt da ja mittlerweile Hämmer aus ... uiuiui ...

    Ich hab' auch so ein Ding hier rumliegen und beim Überfliegen der Dokus dazu schon mitbekommen, dass das ziemlich undurchsichtig und relativ aufwändig sein soll ...

    Na, schau mer amoi ...

    cu,
    -ds-

  • Sodale ... die Offsets kommen m.E. aus der Motionmachine - deshalb soll man das Ding ja erstmal in waagrechter Pos. zum Stillstand bringen ...

    Ich hab keine Pin-Leiste an meinem Gyro-Board ... da werd ich wohl erst mal die Lötmaschine anschmeissen müssen ...

    // EDIT:
    Hast Du den -> hier <- schon probiert?

    //EDIT2:
    Ich hab' -> hier <- noch was, wie ich glaube, ganz Brauchbares gefunden.

    //EDIT3:
    Und das-> hier <- werde ich wohl als erstes ausprobieren ... ich finde, das klingt schon mal recht eingängig ;)


    cu,
    -ds-

  • Naja wie gesagt soll der MPU6050 in einem Pinball Gehäuse verbaut werden und das steht eben nicht absolut gerade - laut dem Beitrag, den dbv gepostet hat, kann man mithilfe der Offsets die Nullstellung also was bei einem "gerade" ist, einstellen - aber wieso sorgt -5 dafür dass er nicht nur 5 punkte weg nimmt sondern ~150 ?

    Ich brauch eigentlich auch keine Neigung - also mit der MPU6050 Demo auf dem RPI kann ich mir auch diese Neigung und Drehung anzeigen lassen, aber was ich fürs Nudging brauche ist Beschleunigung - eben das was einem quasi starren Gehäuse ausgesetzt wird wenn man da gegen haut, man schuppst es nicht um sondern drückt es nur minimal in eine Richtung, das Gehäuse bleibt aber so stehen......

    Kennst du keine Flipperautomaten und weißt was mit Rütteln gemeint is bzw was dadurch bewirkt wird :huh:


    /EDIT: also noch mal für unsern dreamshader :D

    Derzeit benutze ich den GY-512 am RaspberryPI und nutze als Code die MPU6050-Pi-Demo

    Den Code für demo_raw.cpp habe ich leicht modifiziert um die Offset Werte direkt ans Programm zu übergeben:

    Spoiler anzeigen

    Wenn ich das nun compiliere ( make demo_raw ) und ausführe, sind die getOffset Werte andere als ich ans Programm übergebe - das ist aber auch so wenn ich sie hardcoded direkt in den Source eintrage..:

    Nun ist wie gesagt die Frage: Wieso macht der Code aus -5 (minus 5) einen Offset Wert von 59 und wieso gibt er bei gx dann bei einem offset von 0 einen Wert von ca. -140, aber bei einem offset von "59" einen gx Wert von +20 ? :huh:

  • Hallöle meigrafd,

    ich hab da noch was gefunden: das -> hier <- klingt auch sehr interessant.

    Klar kenne ich Flipper ( und ich meine jetzt nicht den quietschenden Meeres-Säuger ;) ). So gesehen bräuchtest Du ja - zumindest rein theoretisch - lediglich die Beschleunigungswerte für die drei Achsen ...

    //EDIT: Was mir gerade noch eingefallenn ist:
    Ich bin mir jetzt nicht sicher, aber ich kann mich nicht erinnern gelesen zu haben, dass der Sensor den Faktor für die g-Kräfte ausspuckt.
    Macht das dann mit diesem Sensor Sinn - also das feststellen des Tilt-Zustands?
    Du merkst zwar, dass der "Kasten" bewegt wurde und Du weisst auch entlang welcher Achse und wie weit, aber ich denke, Du willst zwischen sanftem Verschieben und grobem "Treten" unterscheiden. Ob das dann überhaupt von diesem Sensor abgedeckt wird?


    Aber jetzt versuchen wir erst mal das Ding zu kalibrieren ;) ...

    ciao,
    -ds-

  • So, jetzad hob i an dreg im schachterl :fies:

    Der RPi erkennt den Sensor am IIC-Bus nicht.
    Darüber hatte ich irgendwo schon gelesen - allerdings im Zusammenhang mit einem Arduino.

    Nun ist "gutes Rad teuer" ...

    grübelnde Grüsse :s ,
    -ds-

    • Offizieller Beitrag


    Nun ist wie gesagt die Frage: Wieso macht der Code aus -5 (minus 5) einen Offset Wert von 59 und wieso gibt er bei gx dann bei einem offset von 0 einen Wert von ca. -140, aber bei einem offset von "59" einen gx Wert von +20 ? :huh:

    Since they are 16 bits, a variation of 50 is just a very small variation.

    Wenn man sich die Werte von dem hier anschaut

    Spoiler anzeigen

    dreht das Teil für meine Verhältnisse auch unter seinen "extremem" Testbedingungen ganz schön durch. Was einem unweigerlich vermuten lässt, dass man die Rohwerte nicht gebrauchen kann.

    Nachdem ich das jetzt gefühlte 10mal gelesen habe, habe ich Kopfschmerzen.

  • Hallöle zusammen,

    war mal kurz offline ... aber der Gehörnte wollte mich noch nicht :fies: ... deshalb ist bei einem kleinen Abstecher ins hiesige Klinikum geblieben ...

    Na ... wie isses?
    Hat wer das Teil am RPi und wird es dort erkannt?

    // EDIT: ich hab' übrigens noch was gefunden -> hier <- werden die Achsen usw. gut und ausführlich erklärt und verlinkt ... vielleicht ist da ja was Passendes dabei :s

    //EDIT EDIT ;) ...
    Und noch was hab ich ausgegraben ... das könnte die Lösung für das Nicht-Erscheinen am IIC-Bus sein. -> Hier <- wird beschrieben, dass man den Chip mit 5V betreiben kann, und der IIC-Bus trotzdem auf 3V3 bleibt. Schau ma amoi ...
    -> Hier <- hatte nämlich jemand das Teil ausschliesslich mit 3V3 zum Laufen bekommen.

    //EDIT EDIT EDIT
    Letzter Update dieses Beitrags ... versprochen ;) ...
    Dass der Sensor nicht entdeckt wurde lag tatsächlich an der Spannungsversorgung. 5V statt 3V3 und schon funktioniert das Teil.
    Die Ausgabe sollte dann in etwa so aussehen:

    Spoiler anzeigen


    pi@raspberrypi ~/PiBits/MPU6050-Pi-Demo $ sudo ./demo_dmp
    Initializing I2C devices...
    Testing device connections...
    MPU6050 connection successful
    Initializing DMP...
    Success! DMP code written and verified.
    Success! DMP configuration written and verified.
    Current FIFO count=0
    Waiting for FIFO count > 2...
    Current FIFO count=42Enabling DMP...
    DMP ready!
    quat 0.99 -0.03 -0.11 0.00 ypr 0.36 13.14 -3.12
    quat 0.99 -0.03 -0.12 -0.00 ypr 0.38 13.22 -3.06
    quat 0.99 -0.03 -0.12 -0.00 ypr 0.40 13.29 -3.01
    quat 0.99 -0.03 -0.12 -0.00 ypr 0.42 13.37 -2.97
    quat 0.99 -0.03 -0.12 -0.00 ypr 0.44 13.44 -2.91
    quat 0.99 -0.03 -0.12 -0.00 ypr 0.46 13.49 -2.87
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.48 13.56 -2.83
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.49 13.62 -2.78
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.52 13.68 -2.74
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.54 13.74 -2.70
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.56 13.78 -2.66
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.57 13.84 -2.62
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.59 13.89 -2.59
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.61 13.94 -2.56
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.63 13.98 -2.53
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.65 14.03 -2.49
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.67 14.07 -2.46
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.69 14.11 -2.43
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.71 14.15 -2.40
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.72 14.18 -2.37
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.74 14.23 -2.35
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.76 14.26 -2.33
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.78 14.30 -2.30
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.79 14.33 -2.28
    quat 0.99 -0.02 -0.12 -0.00 ypr 0.81 14.36 -2.26
    quat 0.99 -0.02 -0.13 -0.00 ypr 0.83 14.39 -2.23
    quat 0.99 -0.02 -0.13 -0.00 ypr 0.84 14.42 -2.21
    quat 0.99 -0.02 -0.13 -0.00 ypr 0.86 14.45 -2.19
    quat 0.99 -0.02 -0.13 -0.01 ypr 0.88 14.48 -2.17
    quat 0.99 -0.02 -0.13 -0.01 ypr 0.89 14.50 -2.15
    quat 0.99 -0.02 -0.13 -0.01 ypr 0.91 14.53 -2.13
    quat 0.99 -0.02 -0.13 -0.01 ypr 0.93 14.55 -2.11
    quat 0.99 -0.02 -0.13 -0.01 ypr 0.95 14.57 -2.10
    quat 0.99 -0.02 -0.13 -0.01 ypr 0.97 14.59 -2.08
    quat 0.99 -0.02 -0.13 -0.01 ypr 0.99 14.61 -2.06
    quat 0.99 -0.02 -0.13 -0.01 ypr 1.00 14.63 -2.05
    quat 0.99 -0.02 -0.13 -0.01 ypr 1.02 14.65 -2.03
    quat 0.99 -0.02 -0.13 -0.01 ypr 1.04 14.67 -2.02
    quat 0.99 -0.02 -0.13 -0.01 ypr 1.05 14.69 -2.01

    So, und jetzt widmen wir uns dem Offset ...

    -ds-

  • So ... moin beinander :) ...

    das Testprogramm tut:

    Spoiler anzeigen


    GO!
    x-> 271 y-> -94 z-> 7
    x-> 271 y-> -94 z-> 7
    x-> 271 y-> -94 z-> 7
    x-> 273 y-> -197 z-> 29
    x-> 273 y-> -238 z-> 60
    x-> 273 y-> -238 z-> 60
    x-> 291 y-> -345 z-> 105
    x-> 291 y-> -345 z-> 105
    x-> 293 y-> -282 z-> 100
    x-> 293 y-> -282 z-> 100
    PAUSE 5 sec ...
    GO!
    x-> 257 y-> -220 z-> -114
    x-> 257 y-> -220 z-> -114
    x-> 257 y-> -220 z-> -114
    x-> 259 y-> -210 z-> -112
    x-> 259 y-> -210 z-> -112
    x-> 253 y-> -219 z-> -98
    x-> 253 y-> -219 z-> -98
    x-> 257 y-> -227 z-> -99
    x-> 257 y-> -227 z-> -99
    x-> 254 y-> -215 z-> -106


    und wenn ich die Platine bewege ändern sich entsprechend die Werte.
    was mir (noch) nicht klar ist: warum ändert ein setZGyroOffsetUser(0) bzw. setXGyroOffset(0) nach jedem Messzyklus nichts an den Werten?
    Ich fürchte, jetzt ist erst mal wieder Studium angesagt.

    To be continued ...
    -ds-

    //EDIT:
    Aufbauend auf dem Beispielcode habe ich mal den Abgleich der Offsets in eine Funktion gepackt.
    Die Dateien aus dem Anhang bitte in das Verzeichnis "MPU6050-Pi-Demo" downloaden, "demo_zero.c" nach "demo_zero.cpp" und "Makefile.txt" nach "Makefile" umbenennen.
    Dann einfach "maken" ;) ...

    Es sieht so aus, als würden sich die Abgleichwerte (Offsets) um die Ausgaben auf 0 zu bekommen, reproduzieren lassen. das lässt hoffen ;)

    Im nächsten Beitrag gucken wir mal weiter ...

    ps915: Guckst Du bitte mal - der Server mag keine .cpp Dateien als Anhang und Makefile lehnt er auch ab ... danke,

    //EDIT EDIT
    Ich hab' die Anhänge mal weggeschmissen. Der tarball in meinem Folgepost ist da sinnvoller.

    -ds-

  • Servus Manda und Mandarinen,
    wenn ich alles was ich bisher gefunden, gelesen und hoffentlich richtig verstanden habe, dann läuft das wohl so:
    Das Teil wird zuerst mal initialisiert. Dazu wird u.a. der Modus aktiviert. Wenn ich das noch richtig im Hinterkopf habe, könnte man die Beschleunigungsmessung ausblenden.
    Dann wird der Sensor kalibriert.
    Dazu wird mit GY521.setXGyroOffset() bzw. dem zugehörigen Pendant der Offset-Wert für die X, Y und Z Achse so lange verändert, bis die mit GY521.getMotion6() ermittelte Position 0 ist.
    aus dem Beispielcode:
    accelgyro.getMotion6(&ax, &ay, &az, &gx, &gy, &gz);
    In jeweils einer Schleife jetzt die Offsets im Bereich von -32768 bis +32767 setzen und die Position auf 0 prüfen.
    Statt GY521.getMotion6() ist es wohl auch möglich, GY521.getRotation() und GY521.getAcceleration() zum Feststellen der Position bzw. Beschleunigung zu verwenden, das hab' ich aber noch nicht ausprobiert.

    Positiv überrascht war ich darüber, dass das ...zero-Programm von mir relativ wenig CPU-Last erzeugt, obwohl die Init-Funktion in Schleifen ohne sleep() aufgerufen wird.
    Ich hab' mal ein Bildschirm-Foto angehängt, das meinen RPi beim Däumchendrehen (top-idle.png) und bei der Arbeit (top-running.png) zeigt.
    Interessant und beruhigend ist, dass die Werte (fast) reproduzierbar sind. Irgendwo habe ich gelesen, dass die Temperatur gerade dieses Sensors die Werte ziemlich beeinflussen kann (vermutlich weil imho das Lesen der Werte nur in einer Endlosschleife ohne delay Sinn macht).

    Im Anhang befindet sich ein tarball, der meinem Testordner inkl. der geänderten Files beinhaltet.
    Es handelt sich zwar um C-Sourcen, die sollten aber mit geringen Änderungen auch auf einem Arduino laufen.

    meigrafd: der Sensor, den Du verwendest, hat schon 6DOF?
    Und vielleicht noch als Hintergrund-Info: warum nimmst Du nicht einfach einen Wii-Controller? Die kriegst Du schon um die 15,- € und die haben ein schickes Gehäuse ...

    Ok, jetzt mal Butter bei die Fische und die Berechnungen machen ...

    cheers,
    -ds-

    Quelle für das Original-Archiv ist

  • Wenn ich diese Reihen sehe, drängt sich mir der Verdacht auf das es sich bei dem x gyro offset um ein 6 Bit speicher ohne vorzeichen handelt (max-Wert = 63 min-Wert = 0) 0 -5 = 59, da keine negativwerte möglich, da ich mir weder den Sensor angesehen habe noch das Programm kann das Problem entweder im Sensor oder im Programm liegen.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!