Assist from Bno055 users on data integrity

41 views
Skip to first unread message

Mark Johnston

unread,
Jan 20, 2021, 3:19:45 PM1/20/21
to HomeBrew Robotics Club
Not having done deep dive into the datasheet I wonder about these Bno055 things:

- Has anybody seen very infrequent but present 'wacky' values from the NDOF_MODE fusion readings?  You may be running for a minute or more and out of the blue some wild velocity reading well out of 3 sigma spikes for one reading?

- Has anybody experience that indicates there may be some form of checksum related piece of the data for accel/gyro readings or the built in fusion readings?

I ask the checksum thing because I tend to be uncomfortable with little subsystems (such as Bno055 M0 processor)  sending data packets over some interface (I2C or SPI or Serial) and not having a way to verify the data in the reading(s) is not corrupt.

I will go back into datasheet of course but wanted to do a ping out to the fine users we have here for any experiences on Bno055

Thank You,
Mark

Chuck Taylor

unread,
Jan 20, 2021, 11:34:54 PM1/20/21
to HomeBrew Robotics Club
I have been using the Bno055 on the Adafruit "9-DOF Absolute Orientation IMU Fusion Breakout board. $39 
I only use Yaw but I have been getting reliable data to support odometry for map generation.
I have it attached to a Arduino mega and use the Arduino library for "Adafruit bno055 ".
 If fact this is currently my favorite IMU right now. Its the only IMU I have never needed to calibrate, so far.
I don't know what your error is but I have only used IMUs for attitude. I have never tried to estimate position or velocity yet.
Good Luck

Charles Sun

unread,
Jan 21, 2021, 1:12:09 AM1/21/21
to hbrob...@googlegroups.com
I evaluated BNO055 sometime ago.
It is good but still has a small drift.
My Arduino/serial test code here:  
> --
> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/1911a979-1a0b-488d-9ea4-1a48177b99f7n%40googlegroups.com.

Mark Johnston

unread,
Jan 21, 2021, 8:55:51 PM1/21/21
to HomeBrew Robotics Club
So to shed a bit more light here is the issue in depth for anybody who is curious.   It appears to be Fusion mode specific.

