Drift compensation about scikit-kinematics HOT 14 CLOSED

No. There are two different points here:

1. Drift compensation would be acceptable, if I assume that i) everybody does the experiments in a static environment, and ii) the position at the end is (at least approximately) the initial position. I am somewhat reluctant to make that assumptions, especially the second one. Also, this is fairly easy to do on your own.
2. The second point relates to your offset. What you have is no drift, but the sensor aligned differently. You should rotate your data, by multiplying them with the corresponding rotation matrix.
   I have just finished my book for Springer, in which I am explaining rotations, quaterions, analysis of IMU-data etc. Don't know when it will be published, but approximately in April. If you need it now, and you promise me that you will by the book when it appears, I could send you a pre-proof version.

from scikit-kinematics.

Does it mean that because my MEMS 3-axis accelerometer was not oriented straight horizontally during the record, its vertical axis got a skew that does not equal usual g ?

from scikit-kinematics.

With a drift of 10 m/s^2, you are using a different coordinate convention. I use x forward, y left, z up. A misalignment would give you changes that are 2 orders of magnitude lower.

from scikit-kinematics.

I've also noticed that the average X acceleration equals 1.05 and Z equals 0.67 even when the device was still! While Y is still -10.02 m/s^2.
My conventions are: +X to the left, +Y vertically up, +Z towards front.
Is it correct to input initial rotation numpy.eye(3) (default)?
And this type of accelerometer includes gravity component recorded in the data, so you need to filter it out first, and your package does, but, as I understand, because your program expects g to be recorded strictly as -9.81, but the data has another value, so the filtered data appears to be constantly accelerating, say falling down.

from scikit-kinematics.

from scikit-kinematics.

• Unfortunately, the records we've already made were not designed to have an obligatory still device at the beginning (the eyetracker was already put on the participant when the Start button was pressed).
• If we manage successfully to determine the source of such an error in this particular device, then, for sure, it should be recommended to let the device stand still and strictly oriented for about 5-10 seconds from start.
• Optional, of course.
• I've already contacted the manufacturer's developers and asked them about the recommended way of drift compensation.
• Calibration file is the best thing I can think of for scientific research. But I'm not sure how to orient the device exactly horizontally. Should I use some sort of "liquid bubble level" tool, or a preinstalled table? The manufacturer should also guarantee that the accelerometer is well-oriented inside the body of the device.

It looks like I need to use either Madgwick filter variant without magnetometer channel, or simply subtract the average value from each axis after rotating the data using rot_mat.

from scikit-kinematics.

from scikit-kinematics.

Tobii (http://tobiipro.com) recommends to filter their data as described in this brochure: https://arxiv.org/pdf/1704.06053.pdf

I work for Russian Academy of Sciences (RAS) dept.

from scikit-kinematics.

from scikit-kinematics.

@thomas-haslwanter, there you go: http://x-io.co.uk/open-source-imu-and-ahrs-algorithms/

How about adding Madgwick variant without magnetic field data?
Also I oughta have a possibility to set g prior to calculating quat, because I've figured out a precise value of g in my area, and it differs from scipy's in about 0.01.

from scikit-kinematics.

from scikit-kinematics.

...subject is in approximately the same position...

How approximate is 'approximately'? 20 cm, 1 m, 5 mm?

from scikit-kinematics.

from scikit-kinematics.

No open questions here, and no more comment for more than a year. So I close the issue.

from scikit-kinematics.