Virtual reality is in, but you shouldn't have to drop hundreds of dollars to gain access to the technology behind it. Luckily, that's where the SparkFun VR IMU Breakout comes in. At its heart is CEVA’s BNO086, a combination triple-axis accelerometer/gyro/magnetometer System in Package (SiP) with a 32-bit ARM© Cortex™ M0+. The BNO086 Inertial Measurement Unit (IMU) produces accurate rotation vector headings, excellently suited for VR and other heading applications, with a two-degree or less static rotation error. The VR IMU is exactly what we’ve been waiting for; all the sensor data is combined and drift-corrected into meaningful, accurate IMU information. It’s perfect for any project that needs to sense orientation or motion.
This IMU breakout board has also been equipped with two I2C Qwiic connectors to make interfacing with the tiny QFN package a bit easier. It’s part of SparkFun’s Qwiic connect system, so you won’t have to do any soldering to figure out how things are oriented. However, we still have broken out 0.1"-spaced pins if you prefer to use a breadboard.
The BNO080 was designed to be implemented in Android-based cellular phones to handle all the computations necessary for virtual reality goggles using only your phone. With the BNO080 EOL, CEVA offers the drop-in replacement BNO086 with enhanced features (14-bit accelerometer fusion, reduced idle state power, and Interactive Calibration). The sensor is quite powerful, and with power comes a complex interface. Thanks to the solder jumpers on the board, you can select between two different I2C addresses. Still, if I2C is not your first communication choice, the sensor can communicate over SPI and UART! We’ve also written an I2C-based library that provides the rotation vector (the reading most folks want from an IMU), acceleration, gyro and magnetometer readings, step counting, and activity classifier (such as riding a bike).
The SparkFun Qwiic Connect System is an ecosystem of I2C sensors, actuators, shields and cables that make prototyping faster and less prone to error. All Qwiic-enabled boards use a common 1mm pitch, 4-pin JST connector. This reduces the amount of required PCB space, and polarized connections mean you can’t hook it up wrong.
If a board needs code or communicates somehow, you're going to need to know how to program or interface with it. The programming skill is all about communication and code.
Skill Level: Competent - The toolchain for programming is a bit more complex and will examples may not be explicitly provided for you. You will be required to have a fundamental knowledge of programming and be required to provide your own code. You may need to modify existing libraries or code to work with your specific hardware. Sensor and hardware interfaces will be SPI or I2C.
See all skill levels
If it requires power, you need to know how much, what all the pins do, and how to hook it up. You may need to reference datasheets, schematics, and know the ins and outs of electronics.
Skill Level: Rookie - You may be required to know a bit more about the component, such as orientation, or how to hook it up, in addition to power requirements. You will need to understand polarized components.
See all skill levels
Based on 4 ratings:
2 of 2 found this helpful:
I ran into an issue with the SparkFun_BNO08x_Arduino_Library.h. I am using the SparkFun Thing Plus SAMD51 and if you upload any of the sample programs windows will notify you that the USB device is not recognized and you will not be able to use the serial monitor to view the serial console for the SAMD51.
I was able to solve the issue if you move the #include <Wire.h> to after the #include "SparkFun_BNO08x_Arduino_Library.h". I am not 100% sure why this is but I would assume it has to do with something in the SparkFun_BNO08x_Arduino_Library.h. Hope this helps anyone that runs into this problem.
Other than that this IMU is pretty cool!
1 of 2 found this helpful:
I am using the configuration in the guide. Using the example code I noticed that, while some of the reports work just fine e.g. EulerAngles, reading accelerometer, gyro and magnetometer data directly is very unstable and inconsistent. At sporadic intervals the measurements will report '0' in one or more of the axes across all 9-DoF messages - not always simultaneously.
On occasion, the serial output will be "BNO08x - Error decoding sensor event"; which appears to be exacerbated when the platform is moving. For this last one, my initial thought was a bad connection, but then again, this is not happening with the aforementioned example code while moving the platform.
For my application, I am looking to implement my own navigation equations and given the unreliable sensor data, this product is no good.
0 of 1 found this helpful:
Took BNO086 as a shift from BNO055. I needed quaternions this gives rotation vector, so basically it cannot determine weather rotation is 175 cc degrees or 185 acc, this creates lot of trouble. BNO086 IS BASICALLY DOWNGRADE FROM BNO055. Also rotation vector output is not smooth and gives all values as zero at regular intervals of few seconds which messes the calculations. If sparkfun can fix rotation vector and convert it to quaternions it will be useful.
I used this as a replacement for Sparkfun's older 9DoF IMU Breakout (ICM-20948). It's way way better. My application relies on accurate lateral rotation positioning (ie compare) so the "tare" feature this board has was a big improvement in usability for me. The library is much easier to use and requires less config.
Like others mentioned, I too am getting occasional "blips" in readings, but they are generally single-sample and off by a lot, so they are easy-ish to just filter out (ignore a reading if it is more than X different than the previous reading, etc). Hopefully a library improvement will address this in the future.