Mode must not be a fusion mode

[jalzone]

I keep getting this error when running on a Raspberry Pi with python3.

Traceback (most recent call last): File "/home/pi/9dof.py", line 39, in <module> sensor = adafruit_bno055.BNO055_I2C(i2c, 0x28) File "/usr/local/lib/python3.9/dist-packages/adafruit_bno055.py", line 793, in __init__ super().__init__() File "/usr/local/lib/python3.9/dist-packages/adafruit_bno055.py", line 232, in __init__ self.gyro_range = GYRO_2000_DPS File "/usr/local/lib/python3.9/dist-packages/adafruit_bno055.py", line 576, in gyro_range raise RuntimeError("Mode must not be a fusion mode") RuntimeError: Mode must not be a fusion mode

Besides import adafruit_bno055 Line 39 is the first line of the script concerning the library. Sensor mode is set after this line as either IMUPLUS or NDOF, but even when there is no mode set after, the error persists. Strangest thing is that it will work and run through the script on rare occasions, where it will run through a calibration routine and then data collection.

[dannystaple]

I am seeing this too. However, some things that may be specific to my use case: I am using the i2c 0 Raspberry Pi bus:

from adafruit_extended_bus import ExtendedI2C as I2C
import adafruit_bno055

i2c = I2C(0)
sensor = adafruit_bno055.BNO055_I2C(i2c)

I see a warning first:

/home/danny/robotvenv/lib/python3.11/site-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py:30: RuntimeWarning: I2C frequency is not settable in python, ignoring!
  warnings.warn(

Then that error:

 Traceback (most recent call last):
  File "/home/danny/robot/bno055_service.py", line 59, in <module>
    service = BNO055Service()
              ^^^^^^^^^^^^^^^
  File "/home/danny/robot/bno055_service.py", line 13, in __init__
    self.sensor = adafruit_bno055.BNO055_I2C(i2c)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/danny/robotvenv/lib/python3.11/site-packages/adafruit_bno055.py", line 793, in __init__
    super().__init__()
  File "/home/danny/robotvenv/lib/python3.11/site-packages/adafruit_bno055.py", line 232, in __init__
    self.gyro_range = GYRO_2000_DPS
    ^^^^^^^^^^^^^^^
  File "/home/danny/robotvenv/lib/python3.11/site-packages/adafruit_bno055.py", line 576, in gyro_range
    raise RuntimeError("Mode must not be a fusion mode")

Other useful detail:

$ robotpython
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import adafruit_bno055
>>> adafruit_bno055.__version__
'5.4.13'
>>> import adafruit_extended_bus
>>> adafruit_extended_bus.__version__
'0.0.0-auto.0'

That adafruit_extended_bus version looks off. I'm perhaps suspecting that it's not actually communicating correctly?

[dannystaple]

Ok - I ran a few times. it went from reproducible every time, to no longer reproducible. I am none the wiser. The first time, I powered up with a logic analyser in place on the I2c bus but not powered, so I thought this was a factor. I ran a bunch of tests, all the way up to getting euler data without the logic analyser. Then a bunch with the analyser plugged in and powered off (yes, an incorrect state), 1 in 5 reproducible, but once it goes, it stays that way until I either remove or correctly power the analyser.

It seems this is the way the library indicates that it's not able to talk properly with the device. To try confirming that, I unplugged it and ran my test. that resulted in the expected ValueError: No I2C device at address: 0x28. So not that.

My nearest hunch is that having a slightly iffy termination to my i2c bus (the unplugged logic probe) may have meant the pull ups on the bus were off.

[FoamyGuy]

I don't know why this would be an intermittent issue, but looking in the stacktrace from the original comment I see it traces through the gyro_range setter. I've recently submitted #126 with a fix for that and a few other setters not entering config mode before writing commands to the device.

I think the error that would arise from that issue is the one reported here, so I think that PR might resolve this issue.

If anyone whose seen this is able to test that branch let us know if you still see any trouble when you try it.