Stange. BNO085 is not on the tractor: he is on a board in my lab, so I can do all the movement I want to do. Although I made a lot of rotation arround x, y and z, like requiered in BNO08x qualibration procedure, I never got anything else than “unrealiable” for magnetometer.
Just to be sure, I spoke of this parameter (the second, with value at high is for acc and gyro calibration):
Not very clear what CPMS use for the factory calibration: BNO08x embaded calibration or an additionnal calibration in the PIC embeded in the CPMS ?
But BNO08x calibration procedure said about magnetometer:
“The magnetometer calibration process will calibrate for the unique magnetic field affecting the environment in which the calibration process takes place. This includes components that affect the magnetic field in the headset itself (soft iron effects) like batteries, and objects that affect the magnetic field around the user (hard iron effects) like metallic furniture or speakers. For best performance, it is recommended that the end-user performs a similar magnetic calibration procedure when they start using the device in their home and any time that they significantly change their environment (e.g. after moving the device to a new room) if Rotation Vector is used by the applications.”
So even if the CPMS is submitted to a factory calibration, the magnetic fiel at the factory calibration is very different at each of our final BNO08x location. So for me, not really surprising that CPMS north isn’t real north. We should make a local calibration for magnetometer for CPMS too I think.
But currently, if I understand correctly, AOG use relative heading value from IMU. There would be a real advantage to have a IMU with a north correctly oriented to magnetic north, compare to the current solution ?
GPS heading is referenced to geographic north, while a correctly calibrate IMU heading is referenced to magnetic north. So GPS heading and IMU heading aren’t referenced to the “same north”, and as we are user from all arround the world magnetic declination is different for all of us (1° where I live, but 20° on Canade west coast).
IMU fusion with GPS is difficult even for the experts. Using the adaptive complimentary filtering works pretty good - but 1000x times beteer with the CMPS14. When you are standing still, it all freezes anyway and the CMPS doesn’t change either. Corrections are done fairly quickly in AOG so all we need is a fairly stable heading. With the BNO055 or brick, the thing would drift at times faster then the fusion could eliminate the error. But if it was stable ish, the filter worked well.
The other part was roll, which is dreadful on the 055, but rock stable AND fast on the CMPS. Unaffected by vibration as well. The only “problem” is going around turns, the roll increases several degrees. Not exactly a problem as the roll calc then will help with sideslip values.
I check CMPS on the table at home and Roll works very well. IMU keeps changing decimal point within 1 degree, is it correct?
There is one more strange thing: I checked the CMPS at home using the original NANO, the roll and IMU worked, I connected to another original NANO in the tractor box and the IMU stopped working. I was looking for reasons and it turns out that with one NANO IMU it works not with another.
The difference between these two NANOs (both original from the same batch) is that one connects to the PC as COM6 and with this IMU works and the other connects as COM 56 and does not work with it.
I drove around the field with CMPS 14 mounted. The field was very uneven, frozen, uneven after cultivation with a grubber. The AGO kept the line straight, but every now and then, every 3-4 minutes or every few hundred meters, a sharp swing of the course appeared, which resulted in a shift of about 0.5 m from the line and a quick return.
The AgIO has a filter algorithm is implemented to correcting the heading. A few days ago, I got similar a signal to your result. Or it seemed like sine/cosine. I am not sure if it is correct to provide raw Euler angle data on CPMS14 to the pivot axle heading directly.
Could that be something electrical affecting it or is re calibration on? I’ve not tested a CMPS14. I’ve got the Adafruit BNO085 breakout.
With the magnetometer on, I once had my lights pull the heading way off course. I have the magnetometer off now. Not tested it properly but nothing seems to bother it now.
Here is my edited version fo Autosteer_USB_4.3.10.ino to use BNO08x with AOG.
It’s based on previous code posted, but with some improvement in the .ino and in the Sparkfun Library:
I add in the library the possibility to plot the current calibration configuration
When we enable a BNO08x report, the BNO08x respond with a report to confirm the correct activation of the report: I add functions to retrieve this report and check if the report is correctly enable
The code is available in the following zip (I would see later to put it on GitHub): https://1drv.ms/u/s!At0hnqbQtv42pVtYpDwNU0x2fiqq?e=oexJXw
All edited line are identified with a comment starting by “Edited by Math”, so you can easily found the edited lines.
The code let you choose if you want to use BNO08x instead of MMA, or instead BNO055 or instead of both (so you can easily switch from one module to the orther if you want to make comparativ test). So at the begining of code you have a config zone with:
BNO08x_ADRESS: adresse of the BNO, 0x4A for Adafruit BNO085 board, 0x4B for Sparkfun BNO080 board
USE_BNO08X_ROLL: set to 1, it will force the .INO to use the BNO08x for roll instead of MMA/DOGS2 (regardless of the Inclinometer you have choose in AOG module configuration page)
USE_BNO08X_HEADING: set to 1, it will force the .INO to use the BNO08x for heading instead of BNO055 (regardless if BNO is selected or not in AOG module configuration page)
REPORT_INTERVAL: if you want to change report interval of the Rotation Vector report, for advanced users
ENABLE_GYRO_CAL: set to 1 if you want to enable the background gyroscope calibration. By default background calibration is enable only for magnetometer and accelerometer. If you set this parameter to 1, during the setup, the Arduino will check the BNO08x background calibration enable and print it to the serial port, so with a serial consol you can check if the calibration are correctly enable
Even if you choose to use BNO08x for roll, in the AOG module configuation page you can still choose the inclinometer axis: the MMA axis selection, will change the BNO08x axis use for roll. If you need to inverse roll value for BNO08x, you just have to activate “invert roll” in AOG module configuration page.
The code is made so that, if we want to add BNO08x as an official alternativ of MMA/BNO055, I can be easily edited to treat BNO08x as additionnal option (we just have to define the corrsponding value for aogSettings.BNOInstalled and aogSettings.InclinometerInstalled).
Finally have the BNO080 and the CMPS14 on the same board with a nano. So guess which one is the clear winner? (The line should be straight like the blue one. )
The blue is probably the CMPS14, if it follows what you have been testing earlier. Too bad I have already got the BNO085 before this
But what exactly did you do with the board, while performing this test ?
Hope there is a way to make the BNO perform better.
The roll seems to take off as you rotate the board - like steering. But oddly it takes a while to settle back to where it should be at 0 again. The roll follows each other with noisy and rapid movement etc. It responds very quickly.
On a development forum such as this a little more information would be good. If that is roll then something is set up wrong. I tested the BNO085 on the bench with very very violent horizontal movements on a flat plane and roll didn’t move one tiny bit. Neither did yaw, if I slid the sensor sharply back and forth along a fixed straight edge.
Not sure what your testing involved there but something seems wrong.
They are basically both the same sensor, with the same Hillcrest firmware after all.
I may be wrong but, given the basically identical price point I would guess all that the cmps14 has extra is i2c conversion to standard protocol and maybe a standard setup that serves it’s target usage to the detriment of flexibility.
I would be leaving background calibration turned off. In the tractor with it turned on I got basically exactly the same problem that the BNO055 has. Drift after calibration.
