Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some thoughts on the BNO055 Sensor #86

Open
ronzeiller opened this issue Nov 30, 2017 · 4 comments
Open

Some thoughts on the BNO055 Sensor #86

ronzeiller opened this issue Nov 30, 2017 · 4 comments
Labels

Comments

@ronzeiller
Copy link
Contributor

ronzeiller commented Nov 30, 2017

Intro:

Many boats have an autopilot with an electronic compass, which serves HDG values. Not so common are heel and pitch. As heel (roll) is needed to calculate leeway it is a must have on a boat to get more control to trim of sails for more performance sailing.

The BNO055:

it is certainly a great fusion sensor for many applications, but I am not sure if it is realy a good sensor for navigation.
The big disadvantage is, that the sensor should keep on moving to self-calibrate. If the sensor is just turned on without any movement you do not get relieable values for HDG. Heel and pitch is not that susceptible to external disturbances therefore the values are more trusted, even with less movements of the sensor.

The BNO055 and KBox:

Personally I am not sure, if the sensor is as good in upright mounting position as it is laying.
The data sheets do not give any information for upright remapping of the axis.
(The sensors inside the BNO055 have some orientation of course and have different sensibility to z and x/y axis. If this is compensated in fusion mode? I do not know. We probably should contact Bosch in that matter.)

Placement of BNO055

(added 3.1.2018)
Forum discussion about Placement of BNO055 for vertical placement:

Beware that the BNO055's Euler output is incorrect at moderate to steep pitch and roll orientations. If you plan to tilt the sensor more than about 20 degrees, I recommend using the quaternion output instead.

https://forums.adafruit.com/viewtopic.php?f=25&t=108290&p=541754#p541754

Quaternions vs. Euler Angles

FAQs on Adafruit says:

According to Bosch BNO055 Euler angle output should only be used for eCompass, where pitch and roll stay below 45 degrees.
For absolute orientation, quaternions should always be used, and they can be converted to Euler angles at the last moment via the .toEuler() helper function in quaternion.h

https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/faqs
https://www.allaboutcircuits.com/projects/bosch-absolute-orientation-sensor-bno055/

image
Image (c) BOSCH from the Quick Guide

The other point is, that the sensor should be calibrated after each power on!

Some users mentioned this on forums and I discovered the same, that the sensor sometimes is switching +/- 180 degrees!
May be it has something to do with the fusion mode itself and the (probably) built in Kalman filter which is "running away" if the sensor is not calibrated (moved) after power on.

System Calibration

(added on 2.1.2018)
As long as the sysCalibration = 0 the BNO055 did not find magnetic north. After finding north the value might jump to magnetic north.
Therefore the code is extended that sysCalibration value must be > 0 for all value readings.
https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/device-calibration

The BNO has no internal EEPROM, so values must be stored to teensy's EEPROM.
Adafruit believes that the calibration can be restored, but there is strong evidence in the net, that this is wrong!
When the sensor is moved (turned) when in the no-power state, than the stored calibration values can not be ok.

KBox software side:

In the quick start is mentioned, that calibration of 2 is still quite ok and calibration value 1 should be signaled to the user, that the sensor should be calibrated again (e.g. by the figure 8 movement for heading).

  • I think, we should separate the two measurement outputs HDG and heel/pitch to their own calibration values.
  • And we should display the cal-values on the IMU-Monitor-Page too.
  • So we can output at least heel and pitch (trim) with trusted values, even when HDG has gone. (As it stops output if cal-value is < 3 anyway)
  • I would like to "invent" a just internal used Signal K JSON for the IMU sensor cals (e.g. SKPathKboxImuSensorMagCal / kbox.imuSensor.magCal....), which we could send to the Hub. So we could do the sensor check for the display (display HDG in red as warning etc.) completely separate of check for building the NMEA0183 and NMEA2000 sentence which should not go out if cal < 2 or 3.

Sources:

Quick Start Guide: https://ae-bst.resource.bosch.com/media/_tech/media/application_notes/BST-BNO055-AN007-00_Quick_Start_Guide.pdf
Calibration: https://www.youtube.com/watch?v=Bw0WuAyGsnY
Datasheet: https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST_BNO055_DS000_14.pdf
Adafruit: https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview

It would be very interesting to get feedback from other users in this matter, especially on HDG-datas. May be the movement of a boat is always big enough to keep the BNO055 well calibrated!

@sarfata
Copy link
Owner

sarfata commented Dec 1, 2017

I think, we should separate the two measurement outputs HDG and heel/pitch to their own calibration values.

OK. We can try that.

And we should display the cal-values on the IMU-Monitor-Page too.

Yes.

So we can output at least heel and pitch (trim) with trusted values, even when HDG has gone. (As it stops output if cal-value is < 3 anyway)
I would like to "invent" a just internal used Signal K JSON for the IMU sensor cals (e.g. SKPathKboxImuSensorMagCal / kbox.imuSensor.magCal....), which we could send to the Hub. So we could do the sensor check for the display (display HDG in red as warning etc.) completely separate of check for building the NMEA0183 and NMEA2000 sentence which should not go out if cal < 2 or 3.

I think in this case a better way to do this is to pass a reference to the IMUService when creating the IMUPage. And the IMUPage will use a method on the IMUService to get calibration status.

@sarfata
Copy link
Owner

sarfata commented Dec 1, 2017

I had never seen this calibration video. It's great and I love that the guys is wearing a pebble watch ;)

@ronzeiller
Copy link
Contributor Author

@sarfata
Update to BNO055 sensor:
I took my Adafruit BNO055 breakout and put it on a cable to bring it away from all the electronic parts.
Now it is connected to 3V and pins 29/30on Teensy.
Then I was taking a compass and I was really surprised how much magnetic things are around and below(!!) my desk. So I had to find a clean magnetic place for my tests.

Now the BNO055 is working much better. Also calibration is much easier now then shaking the whole box.

@ronzeiller
Copy link
Contributor Author

Update 2 to BNO055 sensor:
was nice looking at it but a simple test by putting the sensor to different positions, let's say , well measured 30° steps (with a precise compass, and no surrounding magnetic disturbances) showed shocking bad values.
Now I kicked out the BNO055 on my "KBox" and go for an external IMU sensor to read on serial input.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants