IMU (BNO055) doesn't return valid data immediately after initialization.

[ftcteam8397]

Perhaps this is more of a feature to be documented than an issue.

tl;dr After calling IMU.initialize (with a BNO055IMU), a brief delay is required before valid yaw angles can be obtained.

This regards use of the IMU interface with a BNO055IMU. Our understanding is that this device maintains heading data between opmode runs. For example, if the yaw is 30 degrees at the end of one opmode run, it will read 30 degrees at the beginning of the next (provided the device hasn't been moved and resetYaw hasn't been called).

In the initialization phase of our linear opmode (before waitForStart), we call the initialize method of IMU to set the LogoFacingDirection to RIGHT and the USBFacingDirection to FORWARD (in keeping with the actual orientation of the control hub on our robot).

If we then immediately call getRobotYawPitchRollAngles, we find that the yaw is zero, regardless of what it was at the end of the preceeding opmode. But, within some fraction of a second, if we call getRobotYawPitchRollAngles again, we get the yaw that was actually present at the end of the preceeding opmode.

Since we are doing this to set a headingOffset in our code, we find that we need to insert a brief delay (using an ElapsedTime) between the call to IMU.initialize and the first call to IMU.getRobotYawPitchRollAngles. We've found that as little as 300 ms delay works, but haven't tried shorter.

[WestsideRobotics]

IMU initialization delays are noted here at ftc-docs.

[AlecHub]

After IMU.initialize(), for us it takes about 60 milliseconds to get a non-zero Yaw sample.

Here is the environment:

Thank you @ftcteam8397 for reporting this behavior!!!