Interface BNO085 through USB to Python

[hlawati]

Hello,

I am interested in the BNO085 to get the roll/yaw/pitch, as well as the heading angle.
I would like to inteface the data to a Python in a Linux PC running Ubuntu 20.04.

I have seen to options to do so:
1) Use the Adafruit FT232H Board to interface the sensor to it through I2C, or
2) Use the UART RVC with a USB FTDI Cable.

Which solution will be better and easier to implement in my case?

Thanks in advance,

[hlawati]

Update:
3) A third choice is to use the Adafruit MCP2221A Breakout. How does this compare to option (1)

[danhalbert]

Yet another choice is https://learn.adafruit.com/circuitpytho ... ry-pi-pico, which uses software called U2IF.

If you have a Pi Pico on hand, you could try this immediately.

The BNO055 and BNO085 use I2C clock stretching. I don't know how well the MCP2221A and FT232H handle it, though I think they might be OK. You might be one of each to try out if you decide to go that route.

[hlawati]

Thank you for your response.

uses software called U2IF.

According to the documentation, U2IF is still in the experimental phase. I am afraid if issues could arise.

On the other hand, According to MCP2221A Datasheet from Microchip:

1.13 I2C Host Module
The I2C host module is responsible for the I2C traffic generation. The module is controlled through the USB HID, through the Bus Matrix module. The I2C module only implements the functionality of an I 2C/SMBus host.
1.13.1 I2C/SMBus HOST
The I2C host initiates all the I2C/SMBus transactions (being read or write operations) on the bus.
The I2C/SMBus host module has the following capabilities:
• Clock stretching (it allows the slower I2C clients to communicate)
All the user data to be sent/transmitted over the I2C bus are conveyed to the USB host only through the USB HID interface.

Does this mean that it is capable to handle clock stretching? (sorry if it is a trivial question, but I am a newbie in this field)


Also, if relavent, I am okay to use a single sensor with a single MCP2221A board.

[hlawati]

Another thing, I have seen that BNO085 supports UART.
Is it possible to interface it using a USB TTL cable?

[danhalbert]

I would not be too afraid of "experimental". If it works, it works.

Other USB-serial cables: https://www.adafruit.com/category/556

I would suggest you search in these forums for << BNO085 serial >> and << BNO055 serial >> to see if people have had any issues that were not setup issues. If this is for significant data collection, I'd collect all of these possibilities and try them for an extended period to see which seems the most reliable. Sometimes sensors hang intermittently, and need to be reset to continue. I'm not saying these have that problem, but if you want reliable data collection you may want to prepare for that possibility.

[hlawati]

Trying them all is indeed a good idea, but unfortunately not in my case.

I need to interface around five sensors. I live far away in the ME and I ship to a mail forwarding address in the US. It would take 10-14 days for me to get the items. So if I purchase one of each to decide which one is the best, and then order it again, that would take around a month.

It would be great if any of the tech support team have tried interfacing the BNO085 to Linux PC.

As far as with serial communciation, I have searched the forums and found that some people report that the BNO data overflows when connected in serial, and hence not all outputs are accessible.


I think that switching to another IMU would overcome all these issues.
The reason that made me choose the BNO085 is that it outputs the roll/pitch/yaw directly without the need to use equations.
Could you suggest me IMUs that do the samething?

[adafruit_support_carter]

The BNO085 is a complex sensor. In addition to using clock stretching on I2C, it has an entire communication protocol it uses called Sensor Hub Transfer Protocol, which adds additional complexity when using the non-RVC modes via I2C, SPI, or UART. Getting the BNO085 to work with *any* application will require some trial and error and iterations. So not sure what can be suggested to deal with the shipping lead time requirement. I don't think there is anything that can be suggested that will be guaranteed to work with your setup and not potentially require additional orders.

Using RVC mode is probably your safest bet. There is a known open issue here:
https://github.com/adafruit/Adafruit_Ci ... C/issues/1
but should be solvable. I'd consider that to be a true bug in the driver code, with the underlying issue being exactly as described in that thread (old values are being buffered). I tried out RVC mode on linux, using a USB-to-serial adapter cable, and saw exactly that issue. But also fixed it same as suggested in that thread.

[adafruit_support_carter]

Example RVC Python script:

Code: Select all

import time
import serial
from adafruit_bno08x_rvc import BNO08x_RVC

s = serial.Serial("/dev/ttyUSB0")
s.baudrate = 115200

rvc = BNO08x_RVC(s)

while True:
    s.reset_input_buffer()
    yaw, pitch, roll, x_accel, y_accel, z_accel = rvc.heading
    print("Yaw: %2.2f Pitch: %2.2f Roll: %2.2f Degrees" % (yaw, pitch, roll))
    print("Acceleration X: %2.2f Y: %2.2f Z: %2.2f m/s^2" % (x_accel, y_accel, z_accel))
    print("")
    time.sleep(0.1)

Output on a linux PC with a USB-to-serial adapter:

Code: Select all

$ python3 rvc_test.py 
Yaw: 17.39 Pitch: 0.00 Roll: 0.04 Degrees
Acceleration X: -0.04 Y: 0.00 Z: 9.62 m/s^2

Yaw: 2.87 Pitch: -65.53 Roll: -48.23 Degrees
Acceleration X: -1.34 Y: 11.81 Z: -4.18 m/s^2

Yaw: -12.07 Pitch: 13.59 Roll: 19.01 Degrees
Acceleration X: -8.70 Y: 7.51 Z: 10.96 m/s^2

Yaw: 20.64 Pitch: 29.23 Roll: 52.92 Degrees
Acceleration X: -8.17 Y: 5.14 Z: -2.79 m/s^2

