IMU Bosch BNO055 (z.B. Arduino, Raspberry Pi)

[Ceos]

SDCards liegen jetzt beim Paketshop, da mein anderes Prjekt eh gerade einen Dämpfer abbekommen hat kann ich heute nochmal hieran arbeiten.

@HaWe Messdaten habe ich unter Python übrigens schon erfolgreich ausgelesen, es kondensiert sich zu folgendem Code in C(ungetestet, das wollte ich heute ausprobieren, wenn ich dazu komme):

#include "ip_connection.h"
#include "brick_imu_v2.h"

typedef struct
{
   float w;
   float x;
   float y;
   float z;
}quaternion_s;


    quaternion_s q;
    // Create IP connection
    IPConnection ipcon;
    ipcon_create(&ipcon);

    // Create device object
    IMUV2 imu;
    imu_v2_create(&imu, UID, &ipcon);

    // Connect to brickd
    if(ipcon_connect(&ipcon, HOST, PORT) < 0) {
        fprintf(stderr, "Could not connect\n");
        return 1;
    }
    // Don't use device before ipcon is connected

    // Get current quaternion
    int16_t w, x, y, z;
    if(imu_v2_get_quaternion(&imu, &w, &x, &y, &z) < 0) {
        fprintf(stderr, "Could not get quaternion, probably timeout\n");
        return 1;
    }
    q.w = w/16383.0;
    q.x = x/16383.0;
    q.y = y/16383.0;
    q.z = z/16383.0;

    float yaw = atan2(2.0*(q.y*q.z + q.w*q.x), q.w*q.w - q.x*q.x - q.y*q.y + q.z*q.z);

    float pitch = asin(-2.0*(q.x*q.z - q.w*q.y));

    float roll = atan2(2.0*(q.x*q.y + q.w*q.z), q.w*q.w + q.x*q.x - q.y*q.y - q.z*q.z);

[HaWe]

SDCards liegen jetzt beim Paketshop, da mein anderes Prjekt eh gerade einen Dämpfer abbekommen hat kann ich heute nochmal hieran arbeiten.

@HaWe Messdaten habe ich unter Python übrigens schon erfolgreich ausgelesen, es kondensiert sich zu folgendem Code in C(ungetestet, das wollte ich heute ausprobieren, wenn ich dazu komme):

#include "ip_connection.h"
#include "brick_imu_v2.h"

typedef struct
{
   float w;
   float x;
   float y;
   float z;
}quaternion_s;


    quaternion_s q;
    // Create IP connection
    IPConnection ipcon;
    ipcon_create(&ipcon);

    // Create device object
    IMUV2 imu;
    imu_v2_create(&imu, UID, &ipcon);

    // Connect to brickd
    if(ipcon_connect(&ipcon, HOST, PORT) < 0) {
        fprintf(stderr, "Could not connect\n");
        return 1;
    }
    // Don't use device before ipcon is connected

    // Get current quaternion
    int16_t w, x, y, z;
    if(imu_v2_get_quaternion(&imu, &w, &x, &y, &z) < 0) {
        fprintf(stderr, "Could not get quaternion, probably timeout\n");
        return 1;
    }
    q.w = w/16383.0;
    q.x = x/16383.0;
    q.y = y/16383.0;
    q.z = z/16383.0;

    float yaw = atan2(2.0*(q.y*q.z + q.w*q.x), q.w*q.w - q.x*q.x - q.y*q.y + q.z*q.z);

    float pitch = asin(-2.0*(q.x*q.z - q.w*q.y));

    float roll = atan2(2.0*(q.x*q.y + q.w*q.z), q.w*q.w + q.x*q.x - q.y*q.y - q.z*q.z);

sieht ja echt schon ungeheuer vielversprechend aus! Bin extrem gespannt!

[Defiant]

Wieso ruft ihr imu_v2_get_quaternion() auf und formt das in Euler-Winkel um anstatt direkt imu_v2_get_orientation() den Euler-Winkel auszulesen?

[Ceos]

wenn du mir erklärst was genau die in der doku mit dem gimballock meinen und warum sie dazu raten die quaternioen zu benutzen? wenn ich es recht verstehe, drehst du das ding auf hochkant und bekommst keine ausrichtugn mehr ... über die quaternionen soll dasd wohl nicht passieren, solange man die ausrichtung der achsen berücksichtigt ... meinem verständnis nach muss man das dann selber machen, weswegen ich den obigen ansatz verfolge ...

denke ich habe das WE mal irgendwo zwit dazwischen um mich wieder ran zu setzen

PS: nicht erklären was gimballock ist, sondern im konkreten kontext dieses sensors und warum sie davor warnen wenn nicht gemeint ist was ich gerade als annahme geschrieben habe

[Defiant]

Ja, die Quaternion-Darstellung ist ohne Gimbal Lock. Allerdings nur solange wie man bei Quaternionen bleibt, bei der Umrechnung in Euler verliert man deren Vorteile.

Gimbal Lock ist in der Deutschen Wikipedia leider nicht mathematisch erklärt, bei Drehungen kann es zu Singularitäten (Sprünge bei einem Pitch von +90/-90°) kommen, Eine gute Erklärung kriege ich leider nicht hin, deswegen der Verweis auf [1].

Der Punkt ist: Das Problem hat man (soweit ich das verstehe) bei Berechnungen, z.B. Gegeben ist eine Position A. Welche Drehung d muss ich anwenden um zu Position B zu kommen. Beim einfachen auslesen des aktuellen Winkels, um die Drehung im 3D-Raum zu lesen kommt es zu keinem Problem. Die Eulerwinkel des IMU Bricks 2 sind hier nicht besser oder schlechter als die Eulerwinkel anderer IMUs.

[1] https://zfx.info/viewtopic.php?p=35924#p35924