My ongoing project uses a Pi Zero W to compare data from 2 sources: heading is derived via UART from Ublox’s F9P receiver, and the absolute heading is derived via I2C from your BNO055 using Raspbian’s software I2C for clock stretching (i2c-bus/raspberry-pi-software-i2c.md at master · fivdi/i2c-bus · GitHub).
The python code for for each sensor was tested separately and worked well despite my inexperience. The code for the BNO055 was based on the necessary lines from simpletest.py for quaternions and calibration status.
But when I merge the two sets of code, something very strange happened. Both sets of data appear to run normally, but the GPS’s sensor data on the Pi lags the actual data being montoried directly via USB connection to Ublox’s U-centre.
So after running the merged code for say 30 seconds, the Pi’s GPS data lags the actual GPS data being monitored directly from the GPS receiver by about 10 seconds. The BNO055’s data is not delayed!
This did not happen when a more basic LSM303D sensor was used before upgrading to the BNO055 (due to distortion despite extensive calibration). The delay can be measured by comparing the GPS’s Time of Week (timestamp) output displayed from the Pi to the timestamp data direct from U-centre.
I would appreciate any help in finding a solution such as:
Using the BNO055 and other existing hearware, but resolving the GPS data delay.
Using another IMU sensor with similar performance (BNO085 heading when run separatelynot as good as BNO055) with other existing hardware.
Any other ideas to determine absolute and relative heading similtaneously in real time.
Sorry just to summarise, the GPS data lags behind when the BNO055 is plugged in and running simulataneously? It may have something to do with the clock stretching messing with the Ublox?
Yes, that is correct. Possibly, thats why I’d like to know if there is a python library for using say SKU: SEN0374 via SPI? Or another IMU with similat performance which doesn’t require clock stretching?
30% lag rate is enormous. If the data is lagging but still feeding through slowly it must be buffering somewhere and somehow. Perhaps in the Linux serial buffer. What baud rate are you using for communication?
I’d suggest trying a Loopback test on the UART port while using the software I2C library - see if that has anything to do with it, or if it’s your specific combination:
Then perhaps try another I2C device as well that you can customise to use clock stretching or not (perhaps an AVR microcontroller based product, like an Arduino Uno) - to see if you can narrow it down at all.
Yes, your ZED-F9P receiver is connected via UART to the Pi and runs without any delay as a single sensor at a baud rate of 115200. The BNO055 runs with delay singly or with the GPS sensor. Your BNO085 has the same delay effect on the GPS sensor, but absolute heading accuracy is inferior to the BNO055 in my application. It seems only BNO’s need clock stretching.
Do you stock another fusion IMU with a python library and which does not require clock stretching?
Or do you stock a 9DoF IMU, for which their is a python fusion library which could be handled on the Pi?
