You made me curious … I just ordered it!
Hello,
Perhaps one advantage I see to connect it directly to the PC, it’s that if AOG could acces directly to yaw & roll the delay for acquiring this data is reduce (compare to actual MMA / BNO055 who are read throught I2C by Arduino and then send to serial to AOG.
Don’t know if reducing this delay could be benefict for AOG for guidance precision ?
Why did you disable the background calibration ? Did you observ a negativ impact on BNO precision du to the background calibration ?
I’ve try the BNO085 in RVC with my Arduino Due: BNO085 connected to UART1 on the Du, data send by the Due to PC with UART0.
In RVC mode, in accordance with the datasheet, the Yaw value range is [-180°;180°], as you can see on the following picture (transition -180°/180):
Also according to the datasheet, the yaw in RVC mode is not referenced to magnetic north: 0° is the yaw at startup of the BNO085. So the 0° yaw change at every startup of the BNO.
Here is an exemple:
_ I positionned the yaw to 25° during the current run (first next picture)
_ I shut of the boards and restart them without moving them: yaw is now 0°
For me, the way that AOG currently use the IMU heading (not using the absolute value but the relative value to fuse it with GPS absolute value for having a more responsiv heading), having a heading not referenced to magnetic north is not a problem.
But I don’t know if having a true, precise and stable heading referenced to magnetic north from a IMU could improve the guidance precision compare to the actual heading fusion system ?
Next step I made a test on the pitch.
BNO085 laid on my table, the pith is 0° (first next picture). So in inclined him to 20° (second next picture). Then I shut-off and again shut-on the boards (still inclined to 20°). The pitch outputed was still 20° (third next picture) and the yaw was back to 0°, to show the shut-off/shut-on sequence.
As we can see on the previous graph, yaw pitch and roll seems to be very stable.
Next I try to generate an vibration environment: by punching on the desk trought Z axis (first next picture) and Y axis (second next picture). Not a rigorous vibration test method, but I haven’t a shaker to generate proper and repeatable sinusoidal vibration. And it seem that even if I “punch my desk to Y axis”, he is more resonating through Z axis (but logical given the configuration of my desk).
The pitch and roll values seems to be still very stable.
I reaped the experience but only with plot of roll, to have a better zoom on it. First next picture is without vibration. Second next picture is with punch on my desk.
Still very stable, I think less than 0.5° of oscillations.
So what I plan to do next:
_ Doing the same sort of test but by reading the datas comming from Absolute Orientation/ Rotation Vector and see the impact on the datas to compare with the RVC mode (and perhaps try other reports available on BNO). And also see the influence of calibration.
_ Records datas into a log so that it would be easier to make some errors calculations on it with Excel by exemple
_ Building a test board and put on it MMA8452, BNO055 and BNO085 to makes some tests and compare the result of BNO085 vs BNO055 + MMA (with AOG Kalman filter) on same situations. With the possibilty to visualise data on the screen and record them in same times.
I’m in hollyday next week, so I hope I will have the time to do that.
_ Also, we have to think how making an “endurence” test, like shaking and making BNO085 turning during a few hours and see if it’s drifting.
But BNO085 look really promising in order to replace BNO055 and MMA8452.
If BNO085 is relevant fas an alternativ of MMA & BNO055, we also have to discuss with Brian how to integrate it in AOG project:
_ With a dedicated Autosteer_USB.ino with BNO085 (could be that until the next version of AOG)
_ With a modification of the current to Autosteer_USB with addiction of BNO085 as an selectable alternativ of MMA and BNO055 which implies and update of AOG for the module configuration page (could be implemented to the next AOG version)
_ Or with an introduction of UART-RVC mod in AOG (if this mod is relevant)
_ Or we can also imagine a total different way: making a bord with has on input the NEMA data and the BNO heading/roll, proced the data and send to AOG GPS coordinate (NEMA or POGI sentence ?) corrected with roll and heading (something like the dual antena configuration).
Math
Full size pictures available here: https://1drv.ms/u/s!At0hnqbQtv42pBLIlnm2mpBTmmiU?e=BGK1bC
3 Likes
Very interesting. Thanks for doing so much testing. Results look promising for both heading and pitch/roll. I’m definitely going to try using it to do terrain compensation for an unrelated GPS project I’m working on.
I suspect performance would be the same whether you’re using I2C or RVC over UART. I did not mess with calibration since, as far as I can tell, RVC doesn’t offer any such thing. Perhaps I’m mistaken.
I do not know if RVC directly to the AOG computer is a benefit, vs the arduino getting it over I2C and communicating that to AOG. I suspect he latency would be similar.
So in RVC mode at 100 Hz you showed the affect of vibration and hitting the desk on the unit. Would we want to average the numbers out over a period of time? I mean we’re only going to be doing compensation at most 10 times a second. Perhaps we could average ten readings? When using the I2C protocol, if you fetch the roll, for example, is it roll at that instant, or will that have some kind of short-term averaging there?
Hello,
Conclusion afert reading BNO085 datasheets and referenced documents: SHTP protocol is really more complicate than a classic way to communicate throught I2C or SPI 
. Fortunately we have the Sparkfun library that makes the job, implementing SHTP throught I2C (or SPI) by ourself would have been painful ! Sparkfun library is limited to I2C or SPI communication but not UART.
Adafruit provide a library to communicate trought I2C, SPI and UART, but not as easy to use than the Sparkfun. And when I try to compilate the Adafruit library for Arduino Nano, Arduino IDE said it use to many space on memory. So not usable for AOG. So despide I made tests with an Arduino Du, I use the Sparkfun library to communicate throught I2C.
Adafruit provide a specific library to communicate trought UART-RVC mode: I use it when I communicate throught UART-RVC mode.
In non RVC-UART mode, all communication between BNO085 and host (like Arduino) is throught “reports” sends on the bus. Repords may have a different form depending of the data send to the BNO or the data send by BNO to the host.
When we configure a sensor report like “Rotation Vector”, with a time interval (like 50ms), the BNO085 “send” the report to the host every 50ms. BNO085 generate an interupt to the host to inform he is read to send a report. It seems that the interupt is necessary for a propoper SPI or UART functionning. But not requiere for I2C functionning. In I2C we can just send a “read request” on the bus to see if a new report is available.
But what is not cleary for my: if we miss a “sensor report”: what happens: the repport is lost or buffered ?
Yes, in UART-RVC mode, you don’t have any control on the “Dynamic calibration” oparate continusly by the BNO085. But in this mode, the “Dynamic calibration” is oparated in a special mode for the accelerometer call “Planar accelerometer calibration”. According to BNO datasheet, this calibration mode is “a planar calibration for devices that are constrained to move in a plane (such as a robot vacuum cleaner)”. No more detail about how it’s operate and I don’t know if it’s relevant for a tractor ? A tractor always operate on a planard surface, but this surface could be incilned (not perpendicular to the gravity vector). A Robot Vacuum Cleaner probably operate 99% on a planar surface close to be perpendicular to the gravity vector. But it’s not the case for a Lawn Mower Robot. So don’t know… Perhaps we could directly ask to Hillcrest Lab ?
In non RVC mode (I2C, SPI or UART), you can configure the “Dynamic calibration”. You can chose for each sensor (Mag, Gyro and Acc) if you enable the “Dynamic Calibration” or not. And for the Acc, you can chose between “a full 3-dimensional approach for devices that can move in freely in space and a planar calibration for devices that are constrained to move in a plane (such as a robot vacuum cleaner).” (by default, it’s full 3-dimensional approach).
Note: by defaut, when you enable the “Rotation Vector Report”, the “Dynamic Calibration” for the gyro sensor is disable. BNO085 provide recommendation to see if we can enable the “Dynamic Calibration” of the gyro (see §3.1.3 & §3.1.6 of datasheet). Again don’t know if this apply to a tractor: we have to test in the field with and without “Dynamic calibration” of the gyro.
Don’t know to. I think @BrianTee_Admin is in the best position to answer to this question.
Other question about RVC mode I can’t find the anwser. In RVC mode, is the BNO085 using magnetometer ?
In non RVC mode, we can enable a report call “Game Rotation Vector”. This report send Yaw, Pitch and Roll, but base only on the Acc and Gyro (Magn is disable). So the Yaw hasn’t a specific reference (not referenced to the north, perhaps referenced to the BNO085 orientation at starup). Looks like UART-RVC mode, so it’s why i’m wondering. But in “Game Rotation Vector” mode, du tu the non use of magn, the datasheet said: “Long term the output will likely drift in yaw due to the characteristics of gyroscopes […]”
Depending on what means “long term”, it could be ok for AOG, as for now he don’t use absolute heading but relative heading.
In “Rotation Vector” report, Yaw is referenced to the North. But according to BNO085 documents, to be effective, we should calibrate the BNO085 in the magnetic field where he is going to operate (in the box, close to where the box will be in the tractor). Again as AOG used relative heading from INO, perhaps it does’nt matters.
Don’t know if it would be an improvement for guidance if we have acces to a stable heading referenced to north usable as absolute value ? Specialy if we take into account that (I think) GPS give a heading referenced to greographic north: where I live magnetic declinaison is 1°, but in some places on the earth like North America it could be 30° or 40°.
So the way we use the heading can really influance on how to setup BNO085 parameters, reports and needed calibrations.
Yes in UART-RVC we can avarage values but two difficulties for me:
- Arduino Nano as only one UART use to communicate with AOG
- Don’t know if the Arduino will “have the time” to acquire BNO085 data at 100Hz, averaging them and in the same time doing all other calculations for steering.
So, In my opinion if we want to do that, we need a second “Slave Arduino” dedicated to aquire the UART-RVC datas, average them and send them to IC2 to the master Arduino with steering algos.
I think in a first approach, it will easier to use I2C: BNO085 could be insert in current PCBv2 and we have acces to the whole possibilitys of BNO085 configurations for our application.
I’have made some test yesterday to try the differences between UART-RVC mode and “Rotation Vector” throught I2C. First at stable position (BNO085 fixed on the desk).
Here is the angles values reported in UART-RVC mode (Yaw at 0° as the BNO don’t move):
Here is the values reported in I2C mode (Yaw not to zero, but I haven’t the mean to check the error compare to the real magnetic north).
With only Pitch and Yaw:
Seems close between UART-RVC mode and Rotation Vector.
So after I made a log of datas of each mode during ~1min. As UART-RVC mode operate at 100Hz and on I2C I had a value every 50ms, I have more datas in the UART-RVC mode on the same time period.
Here is the results of I2C mode:
- Yaw: 78,3° for all datas
- Pitch: -0.1° for all datas
- Roll:
Mean: 0,54°
Here is the values for UART-RVC mode:
Mean: 0°
Mean: 0.60°
Roll: -0.13°
I discover after: Pitch for UART-RVC mode = Roll for Vector Rotation mode = rotation arround X and vice versa.
So the values in the 2 modes are quite the sames. In I2C Rotation vector the data as a résolution of 0.1° (vs 0.01° in UART RVC-Mode) due to a rounding in the code: it explain the biggest dispertions UART-RVC mode despide a low min/max values. I will delet this rounding for the next tests.
I faced a “bug” with the UART of the Due that conducted to failled all the other datalog that I try to make. Don’t unsternd why, I have to solve it before making new tests.
But as I didn’t see big differences between the 2 modes, I will focus on I2C operation, where I can acces the whole BNO085 configuration possibility and calibrations.
Math
2 Likes
Will you mount the BNO085 in the cab (I2C requires short wires)? Will be interesting to see how the yaw works in that environment.
You can easily get a couple of metres out of I2C if you’ve only got 2 nodes and you’re somewhat careful about what wires you use (thin gauge, unshielded).
My BNO is mounted against the door pillar, a couple of feet of wire away from the main box
Hello,
I would like but unfortunately, I’m confined 200km away from my father farm. We are confined until (in best case) 01/12 in France. I could make tests with my car but not as representativ as a tractor and I’ll be limited in term of possibility of maneuvers compare to a tractor in our field.
So it’s why I’m focused to fully take in charge the functionning of BNO085 and it’s specific protocol and why I’m limited to laboratory test.
I’have edited the Sparkfun Library to add the possibility to display the BNO085 “ME Calibration Response Report”. When we send a “Configure ME Calibration Command Report” to configure the Dynamic Calibration of the BNO (or following a Get ME Calibration Command Report send to the BNO to ask him to give it current calibration configuration), BNO085 respond with a “ME Calibration Response Report” to give a feedback of the calibration configuration. Original Sparkfun library doesn’t have the possibility to catch and display this report: it’s why I edit it because before making some test, I want to be sure which dynamic calibration are currently enable.
I try to calibrate my BNO085 with the Sparkfun dedicated sketch and by applying the calibration method givent by hillcrest lab. But I never succeeded to calibrate the magnetometer. I open a topic on the Sparkfun forum about this to see if they have a solution: BNO080: impossible to have a complete calibration - SparkFun Electronics.
I run the BNO085 “Rotation Vector Reports”, that should give me a heading referenced to the north. But when BNO085 give me 0°, he clearly doesn’t point to north.
So if in lab it’s already difficult to calibrate the heading, I am not confident to be able to calibrate it in a box in a tractor. Will see if I had a response on Sparkfun Forum, but if not, we will have to keep using heading value as a relative value.
I will try to make a breadboard with BNO085, BNO055 and MMA8451 (have only MMA8451 from Adafruit at home) and try to compare their output.
Math
3 Likes
Hello,
My comparative breadboard is operationnal.
The INO to retrive datas from BNO085, BNO055 and MMA8451 is also operationnal.
For MMA8451 and BNO055, I just copy/past the code from AOG INO Autosteer_USB_4.3.10. So the filtering is exactly the same: same Kalman filter for MMA8451
Here is a first comparativ of roll datas, between BNO085 and MMA8452.
Board stable on the desk:
Board always on the desk, when “punching” the desk:
When inclinate the board:
Again, board stable on the desk (without punching the desk):
First impressions:
- BNO085 roll output is really less noisy, specialy under vibrating environment.
- BNO085 seams to have less delay
I will see tomorrow to make some datalogs that we can plot into Excel to make some maths.
Is there some people who are competent in Scilab ?
I think it would be better to plot the graphic with this software: we can zoom/unzoom, move insinde the graphic, so we could easier visualze the datas, specially with a long run of data. That not possible with Excel.
I learn Scilab (and MathLab) at engineering school but as I never practice then, I forget everythings.
Just to be sure that I have make mistake when I copy past the AOG algorithm part for MMA: the MMA output is saturated at 16.37°, I never paid attention to that. Some can confirm that I has the same saturation with PCBv2 and AOG ?
Thank,
Math
Full size picture always available on my Onedrive link mention on one of my previous post.
4 Likes
Nice work and testing 
It has been so for a long time, so I believe that is a limit Brian has put in the code, either in AOG or ino,
Yes , there is a limit in pcbv2 code :
//16 counts per degree (good for 0 - +/-18 degrees)
if (roll > 4200) roll = 4200;
if (roll < -4200) roll = -4200;
1 Like
Thank Tooki57,
I copy/past this code but I I did not pay attention to the comment.
Math
Hello,
Some other results.
By doing some “planar translation” of the breadboard on the desk, so no rotation applied to the board and the vibration applied to the board was only du to my “hand tremor”, I obtain a lot of noise on MMA roll output:
When doing some tests I also catch some stranges behavior of BNO055.
Here a suddenly drop of the BNO055 heading while I was only aplyinng a pitch angle on the board (you can see that the BNO085 yaw is stable):
Here other strange behavior of the BNO055, when I made some other measurement that I treat into Scilab:
Now I treat the data log into Scilab (Scilab is a free and open-source, cross-platform numerical computational package made by a French Instutute, a equivalent of MatLab), who is more suitable than Excel to do this kind of job. Particulary, we can zoom into graphs, move insite the graph etc… So really more pratical specially for long datalog.
From the same datalog than previous, the plot of the roll only:
I made a modification on the .ino: BNO085 output heading in a range of [-180°;+180°] (even if in Rotation Vector Mode) and counter clockwise (positive value when turn counter clockwise) , so now the .ino scale it into [0°, 360°] and clockwise.
Now BNO085 and BN055 has both the same output type for heading. Each has is own North reference, none is pointing to the good magnetics north !
If some of you are interested, I can share the graphic file: you just have to open them with Scilab, no specific manipulations required in Scilab.
I think I’m going to go for a drive (~1h) with the board inside the car, make a log of datas and plot them to have a test more closed to a tractor environment.
For now, we can said that the BNO085, is really less noisy than the MMA for roll datas (I think it’s du to the benefic of the fusion of accelerometer data with gyroscope data). But the oppening question for me is still:
- Is the BNO085 for roll data is drifting over the time ? And I have not a clear idea how to test that ?
- All my test was done with Dynamic Calibration enable on accelerometer and magnetometer (defaut when the Rotation Vector mode is enable): activate the gyro dynamic calibration will improve the roll output or will it introduce some drift ?
Math
8 Likes
Very interesting and scientific! Well done!
Hello,
Thank a lot for all your encouragement.
Last monday, when I went to food shop, I take my board in my car (my girlfriend think I went completely crazy 
) to records some datas. The board was positioned in a way that the “roll axis” of BNO085 & MMA are measuring the pitch of the car (mutch more pitch variation on the road than roll). Consequence: the heading measure by the BNO085 is the reverse heading of the car. I made a mistake when I positionned the BNO055 on the board. So BNO055 heading is looking on the right direction of the car.
I just have the time to retrieve the data log. Here is the “raw graphic” ouputed from Scilab.
I will deal with them in more detail this weekend.
What we can quickly observe:
-
There are some phases where BNO085 is outputed a constant straight heading, while the BNO055 heading is drifting
-
Between the 2 logs, le board wasn’t shut-down: at the end of the last log, the delta value between the BNO085 and MMA seems to be the same. So It’s seems that there is no drift of BNO085 during the run (1h00).
Math
9 Likes
What about FXOS8700 + FXAS21002?
Looks like FXAS21002 obsolete.
What about ICM-20948?
It is successor of MPU9250 widely used on copters.
I glanced over the specs and the Sparkfun library and example code for the ICM-20948. I’m sure you could probably use it, but it does not do any fusion of the various data sources, so you’d have to do that yourself. For example, the gyro will drift and thus you won’t have a heading that stays stable, corrected by input from the accelerometers and magnetometers as the BNO08x series seem to do. In my opinion the BNO08x would be simpler and more appropriate for AOG application, but i don’t really know that much about it compared to @Math!
https://openimu.readthedocs.io/en/latest/apps/ins.html
Very interesting project. But costly and fusion lib are closed source.
@Math this is very interesting as I’m sure the only things that causes my AOG issues are heading and roll. As soon as I run on smooth level fields the thing is really stable. Which BNO085 board are you using? I will get one and see if I can get it working with my AOG.
1 Like
More one interesting project:
Also they tested MMC5983MA with even better accuracy: