Isn’t the sparkfun BNO080 library pretty small? It’s compatible with the 085 also. Will definitely run on a 328.
The sparkfun library works absolutely fine with the 328.
Hello,
@BrianTee_Admin, very interesting results. If I understand well, you obtain this by translating BNO080 on a flat surface (following x and y axis) and rotation aroung Z axis ?
Your BNO080 was calibrated following Hillcrest procedure with Sparkfun calibration code ?
Few weeks ago, I log data from my comparativ board with MMA, BNO085 and BNO055 when driving my car. Board was positionned, such as roll measurement from BNO085 and MMA correspond to the pitch of the car. Here the result of the first log:
In zooming on roll measurement, we saw that I perhaps catch the same phenomen that you show before. By example where I put some marks. We can see:
- A pic variation from MMA and BNO085 roll
- A pic variation from BNO085 pitch
- This corelated to heading variation.
I didn’t pay attention to that before because I add the same measurement on MMA and BNO085. As I’ve no other references I cannot check if it’s a real car movement or not. So I suppose if both catch them, it’s a real measurement.
But: when I do this measurement, BNO085 was not calibrated (because I never obtain a good calibration status). I could why I add this and @Alan.Webb doesn’t see this phenomen.
And: I don’t understand why I will also happen on MMA measurement ?
@Alan.Webb Thank for your answer, I will try angain calibration on BNO085.
I will also add the possibility to disable calibration in my code. What sort of problem do you encournter ? Drifting ? When I look on my log, I cannot see drifting of roll between MMA and BNO (background calibration for acc and magn was enable).
Agree with that. Not easy job, lot of test to do, and we never had a reference to compare the measurement.
BNO08x has an output report call “Game Rotation Vector”, thas output yaw/pitch/roll without the use of magnetometer (so heading is not referenced to north). Perhaps we shall use this mode ?
Do you know if there is an equivalent with CPMS ?
Math
I saw the classic BNO055 type yaw drift despite heading in a straight line, or standing still. With the 055 it would nearly always work fine for a while then randomly start drifting for no apparent reason. An issue when it re-calibrated I assume.
I’m hoping to get out and do some more testing in the next few days.
Pretty certain that is what I was using when I tested it a few days ago, with the magnetometer turned off. Well at least I thought I’d got it off!
I found with the BNO085 I could run significantly more aggressive steer settings and AOG behaved really well, despite a really rough wet maize field.
Ok. It that i saw on my measures (previous posted graph), by exemple between sample 4000 and 7000, BNO055 is constantly drifting while BNO085 is straight.
I’ve updated my .INO: you can now select to disable all background calibration:
https://1drv.ms/u/s!At0hnqbQtv42pVtYpDwNU0x2fiqq?e=UCKrPN
About memory of the 328:
17,728Mo (57%) of ROM vs 12,116Mo (39%) for the standart AOG INO.
1,156Mo (56%) of RAM vs 0,709Mo (34%) for the standart AOG INO.
So fully compatible with 328 µC, but not insignificant in terms of space memory occupation.
Math
1 Like
The thing i like about the CMPS, you just hook it up and go drive.
I agree @BrianTee_Admin . The only issue would be if it transpired for best operation we needed to alter configuration that isn’t available via the CMPS14’s additional microcontroller.
To be fair, apart from getting the library there isn’t any more to the BNO085 breakout.
1 Like
Just a heads up for future releases, the imu will be a module on its own. That way you can use any imu from the past current or whatever comes up in the future. No longer will be connected in any way to the autosteer module.
All designs will just be required to send the correct pgn - which is really simple - just heading and roll at 10x as signed integers. Super simple.
An example. cmps14_i2c.ino (1.3 KB)
9 Likes
Hello,
Agree with that too. So bad that they don’t give more information about how their product works with the embeded BNO (what report they use etc…), improvement they do (except factory calibration).
It’s mean that IMU will be managed by a separate Arduino, connected by USB or UDP to AOG ? I think it’s a really good choice. As you said, IMU can evolve without impacting PCB autosteer. So we get closer to a board that treat GPS + IMU data and send them to AOG as we discuss on telegram 
.
Math
2 Likes
The only thing I’ve found is this in an .ino file from a Uk based company that is using the CMPS14. Does this ( 4 and 5) suggest how the CMPS14 filters the BNO085 output, or are they just describing standard BNO085 output. I get a little lost in data sheets sometimes! 
// Register Function
// 0 Command register
// 1 Compass Bearing as a byte, i.e. 0-255 for a full circle
// 2,3 Compass Bearing as a word, i.e. 0-3599 for a full circle, representing 0-359.9 degrees. Register 2 being the high byte
// 4 Pitch angle - signed byte giving angle in degrees from the horizontal plane, Kalman filtered with Gyro
// 5 Roll angle - signed byte giving angle in degrees from the horizontal plane, Kalman filtered with Gyro
I have noticed in the BNO080 datasheet that calibration is by default set to on in all modes except robovac mode.
I posted an ino just up a couple
Yes, I saw that. I was referring to the comments in this .ino stating the roll is Kalman filtered with the Gyro. My point was, is that suggesting how the CMPS14 post processes the BNO085 data. On the face of it he CMPS14 output looks very similar to the robovac output. Robotshop do not seem to elaborate on what, if anything they actually do to the output data.
Is this the datasheet we are talking about?
That’s the one I was reading yes.
Hello,
Yes but, not all calibration enable. By example, in Rotation Vector, only accelerometer and Gyrometer acceleration are enable by default.
In RVC mode, a specific calibration for accelerometer is enable, call “planar calibration”.
I think CMPS doesn’t use this mode. In this mode, yaw value is not referenced to north (not a real heading). CMPS is a “compass”, so yaw should be referenced to north. They probably use Rotation Vector Data.
Math
I would agree. We will never know exactly how the CMPS works,
Hello,
Agree too. Most important is how it’s perform.
I’ve done some test: violent translation along Y and X axis of my “comparative board” on the planar surface of the desk and rotation arround Z. With the board non calibrated. I never obtain a roll variation arround +/-8° (whereas it’ should measure 0°). More something arround 1°.
Finally, I succed to calibrate the BNO08x, do the same test again, quite the same result. So no influance of the calibration on the roll results:
But now, North of the IMU seems to be more correlated to magnetic north.
According to the BNO08x datasheet, we are in the accuracy of the BNO08x:
Also, Game Rotation Vector doesn’t seems to be usable for Yaw du to the drift (0,5°/min).
Math
Is that level any issue to us? I doubt it?