BNO086 - Explanation and detailed info for readings please?

Sensors IMU & Motion
1

Hi,

I would appreciate if someone could please explain the various readings provided by the BNO086 library in more detail. I have gone through the hookup guide, tried most of the library examples and did read all BNO086 related posts, but still there are some ??? in my head.

So far I think I figured this out:

  1. enableRotationVector()
    1. absolute rotation of the IMU in space, using magnetometer + gyroscope + accelerometer
    2. absolute = it does not matter in which rotation the device is turned on, orientation will always stay the same, e.g. North is North
    3. provides rotation in either Quaternions or Vector3 (roll, pitch, yaw)
    4. problem: gets inaccurate with close magnetic fields, plus at least I get a deviation of around 0-20 degress when turning the devices 360 degrees around itself once.
  2. enableGyroIntegratedRotationVector()
    1. relative rotation of the IMU in space, using gyroscope + accelerometer (but not the magnetic orientation)
    2. relative = in whatever rotation the IMU is turned on, this is rotation zero.
    3. provides rotation in Quaternions or angle velocity in Vector3
    4. Magentometer is not involved, therefore the rotation will be less errorprone to magnetic interference… is it faster? is it more accurate? (need further testings)

And then there are readings like

  1. enableGameRotationVector() (I’ve read it should give faster readings, but more precise?)
  2. enableARVRStabilizedRotationVector()
  3. enableARVRStabilizedGameRotationVector

What is it good for, advantages, disadvantages.. ? (E.g. it is mentioned in this thread that GameRotationVector is faster, but what does it mean by “its faster”?)

Also, when testing enableARVRStabilizedGameRotationVector I tried using getRoll(), getPitch() and getYaw() to get Euler Angles (as there are no methods like “getARVR…Vector”, and it seems to me that the readings are independent from magnetometer. So I assume that via roll pitch yaw I get the proper readings here?

  1. I assume that all readings are provided as Quaternions, but with roll pitch yaw its always possible to access those readings as Euler Angles, no matter what kind of report is set. Is that assumption correct? (With other words, to roll pitch yaw always report the current readings set?)

All in all I think it would be great to have such an overview in the hookup guide along with the examples, like “For use case X use readings Y because Z..”

2

The best, most complete and reliable source of information is the very extensive BNO086 data sheet. Have you gone through that?

I assume that all readings are provided as Quaternions, but with roll pitch yaw its always possible to access those readings as Euler Angles

The quaternion is the basic entity that contains the orientation information. It can be converted into Euler angles at any time, except for special circumstances where the angles become indeterminate. Do a web search for “gimbal lock” to learn when and why.

Keep in mind that there are many different definitions for Euler angles, and that the order of applying the three rotations matters a great deal. They are also limited in range of application, which is why most people use the quaternion instead.

1 Like
3

I am familiar with Quaternions, Euler Angles and the usage implications, but thanks anyways.

Thank you for the data sheet link, I didn’t think of that as I was searching around the hookup guide and git examples, but I find my answers under 2.2 Orientation outputs.

As reference for other readers (and maybe to complement), I copy paste basic infos about orientation ouputs from the data sheet to this thread, as this was the main question for me:

Geomagnetic Rotation Vector

The geomagnetic rotation vector is an orientation output that is expressed as a quaternion referenced to magnetic north and gravity. It is produced by fusing the outputs of the accelerometer and magnetometer. The gyroscope is specifically excluded in order to produce a rotation vector output using less power

  • less energy consumption, but less resposive and more errors due to varying magnetic fields

Game Rotation Vector

The game rotation vector is an orientation output that is expressed as a quaternion with no specific reference for heading, while roll and pitch are referenced against gravity. It is produced by fusing the outputs of the accelerometer and the gyroscope (i.e. no magnetometer). The game rotation vector does not use the magnetometer to correct the gyroscopes drift in yaw.

  • smoother representation, but drift in yaw over time

AR/VR Stabilized Game Rotation vector

While the magnetometer is removed from the calculation of the game rotation vector, the accelerometer itself can create a potential correction in the rotation vector produced (i.e. the estimate of gravity changes). For applications (typically augmented or virtual reality applications) where a sudden jump can be disturbing, the output is adjusted to prevent these jumps in a manner that takes account of the velocity of the sensor system. This process is called AR/VR stabilization.

  • less drift than without stabilization (as I understand that is what I want for my use case)

Rotation Vector

The rotation vector provides an orientation output that is expressed as a quaternion referenced to magnetic north and gravity. It is produced by fusing the outputs of the accelerometer, gyroscope and magnetometer. The rotation vector is the most accurate orientation estimate available. The magnetometer provides correction in yaw to reduce drift and the gyroscope enables the most responsive performance.

  • the problem at least I have with that output is a certain drift over time when rotating the device around 360° several times.

AR/VR Stabilized Rotation Vector

Same as rotation vector, but stabilized. Did not make a difference at least with my use case.

Gyro rotation Vector

In virtual reality systems reducing latency is a vital requirement to proving an immersive experience. The gyro rotation vector provides a low latency output.

  • I haven’ tried this one so far, but maybe someone else can share experience?

Game rotation vs. rotation

For my use case the main difference between rotation vector and game rotation / ar vr stabilized game rotation vector is that

  • rotation vector + derivates ouputs the current rotation aligned with the geographic direction, with other words no matter in which Z rotation the IMU is powered on, it will report “north” where “north” is approximately. When rotating the device around Z several times, some readings are quite off (e.g. once from north to south is 180°, next time its only 160° or 200° and so forth).
  • game rotation / ar vr stabilized game rotation sets the current Z rotation to 0 from where the IMU is powered on, while X and Z are calculated against earth gravity. In my use case this has the advantage of much more stable rotation when turning the IMU around Z for several times, since the magnetometer is removed from the rotation calculation. As I have an external reference in which position the IMU is powered on, I do not need magnetic north data.

Tare function (reset rotation to 0,0,0)

Maybe for someone else good to know also is this:

myIMU.tareNow();

alone does not work when using ARVRStabilizedGameRotationVector or GameRotationVector. Then you must call:

myIMU.tareNow(false, SH2_TARE_BASIS_GAMING_ROTATION_VECTOR);