The Bno055s I am using (this has been shown on the 2 IMUs tested on a custom board in I2C mode on Raspberry Pi 4.

BN0055 Information at Fri Jan 22 01:43:07 2021
----------------------------------------------
   Chip Version ID = 0xA0
  Accelerometer ID = 0x7B
      Gyroscope ID = 0x0F
   Magnetoscope ID = 0xB2
  Software Version = 3.17
   Operations Mode = NDOF_FMC
        Power Mode = NORMAL

What we see is that on intervals of 12 seconds (not exactly) we see the  orientation.x return value (which is a fusion enabled output)  take a jump then return to normal.
We are currently putting in a filter to ignore sudden returns out of 3 sigma from the running average.    This 'fixes' things but IMHO is 'flakey, sweep it under the rug' stuff.
I am thus trying to understand why this may happen based on sample rate, length of internal Bno055 buffers and in short all manor of 'software' related settings or features.

I have run the device with no xtal and with xtal.  With xtal it seems to be mostly about every 15 sec.   This leads me to believe it is not some Pi4 specific issue because if something woke up every X seconds and messed up I2C then it would not follow my starting to use a xtal on my tiny little IMU pc board I made at JLCPCB and have discussed here recently but that is beside the point, I often make boards through JLCPCB.  (separate threads).

This Bno055 runs even in totally static fixed bench situation and in a robot but always it is like every 12 seconds it puts out a totally WACK value.  To me this really 'stinks' of some sort of software rolling around on some index or buffer or something but I wanted to ask if anybody else has seen FUSION mode really ODD values pop up regularly.

Also I want to note that the really ODD values for orientation.x in Fusion mode seem to be at very distinct quanta and not just 'all over the map'.   I am doing analysis in much more detail looking at over the wire values and so on but this was a query to ask if anybody sees odd values periodically using Fusion NDOF mode on the Bno055.  That is all.

I am looking at system specific things and also open to consider that there is some bug in the firmware of the Bno055.  Recall that it is a M0 inside gizmo.

Thus only if you have seen such semi-repeatable odd behavior you need respond.    

Sergei Grichine

unread,
Jan 21, 2021, 9:46:29 PM1/21/21
to hbrob...@googlegroups.com
From the guy who hasn't used Bno055, but have met gremlins before:

1. if the I2C from RPi is a suspect (and it should be), why not test it with Arduino to eliminate this possibility?

2. Normally IMU sensors must be calibrated first, which saves correction tables in the chip's memory. After that fusion makes sense and can be done without jumps. What if the gyro drifts (without compensation) so fast, that in 15 seconds the algorithm has to reset it? Is there a way to properly calibrate Bno055?

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/67b023bc-6f64-4e4e-9b17-127c1f018eaen%40googlegroups.com.


--
Best Regards,
-- Sergei

Steve " 'dillo" Okay

unread,
Jan 22, 2021, 10:24:54 AM1/22/21
to HomeBrew Robotics Club
On Thursday, January 21, 2021 at 6:46:29 PM UTC-8 vital...@gmail.com wrote:
From the guy who hasn't used Bno055, but have met gremlins before:

1. if the I2C from RPi is a suspect (and it should be), why not test it with Arduino to eliminate this possibility?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm gonna go with this.  If the problem occurs with a reasonably consistent interval, I would suspect something on the I2C bus or with the Pi itself.
I'm assuming you're running Linux on this Pi, which is not an RTOS and pre-emptively schedules its own house-cleaning tasks whenever it feels like it.
Unless you're running a real-time kernel or see this sort of behavior when hooked up to an Arduino, suspect the OS. 

'dillo

Ralph Gnauck

unread,
Jan 22, 2021, 1:33:16 PM1/22/21
to HomeBrew Robotics Club
Mark -

 I have seen issues with these chips (multiple times on different hardware).  Its kind of a known issue, but not sure it is exactly what you are seeing.

It appears that the chips using IMU mode are susceptible to high acceleration while rotating - this can cause them to get out of whack badly and the orientation to  appear to be tilted over quite significantly.  It takes a few seconds (10s) for them to recover.
No known solution. Using the Mode with the Magnetometer turned on NDOF is apparently much  better and not really susceptible to interference (so long as you don't care about absolute heading).

This is not very obvious if you are only using the chip in 2D mode and ignoring the full 3D orientation (as I think a lot of  peopled do if just using normal ROS Nav. stack) - but just about every one I know who has tried to use the chips for  full 3d orientation has had this issue.


Another known issues is they will fail to properly come out of reset sometimes - only solution is to power cycle them. https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BNO055-power-on-reset-issues/td-p/6192

Not sure if this varies by chip and firmware version so your mileage may vary, looks like they have been releasing new firmware versions in teh chip lately so some of these problems may be fixed now.


As you say you are only seeing issues for one  reading make sure you are reading the registers in the correct order to ensure the  full 16bit values are consistent. 
see section 3.7 in the data sheet


Ralph G.



--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

Mark Johnston

unread,
Jan 22, 2021, 6:48:27 PM1/22/21
to HomeBrew Robotics Club
Dillo:  Agree fully.  Thanks for input.

Ralph:  This reset issue is the most disturbing.  On the board I have already routed lines for the Bno055 RESET hardware line as well as the NBOOT line that can be connected to a separate set of IO lines because I felt it would be 'nice' to have ability to load new firmware.  Now I feel it is beyond 'nice' and in fact better be planned on or endless headaches from on-chip Bno055 firmware may continue.   

I now suspect the folks at Hillcrest labs came out with the Bno08x parts because they came to realize that Bosch was out of it's element and not capable of sound embedded firmware on the 055 (ever).    The board I have can also be configured to run Bno080 with xtal which I have run already tried with success just to check the board. So that is an option still for me.    Basically:  Always have a Plan B, in this case there is also a Plan C, Bno08x.

The link on reset appears to focus on reset via the I2C lines but I would be rather shocked if the actual RESET pin itself did not go right to the internal M0 and really reset it.
So this troubles me as I was so far not planning on having to actually 'unplug' and then plug it back in but do have the ability to add that to this expansion board if required.

All these things about reset combined with the chip having to do clock stretch due to it's apparently really crappy internal ability to not be able to separate I2C from the M0 processing really leaves me with a very poor feeling about reliability of this device when the only cure is the age old:   'Did you try power cycling'?   The lowest form of recovery.  Yuch.

Sergei Grichine

unread,
Jan 15, 2023, 10:15:11 AM1/15/23
to hbrob...@googlegroups.com
Reviving this thread, as I just finished experimenting with BNO055 on Raspberry Pi 3B under Ubuntu 22.04 Server 64 bit and ROS2 Humble.

It turns out that there's a good Github repository - which was updated recently to support I2C (it was originally handling UART connection mode only).

Here are my notes.

=========================================================================

BNO055 IMU (via UART or I2C - Python) - seems well supported, active development, ROS2 node:
https://github.com/flynneva/bno055

mkdir -p ~/bno055_ws/src
cd ~/bno055_ws/src/
git clone https://github.com/flynneva/bno055.git
cd ..
colcon build
vi ~/bno055_ws/src/bno055/bno055/params/bno055_params_i2c.yaml   - change i2c_bus to 1. Use i2cdetect -y 1
sudo pip3 install smbus
 
source ~/bno055_ws/install/setup.bash
ros2 run bno055 bno055  --ros-args --params-file ~/bno055_ws/src/bno055/bno055/params/bno055_params_i2c.yaml

=========================================================================

Optionally, a Python launch file:

source ~/bno055_ws/install/setup.bash
ros2 launch ~/launch/bno055_launch.py

ros@turtle:~$ cat ~/launch/bno055_launch.py

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(
            package='bno055',
            namespace='',
            executable='bno055',
            name='bno055',
            output='screen',
            respawn=True,
            respawn_delay=4,
            parameters=[{
                'ros_topic_prefix': '',
                'connection_type': 'i2c',
                'i2c_bus': 1,
                'i2c_addr': 0x28,
                'data_query_frequency': 100,
                'calib_status_frequency': 0.1,
                'frame_id': 'bno055',
                'operation_mode': 0x0C,
                'placement_axis_remap': 'P2',
                'acc_factor': 100.0,
                'mag_factor': 16000000.0,
                'gyr_factor': 900.0,
                'set_offsets': False, # set to true to use offsets below
                'offset_acc': [0xFFEC, 0x00A5, 0xFFE8],
                'offset_mag': [0xFFB4, 0xFE9E, 0x027D],
                'offset_gyr': [0x0002, 0xFFFF, 0xFFFF]
            }]
        )
    ])