Yaw: 15.95 Pitch: 3.67 Roll: 73.81 Degrees
Acceleration X: -19.48 Y: -2.33 Z: 20.93 m/s^2

Yaw: 13.03 Pitch: -14.55 Roll: 56.69 Degrees
Acceleration X: -6.47 Y: -14.64 Z: -10.00 m/s^2

Yaw: 24.55 Pitch: -25.90 Roll: 13.62 Degrees
Acceleration X: 2.15 Y: 1.91 Z: 3.72 m/s^2

Yaw: 26.61 Pitch: -41.93 Roll: -35.29 Degrees
Acceleration X: -2.45 Y: 1.84 Z: 7.36 m/s^2

Yaw: 47.90 Pitch: -51.15 Roll: -95.48 Degrees
Acceleration X: 5.10 Y: -10.96 Z: -2.79 m/s^2

Yaw: 70.36 Pitch: -19.46 Roll: -138.33 Degrees
Acceleration X: 7.01 Y: 3.07 Z: -7.89 m/s^2

Yaw: 77.23 Pitch: -11.00 Roll: -158.23 Degrees
Acceleration X: 4.98 Y: -1.34 Z: -5.18 m/s^2

[gammaburst]

Hi hlawati,

Another possible approach: put a microcontroller between your five BNO085s and Linux. Depending on how much data you want and how fast, you may need to connect the BNOs to multiple ports on the micro, because each BNO085 communicates inefficiently, wasting a lot of time between messages.

You requested heading. If that means magnetic compass heading, then RVC mode is unsuitable because it outputs relative yaw only, no magnetometer/compass.

I have successfully used the BNO085 in UART mode with Windows (not Linux) and a USB-serial adapter (Adafruit 954):
viewtopic.php?p=953477#p953477
In that somewhat painful experimental project, I send a request for my desired reports, then I receive and decode the data reports myself. No library, and therefore no library bugs. Beware, the BNO085 communication protocol is overcomplicated and poorly documented. Also, UART mode runs at 3000000 baud, and some reports are hundreds of bytes long, so you need proper buffering in Windows/Linux to avoid losing data. Depending on your skills, all that could be a rather big project for you.

I have also connected multiple BNO085s to one SPI port on a microcontroller. It worked, but the BNO communication inefficiency caused lower data rates than you may expect. This project was a bit painful:
viewtopic.php?p=859651#p859651

The BNO055 and BNO085 are the only two low-cost sensors that I know of with built-in 9-axis fusion math. You could do the fusion math in a microcontroller or Linux, although it would be difficult to do it better than the BNO085's internal algorithm, and you would need to output even more data from each BNO.

[hlawati]

adafruit_support_carter and gammaburst

Thank you very much for your informative replies.

It seems that the using the BNO085 might introduce some difficulties, due its complexity.
What made me think to use in the begining is that, when comparing it with other sensors, such as the Adafruit LSM6DSOX + LIS3MDL or the Adafruit LSM6DS3TR-C + LIS3MDL , it was the only one that outputs roll/yaw/pitch directly. All others didn't. We don't have an expert in sensors nor in UART/I2C protocols, nor we have a lot of time for debugging and troubleshooting, and hence I liked that the BNO085 simplifies everthing. We rather wanted a sort of "plug and play" sensor.

With the difficulties and limiations mentioned about the sensor in mind, and after reading about How to Deal With Clock Stretching Issues
I am thinking to use a simpler sensor that requires software algorithms to do the sensor fusion. I searched about sensor fusion algorithms implementation in python. I thought in the begining that many people should have done it and it would be straight forward, but that wasn't the case.

With that being said, have anyone of you guys tried the Adafruit LSM6DSOX + LIS3MDL or the Adafruit LSM6DS3TR-C + LIS3MDL or something similar with python based sensor fusion algorithms, to output roll/yaw/pitch/heading easily ?


One more thing to note is, it is okay with me to use a 6DOF IMU, with a separate magnetometer/compass. They are involved in different parts of the project and don't need to be on a single breakout board

[gammaburst]

The BNO085's built-in fusion makes things a lot easier, and it can give good performance. The BNO085 has some quirks and disadvantages that may or may not matter to your project. Maybe you can easily modify something in your project so those disadvantages disappear.

I think you need ...
1. Five sensors, each outputting Euler angles (roll, pitch, compass heading). Could you use quaternions instead?
2. Unknown data rate - this is important! How many measurements per second per sensor do you need?
3. Send data to Linux, read it with Python
4. Do the data messages need to be a specific format, or doesn't matter?
5. Is USB a requirement, or would some other connection be acceptable?
6. Would it be acceptable to add a microcontroller between the five sensors and your Linux machine?
7. Do you need libraries to help do everything, or can you write some low-level control code to workaround library limitations/bugs?

I think item 6 would help a lot.

[hlawati]

gammaburst,

To make things clear, I want to implement a self stabilizing platform (something similar to this.)

1. I will implement two platforms, hence I will need two sensors. The third sensor will be used for heading in a different part of the project. The other two sensors are spare just in case.

2. Not sure of the exact data rate needed, but I thing It will require tens of measurements per second .

3. Exactly. Send data to Linux, read it with Python

4. Do the data messages need to be a specific format, or doesn't matter? No, doesn't matter.

5. USB is not a requirement. Any reliable connection is acceptable. The simpler the better.

6. Prefer not to add a microcontroller between the sensors and the Linux machine, since it might introduce delays and extra overhead.

7. Most importantly that it works without complications. Ofcourse precense of libraries is a huge plus since it will make our life easier. However, it is not a must.

Thanks,