Why not add AxesMap and AxesSign to BNO055?

[jkenney2]

Lots of teams would like to be able to mount their Rev Control Hub and/or Expansion Hub in a vertical orientation, and keep full functionality of the IMU. We have extended the BNO055.Parameters interface with AxesMap and AxesSign enums, and have extended the BNO055IMUImpl class to remap axes and signs during initialization (which requires only minimal additional code in the internalInitializeOnce method). Why not just make this functionality part of the SDK?

[WestsideRobotics]

I'm not sure if this addresses all of your suggestion, but the SDK does currently default to Heading, whether the Hub is horizontal or vertical.

The method call can simply omit parameters, including AxesReference and AxesOrder.

heading = imu.getAngularOrientation().firstAngle;

[jkenney2]

It's been a couple of years since I tested. My recollection is that mounting upside down is problematic, which can be corrected by changing the sign of the z-axis (a team had asked about this on the forum). Mounting vertically with pitch, i.e. Y-axis rotation, equal or very close to pi/2, could lead to ambiguity in the Z and X axis rotations, and I've wondered whether that is handled in a robust way, such that the heading is as accurate as it would be with horizontal mounting (or with remapping). I'll have to do a little more testing.

[jkenney2]

@WestsideRobotics Here is an example of where things can break if axis remapping is not used, based upon recent testing:

Position the expansion hub vertically, with the servo-port side contacting the table top, then initialize the IMU and proceed to obtain serial measurements (ZYX, Intrinsic). The initial angles ZYX then appear, as expected, as 0, -90, 0. Pure changes in heading can now be read from the first angle (z axis). Pure changes in pitch can be read from the second angle (y axis). But pure changes in roll (i.e., lifting the end with the I2C ports so it is a little higher than the end with the dc motor ports) are interpreted as a combination of changes in all three axes. This results in an inaccurate reading of the heading.

One solution to this problem would be to make sure the hub is mounted perfectly vertically on the robot. But that won't correct the situation where the robot itself is inclined (for example, going over the barrier in the current game). This problem can be avoided entirely by remapping the axes (specifically, by writing the 6 LSB of the AxesMap register to 000110, and the 3 LSB of the AxesSign register to 001).