micropython-IMU / micropython-bno055

Bosch BNO055 driver for MicroPython. IMU with hardware sensor fusion.
MIT License
48 stars 9 forks source link

Calibration starts and then it errors out #3

Closed efremovru closed 3 years ago

efremovru commented 3 years ago

I am using ESP32 and Adafruit's BNO055. Breadboard. No other chips. The code starts fine and after few cycles i start getting errors like the one on the bottom. Restart. Same thing. Similar error somewhere else. I am sure that i am doing something wrong, but i can't figure out what. Any help will be greatly appreciated.

The only change i made in the bno055_test.py is the i2c line

scl=machine.Pin(4) sda=machine.Pin(2) i2c = machine.SoftI2C(scl, sda, freq=100000)

Calibration required: sys 0 gyro 3 accel 0 mag 0 Temperature 23°C Mag x -27 y -0 z -25 Gyro x -0 y 0 z -0 Accel x 0.2 y 0.7 z 9.5 Lin acc. x 0.0 y -0.0 z -0.2 Gravity x 0.2 y 0.7 z 9.8 Heading 360 roll 1 pitch -4 Calibration required: sys 0 gyro 3 accel 0 mag 0 Temperature 23°C Mag x -28 y -1 z -27 Gyro x 0 y 0 z 0 Accel x 0.2 y 0.7 z 9.5 Traceback (most recent call last): File "", line 26, in File "bno055_base.py", line 61, in File "bno055_base.py", line 91, in scaled_tuple File "bno055_base.py", line 123, in _readn OSError: [Errno 110] ETIMEDOUT

here are copies of the other errors i got

Traceback (most recent call last): File "", line 22, in File "bno055_base.py", line 94, in temperature File "bno055_base.py", line 113, in _read OSError: [Errno 110] ETIMEDOUT

Traceback (most recent call last): File "", line 21, in File "bno055_base.py", line 99, in cal_status File "bno055_base.py", line 113, in _read OSError: [Errno 110] ETIMEDOUT

Traceback (most recent call last): File "", line 27, in File "bno055_base.py", line 62, in File "bno055_base.py", line 91, in scaled_tuple File "bno055_base.py", line 123, in _readn OSError: [Errno 110] ETIMEDOUT

the code always stars fine (in calibration mode) and then it errors out

peterhinch commented 3 years ago

Your code looks fine: I think your problem is electrical.

The I2C communication is evidently unreliable. The commonest reason for this is a lack of pullup resistors. If these are OK you need to check that wiring is sound and reasonably short, supply voltages are OK and suchlike.

efremovru commented 3 years ago

Peter, thanks for the quick reply. I moved from a breadboard to perf board just to make sure that all the wiring is good and secure. I added 1K pullup resistors to SDA and SDL. no change in the results. I changed the SDL and SDA pins (grasping for straws). still the same issue. I'm powering the board from my laptop. what else can I try? 20210306_171657 1

peterhinch commented 3 years ago

I'm foxed. The code has run on ESP32 and even (with the minimal RAM version) on ESP8266. Some ESP32 problems have been down to voltage drops on the USB cable. I use short cables and prefer thick ones in the hope that they have thicker conductors: the ESP32 can consume spikes of higher current if any WiFi access takes place. You could try disabling the AP and station interfaces.

Another thought is to run a loop doing I2C.scan() every (say) 100ms and see if that ever times out.

efremovru commented 3 years ago

Thanks Peter. I found a solution. Dropping the frequency.

i2c = machine.SoftI2C(scl, sda, freq=10000)

what is the accuracy i should expect? the observed one is +/- 3 degrees. Is this reasonable? There is not much you can do anyway BUT reading Honeywell's docs i feel that i am not achieving the top possible results

peterhinch commented 3 years ago

I still believe something is wrong at the hardware level. The bno055_test.py script, when used unchanged with a Pyboard, runs the interface at 400KHz and I have never seen a problem. I ran it for long periods in that mode while developing the quaternion module and experimenting with 3D rotation.

A few random thoughts re hardware.

Bear in mind that ESP32 GPIO pins are not 5V safe. However the Adafruit BNo055 has a 3.3V voltage regulator so this shouldn't be an issue. Also - I've just reminded myself - their board has pullups. Looking at my ESP32 pinout I see there is a note against GPIO2 "external pulldown". I wonder if it might be worth trying a different pin?

As for absolute accuracy, I'm afraid I've never measured this or investigated it. While measuring pitch and roll to an absolute accuracy of (say) one degree is straightforward I'm not so sure about heading. There are so many things that influence local magnetic fields, the only thing you could legitimately compare your readings against would be a laboratory grade magnetometer. I have found getting accurate readings from magnetometers to be quite difficult.

efremovru commented 3 years ago

I tried 3 different pairs of pins. first i started with the "default" 21/22, then 2/4 and now I am on 16/17. Other than that issue the code runs as a clock!!! I remember somebody else fighting with ESP32 I2C and that's how they solved it. Don't remember the application though. I've read so many posts.

I agree with your observation about the magnetometer accuracy. It seems that there is quite a bit of gap between advertisement and "real" world applications.

Many thanks for the code !!!!!!!!!!!!!!!