Hi,

Noticed, that the repo is missing User Guide file. As far as I understand this driver version is different than the one for RTOS (bno080-driver) which has the 'UserGuide.pdf'. What are the differences from API point of view? I'm trying to interface BNO080 from MSP430 without RTOS.

Thanks in advance,

Atis

I'm currently trying to make sense of the sh2_setReorientation function, and it seems to be reversed from what my expectations are.

tl;dr

It seems like the { x, y, z, w } reorientation quaternion has a strangle mapping onto the game vector (re + i + j + k) quaternion ( also the rotation vector, but I didn't do much testing on that one). Where, w -> re, +z -> -k, but +x -> +j and +y->+i. As far as I can tell, there is no place in the documentation where the { x, y, z, w } convention is defined with respect to the ( re + i + j + k ) convention, but the one described here seems highly non-standard, making me think it is a bug?

What I am hoping to accomplish

on boot, I want to stipulate a new orientation for the IMU to consider as "forward", and then pull data from the GameRotationVector reports which will give me orientations relative to this new tare. I am award that the game vector does not give absolute yaw, however, I'm assuming that the yaw=0 is inferred from the devices position at boot, and so I am careful to always boot the device in the same starting orientation. Additionally, I am also aware that the yaw for the game vector drifts, so all the following observations were conducted quickly after boot to mitigate this effect.

How I have attempted to accomplish this so far

Following the SH-2 Reference manual 6.4.4.3 and , sh2_setReorientation, the library expects a struct of the form { x, y, z, w }, and following the SH-2 Reference manual 6.4.19, the library gives a report with for which the traditional quaternion form: ( re + i + j + k ) can be extracted.

Code example

In my main program, I have the following code:

static void sh2_sensor_callback(void *, sh2_SensorEvent_t *event)
{
    if (event->reportId == SH2_GAME_ROTATION_VECTOR) {
        // This function pulls re, i, j, k out of the report, converting Q-14 to doubles
        update_game_rotation(event->report);
    }
}

static void sh2_event_callback(void *, sh2_AsyncEvent_t *event)
{
    if(event->eventId == SH2_RESET) {
        sh2_Quaternion_t vector = {
                        // For testing, this is currently hardcoded
			.x = 0.0,
			.y = 0.0,
			.z = 0.0,
			.w = 1.0,
        };
        sh2_setReorientation(&vector);

        sh2_setSensorCallback(sh2_sensor_callback, nullptr);

        sh2_SensorConfig_t sensor_config;
        memset(&sensor_config, 0, sizeof(sensor_config));

        sensor_config.reportInterval_us = 16667; // 60 Hz
        sh2_setSensorConfig(SH2_GAME_ROTATION_VECTOR, &sensor_config);
};

int main()
{
    sh2_initialize(sh2_event_callback, nullptr);
    /*
     * Do things here with data pulled from `update_game_rotation`
     */
}

Behavior that matches my intuition

If I set the reorientation record to { x=0, y=0, z=0, w=1 }, and boot the device flat with +z up, +y north, +x east (that is, the chip's internal axis), then

• The returned report gives the game vector ( 1.0 + 0i + 0j + 0k ), as expected.
• If I rotate the device around "EAST" then the game vector increase in the i component
• If I rotate around "NORTH", then the game vector increases in the j component
• If I rotate around "UP" then the game vector increases in the k component

This is all matches my expectation.

Next, If I then set the reorientation to { x=0, y=0, z=0.707, w=0.707 } and boot the device flat with +z up, +y north, +x east (that is, the chip's internal axis), then

• The returned report gives the game vector ( 0.707 + 0i + 0j - 0.707k ), for which I can rationalize the negative z component if the orientation vector is rotating the reference frame (i.e. gravity vector) rather than the current orientation.
• Next, if I rotate the device +90 degrees around "UP", the game vector becomes (1+0i+0j+0k), as expect.
• What is slightly strange, however, is that the game vector still treats the original "ENU" axes as corresponding to the ijk components. That is, if I rotate: 1) +90 about UP, then 2) +90 about NORTH I get the game vector ( 0.707 + 0i + 0.707j + 0k ), meaning that the device still perceives NORTH as +y, even though the reorientation quaternion has ostensibly rotated the system about the UP direction by +90 degrees? Again, I can rationalized this by imagining that the coordinate system never actually changes, but that only the reference frame does, but that doesn't seem to be what BNO08x datasheet section 4 is communicating.

In any case, if this all is expected behavior, I can easily design around it.

Behavior that doesn't match my intuitions

If I set the reorientation record to { x=0.707, y=0, z=0, w=0.707 }, and boot the device flat with +z up, +y north, +x east (that is, the chip's internal axis), then

• I would expect the game vector to yield ( 0.707 - 0.707i + 0j + 0k ), BUT:
• The returned report gives the game vector ( 0.707 + 0i + 0.707j + 0k ) which seems to imply that x -> j? Also, this is strangle because where as the previous example had +z -> -k, here +x -> +j.
• This is further made strangle because the game vector still recognizes NORTH as effecting j, so that I map the game vector onto ( 1 + 0i +0j + 0k ) by rotating the the device -90 degrees around NORTH.

I'm pretty sure that somehow x and y (from the reorientation quaternion) are flipped with respect to the i and j for the game vector, because: if I set the reorientation record to { x=0, y=0.707, z=0, w=0.707 }, and boot the device flat with +z up, +y north, +x east (that is, the chip's internal axis), then

• The returned report gives the game vector ( 0.707 + 0.707i + 0j + 0k ) which seems to imply that y -> i?

Possible theories

It is possible that my device has some factory-set default orientation which applies { x = 0.707, y = 0.707, z = 0, w = 0} (flipping x and y, and turning z upsidedown), but is isn't clear to me how I could check that, or if such a default even exists? Additionally, it seems from the documentation that the way to clear any factory default is to call sh2_clearTare, but the source for that function is equivalent to calling reorientation.

the following function in the file sh2.c returns nothing:

int sh2_getOscType(sh2_OscType_t *pOscType)
{
sh2_t *pSh2 = &_sh2;

return opProcess(pSh2, &getOscTypeOp);

}

it has to look like this:

int sh2_getOscType(sh2_OscType_t *pOscType)
{
sh2_t *pSh2 = &_sh2;

pSh2->opData.getOscType.pOscType = pOscType;

return opProcess(pSh2, &getOscTypeOp);

}

Hello,

Im looking for a IIO Android Linux driver for BMO086, does anyone know where I can get that?

Thanks