Nicla Sense ME Orientation values

[xamix]

Description of defect

The orientation sensor on Nicla Sense ME board output bad values.

Target(s) affected by this defect ?

Nicla Sense ME

Toolchain(s) (name and version) displaying this defect ?

Arduino 2.0.0-Rc5

What version of Mbed-os are you using (tag or sha) ?

3.0.1 Arduino OS Nicla Boards
1.0.4 Arduino_BPHY2

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

3.0.1 Arduino OS Nicla Boards
1.0.4 Arduino_BPHY2

How is this defect reproduced ?

Running the following program lead to output bad values on PITCH ROLL and YAW (the values barrely change):

#include "Arduino_BHY2.h"

SensorOrientation orientation(SENSOR_ID_DEVICE_ORI);

void setup(){
  Serial.begin(115200);
  BHY2.begin();
  orientation.begin();
}

void loop(){
  BHY2.update();
  
  Serial.print("orientation :");
  Serial.println(orientation.toString());
  delay(500);
}

Output:

orientation :Orientation values - heading: 1.000   pitch: 14.000   roll: 0.000

Is there anything to do in order to get it work?
Regards.

[giulcioffi]

Hi @xamix, you are using the wrong SensorClass.
SENSOR_ID_DEVICE_ORI returns just a byte of value, since it provides the device orientation: 4 possible values (0,1,2,3). You should initialize it as:
Sensor device_ori(SENSOR_ID_DEVICE_ORI);

SensorOrientation class has been created for SENSOR_ID_ORI which provides the orientation in Euler format.
SensorOrientation ori(SENSOR_ID_ORI);

[xamix]

Hi,

Ho okay I will test that,
However it was a pure copy and paste from the quick start here:

https://docs.arduino.cc/tutorials/nicla-sense-me/getting-started#sensororientation

Is it an error in the docs?

[giulcioffi]

Yes, it is definitely an error and thanks for spotting it. We will fix it asap.
@BenjaminDannegard can you fix it?

[BenjaminDannegard]

@giulcioffi Yes I will fix it. Thanks for letting us know!

[xamix]

Also I have some questions:

1. Do you confirm that the current firmware in BHI260AP is 9Dof (it take magnetometer data) and not only 6Dof?
2. Is it possible to send calibration data or do some calibration for Accelerometer, Gyroscope and Magnetometer (offsets and soft iron) to set into the BHI260AP?

[giulcioffi]

Hi @bstbud, would you like to help @xamix with these questions? Thanks!

[bstbud]

@xamix @giulcioffi

