SzabolcsGergely
commented
2 years ago I would expect the coordinate system for acceleration and gravity to be shared as documented in IMU datasheet section 2. Since gravity is derived from the raw accelerometer. Meaning I would e:xpect: accelerometer_linear + gravity = accelerometer. But that is not possible given the actual data being output via depthai APIs.
This indeed should be the case, as a matter of fact, I tested on several boards, and the coordinate system is the same for gravity/accelerometer. Here is the test script.
Can you set DEPTHAI_LEVEL=info and confirm that the IMU FW version is the following:
[IMU(0)] [info] IMU product ID:
[IMU(0)] [info] Part 10004148 : Version 3.9.7 Build 224
[IMU(0)] [info] Part 10003606 : Version 1.7.3 Build 337
[IMU(0)] [info] Part 10004135 : Version 5.5.1 Build 159
[IMU(0)] [info] Part 10004149 : Version 5.1.11 Build 182
Currently we don't calibrate IMU, so no extrinsic calibration or static/dynamic calibration is performed therefore there are differences between boards/accuracy. We expect to add IMU calibration next year in Q1.
diablodale
chengguizi
Data returned from an IMU node is not consistent with Earth gravity of 9.81 m/s^2 on the Y-axis. My OAK-D instead returns a vector magnitude value 10.20799. And the gravity component changes between X and Y axes. Please reference the IMU Datasheet provided by Luxonis https://www.ceva-dsp.com/wp-content/uploads/2019/10/BNO080_085-Datasheet.pdf
Setup
Repro
imu_gyroscope_accelerometer.exeResult
The magnitude of the accelerometer data above is 10.20799 which is 4% larger than expected. The IMU datasheets claims an accuracy of 0.3 m/s^2. 10.20799 - 9.81 = 0.39799 making it outside the datasheet's accuracy claim and 5% larger than expected 9.81.
This unexpected accelerometer data is seen in all enums ACCELEROMETER, ACCELEROMETER_RAW, and GRAVITY In a separate app I wrote, I see the same errors across different outputs...
In addition, the gravity component (very likely the 10.1 value) changes between the X and Y axes depending on what output is chosen with
enum class dai::IMUSensor. This is unexpected and not in alignment with the IMU datasheet section 2 which specifies a fixed coordinate system. This would then make it impossible for the gravity component to change axes.Expected
At rest, the normal of the x,y,z vector from the accelerometer should be ~9.81.
I would expect the coordinate system for acceleration and gravity to be shared as documented in IMU datasheet section 2. Since gravity is derived from the raw accelerometer. Meaning I would e:xpect: accelerometer_linear + gravity = accelerometer. But that is not possible given the actual data being output via depthai APIs.
It is also unusual the gravity component changes +/-, but maybe the documentation is lax in that. Yes, I can negate and flip order...but it is suspicious that the "10" component is changing its coordinate system. It makes me suspect math error, or pointer offset error, struct member name/misuse, etc.
Notes
Is the 5% error due to section 3.2.1 ZGO errors? If so, then we need a mechanism to "dynamic calibrate" datasheet section 3 the accelerometer -as distinct- from extrinsic calibration of https://github.com/luxonis/depthai-core/issues/155
Or has there been a "Static calibration" datasheet section 3 burned into the IMU already?