I would speculate that your IMU is not yet calibrated. What does the “Current Cal Status” indicator say? If all values are red you probably haven’t gone through the calibration process. Advise if this isn’t the problem and I’ll help troubleshoot. For now, I’ll assume cal is the problem …
IMU’s require calibration for their measurements to become useful. This BNO055 IMU is advanced to the point that the sensor will self-calibrate if you simply physically move it as described by section 3.10 of the
datasheet (and then it will continue to update its calibration as it’s used in operation).
There’s a short version of this guidance in a comment on the back panel diagram of IMUOrientOpen, but here’s the procedure in a bit more detail:
The code is designed to first help you calibrate the IMU by letting you put it into a calibrate mode. This is where you make the physical sensor movements for calibration. As this mode completes, a calibration dataset is stored on the flash drive that you previously installed in either one of the roboRIO’s USB ports. The next time you run the code, you put it in normal mode and tell it the name of the stored calibration file. This lets the IMU to be ready at startup.
Let’s try this ... once you have the IMUOrientDemo2016 vi open, select the “Calibrate?” control on the front panel, and open the IMUOrientOpen vi so you can see its front panel (you’ll need this in a moment). Do a Run-button deploy (not a Compile-and-deploy). TheIMUOrientOpen vi will run first, and since Calibrate? is set to True, you will be prompted via a dialog box with instructions on the physical motion required to achieve calibration. With Demo running, switch to the IMUOrientOpen front panel so you can observe the “Manual Calibration Status” indicator – this provides immediate feedback as you move the sensor around per the instruction. Once all four status indicators are green, another dialog box will congratulate you on your perseverance and personal intelligence, but most importantly, it will identify the filename where the calibration constants have been stored. Write this down and stop the code.
Go back to the IMUOrientDemo2016 vi, deselect the Calibration? control, and enter the cal filename into the “Stored Cal File” control on the front panel of IMUOrientDemo2016. Run the vi again (it can be a Run-button deploy or a Compile-and-deploy, doesn’t matter now). You should now see data updates on the front panel graphs and other indicators.
The calibration process needs to be executed at least once so there’s a cal file for the code to reference. Try this first with the sensor on a table-top to get used to what motion it takes to achieve full (all green) calibration. The accelerometer generally takes the most finesse to calibrate - keep trying, it’s worth it. Once you install the sensor on the robot, you’ll have to move the entire robot around as a unit to create a new calibration file. This is because the robot can disturb the local magnetic field, and you want the cal to compensate for this. It’s not too difficult.
Explore the different sensor operating modes using the “Op Mode” control on the Demo vi, which are described in section 3.3 of the datasheet. Some are fusion modes and some are not. The code defaults to the “NDOF_FMC_OFF” operating mode, which translates to Nine Degrees Of Freedom / Fast Magnetic Calibration Off. The “IMU” operating mode avoids the use of the sensor’s magnetometer, which could be useful should you find issues with robot magnetic interference affecting sensor performance (one tradeoff is that you won’t know North). The Op Mode must be designated prior to running the code.
Explore the different sensor read functions with the “Read Enable” control on the Demo vi. These can be selected / deselected ‘live’. The accelerometer read function has three different modes so you can explore Einstein’s Principle of Equivalence with the power of sensor fusion. You can turn on all the read functions so you can see what’s available. You might want to leave on only the functions you use to optimize the execution speed of your code.
There are two separate I2C interface buses on the roboRIO. I recommend staying with the default “MXP” interface, as there still appears to be difference in how they work, and the On-Board I2C port is apparently causing issues with the BNO055 bus traffic (best I can tell). Get a Rev Robotics More Board to get easy access to the MXP I2C interface, if you like.
Don't forget to run the Visualization vi to observe in real-time the orientation change as the sensor is moved. The vi runs on the My Computer Target, (not the roboRIO Target), which means it can only be accessed in debug mode. There is an issue where Roll exceeding ~45 degrees causes an orientation error (possible BNO055 firmware issue). Most FIRST robots don’t roll that far so perhaps it’s not a major issue.
That’s about it … you might read through the datasheet to get a better idea of everything the sensor can do. Our software abstracts the details to make it quick/easy to use in competition. There a bunch of comments in the code that discusses the code design and implementation considerations.
Let us know if this helped!