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:
Startup CMPS at different heading orientation: if at each startup, CMPS give a different heading → CMPS use Rotation Vector
Startup CMPS at different heading orientation: if at each startup, CMPS give 0° heading → CMPS use Game Rotation Vector.
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.
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.
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
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
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 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.
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.
I can actually because when it wasn’t drifting the heading from the BNO055 was absolutely fine. I used it for ages and didn’t notice an issue. It only came to light when I was doing a job that REALLY shows up errors. Maize drilling. The little 750mm spaced, 100mm wide rollers on fluffy ground make VERY obvious clearly defined lines. Even locked link arms spoil the lines as every tiny steer input is directly affecting the rows. The drift came from auto calibration and it happening during conditions that didn’t suit the process. This seemed to set off a drift scenario.
In rotationvector, with calibration on, with some hefty persuasion I’ve managed to get the BNO085 to do the same. As the CMPS14 is exactly the same sensor, with calibration on it will do it too, under the same circumstances.
Hello, I got a bno08x is the Chinese version, I attach an image.
Compile and import the .ino for bno080 that is in the forum that math left.
and it throws me an error that the BNO i2c does not detect, I connect it directly to the MMA, does anyone know what may be happening? or how can I validate if the board is not the problem?
