Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mode must not be a fusion mode #117

Open
jalzone opened this issue Aug 1, 2023 · 3 comments
Open

Mode must not be a fusion mode #117

jalzone opened this issue Aug 1, 2023 · 3 comments

Comments

@jalzone
Copy link

jalzone commented Aug 1, 2023

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
Copy link

dannystaple commented Oct 27, 2024

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
Copy link

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants