Due to high demand expect some shipping delays at this time, orders may not ship for 3-4 business days. On MLK Day no orders will be shipped.
0

BNO085 Reports: Activity Classification working?
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

BNO085 Reports: Activity Classification working?

by furusato on Fri Dec 04, 2020 4:12 pm

Hi, I'm a recent convert from a BNO055, which I found dropped calibration rather quickly after gaining it. I'm hoping to use the BNO085 as an absolute orientation compass for a robot. I've built out a Python test class and have been trying some of the available features and reports.

I was able to get the _bno.calibration_status report (which returns an int used as an index into an array of descriptive strings) with no difficulty, as well as the _bno.stability_classification, which simply returns a str (descriptor).

But the _bno.activity_classification returns a dictionary (not a string value or index) and it seems unclear how it can be used. The documentation
on https://circuitpython.readthedocs.io/projects/bno08x/en/latest/api.html would seem to indicate it's meant to return a string (e.g., "In-Vehicle") but it seems to be returning the dictionary itself. Is this a bug?

Thanks for your help!

furusato
 
Posts: 31
Joined: Tue Nov 05, 2019 7:42 pm

Re: BNO085 Reports: Activity Classification working?

by mikeysklar on Sun Dec 06, 2020 11:37 am

@furusato,

I see some checkins form September which indicate that activity classification is working. Which version of the library are you using?

https://github.com/adafruit/Adafruit_Ci ... 08x/pull/4

Did you see the report example with activity classifier code?

https://github.com/adafruit/Adafruit_Ci ... reports.py

Code: Select all | TOGGLE FULL SIZE
bno.enable_feature(adafruit_bno08x.BNO_REPORT_ACTIVITY_CLASSIFIER)
[...]
print("Stability classification:", bno.stability_classification)
    print("")

    activity_classification = bno.activity_classification
    most_likely = activity_classification["most_likely"]
    print(
        "Activity classification:",
        most_likely,
        "confidence: %d/100" % activity_classification[most_likely],
    )

mikeysklar
 
Posts: 6466
Joined: Mon Aug 01, 2016 8:10 pm

Re: BNO085 Reports: Activity Classification working?

by furusato on Sun Dec 06, 2020 2:19 pm

Hi, thanks for your reply.

Just to be sure I did an update of the library via:
Code: Select all | TOGGLE FULL SIZE
sudo pip3 install --upgrade --force-reinstall adafruit-circuitpython-bno08x

and ran bno08x_more_reports.py using python3. The result prints zero or more reports before exiting with a PacketError. The following is one of the more successful, e.g.,
Code: Select all | TOGGLE FULL SIZE
Acceleration:
X: -0.460938  Y: -0.882812 Z: 9.609375  m/s^2

Gyro:
X: 0.005859  Y: -0.007812 Z: 0.001953 rads/s

Magnetometer:
X: -5.500000  Y: 9.812500 Z: 15.875000 uT

Linear Acceleration:
X: 0.019531  Y: 0.089844 Z: -0.003906 m/s^2

Rotation Vector Quaternion:
I: -0.032898  J: 0.033997 K: -0.199585  Real: 0.978760

Geomagnetic Rotation Vector Quaternion:
I: -0.130615  J: 0.133789 K: -0.765869  Real: 3.921631
Game Rotation Vector Quaternion:
I: -0.038635  J: 0.026672 K: -0.000793  Real: 0.998901

Steps detected: 0

Stability classification: In motion

Activity classification: Unknown confidence: 91/100
Raw Acceleration:
X: 0xFEA0  Y: 0x00E0 Z: 0x0FB0 LSB

Raw Gyro:
X: 0xFFFD  Y: 0xFFFD Z: 0x0000 LSB

Raw Magnetometer:
X: 0x001C  Y: 0xFDF8 Z: 0x02B0 LSB

SHAKE DETECTED!

Acceleration:
X: -0.535156  Y: -0.652344 Z: 9.609375  m/s^2

Gyro:
X: -0.003906  Y: 0.001953 Z: 0.001953 rads/s

Magnetometer:
X: -4.375000  Y: 9.625000 Z: 16.500000 uT

Linear Acceleration:
X: 0.093750  Y: 0.128906 Z: 0.027344 m/s^2

Rotation Vector Quaternion:
I: -0.032715  J: 0.033875 K: -0.199585  Real: 0.978760