To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/9e4b690e-c7e9-4c69-88e0-7b2e1a6a94aan%40googlegroups.com.

Scott Monaghan

unread,
Jan 15, 2023, 2:35:55 PM1/15/23
to hbrob...@googlegroups.com
Hi all,

Not sure of the actual trouble you have had but I have been using the BNO055’s for years with “it just works” reliability.

I always use i2c and the Adafruit Python/CircuitPython libraries. I’ve run them from Feather M4, Jetson Nano Dev Kit, and Raspberry Pi 4.


--

A J

unread,
Jan 15, 2023, 11:04:37 PM1/15/23
to HomeBrew Robotics Club
Hi all,

Have not used the bno055 but did find a reference to clock stretching on the Pi for i2c.

Ross Lunan

unread,
Jan 16, 2023, 7:36:08 PM1/16/23
to HomeBrew Robotics Club
Sergio, Appreciate you posting your work on the Bno055 IMU (and iRobot Create & Kinect). I got this IMU  a couple years ago, but then disappointed there was no I2C code - but now there is! So as I have a "spare" Jetson Nano 2G (that I bought 3 years ago for $69) that is significantly more powerful than a Raspi, I am proceeding with revamping my original Create/Kinect hardware working your new code. I actually got a Kinect Freenect stack working back then on the Nano native UB18 with ROS Melodic. I have now successfully got a Linux Docker running and just installed a "osrf/ros2 Docker Image" that provides a Ubuntu 22.04/ROS2 Humble OS container on the Jetson to install and build Humble packages. There's a some tricky parts to expose the I2C and USB ports from hardware into the Container code, but there's lots  resources explaining how to do that. Last year I built a Nanosaur ( Jetson Nano Nanosaur) which uses a Jetson Nano 2G w/Foxy container that is a great model for the code needed to run a ROS2 Humble Turtlebot-Create base robot. Ross

