I’m working with the BNO055 for a robotics project, needing constant and accurate geographical orientation data in ENU (East, North, Up) context.
Effectively, I need constant awareness of geographical direction with respect to magnetic north, regardless of the unit’s orientation.
Unfortunately, I can’t seem to get any meaningful data out of this device that works under all orientations.
For example, in “Compass” or “NDOF” mode (I’ve tried this in both) – starting with XYZ of the device corresponding to ENU – if I “roll” the device 90 degrees around its Y-axis (so that the device’s X-axis is aligned with gravity), and then “yaw” the device CC by 45 degrees, the heading will read 315 degrees.
This makes sense as an Euler angle describing intrinsic yaw, but is completely senseless as an extrinsic heading, as in-reality the device is still pointed North, and angled 45 degrees Up – and so the geographical (compass) heading should still be 0.
Am I perhaps retrieving “heading” data in “Compass” mode from the wrong registers? I see no other likely candidates, or perhaps I am using this mode incorrectly (though the datasheet seems to imply this mode is designed exactly for the use I’ve described).
Failing a direct output of such information, I’ve resorted to calculating it myself using the quaternion absolute orientation output, but I am not getting the results I expect.
I’m confident that I am reading the registers correctly and correctly computing the decimal value of each component of the quaternion. The sensor output agrees quite well with expected values when limited to simple rotations - for example, when XYZ are aligned with ENU, the quaternion reads [1,0,0,0]; and then [0,0,0,1] when rotated 180 degrees about Z/U.
My approach also seems sound – I am using the quaternion data from the IMU to create a rotation matrix as described here: http://www.chrobotics.com/library/understanding-quaternions .
Multiplying this 3x3 matrix against an ENU vector should give me the E’N’U’ coordinates of any vector translated through the same rotation as the device – in this case the N unit vector [0,1,0]. I can then take only the E’ and N’ values of this translated vector (the projection onto the EN plane), and easily compute an angle from N.
In practice, however, this method seems to suffer from the same issue as taking the heading in compass mode. As the device “yaws” while rolled at 90 degrees, the E’N’ coordinates skew angularly from N. Obviously this should not happen, as the projection of the device's Y axis is not changing angular position in the EN plane.
Can someone please shed some insight into what may be going on here? I’m on the verge of tearing my hair out.
I will ask for internal experts' help, if any update, I will keep you informed.
Do you mean Gimbal lock?
Could you list your operation and tell us your test results and the results you expect?
We can confirm these according to your description.
The issue I'm describing is present when reading absolute orientation quaternions directly from the device registers.
Quaternion-described orientation should be immune to gimbal lock.
I talked to our internal experts, need you to offer more details based on your description:
1. "Rotate sensor about its Z axis (intrinsic)" are your actions? And your putput results are"shows angular changes in the E-N plane"? they were not accord with the actual action which are " in reality the device is only translating in the N-U plane".
2. "when transformed from XYZ to ENU coordinates" in the results, what is mean? this made us confused.
If you can offer the raw data of three axis, it is useful for us to understand your operations.
Looking forward to your feedback.