MPU6050 - Raw-, gravity- and bodyacceleration

[Niklas S. (nicklarrs)]

Hi,

Ich versuche mit dem MPU6050 Sensor menschliche Bewegungen zu erkennen. 
Ich bin schon sowei, die Sensordaten aus den Registern auszulesen.

In einem, zu meinem Thema sehr ähnlichen, Artikel schreibt der Autor 
davon wie er aus den Rohen Sensordaten (ax, ay, az) die "gravity 
acceleration" (gx,gy,gz) und die "body acceleration" (bx, by, bz) 
berechnet.

Was sind die einzelnen Beschleunigungen (Rohdaten, graivty acceleration 
und body acceleration)?
Was ist der genaue Unterschied zwischen ihnen?
Wie berechne ich die einzelnen Werte (BA, GA und RD)?

Im Moment verwende ich einen im Internet gefunden Code in dem ich die 
Register auslese und dann die "gForce" berechne (ist dies schon die 
besagt gravity acceleration?):

void recordAccelRegisters() {
  Wire.beginTransmission(MPU);
  Wire.write(0x3B);  // starting with register 0x3B (ACCEL_XOUT_H)
  Wire.endTransmission(false);
  Wire.requestFrom(MPU,14,true);  // request a total of 14 registers
  AcX=Wire.read()<<8|Wire.read();  // 0x3B (ACCEL_XOUT_H) & 0x3C (ACCEL_XOUT_L)    
  AcY=Wire.read()<<8|Wire.read();  // 0x3D (ACCEL_YOUT_H) & 0x3E (ACCEL_YOUT_L)
  AcZ=Wire.read()<<8|Wire.read();  // 0x3F (ACCEL_ZOUT_H) & 0x40 (ACCEL_ZOUT_L)
  Tmp=Wire.read()<<8|Wire.read();  // 0x41 (TEMP_OUT_H) & 0x42 (TEMP_OUT_L)
  gForceX = AcX / 16384.0;
  gForceY = AcY / 16384.0;
  gForceZ = AcZ / 16384.0;
}

edit:
Dazu sollte ich noch sagen, dass ich einen NodeMcu und die Arduino IDE 
verwende.w

Danke, mfG
Niklas

[Wolfgang (Gast)]

Niklas S. schrieb:
> In einem, zu meinem Thema sehr ähnlichen, Artikel schreibt der Autor
> davon wie er aus den Rohen Sensordaten (ax, ay, az) die "gravity
> acceleration" (gx,gy,gz) und die "body acceleration" (bx, by, bz)
> berechnet.

Und? Was schreibt er, wie er das macht?

[Niklas S. (nicklarrs)]

Das kann ich/man so nicht rauslesen, hier der Wortlaut:
"The measurements from tri-axial accelerometers, known as raw data (RD, 
ax, ay, az), can be decomposed into gravity acceleration (G) - due to 
each gravity, gx, gy , gz and body acceleration (BA) - which is due to 
the human movement bx, by, bz", aus Improving Human Activity Recognition 
von Jose Villar, Internation Journal of Neural Systems.

[Joachim S. (oyo)]

Ich würde mal vermuten, dass die Raw-Werte die Rohdaten sind, die Du vom 
Sensor bekommst (also vermutlich irgendwelche Integer-Werte), diese für 
die gravity-Werte dann bereits in float-Werte umgewandelt/skaliert sind, 
dass die Werte sozusagen in G sind, also der Wert 1.0 bspw. genau der 
Beschleunigung durch die Gravitation entspricht.

Und für die "body-acceleration" wird aus den gravity-acceleration-Werten 
vermutlich gleich noch die Erdanziehungskraft herausgerechnet - also so, 
dass in völliger Ruheposition der Beschleunigungswert sämtlicher Achsen 
0 beträgt.

Von daher würde ich vermuten:
AcX/Y/Z sind die Rohdaten
und
gForceX/Y/Z sind in der Tat bereits die "gravity acceleration"-Daten

[Jonas G. (jstjst)]

Hallo,

also ich verstehe das so, dass die gemessenen rohwerte in die 
Erdbeschleunigung und die eigentliche Bewegung aufgeteilt werden.

Gruß Jonas

[Niklas S. (nicklarrs)]

Danke für die Antworten.

Blöde frage, aber wie rechne ich die gravitation aus der ganzen 
beschleunigung raus?

[Johann L. (gjlayde)]

Niklas S. schrieb:
> Wire.read()<<8|Wire.read()

Die Reihenfolge, in welcher der linke und der rechte Operand von | 
bestimmt werden, ist in C/C++ nicht festgelegt:

"Unlike the bitwise | operator, the || operator guarantees left-to-right 
evaluation [...]"

M.a.W: | wird nicht notwendig von links nach rechts ausgewertet — 
übrigens hat das nix mit der Kommutativität von | zu tun; gleiches gilt 
sinngemaß etwa auch für - (minus).

[Niklas S. (nicklarrs)]