Geomagnetic Rotation Vector Quaternion:
I: -0.129639  J: 0.135010 K: -0.795166  Real: 3.915771
Game Rotation Vector Quaternion:
I: -0.038635  J: 0.026672 K: -0.000793  Real: 0.998901

Steps detected: 0

Stability classification: Stable

Activity classification: Unknown confidence: 91/100
Raw Acceleration:
X: 0xFEF0  Y: 0x00C0 Z: 0x0FB0 LSB

Raw Gyro:
X: 0xFFFC  Y: 0xFFF6 Z: 0xFFFF LSB

Raw Magnetometer:
X: 0x0011  Y: 0xFDFE Z: 0x02AA LSB

Acceleration:
X: -0.460938  Y: -0.804688 Z: 9.613281  m/s^2

Gyro:
X: 0.001953  Y: -0.001953 Z: 0.000000 rads/s

Magnetometer:
X: -5.937500  Y: 9.562500 Z: 16.437500 uT

Linear Acceleration:
   
      ********** Packet *************
DBG::       HEADER:
DBG::       Data Len: 15
DBG::       Channel: INPUT_SENSOR_REPORTS (3)
DBG::          ** UNKNOWN Report Type **: 0x7b
DBG::       Sequence number: 131

DBG::       Data:
DBG::      [0x04] 0x7B 0x31 0x00 0x00
DBG::      [0x08] 0x00 0x01 0x36 0x02
DBG::      [0x0C] 0x00 0x81 0xFF 0x3C
DBG::      [0x10] 0xFF 0x9D 0x09
      *******************************

Traceback (most recent call last):
  File "bno08x_more_reports.py", line 25, in <module>
    bno.enable_feature(adafruit_bno08x.BNO_REPORT_ACTIVITY_CLASSIFIER)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 975, in enable_feature
    self._process_available_packets(max_packets=10)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 783, in _process_available_packets
    self._handle_packet(new_packet)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 841, in _handle_packet
    raise error
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 836, in _handle_packet
    _separate_batch(packet, self._packet_slices)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 351, in _separate_batch
    required_bytes = _report_length(report_id)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 340, in _report_length
    return _AVAIL_SENSOR_REPORTS[report_id][2]
KeyError: 123

I've seen these errors before and have put my calls into a try-catch wrapper so things at least keep running. But I do see that the ActivityClassification in this Python file is showing "Unknown" as a result, so that seems to be working.

It turns out the problem with that report was the way I was calling it. I copied lines 97-103 over to my own file and modified it to suit, and it's now printing reasonable outputs:
Code: Select all | TOGGLE FULL SIZE
Activity Classification: Still; confidence: 97%

It'd be nice to not have about every fifth sensor read fail with a PacketError to the console, not sure why that's happening. This was something that never happened with the BNO055. But you've shown me how to get that Activity Report, which I hadn't figured out from the documentation. Thank you!

furusato
 
Posts: 31
Joined: Tue Nov 05, 2019 7:42 pm

Re: BNO085 Reports: Activity Classification working?

by furusato on Sun Dec 06, 2020 2:28 pm

I thought to follow up with a copy of some of the errors, which are quite common. These seem to be of three types, RuntimeError: ('Unprocessable Batch bytes', 2), KeyError, and IndexError. Not sure if these are all due to the same problem or separate issues.

Code: Select all | TOGGLE FULL SIZE
bno08x error: ('Unprocessable Batch bytes', 2) Traceback (most recent call last):
  File "/home/pi/ros/lib/bno08x.py", line 214, in read
    _calibration_status = self._bno.calibration_status
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 731, in calibration_status
    0,  # reserved
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 749, in _send_me_command
    self._process_available_packets()
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 783, in _process_available_packets
    self._handle_packet(new_packet)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 841, in _handle_packet
    raise error
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 836, in _handle_packet
    _separate_batch(packet, self._packet_slices)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 357, in _separate_batch
    raise RuntimeError("Unprocessable Batch bytes", unprocessed_byte_count)
RuntimeError: ('Unprocessable Batch bytes', 2)

