Bosch Sensortec Community

cancel
Showing results for
Did you mean:
SOLVED

BNO055 Calculating position datas (x,y,z) based on accelerometer datas

Member

Hi all,

I am working with the BNO055 (Adafruit  9-DOF Absolute Orientation) and Arduino Uno. First I calibrate the system completely (gyro=3, mag=3, accel=3, system=3). If I lay down the sensor without any movement and vibration on the table all gravity-vector components g(x),g(y),g(z) are not stable and the sum of them isnt 9,81 m/s2. Also the angle-velocity shows a lot of drift in each direction. The most relevant physical variable is the linear acceleration (movement without any gravity influence). But their 3 components a(x), a(y), a(z) shows a lot of drift too. Only the 3 Euler-angles are constant.

If I calculate the velocity and the distance (in x,y, and z-direction) the position change all over the time, but the sensor is completely immobile. The acceleration datas are drifting and in that way there is no basis for calculation the 3D-translations and 3D-positions. Because of those values I cant believe that this sensor (BNO055) is accurate enough to be used in any case for orientation-oberservations.

I tried to write new sketches for the sensor, e.g. measuring the time-consumption for 1 loop (delta t). But s(x)=0,5*a(x)*delta t * delta t (for y and z also) is increasing steadily by immobile sensor. Is delta t to small the sensor doesnt notice any movement, if its too big there is no accuracy. The acceleration datas are changing all the time, drifting in one direction. The position is never stable by immobile sensor. I would like to use this system for a navigation system to calculate precise positions and orientations all the time during moving the sensor. For immobile sensor I could implement a zero offset, e.g. a horizontal straigthened sensor should get g(x) =0, g(y)=0 and g(z)=9,81 m/s2, then delta x, delta y and delta z =0. But most of the time in the navigation application the sensor moves......

Could somebody give an idea or proposal what to do?

Have a nice weekend, thanks in advance, best regards, MichaelA

4 REPLIES 4
Community Moderator

Hi,

Thanks for your inquiry. BNO055 is very stable to output NDOF sensor fusion results such as quaternions, Euler angles (pitch/roll/heading), gravity vector and linear acceleration. It is not suitable for positioning by double integrating the linear acceleration output, because with any tiny noise of linear accelration data the position results will quickly accumulate to large errors even when BNO055 is not moving. You should think about other ways for positioning, for example RF beacons, ultrasonic, etc.

Thanks.

Member

Like you, I dreamed of using the BNO055 as an accurate position estimator for my home robot, even though I had read university level research papers that were using Kalman filtering of various IMUs were seeing 5% error.  I have abandoned that dream.

Even more dissappointing is that testing on my robot, has shown the wheel encoders may be more consistent estimators of rotations.

Update 3: Docked Heading per IMU: 355.8 Actual Looks like 360 to me:

Started off dock IMU reading 359.4, actual looked like +1 degree to me,
then backed onto dock, IMU reading 355.8, Actual looks like 360 to me.
This is IMUPLUS mode reset 12 hours ago, so roughly 4 degrees drift.

```2020-05-10 14:52|[imulog.py.logMotionStop]heading:   359.4
2020-05-10 21:04|[imulog.py.logMotionStop]heading:   177.8  rotation:   178.4 motion:     2.5 sec errors: 553
2020-05-10 21:05|[imulog.py.logMotionStop]heading:   355.7  rotation:   177.7 motion:     2.4 sec errors: 553
2020-05-10 21:05|[imulog.py.logMotionStop]heading:   355.8  rotation:     0.1 motion:     0.1 sec errors: 553
2020-05-10 21:05|[imulog.py.logMotionStop]heading:   355.7  rotation:    -0.1 motion:     2.7 sec errors: 553
2020-05-10 21:05|[imulog.py.logMotionStop]heading:   355.7  rotation:     0.0 motion:     0.3 sec errors: 553
2020-05-10 21:05|[imulog.py.logMotionStop]heading:   355.8  rotation:     0.1 motion:     0.3 sec errors: 553```

For comparison, note the corresponding two +180 degree turns recorded by the wheel encoders -0.1 degrees and -0.7 degrees, versus -1.6 degrees and -2.3 degrees from the IMU!

```2020-05-10 21:04|[wheellog.py.logMotionStop]travel:     0.3 rotation:   179.9 motion:     2.4 sec
2020-05-10 21:05|[wheellog.py.logMotionStop]travel:     0.8 rotation:   179.3 motion:     2.3 sec```

Of course the commanded 180 degree turns are never exactly 180, but both sensors were reading the same turn.

Community Moderator

Hi,

Thank you for the update.

Occasional Visitor

Four degrees of actual drift over several hours sounds very reasonable, unless you are very close to the equator. You can expect from 0-360 degrees drift per 24 hours depending on your latitude, just due to the rotation of the earth.

I've found the error in IMUPlus mode to be much less than one degree if I start at a known direction, turn the unit around a few times, then return to the original direction within a minute or so.

I agree that it is useless for inertial XYZ displacement measurements. Double integrating the acceleration, even when the unit is perfectly still results in a metre of calculated displacement after a few seconds. The orientation measurements however are extremely reliable. Bosch do call it an "absolute orientation sensor", and it does an excellent job in that role.