Johann L. schrieb:
> Niklas S. schrieb:
>> Wire.read()<<8|Wire.read()
>
> Die Reihenfolge, in welcher der linke und der rechte Operand von |
> bestimmt werden, ist in C/C++ nicht festgelegt:
>
> "Unlike the bitwise | operator, the || operator guarantees left-to-right
> evaluation [...]"
>
> M.a.W: | wird nicht notwendig von links nach rechts ausgewertet —
> übrigens hat das nix mit der Kommutativität von | zu tun; gleiches gilt
> sinngemaß etwa auch für - (minus).

Also gehört in meinem Fall ||?

[Leo C. (rapid)]

Niklas S. schrieb:
> Also gehört in meinem Fall ||?

Nein, z.B so:

AcX =  Wire.read()<<8;
AcX |= Wire.read();

[Niklas S. (nicklarrs)]

Hatte so spät mit keiner Antwort mehr gerechnet, danke dir vielmals :)

[Wolfgang (Gast)]

Niklas S. schrieb:
> aus Improving Human Activity Recognition
> von Jose Villar, Internation Journal of Neural Systems.

Dann meinst du wahrscheinlich den Artikel:
José R. Villar et al, Int. J. Neur. Syst. 25, 1450036 (2015)
/Improving human activity recognition and its application in early 
stroke diagnosis/

http://di002.edv.uniovi.es/~villar/Jose_R._Villar/Journal_papers_files/villarIJNSfinal.pdf

Der von dir genannte lapidare Satz am Anfang vom Abschnitt 2.1 müsste 
IMHO eine Trivialität ausdrücken, sonst hätte er dort irgendetwas 
zitieren (müssen). Vielleicht findet man in einer vorhergehenden 
Veröffentlichung mehr Details zu seiner Vorgehensweise.

[Niklas S. (nicklarrs)]

Hi Leute,

bin jetzt, da ich ja auch die Beschleunigung ohne Gravitation brauche 
auf die i2cdevlib umgestiegen um die Beschleunigungsdaten zu erlangen.

Soweit funktioniert alles sehr gut, jedoch bekomme ich nach einigen 
Sekunden immer öfters FIFO Overflows und dann stürzt das Programm ab.


