I would have never even noticed it if the roll correction with the CMPS wasn’t so good. if the bump was “slower” then it was the same amplitude, but quicker and you could just see the point to point limitation. I’m putting up the video right now on youtube.
Without the capability of graphing, it would be impossible to see if there is any filtering.
back and forth would be considered local coordinates whereas northing and easting are world coordinates. Terms like back and forth are pretty vague and i should not use them. swaying back and forth would be roll in this case. Rolling left to right is roll as well.
Hello @BrianTee_Admin
Ok thank for your explanation. UTM is the projection system used by AOG ?
So if I understand well, if you drive straight north, on a perfect flat surface, easting value will be a constant, like this:
Now, if you always drive straight north, but not on a flat surface (a surface where your tractor will roll left and right): theoretically, you should still have a constant for easting value, but du to the left/right roll of the antenna, you will have a oscillating value of Easting like this:
And what you does is using the roll angle from the roll sensor to correct the Easting value du to the roll of the antenna ?
Did I understand right ?
But in case of you are not driving straight to the north, Northing and Easting value shall be corrected with roll, right ?
Otherwise, about the use of the BNO08x, I was thinking about the use of Rotation Vector.
Adantage of using Rotation Vector is to have a heading normaly referenced to the north. But is it really useful for AOG autosteering ? Because, there is the following drawback with Rotation Vector:
On another side we can use Game Rotation Vector (that don’t use magnetometer). Advantage is that:
We only need to calibrate accelerometer and gyroscope, which is really easier.
In this mode, accuracy annonced by Hillcrest Lab is better in this mode:
The only drawback is that:
Heading is not referenced to north: is it really a drawback ?
A drift of 0,5°/min in heading is annonced. As I experencied in this mode, it doesn’t seem to have any influence on the guidance, and for @Alan.Webb too.
What do you think ?
@BrianTee_Admin would you do a magnet test, to check if the output that you use from your cmps, is of the rotation vector, or game rotation vector type
I’ve emailed Robot-Electronics UK about it. See what response I get! 
No effect with a magnet. It always starts out in random heading. Currently this isn’t an issue as the heading of the imu can be anything and gets corrrected to match the gps heading. You do need to drive a bit initially from cold start.
No mag, less problems.
So the CMPS14 isn’t using the magnetometer at all then? So it should be equivalent to the BNO085 directly in one of the modes that also doesn’t use it. Or am I getting that wrong?
Could the CMPS14 be using one of the AHRS algortihms with magnetic error rejection prior to the orientation calculations, such as Madgwick’s 2014 work? I would be suprised if Devantech market the CMPS14 as a tilt compensated compass if it doesnt use the magnetometer readings at all?
Hello,
I’ve no doubt that CMPS use the Rotation Vector repport from BNO080.
Rotation Vector report give an absolute orientation with heading referenced to north. CMPS is sold as a compass, so heading output is referenced to magnetic north.
In this mode BNO08x use magnetometer to measure where is magnetic north.
In Game Rotation Vector, heading is not referenced to north, because in this mode BNO08x doesn’t use his magnetometer. So in this mode, heading is referenced to where BNO08x was oriented at startup (At startup, BNO08x heading is 0°, regardless of where BNO08x is pointed). Move BNO08x orientation, start it up again and heading will be 0°.
Easy to check which of this report CMPS use:
@BrianTee_Admin has answered to this question:
BNO08x (IMU from CMPS) use Hillcrest Lab proprietary AHRS algorithms: so we don’t know exactly how they perform EKF. But result is the same as Madgwick’s 2014 work: given an absolute orientation.
Math
To add to your comment. Magnet sensitivity is not immediately apparent in RotationVector. I would guess it references the magnetometer periodically. When I tested it with a strong magnet, getting it to jump required persistence. This would also account for the periodic jumps in heading noted by some when using this mode.
From what I’ve discovered, GameRotationVector is totally unaffected by any magnetic activity.
This flexibility is the main reason why I chose the BNO085 over the CMPS14 despite what had been said here.
I’ve just received my i2c extender kit but with what I’ve discovered about the 085 and GRV mode it doesn’t seem necessary. Really no point in mounting it higher up, exposed to higher roll acceleration forces when it isn’t affected by it’s in cab environment anyway.
… but it’s a never ending learning curve!
Maybe jump is a program issue? perhaps when changing between 0 and 360?
I didn´t notice jumps as I am using Sim in the office.
I made an office test with Math´s Ino:Autosteer_USB_4.3.10_BN08x
Changing only between 1 and 0 in this line
Edit: Forgot to mention that background calibration is disabled!
/*BNO08x Overwrite by Math*/
#define BNO08x_ADRESS 0x4A //Use 0x4A for Adafruit BNO085 board, use 0x4B for Sparkfun BNO080 board
#define USE_BNO08X_ROLL 1 //Set to 1 if you want to use BNO08x for roll, else 0
#define USE_BNO08X_HEADING 1 //Set to 1 if you want to use BNO08x for heading, else 0
#define USE_GAME_ROTATION 0 // Set to 1 if you want to use Game Rotation Vector Report
#define REPORT_INTERVAL 40 //Report interval in ms
#define CALIBRATION 2 //Set to 1 if you want to enable gyro background calibration (not enable by default)
//Set to 2 if you want to disable background calibration for all sensors
When in Rotation Vector, I got an immediate reaction in AOG (of the I number) or the heading number if you choose to see it in the Module Info screen, when moving a magnet towards and away from BNO085
The I number changing from 334 when magnet 1 m away and continuously down to 329 when magnet 20 cm near BNO, and back to 334 when magnet at startpoint again.
And changing as soon as magnet starts moving.
I obviously found no affect of magnet in Game Rotation mode
Hello,
Yes, according to BNO08x datasheet, main reason for Game Rotation Vector: no use of magnetometer, so no effect of magnetic field.
Interesting. I’ve never tested with a magnet. I’m in holliday this week so cannot test to reproduce what you measure.
When I experienced heading “jump” in Rotation Vector, my magnetometer wasn’t calibrated (status unreliable) and default calibration was enable.
But something that I cannot understand: people using CMPS doesn’t seems to experimented same behavior with CMPS. But CMPS use magnetometer.
Only difference I can see: having a non calibrated magnetometer in my case or having background calibration enable in y case.
But as BNO08x datasheet said that “jump” could be experienced when using magnetometer, I don’t expect these 2 options to fix the problem.
Strange.
Agree with this advantage.
Not easy to find the “best” module: engineering choices are always compromises 
Math
It’s all really quite simple, you need a steady heading. How you get there, doesn’t really matter. Until we have a module that has 0 drift and perfect heading we will always need some sort of fusion to align the imu module heading with the actual gps heading.
Dual antenna of course gets around all those issues.
Just a thought, but maybe just delete everything that isn’t bno08x ? Since it is specifically for the 08x, it would greatly simplify the code.
Hello,
Guide updated in GitHub. Juste 2 remaining paragraph to write.
For this reason:
Just need to edit some test condition and go.
Math
Just put BNO085 into our setup, loaded the ino above and what a difference 10x better at driving onto and holding the line. The roll correction is definitely working too (can tell when it’s on and off). Will be interesting over the next few days when we get windrowing again.
Someone used any of these, in adafruit there is no stock and shipping to my country is 3 times the value of the plate.
GY BNO08X
PD: The CMPS14 is not shipped to my country.
If I remember correctly, the only difference between the BNO080 and BNO085 is an updated on-chip firmware that fixes a problem with SPI communication, which isn’t something we’re using anyway (we’re using I2C). So as I understand it, the BNO080 should otherwise perform identically to the BNO085.
Its even the same hardware as the BNO055 if you can believe it!!