Open ronzeiller opened 6 years ago
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.
I had never seen this calibration video. It's great and I love that the guys is wearing a pebble watch ;)
@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.
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.
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:
https://forums.adafruit.com/viewtopic.php?f=25&t=108290&p=541754#p541754
Quaternions vs. Euler Angles
FAQs on Adafruit says:
https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/faqs https://www.allaboutcircuits.com/projects/bosch-absolute-orientation-sensor-bno055/
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).
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!