BNO055 Possible use in +/- 1.0 deg pointing system

[mfstewart]

I am developing an automated pointing system that requires an accuracy of ~+/- 1.0 degree in both azimuth and elevation. I have been working with the BNO055 IMU and while it is very easy to work with, it is not producing the desired results. I am wondering if anyone has used the BNO055 in any system that requires such accuracies and if so, how do you interface to the device? I am using the BNO055 adafruit libraries and started with software that polls the IMU every ~3/4 seconds for Euler angles, calibration status and calibration offsets. I've recently made a slight change and now poll for the quaternion and then convert to Euler angles. As far as I can tell this doesn't produce any better results.

To test the repeatability of the yaw position measurement, I've built a turn table to which the IMU is mounted. This allows me to rotate the IMU clockwise and counter clockwise and return to the same 'stop' point. While collecting data, I rotate anywhere from 10 to 180 degrees off the stop point and then back collecting 20 or so data points each time I return to the stop point. I try to rotate in smooth continuous motion returning to the stop point within 5 - 10 seconds; so not too fast but not to slow either. I repeat this many times to build up some statistics that indicate the overall accuracy of the BNO055 yaw measurements and plot the resulting histogram labeled as Euler Repeatability Measure. It looks like if I built up enough statistics, that there is an approx. +/- 3 deg 1-sigma error.

I've done the same thing with the calculated (from quaternion readout) Euler angles. The histogram of this dataset doesn't look any better than the previous indicating that quaternions (converted to Euler angles) are not any more accurate. The plot is labeled as Calculated Euler from Quaternion Repeatability Measure.

I've also taken the difference in these histograms to see if the Euler and Quaternions are reporting different measures. The plot indicates that this is not the case. This plot is labeled as Quaternion - Euler Difference in Yaw.

I should mention that the system calibration remained at 3 for the entire testing process and the magnetometer calibration remained at >2, most of the time it was at 3.

I am beginning to think that the BNO055 is not the best choice for this application but was hoping for some pointers / feedback from anyone who has possible solved this problem already. Any help will be much appreciated.

Euler Repeatability Measure

Direct Euler Yaw Repeatability Test small.jpg (19.36 KiB) Viewed 8743 times

Calculated Euler from Quaternion Repeatability Measure

Quaternion Euler Yaw Repeatability Test small.jpg (19.68 KiB) Viewed 8743 times

Quaternion - Euler Difference in Yaw

Quaternion Euler Difference Yaw Repeatability Test small.jpg (18.35 KiB) Viewed 8743 times

[gammaburst]

Bosch doesn't publish orientation accuracy specs, and the chip sells for only $10 in small quantity, so I don't expect much accuracy. Twirling it around in my hand, it seems to be good to a few degrees, just as you measured. The folks at Hillcrest Labs sell the same/similar device with improved firmware - BNO080, however the communication protocol is wildly different.

The BNO055 Euler outputs closely match its quaternion when the sensor is near horizontal, but tilt the sensor more than about 20 degrees and the Euler angles become increasingly distorted. It's a math bug. So I do my own quaternion-to-Euler conversion. My BNO055 devices all have firmware version 0x0311.

[PaulRowntree]

I am running a BNO on a breadboard, with readouts on a LED display (no decimals) or to the IDE Serial monitor. It is almost snug inside a plastic tub, so there is no tension on wires as I move it about on the bench, but no heroic efforts to lock it in place. I have a stop that allows the tub edge to be aligned to the table after moving it about.
My heading precision is usually much better than 1 degree .. Rock steady if not moving.

I don't understand the points on your graphs that are ten-fifteen degrees off the mean. Was it still moving?.

[mfstewart]

Thank you for the added information. That answers an important question about why I wasn't seeing improved performance out of the quaternions over directly reading the Euler event. I only conducted the test while the IMU was flat (almost level... no pitch or roll) and only moved in the yaw dimension. I will take a look at the firmware version I am running, maybe Bosch has a later version out. To answer the question in the other reply... You are absolutely correct, the counts that are 10 - 15 degrees off represent those angles when I was still rotating the IMU.