Do you confirm that the current firmware (to be sure, you could use the sketch https://github.com/arduino/nicla-sense-me-fw/tree/main/Arduino_BHY2/examples/BHYFirmwareUpdate to update the latest BHI260 Firmware) in BHI260AP is 9Dof (it take magnetometer data) and not only 6Dof?

[bstbud] yes, the current firmware supports up to 9Dof, but to use the 9DoF fusion result, the correct sensor ID should be used, for example: sensor orientation in Euler (id: 43/44) is 9Dof, and orientation rotation vector (id: 34/35) are also 9Dof, however, orientation game rotation vector (id: 37/38) is 6Dof w/o using the magnetometer. Sometimes the game rotation vector is a better choice if you need only relative orientation and don't want to use results that might be affected by erratic magnetic disturbances, but if you want to use know orientation relative to the magnetic north, the 9DoF variant is the right choice. The proper virtual sensors should be selected based on your application requirements.

Is it possible to send calibration data or do some calibration for Accelerometer, Gyroscope and Magnetometer (offsets and soft iron) to set into the BHI260AP?

[bstbud] there is no need to input calibration data (offsets) to the sensor hub, because the sensor has built-in offset calibration which runs automatically when the virtual sensors are enabled.
for soft iron calibration, as far as the board itself is concerned, the soft-iron effect is pretty trivial and I don't see the need for this, but if you are going to install the board to a larger board which might introduce external soft iron effects, there may be such need to do so, in this case, there is an API: bhy2_set_sic_matrix which is meant for this purpose, and this API could be in routines such as setup() of a sketch to feed in the soft iron correction parameters.

let me know if this helps.

[xamix]

Hi @bstbud,

Thank you very much for all the informations,

I already used the https://github.com/arduino/nicla-sense-me-fw/tree/main/Arduino_BHY2/examples/BHYFirmwareUpdate sketch, and thank you to confirm that it's usefull.

You said:

there is no need to input calibration data (offsets) to the sensor hub, because the sensor has built-in offset calibration which runs automatically when the virtual sensors are enabled.

But what if the board is powered-up while moving, those offsets calibration will be wrong??

For the bhy2_set_sic_matrix function for soft iron cal, I tried to use it, but I need to know the format of the data to send.
In datasheet they said The Calibration state and SIC matrix use a BSX internal binary data format and are not intended to be interpreted by the host

So I don't know the format of data to send...
It seem it's not publicly available as suggested in this thread from Bosh community:
https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BHI260AP-Soft-Iron-Calibration-matrix/td-p/49087

You maybe have more informations on the format?

[xamix]

@BenjaminDannegard
It seem also that the array here https://docs.arduino.cc/tutorials/nicla-sense-me/cheat-sheet#sensor-ids is wrong,
it also say SensorOrientation instead of Sensor for SENSOR_ID_DEVICE_ORI (ID=69)

[bstbud]

Hi @bstbud,

Thank you very much for all the informations,

I already used the https://github.com/arduino/nicla-sense-me-fw/tree/main/Arduino_BHY2/examples/BHYFirmwareUpdate sketch, and thank you to confirm that it's usefull.

You said:

there is no need to input calibration data (offsets) to the sensor hub, because the sensor has built-in offset calibration which runs automatically when the virtual sensors are enabled.

But what if the board is powered-up while moving, those offsets calibration will be wrong??

For the bhy2_set_sic_matrix function for soft iron cal, I tried to use it, but I need to know the format of the data to send. In datasheet they said The Calibration state and SIC matrix use a BSX internal binary data format and are not intended to be interpreted by the host

So I don't know the format of data to send... It seem it's not publicly available as suggested in this thread from Bosh community: https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BHI260AP-Soft-Iron-Calibration-matrix/td-p/49087

You maybe have more informations on the format?

@xamix
But what if the board is powered-up while moving, those offsets calibration will be wrong??

[bstbud] the built-in calibration will constantly monitor the whole state space including the offsets to see if there are changes needed for the offsets, in which case the sensor will notify the user with a calibration status change through the meta events (see datasheet, section 15.3.6 Meta Event: Sensor Status), when the sensor status is not 3 (high), it's an indicator to the user that re-calibration is needed and user need to calibrate the system by some motions (preferably butterfly style, but not mandatory).

is this what you are asking for?

So I don't know the format of data to send...
It seem it's not publicly available as suggested in this thread from Bosch community:
https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BHI260AP-Soft-Iron-Calibration-matrix/td-p/49087

[bstbud] if you see a need to do the soft-iron calibration, which requires professional guidance and support from Bosch, you would need to submit a request through the contact window

[xamix]

@bstbud

is this what you are asking for?

Yes it answer to my question

Finally what do you suggest to use (which Sensor) in order to create a compass application which will continuously indicate the North.
(Do not take into account the declination between geographic and magnetic North for now).

I need to get the position of the North at any time, maybe the use of
SENSOR_ID_GEORV (ID=40, /* Geo-magnetic rotation vector */)?

Thank you for all your help!

[bstbud]

@xamix
to create a compass application, you can use sensors that involve fusion with magnetic sensor which could be 9Dof (accel+gyro+mag) or 6Dof (accel +mag).
For the 9Dof option, you could use Euler (id: 43/44) or orientation rotation vector / quaternions (id: 34/35).
for the 6Dof option, you could use id (40/41).

With the 9Dof, you get best performance (accuracy, magnetic distortion rejection, better dynamics etc) and fast calibration because of contribution from the gyro at the cost of higher power consumption from the gyro and additional computation.
With the 6Dof, you can also get a working compass application with the benefit of lower power consumption.
The decision is really up to your own preferences.

[xamix]

@bstbud

For the id (43) Euler, it output Heading in degrees but it seem it is relative to the start position (Heading is 0°after each reboot of the board, position independant), not to the North, so how to offset this to get the North position?

[bstbud]

@xamix
when the system restarts, you will need to do some calibration with the sensors (because the calibration profile of the sensors are not known yet, a calibration profile means the offset etc of a sensor),
and it's pretty easy to do:
once the sensor (id 43) is enabled, leave the device stationary for about 3 seconds, then rotate the device back and forth, left and right that involves rotation of 3 axes if possible, or simply do a slur of the device like the way you are swinging a racket with mild speed.

there is possibility to reload calibration profiles saved from last calibration if needed and there are APIs to do that.
However, given the calibration is so easy to do and also past magnetic environments might have been invalidated / stale, a recalibration is suggested here.

[djebel-amila]

Hello @xamix and @bstbud ,
I read with great attention this thread. I am trying to get an absolute heading value (angle in degrees from north) from the Nicla Sense ME. I am having troubles differentiationg 9DOF and 6DOF, except for that 9DOF may perform better and fuses more data together.

I am not sure where to start with all the available classes and data format. Is there an example sketch somewhere that reads and prints the Nicla’s absolute orientation? @xamix, do you have by any chance a snippet of code for the compass value?

Thanks!

[bstbud]

Hi
you could refer to the existing example: https://github.com/arduino/nicla-sense-me-fw/blob/main/Arduino_BHY2/examples/Standalone/Standalone.ino on how to print the sensor values.
Specifically for absolute orientation, there is already the example object SensorQuaternion which uses the quaternion format.
If you want to use Euler format of the orientation, you could simple add a new object:
SensorOrientation euler_orientation(SENSOR_ID_ORI);
in the setup();

void setup {
  Serial.begin(115200);
  while(!Serial);

  BHY2.begin();
  euler_orientation.begin();
}

In loop()

void loop() {
    BHY2.update(100);
    Serial.println(String("9DoF Euler orientation: ") + euler_orientation.toString());
}

Hope this helps.

[djebel-amila]

Hi bstbud,

thanks for your answer and advice, thanks to that I can get the euler orientation which is a good starting point!

The orientation value works as expected as long as I keep the Nicla flat horizontally, but when I tilt it (along the pitch or roll axis) it’s hard to tell whether it keeps telling north. But I am guessing that’s what 9DOF suggests, it integrates the accelerometer/gyroscope to always show north even under various position/rotation?

I’d like to attach the Nicla to a smartphone and stream the heading values over Bluetooth to my location based webapp. I’d like to compare the nicla’s compass to that of a smartphone to see if it gives more accurate results.

Thank you for your help.

[bstbud]

Hi @djebel-amila

Assuming you have done the calibration, when you are tilting the device, the Euler orientation still gives you north, with some restrictions, i.e., you can only tilt or pitch the device less than 90 degrees, and this is due to an intrinsic limitation with Euler representation of orientation. You could learn more info about gimbal lock issue (e.g.: from wikipedia). This restriction exists as long as you are using Euler, and it has nothing to do with 9DOF. 9DOF does bring a lot of advantages such as faster calibration, better dynamics (less delays), better accuracies and stabilities (such as disturbance rejections), but it won't overcome the gimbal lock issue governed by math/physic laws.

With quaternion representation of the same orientation, you don't have such a limitation. The quaternion is not as human friendly because it's kind of hard to interpret just by human eyes. However, it's friendly to machines/3D rendering engines.

The other point you want to keep in mind is that, when you attaching the Nicla to the phone, there are many sources of magnetic disturbances from different components from the phone such as camera, speaker, charging coil etc and they may disturb or distort the mag flux and hence the orientation result around the Nicla. So you have to note about that.