as well as
Code: Select all | TOGGLE FULL SIZE
bno08x error: 0 Traceback (most recent call last):
  File "/home/pi/ros/lib/bno08x.py", line 214, in read
    _calibration_status = self._bno.calibration_status
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 731, in calibration_status
    0,  # reserved
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 749, in _send_me_command
    self._process_available_packets()
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 783, in _process_available_packets
    self._handle_packet(new_packet)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 841, in _handle_packet
    raise error
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 836, in _handle_packet
    _separate_batch(packet, self._packet_slices)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 351, in _separate_batch
    required_bytes = _report_length(report_id)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 340, in _report_length
    return _AVAIL_SENSOR_REPORTS[report_id][2]
KeyError: 0


where the value of the KeyError seem to be a variety of values between 0 and 255.

I also see the following, less regularly:
Code: Select all | TOGGLE FULL SIZE
 list assignment index out of range Traceback (most recent call last):
  File "/home/pi/ros/lib/bno08x.py", line 243, in read
    _quaternion = self._bno.quaternion
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 533, in quaternion
    self._process_available_packets()
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 780, in _process_available_packets
    new_packet = self._read_packet()
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/i2c.py", line 88, in _read_packet
    self._update_sequence_number(new_packet)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 831, in _update_sequence_number
    self._sequence_number[channel] = seq
IndexError: list assignment index out of range


I don't think there's anything peculiar about my hardware installation. The BNO085 is in the location (on top of a 25cm stalk on top of the robot) where the BNO055 used to be.

furusato
 
Posts: 31
Joined: Tue Nov 05, 2019 7:42 pm

Re: BNO085 Reports: Activity Classification working?

by jps2000 on Sun Dec 06, 2020 4:57 pm

Just a comment:
This can not be correct in my opinion:
Geomagnetic Rotation Vector Quaternion:
I: -0.129639 J: 0.135010 K: -0.795166 Real: 3.915771
Quaternions should be unity vector

jps2000
 
Posts: 701
Joined: Fri Jun 02, 2017 4:12 pm

Re: BNO085 Reports: Activity Classification working?

by mikeysklar on Mon Dec 07, 2020 6:41 pm

@furusato,

Interesting variety of failures. The most concerning is own reporting example code is also bailing out with the packet error you noted after running for a bit.

Would you mind posting some images of how you have the sensor wired up and what other devices are connected to your Pi?

mikeysklar
 
Posts: 6466
Joined: Mon Aug 01, 2016 8:10 pm

Re: BNO085 Reports: Activity Classification working?

by furusato on Mon Dec 07, 2020 7:53 pm

I've attached a photo of the KR01 robot. The BNO085 is attached at the top of the 25cm mast using only non-ferrous materials.

KR01-0666.jpg
Photo of KR01 robot showing BNO085 at top of mast
KR01-0666.jpg (439.77 KiB) Viewed 747 times


There's also a BNO055 (which used to be up on that mast), currently velcroed to the top of the Makita battery. It surprisingly doesn't seem to be too affected by that. Most of the robot sensors are connected via I2C using the Pimoroni Breakout Garden connectors.

The test results are the same regardless of how many I2C devices are connected, or quiescent, i.e., if I disconnect all the easily-disconnected devices. The results seem to be entirely related to the board itself. I've found the board seems a bit more stable if I give it a 5 second settle time before making requests, but will still display a PacketError on occasion. This success:failure ratio doesn't seem related to how fast I query the board, whether 0.1 or 1.0 second is about the same, indeed, if I just query the board with no delay whatsoever failure rate is about the same.

If you're not able to replicate my results I can move the sensor over to a bare Raspberry Pi test bed I keep around for such purposes, but I think the results will likely be the same.

furusato
 
Posts: 31
Joined: Tue Nov 05, 2019 7:42 pm

Re: BNO085 Reports: Activity Classification working?

by furusato on Mon Dec 07, 2020 8:26 pm

One other thing I've noted that I forgot to mention: sometimes the BNO085 will "lock up" and just send on the last magnetometer output regardless of robot heading.

I.e., it will still let me call self._bno.magnetic and not fail but just send the same result, over and over. Once it's in that state I'll get this static result but no exceptions are thrown, e.g.,

