Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    BNO055 - complications interpreting absolute orientation data - help request

    BNO055 - complications interpreting absolute orientation data - help request

    c_bot
    New Poster

    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.

    9 REPLIES 9

    I'm honestly not sure how much more explicit I can be.  Between my two posts, I've explained the situation with as much clarity and detail as I can muster. 

    Perhaps I will try making a video, since my descriptions are somehow unclear. 

    However, to recap:

    XYZ is the body frame of the device.

    ENU is "East, North, Up".  This is the X'Y'Z' of the *reference* frame.

    When the device moves, XYZ is reorienting with respect to ENU.

    Translating this quaternion-described rotation of a vector from XYZ to ENU is done via a rotation matrix: https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#Quaternion-derived_rotation_matrix.

    In this fashion, any vector in ENU can undergo the same rotation as XYZ, and have its coordinates recovered in ENU space.

    If you turn the device on its side (rotation about Y), then yaw (rotate about Z), the transformation will rotate the N unit vector away from N.  This should not happen, as the projection of the device's orientation vector (onto the EN plane) is still colinear with N - it simply now also has a nonzero U coordinate.

    In short, with the device rotated 90 degrees about Y, and 45 degrees counter-clockwise about Z, but still pointing "North" (just now also pointing 45 degrees "Up" - the output instead implies the device is pointing 45 degrees away from North - when, clearly, it is not.  Pointing "North and 45 degrees Upward" is not the same as "heading 315 degrees (NorthWest)".

    I will follow up with photos and/or a video when possible.

    Jet
    Occasional Contributor

    Hi Sir:

      Regarding your test, if you read Eular data directly and don't use translation formula, the result you get is the same as translated value or the result is satisfied?

      Talked to our internal experts, we wanted to know whether the different platform produced this difference.

       Do you mean the result is heading 315 degree, not 45 degree? Or Could you tell what value you expected and what the actual value is?

      

    My translated data matches the Euler output as long as I avoid 'yaw' rotations

    If I start with a body oriented along the North unit vector <0,1,0>, then roll it 90 degrees CW, then yaw it 45 degrees CCW, the rotated vector should have ENU coordinates of <0, .707, .707>.  Thus, atan2(.707, 0)  [C++] would return 0 degrees (still pointing North, just also "Up"). 

    Instead, it consistently describes Yaw as rotation away from North - even in the above scenario (the rotated vector has a non-zero E component).

    I feel as though there's an assumption in the sensor fusion algorithms somewhere that is skewing the output. 

    I'm sorry I have not yet created a video - I have not had sufficient time yet.  Hopefully before the end of the year.

    Jet
    Occasional Contributor

    Hi Sir:

         Could you offer the video or picture to present the process of your rotation with your explanation to help us to understand them.

     

    Jet
    Occasional Contributor

    Hi Sir:

       Did you know the difference between euler angle and attitude angle?

       You should rotate in a preset sequence. If you want to get the attitude angle according to your own sequence, it's not possible to get the results you expected, because euler angle is not equal to attitude angle.

       Please see the following comments:

       Actually no matter yaw, roll or pitch, they are euler angles around each axis. Euler angle can not describe an angle position in a 3D situation. It can only describe a angle around an axis. So if you want to describe a 3D angle position, you need 3 euler angle, which are yaw angle, roll angle and pitch angle. And the 3D angle position is called attitude angle, which is often used in navigation system. So the attitude angle is the almost the only thing the user needs. The result in direction vector and quarternion are all attitude angle, it's not euler angle. But the euler angle equals attitude angle if and only if the user transform the coordinates following sequence: yaw -> pitch -> roll or yaw -> roll -> pitch (it depends on you global coordinates are ENU or END). That's why we can use euler angles to represent attitdue angle.

       Could these comments solve your query? 

      Hopefully, it helps you.

      Thanks.

     

     

     

     

     

     

     

    Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist