Is there any reason to get the BNO080 when the BNO085 is available with the latest firmware? Of course the only breakout board I’ve seen with the 85 is from Adafruit currently.
The 085 is the same chip i am pretty sure but with all the “consumer” algorithms like step tilt shake etc.
Hey Simon - did you try the serial Robovac mode that comes out on serial? it spits out exactly what we need 100x per second in 1/100 decimal accuracy. HEading, roll, pitch…
Header: Each report is prefixed with a 0xAAAA headerIndex: A monotonically increasing 8-bit count is provided (0-255) per reportYaw: The yaw is a measure of the rotation around the Z-axis since reset. The yaw has a range of +/-180 ̊and is provided in 0.01 ̊ increments, i.e. a report of 8734is equivalent to 87.34 ̊.Pitch: The pitch is a measure of the rotation around the Y-axis. The pitch has a range of +/-90 ̊and is provided in 0.01 ̊ increments, i.e. a report of 1072 is equivalent to 10.72 ̊.Roll: The roll is a measure of the rotation around the X-axis. The roll has a range of +/-180 ̊and is provided in 0.01 ̊ increments, i.e. a report of 1072 is equivalent to 10.72 ̊.X-axis acceleration: The acceleration along the X-axis, presented in mgY-axis acceleration: The acceleration along the Y-axis, presented in mgZ-axis acceleration: The acceleration along the Z-axis, presented in mgReserved: The message is terminated with three reserved bytes, currently set to zeroChecksum(Csum): The Index, yaw, pitch, roll, acceleration and reserved data bytes are addedto produce the checksum.To determine the actual orientation of the module, the rotations should be applied in the order yaw, pitch then roll.An example complete message and checksum calculation is as follows:Message: 0xAAAADE 01 00 92FF 25 08 8D FE EC FF D1 03 00 00 00 E7Where: Index = 0xDE = 222Yaw = 00.01 ̊ (1= 0x0001)Pitch= -1.10 ̊ (-110 = 0xFF92)Roll = 20.85 ̊ (2085 = 0x0825)X-acceleration = -371mg= -3.638 m/s2(-371 = 0xFE8D)Y-acceleration = -20mg= -0.196 m/s2(-20 = 0xFFEC)Z-acceleration = 977mg= -9.581 m/s2(977 = 0x03D1)Checksum = 0xE7
Is the ol’ Nano going to handle 100hz? Maybe the new pcb is moving to something faster…
No Brian, didn’t try the Robovac mode.
I really didn’t pay much attention to it, because I read in the datasheet:
For general applications that require motiontracking in a relatively stable magnetic field it is recommended to use 9-axis sensor fusion outputs (Rotation Vector –see section 2.2.4) from the BNO080.
Because I thought the magnetic field was very imporant, I opted for the Rotation Vector option.
Since that seemed to work quite well, there was no need (and time) to try anything else.
Perhaps I was too focussed on the magnetic field, probably if you place the sensor near electric
leads in the cabin that’s not such a good option, but mine is outside in the open.
Directly into aog is an option…
Do you know if auto calibration is by default on or off with the sparkfun library?
By the calibration example ino I would guess it’s not on by default but I’m not sure.
I’ve added .calibrateAll() and .endCalibration() to the BNO installed part of the machine header AogSettingsFound code.
if (bitRead(sett,0)) myIMU.calibrateAll(); else myIMU.endCalibration();
Pretty certain this will allow me to enable or disable calibration from AOG.
I’ve removed the MMA and BNO055 code so BNO085 heading and roll data is sent whatever the setting in AOG.
I’ve kept the x or Y axis and roll invert options.
I’ve got some tuning to do yet but my first impression is VERY stable roll with no damping or filtering needed.
My test field is that wet and rutted it is hard to tell how well the compass is working.
Alen, Having read the BNO080 Sensor Calibration Procedure sheet (https://xdevs.com/doc/CEVA/BNO080-BNO085-Sesnor-Calibration-Procedure.pdf) again, if I’m correct there’s
actually no autocalibration at all, it states:
The magnetometer is most important when using the Rotation Vector BNO080 output (which
aligns the quaternion output to magnetic north). When using the Game Rotation Vector output
(which aligns the quaternion output to an arbitrary orientation and is not affected by magnetic
perturbations), accurate calibration of the magnetometer is less important.
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 you will have to start and stop the dynamic calibration just once in the environment the sensor is used. It should be OK then, so you shouldn’t repeat it everytime you start AGopen,
but:
Hillcrest
recommends that dynamic calibration for the gyroscope and magnetometer be disabled to avoid new calibrations being created during gameplay which can cause unwanted motion artifacts.The gyroscope is automatically calibrated when the device is stable, and the magnetometer calibration is not likely to change significantly if the user uses the device in the same general
There is also the “SH-2 Reference Manual” (https://cdn.sparkfun.com/assets/4/d/9/3/8/SH-2-Reference-Manual-v1.2.pdf) where the BNO is part of the Hillcrest board with some info.
I calibrated mine once with the example code in the Sparkfun package that comes with the library , but found out that if you yaw it very fast (by hand) , it goes off, but there’s no way you can do it that fast with a tractor.
The advantage of the CMPS is it is factory calibrated in a special jig. You can’t come close to that cal doing it by hand.
Hi,
@BrianTee_Admin
As we discuss on Telegram, in my post number 27 (sorry long post but I tried give as mutch as details that I can): I tried UART-RVC mode with an Arduino Due. Also very stable when I do test on the desk by “punching” the desk to simulate vibration.
Adafruit code available to use this mode, realy easier than SHTP over I2C.
I didn’t go futher because I was thinking that we cannot interface this mode with Nano, du to the absence of additional UART on Nano.
In this mode:
- Heading not referenced to magnetic north: heading is zero when you start BNO, so 0° correspond to where “BNO was looking at start”.
- Background calibration is running a specific mode for accelerometer call “planar calibration”: don’t know if it’s better or worst for our application
@Alan.Webb @Simon_1
When you enable the Rotation Vector, the background magnetormeter and accelerometer autocalibration are enable and gyro background autocalibration is disable. You have to enable gyro calibration if you want with: calibrateGyro() or calibrateAll().
HillcrestLab said about the gyro caliibration in Rotation Vector : “For general applications that require motion tracking in a relatively stable magnetic field it is recommended to use 9-axis sensor fusion outputs (Rotation Vector – see section 2.2.4) from the BNO08X. If the device to which the BNO08X is attached provides sufficient tremor then the gyroscope calibration can be enabled. However the user should verify performance with their specific motion profile.”
I’ve edited Sparkfun library to add the possibility to display which calibration is enable. Hop I can post the code soon.
Did you succed to have both magnetometer and GameRotationVector (accelerometer + gyroscope) calibrate ? Both with a status to “High” ?
I never succed to have magnetometer to an other status than “Unreliable” despide repeating the calibration procedure: BNO080: impossible to have a complete calibration - SparkFun Electronics. No problem with gyro+accel: calibration status “High”.
Math
I got medium and high. It did require a bit of lively driving around!
I tried with calibrate all enabled and tonight I have had the old BNO055 compass drift again. Drifting downward whilst completely stationary. It doesn’t always happen but then it didn’t with the 055 either. Sometimes it was perfectly fine.
@ Math:
I had no problem to get three “Highs”, the magnetometer takes a bit more time, but still within a
minute. I think you can’t get it done with the sensor mounted on the tractor, unless you roll it a couple of times.
@Brian:
I believe that when you use Rotation Vector , calibration has to be done in the environment where the sensor has to live to do it’s job, because of the magnetometer. If the CMPS only uses the gyro and accelerometer, I think the factory calibration on the breakout board should be
hard to beat.
Not sure what CMPs uses exactly - but it is very stable. No cal needed anytime. North isn’t north though
Would it (if necessary) be possible to have an adjustment “slider” + - some degree, or maybe a field like when changing AB line some degrees, to make BNO point to where north are at our place.
Would it be possible to automatically adjust the heading? Over a period of time when the GPS heading is relatively stable, an offset could be computed from the average GPS heading and the average CMP heading.
Hello,
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).
Math
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.
2 Likes
Yes. I got medium on the first and high on the second. Both in my hand and in my tractor, with lively driving around.
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.