Code: Select all | TOGGLE FULL SIZE
2020-12-08T13:18:44.809.415817Z   : bno085            : INFO  : Activity:      Still
2020-12-08T13:18:44.809.998512Z   : bno085            : INFO  : Confidence:    97%
2020-12-08T13:18:44.811.914444Z   : bno085            : INFO  : Stability:     On Table
2020-12-08T13:18:44.823.378325Z   : bno085            : INFO  : Calibration:   Low Accuracy (1)
2020-12-08T13:18:44.825.408697Z   : bno085            : INFO  : mag   heading:  5.22°
2020-12-08T13:18:44.830.990553Z   : bno085            : INFO  : quat   heading:  4.61°   p=0.0506    r=-0.0551    y=-0.0280
2020-12-08T13:18:44.833.940268Z   : bno085            : INFO  : gm-quat   heading:  6.16°   p=0.0530    r=-0.0525    y=-0.0761
.
2020-12-08T13:18:45.86.487532Z   : bno085            : INFO  : Activity:      Still
2020-12-08T13:18:45.87.066174Z   : bno085            : INFO  : Confidence:    97%
2020-12-08T13:18:45.89.022875Z   : bno085            : INFO  : Stability:     On Table
2020-12-08T13:18:45.100.508690Z   : bno085            : INFO  : Calibration:   Low Accuracy (1)
2020-12-08T13:18:45.102.504492Z   : bno085            : INFO  : mag   heading:  5.22°
2020-12-08T13:18:45.108.062029Z   : bno085            : INFO  : quat   heading:  4.61°   p=0.0506    r=-0.0551    y=-0.0280
2020-12-08T13:18:45.111.008167Z   : bno085            : INFO  : gm-quat   heading:  6.16°   p=0.0530    r=-0.0525    y=-0.0761


...and then "5.22°" on and on forever until I Ctrl-C out of the program.

The code for this is at: https://github.com/ifurusato/ros, test file is bno08x_test.py, which calls (among others) ./lib/bno08x.py

furusato
 
Posts: 31
Joined: Tue Nov 05, 2019 7:42 pm

Re: BNO085 Reports: Activity Classification working?

by mikeysklar on Tue Dec 08, 2020 5:34 pm

What a cool project. Thanks for the photo and link to the github site. Your NZ robotics club sounds awesome.

Do you think that it is worth testing the BNO085 in isolation with the Pi and example scripts? Disconnected from the robot mast and using minimal cable lengths to confirm that the hardware and example work can work in a ideal situation?

mikeysklar
 
Posts: 6466
Joined: Mon Aug 01, 2016 8:10 pm

Re: BNO085 Reports: Activity Classification working?

by furusato on Tue Dec 08, 2020 9:19 pm

Thanks for the comments on the KR01 robot and the club. If you're interested, I also maintain a New Zealand Personal Robotics Group (NZPRG) blog.

