BNO085 gyro cal (example sketch 'quarternion_yaw_pitch_roll')

[SteveDillon123]

Hi,
I have raised a question on the Adafruit forum and the support reply suggested I raise the issue here, even though I don't really think it's a library issue.

https://forums.adafruit.com/viewtopic.php?f=19&t=183919&p=894463#p894463

The issue is 100% repeatable.
I hope the information provided in the forum post is sufficient

[dwheeler-ceva]

The reason the status field is always zero is that the BNO086 doesn't include a status field in the Gyro_Integrated_RV sensor report. That particular report is unique in that it supports 1000Hz operation and delivers a full orientation quaternion and angular velocity vector. To pack all this into one message, some header fields were discarded including the status and sequence number. In the C driver, that field is still present in the structure but will always be set to zero.

The SH-2 Reference Manual has all the details: https://www.ceva-dsp.com/wp-content/uploads/2019/10/SH-2-Reference-Manual.pdf

[Moksh-Mehta-1937]

I know its been a long time someone replied to this issue, but was someone able to solve this? I currently have the Adafruit BNO085 sensor fusion breakout board connected to a Xiao Seeed ESP32-S3 over SPI and just reading the SH2_GYROSCOPE_CALIBRATED field but no matter how I move the sensor, the accuracy always stays at 0 (UNRELIABLE)

[NazikMGE]

@Moksh-Mehta-1937 did you fix that ?

[mdmehta1937]

@NazikMGE I was not able to fully resolve the issue. My current understanding is that this may need to be addressed by CEVA, potentially within the fusion engine itself, to properly expose the gyroscope calibration status over the SHTP protocol. That said, I did not spend extensive time debugging it further, so my assumption could be incorrect.

Although the reported calibration status consistently remains at 0, I observed that after a few seconds the gyroscope output stabilizes and becomes usable for downstream processing. My primary focus was obtaining a correct unit quaternion, and for my current use case the onboard fusion appears to work reliably enough.

At the moment, I do not expect this to be a blocking issue for my application, but I still plan to perform additional long-term testing. I am also planning to evaluate other IMUs with onboard calibration and sensor fusion capabilities to compare overall accuracy and behavior.

[NazikMGE]

I'm on ESP-IDF v6.0 and hit the same issue: cal_gyro.accuracy stays at UNRELIABLE.

(Note: this is the Calibrated Gyroscope report, sensor ID 0x02 — which does have an accuracy field, unlike the uncalibrated one.)

My setup looks like this:

auto cal_cfg = static_cast<BNO08xCalSel>(
    static_cast<uint8_t>(BNO08xCalSel::accelerometer) |
    static_cast<uint8_t>(BNO08xCalSel::gyro));

if (!imu.dynamic_calibration_enable(cal_cfg)) {
    ESP_LOGE("imu", "dynamic_calibration_enable failed");
} else {
    ESP_LOGI("imu", "dynamic_calibration_enable(accel|gyro) OK");
}

Even with this in place, cal_gyro.accuracy stayed at UNRELIABLE indefinitely. I suspected that internal chip resets during init were reverting the configuration back to factory defaults, silently dropping the host-requested setCalConfig.

To verify, I forked https://github.com/myles-parfeniuk/esp32_BNO08x and pushed a fix on the esp-idf-v6-compat branch of https://github.com/NazikMGE/esp32_BNO08x — commit "fix: post-reset stability — settling delay + cal_config re-apply". It does two things:

1. Adds a settling delay after deasserting RST (~90 ms per the BNO08x datasheet — the original delay was too short and the first SHTP packets were getting dropped).
2. Caches the calibration bitmask and re-applies it inside re_enable_reports() after any reset event.

After flashing with the patch, the UART logs show exactly what I'd expect:

I (2451) imu:   dynamic_calibration_enable(accel|gyro) OK
I (3152) BNO08x: Re-applied cached cal_config 0x03 after reset
I (3348) BNO08x: Re-applied cached cal_config 0x03 after reset
I (5518) imu:   [fusion=HIGH gyro=HIGH accel=HIGH mag=MED stab=STATIONARY]

Both gyro=HIGH (cal_gyro.accuracy == 3) and stab=STATIONARY are present. The latter is particularly telling — per SH-2 RM §6.5.31, the stability classifier only reports STATIONARY when gyro calibration is actually running, so this is a strong end-to-end confirmation that the cached re-apply works.

These exact two steps fixed it in my case — maybe useful for anyone else hitting the same wall.