Just noticed that Adafruit has released a breakout board that contains the BNO085, which they say is virtually the same as the BNO080, but with some fixes for I2C. In any event I believe both the BNO080 and BNO085 have the “robotic vacuum cleaner” mode which lets you read the integrated roll and tilt values with no fuss and no complicated calculations. RVC mode looks very simple, and it’s supported by an Arduino library supplied by Adafruit. This looks pretty simple (way simpler than the BNO055). I see a few of you are using the BNO080. Are you using the RVC mode?
Not sure what you’re talking about. The datasheet lists 13 different mode, of which the 5 “fusion” modes seem to do some intelligent calculations internally. Especially the NDOF mode could be interesting to calculate the heading I think. But, as I’m curious, what is the background of your question?
That datasheet is for the BNO055, which doesn’t have UART-RVC mode. The BNO08x have firmware from Hillcrest technologies which has the simplified UART-RVC mode. RCV mode seems ideal for AOG’s needs for terrain compensation, and super simple to use. I know a few people have talked about using the BNO080, and wondered if they had used this UART-RVC mode.
Here’s the datasheet for the BNO080, which applies to the BNO085 as well: https://cdn.sparkfun.com/assets/1/3/4/5/9/BNO080_Datasheet_v1.3.pdf. See section 1.3.5.
Hello,
I not sure to understand what you mean with:
I looked quickly the BNO085 datasheet. What I understand is that the UART-RVC interface is a simple way to receive from the BNO085 some datas (among them, eular angle), without using the Hillcrest’s SHTP protocol to communicate throught UART/SPI/I2C.
But the data provided by UART-RVC are still and output of the fusion algorithm (Hillcrest algorithm result) ? From a 9DOF IMU you need a fusion algorithm of datas from acc, gyro and magneto to provide orientation (throught quaternion or eular angle).
The BNO055 is already configured in NDOF mode by AOG arduino code. So the BNO already send the headin, roll and pitch angle to AOG. Without the integrated fusion algorithm of the BNO, you should run on your microcontroler an HARS/IMU fusion algorithm to obtain orientation angle from the acc/gyro/magneto raw output data.
But according to the wiki, the roll and pitch angle of the BNO is very unstable so it’s why isn’t use by AOG: http://agopengps.gh-ortner.com/doku.php?id=heading:start
I agree, this UART-RVC seems ideal for AOG to receive data from BNO: we can also imagine to connect the BNO055 directly to AOG via and UART to USB chip. And we reduce the latency of passing throught the arduino (like with BNO055) for transmiting angles. But I think we still need to implement UART-SHTP to configure the BNO at startup.
Andt for the pitch and roll angle, is the BNO085 more stable than the BNO055 ? According to the Adafruit presentation yes. But no real data to compare. Don’t know if we could expect to replace the BNO055 and MMA by one BNO085.
Durint the confinement in EU, I try to build a IMU base on MPU-9250 and an arduino which read the raw data from MPU and compute and open-source HARS/IMU algorithm ouputing quaternion and then convert them into eular angle and send them to USB. I obtain eular angles but never representativ of the real orientation of the MPU-9250. 
I think a problem of calibration. I’have never had the time to go futher. My idea was to provide heading, pitch, roll to AOG base on one unit.
Math
Yes I believe that is correct. That’s why this is intriguing to me, although I know very little about it. If all the various sensors can be combined (onboard 9dof fusion) into some simple euler or quaternion readings as RVC apparently does, that’s ideal for applications like terrain-compensation. If I read it right, UART-RVC does the fusion internally to provide the orientation, hopefully stable and accurate. Whether this includes automatic calibration of the magnetic compass to make the yaw/heading accurate, I do not know. Anyway the more the chip can do onboard without requiring external fusion algorithms the simpler.
1 Like
@Aortner did some tests with the bno080. Not sure how it goes in the field but he probably will share its outcome here 
1 Like
I do hope so. And I’m also interested in knowing if the simplified RVC mode is of any benefit to AOG for both terrain compensation and heading.
Hello,
What I understant is that UART-RVC is only a communication way to received the data computed by the internal fusion algorithm. But you can access to the same data trought I2C, SPI ou more conventionnal UART.
In fact BNO055 already has an fusion algorithm which provide quaternion or euler angle. I check the AOG Arduino code and the code read pich, roll and yaw computed by BNO055 throught I2C. But only yaw (heading) is used by AOG.
What I understand, the problem with BNO055 is not a difficulty to compute eular angle or reading this data, but a problem of stability of the roll value outputed by BNO055 (oscillating value or drifting value, not exactly sure).
So the problem is more to determinad if the unstability of the roll value of BNO055 is “solved” with the improved fusion algorithm of BNO085.
Perhaps we should realized a experimental test to compare the roll value of BNO085 to BNO055 (and MMA for having a validated reference).
Math
Whatever the case, if it was stable enough, it would be super simple to use it with AOG. An arduino could easily parse the UART text stream and send AOG the info. I’ll try to get a hold of one this winter later and see how it works.
Hi all,
I use the BNO080 on all my AOG setups here, using the Sparkfun library over I2C, pretty much a drop in replacement for the 055. See my other posts for technical details. I read off the quaternions then convert them to Euler angles on the arduino, using the heading and roll values for AOG.
It’s a really nice chip, gives a very stable heading and roll with no need for a kalman filter on the arduino.
3 Likes
Do you have your arduino code posted anywhere? The code that is in AOG’s github only has BNO055 heading only code in it from what I can see.
By the way the only difference between the BNO085 and the 80 is a firmware fix for an I2C timing issue that can affect communication with some microcontrollers.
Yeah here is my code, although it is still for version 3. It should be no trouble to just copy/paste the functions into v4 though.
1 Like
hi charles!
nice to hear from you again. long long time ago we did the newspaper thing 
just some questions:
why to you read quaterninos and why you not take sparkfun (get.roll, picht yaw)?
float roll = (myIMU.getRoll()) * 180.0 / PI; // Convert roll to degrees
do you calibrate the bno080 at start?
if have testet cmps14 works also very very good , is calibrated, and give you easy data acess.
regads andreas
Andreas! Great to hear from you too
I clearly didn’t read the documentation properly because I never knew getting the euler angles directly was an option. I agree it would be much more elegant to do it with getRoll()
I didn’t calibrate it, but it does auto-calibrate over time. I thought the heading doesn’t have to be exact as it’s fused with the GPS calculated heading anyway?
I see the cmps14 is based around the 080. What extra features does it offer? Is it just essentially a pre-calibrated 080 module?
1 Like
yes but the auto calibration did cause some problems with bno050 and reading roll. so it was not stable.
i think there are no major change between bno80 and 85.
what i see from the cmps module it is easier to use via some codings - you dont need a libaray.
with the pre-calibration the module is much more stable
1 Like
You mean that DCD should be disabled? 
Good news. For the application I haven in mind, initially I don’t really need any heading information. just roll mainly. Looks like it should work well for that. And it’s cheap. I’ve got two coming from adafruit to play with.
Gives you a decent heading reading?
What about auto calibration enabled?
Hello,
I have also received a BNO085. I’m also going to try it.
After reading a bit more about the documentation, I think i made a mistake in my previous post. For communication mode of the BNO085, we have to select it with P0 and P1 pin. By default it’s I2C.
With I2C (or SPI ou UART), we have acces to different reports of the fusion algorithms: Report Types | Adafruit 9-DOF Orientation IMU Fusion Breakout - BNO085 | Adafruit Learning System
It’s seems that all the report concerning the angle reports only quaternions: https://cdn.sparkfun.com/assets/4/d/9/3/8/SH-2-Reference-Manual-v1.2.pdf. So the Arduino code (or Sparkfun libray) had to convert it into eular angles.
While, with the UART-RVC mod, the BNO directly send yaw, pitch, roll (among other values), that is not the case with I2C, SPI, and UART.
I have also received an Arduino Du who has multiples UART interfaces: I will try the UART-RVC mod with it.
With Sparkfun librairie function myIMU.getRoll() (or myIMU.getQuatx()), have you an idea of which report (fusion algorithm output) you are dealing with exactly ? Rotation Vector, Game Rotation Vector, Geomagnetic rotation vector, other ? As in the setup we have myIMU.enableRotationVector(), I supposed that is for rotation vector report, but I couldn’t find a clear anser in the code.
The protocol to read data from I2C, SPI or UART is very particular for this chip (SHTP protocol), not easy: https://cdn.sparkfun.com/assets/7/6/9/3/c/Sensor-Hub-Transport-Protocol-v1.7.pdf
For sending roll to AOG, you send directly the angle value in degree on the serial port ? It’s that I understand from the line 576 of the Autosteer_USB4.3.10.ino. But I doesn’t understant where in the code the accelerations data of MMA8452 are converted in rotation angle ? Or the MMA1D.getRawData() give directly rotation angle (so it’s a data directly provided by MMA8452) ?
Thank,
Math
I just got my board in the mail today. I soldered the PS0 jumper so it will always run in UART-RVC mode. Then I hooked it to a USB to TTL serial adapter. Sadly it’s not working at all for me. The unit is dutifully cranking out information, but it’s nonsensical. Just sitting still on my desk it reports a continuously changing yaw (between -1 and -3 degrees), a pitch that seems to cycle between 4 and -4 degrees, and a roll that also cycles between -2 and -3 degrees. I can pick it up and rotate it and it doesn’t ever seem to change. The acceleration values are weird too. Z reports 9.5 to 9.6 m/s^2, which isn’t right at all. So strange. Maybe I have a dud. I’ve got a second one to try tomorrow I guess. So far it does not look promising. Eventually I’ll get an arduino hooked up with i2c and see if that works any better.
Using RVC because it’s brain-dead simple (in theory) and I can test it with simply a USB serial adapter on my computer. Perfect for my particular application.
I found the problem. My USB adapter was buffering the data and the Python demo script I was using had a sleep() call in it to only update 10 times a second. I assume on Micropython or on a Pi, this would work fine as the data that came in during the sleep would just be ignored/lost. But on my PC, it was being buffered. Anyway, I removed the sleep() and I can see I’m getting very good data now. I’ll probably want to do some averaging as at 100 Hz the data is quite sensitive to vibration. Not sure if using I2C would also require filtering.
Anyway it’s working quite well now, regardless of whether you want to use RVC or I2C. yaw, pitch, and roll all seem quite stable here on my desk. yaw (heading) is mostly stable, despite being on my metal desk where the magnetometer can’t get a real good reading so I assume it’s relying mostly on the gyro.