Scott Monaghan

unread,
Jan 17, 2023, 8:07:54 PM1/17/23
to hbrob...@googlegroups.com
Hi all,

I just wanted to let you all know that I ran into problems tonight getting my BNO055 working with my Pi4 as well (previously I had it working fine with Jetson Nano, and Feather M4 before that).

I did find what appears to be a fix though, at least so far tonight.

I took this advice from the adafruit page re: the 085, and it seems to work wonders for the 055 as well.

NOTE: The BNO85 seems to work best on the Raspberry Pi with an I2C clock frequency of 400kHz. You can make that change by adding this line to your /boot/config.txt file:
dtparam=i2c_arm_baudrate=400000

I hope this is helpful!
On Sun, Jan 15, 2023 at 9:15 AM Sergei Grichine <vital...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVPH2p_ackJ029iGCZZ3oYSWCgAiEhZzhNGCR3GhcRN7SQ%40mail.gmail.com.

Chris Albertson

unread,
Jan 17, 2023, 9:03:41 PM1/17/23
to hbrob...@googlegroups.com
That's odd.  My usual first idea when I have problems is to reduce the clock, nt speed it up.

For example I am working with a rotational sensor, the AS5600.  It is a useful chip.  It you put a tiny magnet of the end of a motor shaft the chip senses the magnetic field as the shaft rotates.  Ther is not mechanical contact and the magnet stick to the shaft all on it's own (but super glue helps.)  Thy cost about $1.25, magnet included.

I was getting some unreliable results.    And the first thing I did was knock the clock rat way down.    That did not fix it.    Then I looked at the size of the magnet to chip air gap.      Now I'm back to CAN system designing a way to make the gap adjustable.    Seem 0.5 mm is about optimal.

Point is, we think it must be communications, but usually it is something else.    With the PCA9685 PWM chip, it turned out, it is just not a high-performance device, it drops data, that is just what it does.

The #1 tool you need is a logic analyser.   This will show you the data in the I2C bus.   I don't think I could find problems without one and they are cheap.   

These work really well amazon.com/Analyzer-Device-Ferrite-Channel...
They are a clone of the Saleae Logic8.  You can download their software and see how it works then if you like spend $11 on the clone or $500 for the Saleae brand.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAMzUCWOThXeZsKJ4GZkXY02XUGDG4FSudpTg-9reahKkf3PAxA%40mail.gmail.com.


--

Chris Albertson
Redondo Beach, California

Sergei Grichine

unread,
Jan 17, 2023, 9:59:58 PM1/17/23
to hbrob...@googlegroups.com
I2C pull-up resistors on SDA and SCL lines are needed.  Most devices already have 10K resistors for convenience. Total value should be between 1K and 10K (considering multiple being in parallel). I like to add 4.7K pull-ups just for reliability. For longer I2C or SPI wires, a 33 Ohm resistor in series to SCLK/SCL line at the microcontroller end might help (it removes bus ringing).