[Note that this is a summary of first, my own code; then running the bno08x_more_reports.py example file. Result: my own code works relatively reliably now after a few initial errors, whereas the bno08x_more_reports.py has basically the same problems either on the KR01 or on the simplified test bed, so this doesn't seem to be related to hardware.]

Well, I took your suggestion to heart and made up a 12cm four wire cable and connected it to a Pi Zero W I use for a test bed, see photo (the ThunderBorg motor controller is not connected).

piz-0687-1100w.jpg
Photo of Pi Zero W test rig
piz-0687-1100w.jpg (490 KiB) Viewed 713 times


I then pulled the latest code for my project (including the Adafruit bno08x_more_reports.py file) from github and tried it out.

A portion of the results from the Pi Zero test are shown below (hex data elided for brevity):

Code: Select all | TOGGLE FULL SIZE
2020-12-09T12:34:19.311.745882Z   : configloader      : INFO  : ready.
2020-12-09T12:34:19.315.822840Z   : configloader      : INFO  : reading from yaml configuration file config.yaml...
2020-12-09T12:34:21.354.160547Z   : configloader      : INFO  : configuration read.
2020-12-09T12:34:21.359.783411Z   : msgfactory        : INFO  : ready.
2020-12-09T12:34:21.370.889425Z   : queue             : INFO  : MessageQueue ready.
2020-12-09T12:34:21.379.912138Z   : bno085            : INFO  : heading trim:   -90.00°
2020-12-09T12:34:21.390.186310Z   : bno085            : INFO  : pitch trim:       0.00°
2020-12-09T12:34:21.397.230148Z   : bno085            : INFO  : roll trim:        0.00°
2020-12-09T12:34:22.524.866581Z   : bno085            : INFO  : settle time... (3s)
2020-12-09T12:34:25.531.641245Z   : bno085            : INFO  : begin configuration/calibration...
2020-12-09T12:34:25.671.143055Z   : bno085            : INFO  : setting features...
2020-12-09T12:34:25.675.808907Z   : bno085            : INFO  : feature 1
2020-12-09T12:34:25.846.177578Z   : bno085            : INFO  : feature 2
2020-12-09T12:34:25.965.607643Z   : bno085            : INFO  : feature 3
2020-12-09T12:34:26.30.396938Z   : bno085            : INFO  : feature 5
2020-12-09T12:34:26.77.958584Z   : bno085            : INFO  : feature 9
2020-12-09T12:34:26.133.542061Z   : bno085            : INFO  : feature 19
2020-12-09T12:34:26.188.241720Z   : bno085            : INFO  : feature 30

      ********** Packet *************
DBG::       HEADER:
DBG::       Data Len: 15
DBG::       Channel: INPUT_SENSOR_REPORTS (3)
DBG::          ** UNKNOWN Report Type **: 0x7b
DBG::       Sequence number: 131

DBG::       Data:
DBG::      [0x04] 0x7B 0x31 0x00 0x00
DBG::      [0x08] 0x00 0x03 0x08 0x01
DBG::      [0x0C] 0x00 0x9F 0xFF 0xEE
DBG::      [0x10] 0x00 0xA7 0x01
      *******************************

2020-12-09T12:34:26.424.384832Z   : bno085            : ERROR : error setting features: 123
2020-12-09T12:34:26.430.443764Z   : bno085            : INFO  : calibration done
2020-12-09T12:34:26.436.772585Z   : bno085            : INFO  : ready.
2020-12-09T12:34:26.445.794582Z   : rot-test          : INFO  : starting BNO08x read loop...

      ********** Packet *************
DBG::       HEADER:
DBG::       Data Len: 79
DBG::       Channel: INPUT_SENSOR_REPORTS (3)
DBG::          Report Type: BASE_TIMESTAMP (0xfb)
DBG::          Sensor Report Type: ACCELEROMETER(0x1)
DBG::       Sequence number: 9

DBG::       Data:
DBG::      [0x04] 0xFB 0xF6 0x01 0x00
DBG::      [0x08] 0x00 0x01 0x0F 0x02
[...]
DBG::      [0x4C] 0xFF 0xFF 0xFF 0xFF
DBG::      [0x50] 0xFF 0xFF 0xFF
      *******************************

2020-12-09T12:34:26.491.055012Z   : bno085            : ERROR : bno08x key error: 255
2020-12-09T12:34:26.494.703054Z   : rot-test          : WARN  : [  1] result: NA
2020-12-09T12:34:26.754.839897Z   : bno085            : ERROR : bno08x OS error: [Errno 121] Remote I/O error
2020-12-09T12:34:26.758.069992Z   : rot-test          : WARN  : [  2] result: NA

      ********** Packet *************
DBG::       HEADER:
DBG::       Data Len: 272
DBG::       Channel: SHTP_COMMAND (0)
DBG::       Sequence number: 2

DBG::       Data:
DBG::      [0x04] 0x00 0x01 0x04 0x00
DBG::      [0x08] 0x00 0x00 0x00 0x80
[...]
DBG::      [0x10C] 0x27 0x00 0x28 0x0E
DBG::      [0x110] 0x29 0x0C 0x2A 0x0E
      *******************************

2020-12-09T12:34:27.64.732313Z   : bno085            : ERROR : bno08x key error: 0
2020-12-09T12:34:27.70.476294Z   : rot-test          : WARN  : [  3] result: NA

      ********** Packet *************
DBG::       HEADER:
DBG::       Data Len: 1
DBG::       Channel: EXE (1)
DBG::       Sequence number: 2

DBG::       Data:
DBG::      [0x04] 0x01
      *******************************

2020-12-09T12:34:27.350.332022Z   : bno085            : ERROR : bno08x runtime error: ('Unprocessable Batch bytes', 1)
2020-12-09T12:34:27.362.556696Z   : rot-test          : WARN  : [  4] result: NA
2020-12-09T12:34:27.631.402493Z   : bno085            : INFO  : heading:  22.89°   (magneto)
2020-12-09T12:34:27.654.457331Z   : bno085            : INFO  : heading:  16.39°   (rot-quat)   p=0.0405    r=-0.0125    y=-0.2826
2020-12-09T12:34:27.673.666954Z   : bno085            : INFO  : heading:  17.28°   (geo-quat)   p=0.0414    r=-0.0124    y=-0.2983
2020-12-09T12:34:27.688.139915Z   : rot-test          : INFO  : [  5] result: 22.89 | -0.01 | -0.04 |   4 errors.
[...after 394 loops...]
2020-12-09T12:36:25.861.465454Z   : bno085            : INFO  : heading:  22.89°   (magneto)
2020-12-09T12:36:25.881.712198Z   : bno085            : INFO  : heading:  16.39°   (rot-quat)   p=0.0405    r=-0.0125    y=-0.2826
2020-12-09T12:36:25.902.024984Z   : bno085            : INFO  : heading:  17.28°   (geo-quat)   p=0.0414    r=-0.0124    y=-0.2983
2020-12-09T12:36:25.912.461996Z   : rot-test          : INFO  : [394] result: 22.89 | -0.01 | -0.04 |   4 errors.
2020-12-09T12:36:26.176.008701Z   : bno085            : INFO  : heading:  22.89°   (magneto)
2020-12-09T12:36:26.188.850641Z   : bno085            : INFO  : heading:  16.39°   (rot-quat)   p=0.0405    r=-0.0125    y=-0.2826
2020-12-09T12:36:26.202.451468Z   : bno085            : INFO  : heading:  17.28°   (geo-quat)   p=0.0414    r=-0.0124    y=-0.2983
2020-12-09T12:36:26.209.221601Z   : rot-test          : INFO  : [395] result: 22.89 | -0.01 | -0.04 |   4 errors.
...


So after the burps at the beginning it seems to loop indefinitely without the kinds of issues I'd seen previously, when connected via a 30cm cable. These initial errors seem related to enabling and/or configuring features, more on that below.

The next step was to mount the BNO085 to the Pi Zero W test bed using the same 30cm cable and sensor stalk as is used on the KR01 robot. I was surprised to learn that the result is basically the same as the shorter cable -- so this had no obvious connection to cable length -- which would indicate this might be something in the environment on the KR01. So I put the stalk and BNO085 back on the KR01 and the result is surprising: the same, i.e., things are now kinda working. After that initial 4-5 errors it seems to run okay. I'm currently looking at the console output and it's up to over 700 calls with just those initial 4 errors. But every once in awhile it pops out an error or two, rarely and intermittently. Not predictable.

So while playing around with test code for the sensor I've accidentally fixed most of the problem, which appears to be in software. What have I done, code-wise, since I first started the thread? I'm not sure what "improvements" I've made, but something has made a difference. The main gist of my changes are that I'm enabling features in a loop, with a bit of time delay between and an initial setting time. I'm also calling bno.begin_calibration() before enabling features. Again, it's unclear what changes have made this difference.

I found a few clues when coming back to the Adafruit bno08x_more_reports.py file, which will consistently die on startup with a KeyError of 123 while trying to enable a feature. The specific feature may vary, sometimes adafruit_bno08x.BNO_REPORT_LINEAR_ACCELERATION, other times adafruit_bno08x.BNO_REPORT_ACTIVITY_CLASSIFIER, seems really to be any of them.

Once it managed to loop maybe five times before dying on the Raw Acceleration report with a KeyError: 255. A typical stack trace is as follows:

Code: Select all | TOGGLE FULL SIZE
      ********** Packet *************
DBG::       HEADER:
DBG::       Data Len: 19
DBG::       Channel: INPUT_SENSOR_REPORTS (3)
DBG::          ** UNKNOWN Report Type **: 0x7b
DBG::       Sequence number: 44

DBG::       Data:
DBG::      [0x04] 0x7B 0x2D 0x00 0x00
DBG::      [0x08] 0x00 0x05 0x00 0x00
DBG::      [0x0C] 0x00 0x7B 0xFF 0xEB
DBG::      [0x10] 0x00 0xFE 0xFF 0xFE
DBG::      [0x14] 0x3F 0x44 0x32
      *******************************

Traceback (most recent call last):
  File "bno08x_more_reports.py", line 46, in <module>
    bno.enable_feature(adafruit_bno08x.BNO_REPORT_GEOMAGNETIC_ROTATION_VECTOR)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 975, in enable_feature
    self._process_available_packets(max_packets=10)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 783, in _process_available_packets
    self._handle_packet(new_packet)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 841, in _handle_packet
    raise error
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 836, in _handle_packet
    _separate_batch(packet, self._packet_slices)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 351, in _separate_batch
    required_bytes = _report_length(report_id)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bno08x/__init__.py", line 340, in _report_length
    return _AVAIL_SENSOR_REPORTS[report_id][2]
KeyError: 123


Basically a serialisation of a PacketError followed by the stack trace. From what I can see in the code, enabling a specific report checks for any dependent features. You can find this in the __init__.py file where you'll see a spelling error of "depencency". My guess is the dependent features aren't getting enabled, are getting enabled too quickly, or in the wrong order? I can't tell if this is truly an IO error or logic, but my own code seems to somehow get started up okay, maybe because I'm not trying to run up all of the reports. I've checked in my modifications to the bno08x_more_reports.py file. I've been playing with putting slight delays around enabling the features, and have improved it from enabling just a couple before dying to enabling about ten. This may be due to timing, feature load order issues, or due to one or more of the reports having some kind of conflicting dependencies. It does seem to be related to time though. At least it doesn't seem to be a hardware issue. I've pushed my version of the reports file to: https://github.com/ifurusato/ros/blob/master/bno08x_more_reports.py

Sorry I wasn't able to find the crux of this one. I'm probably like you in not liking any mystery when it comes to hardware and software: if something works or doesn't work I'd really like to know why. And this one is enough of a black box that it's hard to know what's actually happening deep in its tiny little brain.

furusato
 
Posts: 31
Joined: Tue Nov 05, 2019 7:42 pm

Re: BNO085 Reports: Activity Classification working?

by mikeysklar on Thu Dec 10, 2020 5:57 pm

Nice troubleshooting and at least things are becoming more stable. The extra delays sounds like a significant improvement. While this does not at all sound like a wire length issue it could have been a lose connection that was resolved. Really hard to say with so many confounding factors.

So happy to see robotics enthusiasts from NZ here. Keep up the good work!

mikeysklar
 
Posts: 6466
Joined: Mon Aug 01, 2016 8:10 pm

Re: BNO085 Reports: Activity Classification working?

by Wardnb on Wed Mar 31, 2021 5:46 pm

I am playing with the BNO085 as well and was getting the same errors on I2C. I saw somewhere that they suggested setting the clock to 400k and I did that at the CLI, but it doesn't seem to have applied that way. I continued to have the errors until I updated the parameter in /boot/config.txt using this line: dtparam=i2c_arm=on,i2c_arm_baudrate=400000

I hope you already figured this out, but that worked for me, I can run the loop as fast as I want without a problem. I have been running it at a .1 second interval for maybe like 20min now and it's running smoothly.

Wardnb
 
Posts: 3
Joined: Wed Mar 24, 2021 7:56 pm

Re: BNO085 Reports: Activity Classification working?

by mikeysklar on Thu Apr 01, 2021 2:41 pm

Interesting that a higher i2c baud rate of 400kHz versus the default of 100kHz would help. Do you think this is specific to the BNO085 performing better at higher frequency?

mikeysklar
 
Posts: 6466
Joined: Mon Aug 01, 2016 8:10 pm

Re: BNO085 Reports: Activity Classification working?

by Wardnb on Thu Apr 01, 2021 3:04 pm

I am not sure really, I am still learning, but I know I had similar issues with drone flight controllers and mag data. I wonder if the device is trying to push data faster than the default i2c bus can handle at the default rate and gets out of sync maybe?

This page does mention it works best at 400kz, but that command did not work for me, I needed to manually set it in the config.txt.
https://learn.adafruit.com/adafruit-9-d ... cuitpython

Wardnb
 
Posts: 3
Joined: Wed Mar 24, 2021 7:56 pm

Re: BNO085 Reports: Activity Classification working?

by furusato on Thu Apr 01, 2021 3:11 pm

The BNO055 and BNO085 use the same sensor hardware but their software is pretty different, and in my own tests they perform quite differently and their libraries are constructed differently. I've used both only via I2C so I can't speak to UART but I'm under the impression that they are pull commands, not push, so I don't think bus speed would impact upon quality, certainly not an increase in bus speed. So that's a bit of a mystery.

furusato
 
Posts: 31
Joined: Tue Nov 05, 2019 7:42 pm

Please be positive and constructive with your questions and comments.


cron