Mein Code:

    // if programming failed, don't try to do anything
    if (!dmpReady) return;

    // wait for MPU interrupt or extra packet(s) available
    while (!mpuInterrupt && fifoCount < packetSize) {
        // other program behavior stuff here
        // .
        // .
        // .
        // if you are really paranoid you can frequently test in between other
        // stuff to see if mpuInterrupt is true, and if so, "break;" from the
        // while() loop to immediately process the MPU data
        // .
        // .
        // .
    }

    // reset interrupt flag and get INT_STATUS byte
    mpuInterrupt = false;
    mpuIntStatus = mpu.getIntStatus();

    // get current FIFO count
    fifoCount = mpu.getFIFOCount();

    // check for overflow (this should never happen unless our code is too inefficient)
    if ((mpuIntStatus & 0x10) || fifoCount == 1024) {
        // reset so we can continue cleanly
        mpu.resetFIFO();
        Serial.println(F("FIFO overflow!"));

    // otherwise, check for DMP data ready interrupt (this should happen frequently)
    } else if (mpuIntStatus & 0x02) {
        // wait for correct available data length, should be a VERY short wait
        while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount();

        // read a packet from FIFO
        mpu.getFIFOBytes(fifoBuffer, packetSize);
        
        // track FIFO count here in case there is > 1 packet available
        // (this lets us immediately read more without waiting for an interrupt)
        fifoCount -= packetSize;

        mpu.dmpGetAccel(&aa, fifoBuffer);
        tmp = String(aa.x) + " " + String(aa.y) + " " + String(aa.z) + " ";
        mpu.dmpGetAccel(&aa, fifoBuffer);
        gravityX = aa.x / 8192.0;
        gravityY = aa.y / 8192.0;
        gravityZ = aa.z / 8192.0;
        tmp = tmp + String(gravityX) + " " + String(gravityY) + " " + String(gravityZ) + " ";

        // display Euler angles in degrees
        mpu.dmpGetQuaternion(&q, fifoBuffer);
        mpu.dmpGetGravity(&gravity, &q);
        mpu.dmpGetYawPitchRoll(ypr, &q, &gravity);
        tmp = tmp + String(ypr[0] * 180/M_PI) + " " + String(ypr[1] * 180/M_PI) + " " + String(ypr[2] * 180/M_PI) + " ";

        mpu.dmpGetLinearAccel(&aaReal, &aa, &gravity);
        tmp = tmp + String(aaReal.x) + " " + String(aaReal.y) + " " + String(aaReal.z) + "\r\n";


        Serial.print(tmp);
        client.print(tmp);

Der Overflow hat eindeutig etwas mit dem Senden (client.print(tmp)) zu 
tun, wenn ich es auskommentiere bekomme ich keinen Overflow.

Ich denke mal das Problem liegt dabei, dass der FIFO Buffer sich 
schneller füllt als ich ihn auslese, da das Senden sehr viel Zeit in 
anspruch nimmt. Liege ich da richtig?

Falls ja, wie kann ich das Problem umgehen?
Gibt es eine Möglichkeit den Buffer langsamer zu füllen, also einfach 
mehr Zeit zwischen den Messungen zu lassen?
Alternativ, gibt es eine Möglichkeit das Senden (client.print...) zu 
beschleunigen?

Danke, Niklas

[Niklas S. (nicklarrs)]

Hi Leute,

ich habe nun den Code sehr abgeändert, habe das hier 
(http://www.i2cdevlib.com/forums/topic/27-fifo-overflow/#entry99) 
versucht und es hat sich auch einiges verbessert.
Jedoch stürzt das Programm trotz allem nach ca. 6 Minuten ab, vorher 
wirft es noch einige "Fifo Overflows" raus.

Ich denke aber inzwischen, dass das Problem nicht an dem Holen der Daten 
vom MPU liegt, sondern am Senden der Daten über den ESP. Sprich, dass 
der FIFO Overflow nur deshalb entsteht, weil ich das WLAN Modul mit dem 
Senden überfordere und es steckenbleibt.

Deshalb habe ich auch mal nach dem "clien.send(tmp)" ein delay(40) 
drangehängt und es hat auch was gebracht. Jedoch konnte ich so das 
Abstürzten des Programms wieder nur nach hinten verschieben, das Problem 
gelöst hat das nicht...

Ich denke also, dass beim Senden ein Flaschenhals entsteht, das 
Wlan-Modul kommt mit dem Senden nicht hinterher und stürzt dann nach zu 
vielen Sendeversuchen ab.

Könnte ich da richtig liegen?
Wenn ja, gibt es irgendeine Lösung für das Problem?
Kann ich die Geschwindigkeit in der das Modul sendet irgendwie erhöhen?

So sieht momentan mein Code aus:

 // wait for MPU interrupt or extra packet(s) available
    while (!mpuInterrupt && fifoCount < packetSize) {
      
      }

    // reset interrupt flag and get INT_STATUS byte
    mpuInterrupt = false;
    mpuIntStatus = mpu.getIntStatus();

    // get current FIFO count
    fifoCount = mpu.getFIFOCount();

    // check for overflow (this should never happen unless our code is too inefficient)
    if ((mpuIntStatus & 0x10) || fifoCount == 1024) {
        // reset so we can continue cleanly
        mpu.resetFIFO();
        Serial.println("FiFO Overflow");
    // otherwise, check for DMP data ready interrupt (this should happen frequently)
    } else if (mpuIntStatus & 0x02) {
        // wait for correct available data length, should be a VERY short wait
        while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount();

        // read a packet from FIFO
        mpu.getFIFOBytes(fifoBuffer, packetSize);
        
        // track FIFO count here in case there is > 1 packet available
        // (this lets us immediately read more without waiting for an interrupt)
        fifoCount -= packetSize;

        mpu.dmpGetAccel(&aa, fifoBuffer);
        /*
        mpu.dmpGetAccel(&aa, fifoBuffer);
        gravityX = aa.x / 8192.0;
        gravityY = aa.y / 8192.0;
        gravityZ = aa.z / 8192.0;
        tmp = tmp + String(gravityX) + " " + String(gravityY) + " " + String(gravityZ) + " ";
        */

        // display Euler angles in degrees
        mpu.dmpGetQuaternion(&q, fifoBuffer);
        mpu.dmpGetGravity(&gravity, &q);
        mpu.dmpGetYawPitchRoll(ypr, &q, &gravity);

        mpu.dmpGetLinearAccel(&aaReal, &aa, &gravity);

        //tmp = String(aa.x) + " " + String(aa.y) + " " + String(aa.z) + " " + String(ypr[0]) + " " + String(ypr[1]) + " " + String(ypr[2]) + " " + String(aaReal.x) + " " + String(aaReal.y) + " " + String(aaReal.z) + "\r\n";
        tmp = String(aa.x) + " " + String(aa.y) + " " + String(aa.z) + " " + String(aaReal.x) + " " + String(aaReal.y) + " " + String(aaReal.z) + "\r\n";
        //Senden der Daten über ESP
        client.print(tmp);
        delay(50);
        Serial.print(tmp);
    }
}

Und so sieht der Output auf der seriellen Console aus:

-6504 2399 4043 -102.56 -54.17 17.34 139 -42 -84 //Ca 7 Minuten bekomme ich alle ca. 50 mS den gewünschten Output
-6504 2399 4043 -102.56 -54.17 17.34 139 -42 -84
-6504 2399 4043 -102.56 -54.17 17.34 139 -42 -84//Dann stockt das Programm, alle ca 20 Sekunden gibt es einen Output und dazu den "Fifo Overflow"
FIFO overflow!
-6504 2399 4043 -102.56 -54.17 17.34 139 -42 -84
FIFO overflow!
-6506 2389 4040 -102.56 -54.16 17.35 135 -54 -87
FIFO overflow!
-6496 2389 4053 -102.54 -54.17 17.34 145 -52 -75
...