Chris - you may want to check if magnetization of these tiny magnets is proper (along the disk's diameter). Magnets that are commonly available have axial magnetization, and could be put in shipment by mistake. I've used MLX90316 sensors for my projects, and they are very reliable and allow 2-3 mm gap easily. In fact a larger gap helps positioning the sensor in a more uniform/aligned zone of the magnetic field - if the magnet is strong enough, of course.


image.png
image.png

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHu%2B1HuT6VABQt1xGqah6egzvPOdsnLfaVkXKPtjDoewbQ%40mail.gmail.com.

Chris Albertson

unread,
Jan 18, 2023, 12:40:02 AM1/18/23
to hbrob...@googlegroups.com
Part of my problem is that the AS5600 is the cheapest and lowest cost magnetic sensor on the market and sells for 1/4 the price of the next higher priced sensor.     The AS5600 has a register you can read for "field strength" and even with the magnet in contact with the chip I don't get full scale.  The magnet is the correct type but it is 4 mm diameter by 1.5 mm thick.  It is well sized for 4 mm motor shafts.

I am not so broke that I can't afford $4 more for a better sensor, but my goal is to make an MIT mini-Cheetah for the lowest possible cost so I will try to make these work.  The robot needs 12 sensors

Same with the motors,  I just bought one 5010 that should be good for 20 amps for under $20.

In any case, that logic analyser is a no-brainer.  The work for most things you do with robots

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVN8t0%3D%2B7dQ%2BRS0jG-3hDG5%2BypKyXhTftbZS3G%3Dyr%3D49cg%40mail.gmail.com.

A J

unread,
Jan 18, 2023, 1:01:59 AM1/18/23
to HomeBrew Robotics Club
The hall sensor seems to act like a tachometer when put on the side of the 5010. Had to order another motor
with a flat bottom for the as5600. The foc code for open loop seems to work for velocity and position
but need to attach encoder to keep track.

I only have the 6050 imu that does not seem to use the clock stretching but there seem to be many posting related
to the bno055. The purpose of clock stretching seems to be that the sensor will hold the line low to catch up to the
controller board.

Some of the suggestions for the Pi are to use soft i2c but it uses up a lot of cpu power. The other way seems to slow
down the i2c on the pi board. The bosch data sheet does mention the reqs for i2c but some blogs do ref setting the
speed to 400k?


Curious to know how the Motions Processors compare between the bno055 and mpu9250.

Alex Sy

unread,
Jan 18, 2023, 2:54:33 AM1/18/23
to hbrob...@googlegroups.com
I think the 4mm magnet diameter might be too small so the curve of the magnetic field will need the magnet to be very close, plus the shaft itself may affect the field curve.  I used to use 6mm diameterically magnetized magnets which allows them to be slightly farther (1mm) from the AS5600 and I epoxy it to the shaft (I chuck the motor on a lathe, then put the magnet on a tail stock then bring them together to center.them.  Later ended up putting the magnet at the end of the gear train to get the absolute angle of the joint, this also lets me use an aluminum shaft so it does not affect the magnetic field. 
I had to modify 5010 motors to put in 4mm shafts so they protrude thru the mounting base to allow connecting to the GT2 pulley..
image.png
image.png

Alex Sy

unread,
Jan 18, 2023, 3:02:17 AM1/18/23
to hbrob...@googlegroups.com
I found the motion code of the BNO055/BNO085 is way better (closer) than the MPU9250 when compared against a Microstrain IMU.  Also the BNO085 supports offsetting the result time to compensate for processing and communication time but have not tested the accuracy.
----- Original Message -----
From: A J
Sent: Tuesday, January 17, 2023 10:01 PM
Subject: Re: [HBRobotics] Assist from Bno055 users on data integrity

Chris Albertson

unread,
Jan 18, 2023, 1:22:29 PM1/18/23
to hbrob...@googlegroups.com
On Tue, Jan 17, 2023 at 10:02 PM A J <aj48...@gmail.com> wrote:
The hall sensor seems to act like a tachometer when put on the side of the 5010. Had to order another motor
with a flat bottom for the as5600. The foc code for open loop seems to work for velocity and position
but need to attach encoder to keep track.

If you have an encoder why would you use open-loop?

The hall sensor on the edge of the motor trick seems to work at least on some motors.  But you use analog hall-effect sensors, they come in  three-pin packages and sell for under $1.    They produce a sine wave analog output that goes to an ADC pin. 

I'm using 6050 IMU also, I figure I will keep using it until I see a reason not to.  I just happened to have a supply of them from before the chip shortage.   They are noisy but software can do a good job of filtering if the task is robot localization because robots move very slow relative to the sample rate.

Reply all
Reply to author
Forward
0 new messages