I have continued testing the BNO055 and will post the results as soon as I get a chance. Long story short, it looks like I am able to achieve approximately 3-sig errors of 1.5 and 2.5 degrees while in NDOF_FMC_OFF and NDOF modes respectively. At this point, it appears that commenting out the GPS interrupt readout code so that the only task for the Arduino UNO application is reading and outputting (serially), {a millisecond time stamp, quaternions converted to Euler (yaw, pitch, roll), calibration status of the sys, gyro, accel, mag and the quaternions themselves} has an affect on measurement accuracy. I don't understand this and find it difficult to believe so am hesitant to say that this is the cause. However, at this point it appears to be so. More testing tomorrow if time permits or possibly next week should shed some light on this.

In addition, I have noticed that while in NDOF mode, the mag calibration drops from 3 -> 1 while the IMU stays flat and is moved in only the yaw dimension. It is easily re-calibrated back to 3 by simply rotating it around all 3 axes for a few seconds but once I lock it down on the turn table and begin rotating in yaw, it doesn't take long for the mag calibration to diminish to 2 then to 1 (minutes possibly). However, while in NDOF_FMC_OFF mode, it has stayed locked at 3 throughout my testing today.

[PaulRowntree]

In addition, I have noticed that while in NDOF mode, the mag calibration drops from 3 -> 1 while the IMU stays flat and is moved in only the yaw dimension. It is easily re-calibrated back to 3 by simply rotating it around all 3 axes for a few seconds but once I lock it down on the turn table and begin rotating in yaw, it doesn't take long for the mag calibration to diminish to 2 then to 1 (minutes possibly). However, while in NDOF_FMC_OFF mode, it has stayed locked at 3 throughout my testing today.

I've seen this a lot on my unit. When powered up it stays in relative orientation mode until the mag cal rises to 2, then it flips into absolute heading readings, Always requires moving the sensor, still working on writing the params. Once in absolute mode, it never drops out, and I can't see any loss of accuracy/precision when the mag cal drops even to 0. It seems to drop the mag cal for no reason at all. If you can get mag cal to 3, it seems to hold the mag cal there longer, but again, no apparent change of accuracy/precision even if it does drop.

There are reports of the BNO losing mag cal when moving in a car. My tests on this aren't conclusive, but the heading info seems reliable once in absolute mode. The mag cal seems to drop out more while moving. I am starting to just ignore mag cal, except to know if it is in absolute mode after power up.

[gammaburst]

When the BNO is motionless, its orientation readings are indeed steady, but that's not necessarily a good thing. The fusion processing seems to do some sort of noise reduction or anti-shake (like a video camera). I rotate it a few degrees, rotate it back, and the reading can be different by a degree or so. I'd rather see the sensor's natural noise.

In fusion modes, the BNO also does continuous auto-calibration. Can't turn it off.

I haven't noticed any 10-15 degree errors during rotation, but I'm merely twirling the sensor in my hand or against little alignment blocks while watching the results on real-time graphs and a 3D rendered airplane model. I suppose I could attach the BNO to a rotary encoder and plot that too. That would be interesting.

I'm using NDOF mode, and reading all sensor and fusion registers at 100 Hz.

- UPDATE -

I attached a rotary encoder to my BNO. I don't see 10-15 degree errors during dynamic rotation. Be sure to account for the BNO's processing delay, or you will see such errors during quick rotations.

[PaulRowntree]

These are great little modules, but the interpretation of what exactly is going on can be frustrating.
I've set mine up with a key press to read back the offsets from the SD card. These parameters were saved a while back when all cal values were 3.

First press and the devices shows magCal of 3, but it immediately drops to zero ... but it switches to absolute heading mode.
Press it repeatedly, each time the magCal jumps to 3, drops back, heading value stays constant and valid
After 3-10 presses it sticks with magCal=3. It seems to stay at 3 indefinitely while moving it about on the workbench.

The code has been force-feeding exactly the same values with each press.

[LuoZhen]

Hi mfstewart,

I'm working on a project which also needs +-1 degree accuracy and I'm facing the same problem with you. To be honest, I'm very happy with the accuracy when BNO055 is fully calibrated. However, the problems are 1) reputability is bad in NDOF mode; 2) mag cal level drops from 3 > 2 after some time or some movement. I'm not sure, but it seems to be the bug of the built-in AHRS algorithm of BNO055.
Have you solved the problem? Or, you are using other sensor right now?

Best,
Zhen