Hello,
As @torriem said, this device provide only raw data of gyro, mag and acc. So you have to fuse this data through a specific algorithm to have yaw, pitch and roll value in degree. You can find open-source fusion algorithm like Madgwick algorithm Open source IMU and AHRS algorithms – x-io Technologies.
I try to do this 6 months ago with an MPU9250 and an Arduino running this algorithm, but never add a good result.
I use the BNO085 from Adafruit, but don’t know why, it’s currently out of stock.
I did not know that they were working on it. There is no topic about this on the forum. I work on BNO085 because I was facing some unstability from MMA (see here : Perfect straight line without MMA, slight oscillation with MMA - #4 by Math). I discovered the potential of BNO085 throught this topics originaly created by @torriem (thank to him), so it’s why I started to try it to determine if it’s a better solution than MMA (by comparing them). And as the final goal to proposed them as an alternativ to include it in AOG project as a selectable device in AOG (and ino) in future versions (and not making a duplicate .ino specific to the BNO085). And I think it’s a better device than MMA.
Too bad, we have duplicated the work.
I take a look on this board: https://www.robot-electronics.co.uk/files/cmps14.pdf. Not a lot of informations, but it’s based on a BNO080. For me, BNO080 is a Bosh BNO055 hardware, but running a specific firmware from HillcrestLabs on his microcontroler (who provided this very stable and various datas). But you had to communicate with him with the specific HillcrestLabs SHTP protocole. Very different from a classic I2C protocol which we are used to deal with (like just reading datas on differents registers: SHTP protocol as an additionnal software layer).
Looking CMPS14, it’s work like a “classic” I2C interface: reading datas on registers defines in the datasheet… But when I look on the picture of the CMPS14, we can see an additionnal PIC16 F18325 Microcontroler on it. So I’m pretty sure that this PIC controler make the interface between BNO080 and the host, “transforming” the SHTP protocol on the BNO080 side into “classic I2C protocol” at the host side.
So read datas from BNO080 is easier with this board, as you don’t have to implement SHTP protocol.
But you also had less control on the configuration of the BNO080: you can only configure what the PIC allow you. By example: BNO080 had diffrent fonctionnal modes (Rotation Vector, game rotation vector): we had no information how the PIC configure it.
My opinion is that as we add success to deal with SHTP protocol (thank to Sparkfun library), we would be interested to interface directly our Arduino with BNO080 (Adafruit or other supplier board): we add a full control of BNO080, and we don’t interface to a microcontroler which we do not fully control what he does. But it’s only my opinion.
Math