Drift compensation

[ivan866]

You used to have drift compensation in imus.py, line382, which equals 0.7*mean(acc). If I have mean=-10.02 m/s^2 in my data (vertical axis), does it mean I have an uncalibrated accelerometer and I need to use drift compensation then?

[thomas-haslwanter]

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.

[ivan866]

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 ?

[thomas-haslwanter]

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.

[ivan866]

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.

[thomas-haslwanter]

Accelerometers that are that far off are a problem.

But before I implement anything, let's talk about it:

• Should I assume that there is exactly 0 movement at the beginning of the recording (first sample)?

• Should I assume that there is exactly 0 movement during the first 0.1 or 1.0 sec at the beginning of the recording?

• Should I make such a setting optional, or compulsory?

• I cannot make the assumption that there is such a strong drift, and that the device is exactly horizontal, can I? But that would also mean that I would interpret your drift primarily as a tilt of the device!

• Maybe it would be best to add a function that assumes that i) the device is exactly aligned with gravity, and ii ) that the drift is constant, and then stores those values in a calibration file. This could then optionally be called ....

But I think with values like that, you should contact the company, and ask for a working device ....

What do you think?

thomas

---

Prof. (FH) PD Dr. Thomas Haslwanter School of Applied Health and Social Sciences University of Applied Sciences Upper Austria FH OÖ Studienbetriebs GmbH Garnisonstraße 21 4020 Linz/Austria Tel.: +43 (0)5 0804 -52170 Fax: +43 (0)5 0804 -52171 E-Mail: Thomas.Haslwanter@fh-linz.at Web: bim.fh-linz.at or work.thaslwanter.at

---

From: Ivan notifications@github.com Sent: Tuesday, January 2, 2018 10:10 PM To: thomas-haslwanter/scikit-kinematics Cc: Haslwanter Thomas; State change Subject: Re: [thomas-haslwanter/scikit-kinematics] Drift compensation (#17)

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. 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.

- You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/thomas-haslwanter/scikit-kinematics/issues/17#issuecomment-354876157, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABdaRUyHvDDzOJjicmr6TLNVNdERKWuUks5tGptcgaJpZM4RMAgr.

[ivan866]

• 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.

[thomas-haslwanter]

For your case, I would make the following assumptions:

• Assume that averaged over the whole experiment, the goggles don't slip, and gravity points downward.

• Assume that at the end, the subject is in approximately the same position as at the beginning.

With these two assumptions, you should be able to i) determine the orientation of the sensor with respect to gravity, and eliminate offsets. Then you should be able to track the movements during the recording.

It will probably be a bit of fuzzing around, but overall that should give you reasonable results.

BTW, which institute / company do you work at?

Best regards

th

---

Prof. (FH) PD Dr. Thomas Haslwanter School of Applied Health and Social Sciences University of Applied Sciences Upper Austria FH OÖ Studienbetriebs GmbH Garnisonstraße 21 4020 Linz/Austria Tel.: +43 (0)5 0804 -52170 Fax: +43 (0)5 0804 -52171 E-Mail: Thomas.Haslwanter@fh-linz.at Web: bim.fh-linz.at or work.thaslwanter.at

---

From: Ivan notifications@github.com Sent: Wednesday, January 3, 2018 2:44 PM To: thomas-haslwanter/scikit-kinematics Cc: Haslwanter Thomas; State change Subject: Re: [thomas-haslwanter/scikit-kinematics] Drift compensation (#17)

• 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 hold the device still and strictly oriented for about 5-10 seconds from start.
• Optional, of course.
• I've also 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.

- You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/thomas-haslwanter/scikit-kinematics/issues/17#issuecomment-355014882, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABdaReNTSgJL4FeWsLlXKmVPflxQWQREks5tG4RKgaJpZM4RMAgr.

[ivan866]

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.

[thomas-haslwanter]

Nice paper, thank you for the link! Would be nice now if some would provide an implementation in Matlab / Python ;)

Best regards th

Von: Ivan [mailto:notifications@github.com] Gesendet: Saturday, 6 January, 2018 3:25 PM An: thomas-haslwanter/scikit-kinematics scikit-kinematics@noreply.github.com Cc: Haslwanter Thomas Thomas.Haslwanter@fh-linz.at; State change state_change@noreply.github.com Betreff: Re: [thomas-haslwanter/scikit-kinematics] Drift compensation (#17)

Tobii (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.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/thomas-haslwanter/scikit-kinematics/issues/17#issuecomment-355750082, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABdaRZjSZ2HE7NKqRzjPKG7i7jmHnK9Hks5tH4I3gaJpZM4RMAgr.

[ivan866]

@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.

[thomas-haslwanter]

Those algorithms are already included in skinematics.

I have now finished adding the OpenGL-viewer, and update scikit-kinematics to Ver 0.7.0

Best regards

th

---

Prof. (FH) PD Dr. Thomas Haslwanter School of Applied Health and Social Sciences University of Applied Sciences Upper Austria FH OÖ Studienbetriebs GmbH Garnisonstraße 21 4020 Linz/Austria Tel.: +43 (0)5 0804 -52170 Fax: +43 (0)5 0804 -52171 E-Mail: Thomas.Haslwanter@fh-linz.at Web: bim.fh-linz.at or work.thaslwanter.at

---

From: Ivan notifications@github.com Sent: Monday, January 8, 2018 6:23 PM To: thomas-haslwanter/scikit-kinematics Cc: Haslwanter Thomas; Mention Subject: Re: [thomas-haslwanter/scikit-kinematics] Drift compensation (#17)

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

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/thomas-haslwanter/scikit-kinematics/issues/17#issuecomment-356033486, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABdaRTnX48HSH4zj9Zv6JjAQoyeM7KRgks5tIk8DgaJpZM4RMAgr.

[ivan866]

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

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

[thomas-haslwanter]

I would say about 0.5 m

---

Prof. (FH) PD Dr. Thomas Haslwanter School of Applied Health and Social Sciences University of Applied Sciences Upper Austria FH OÖ Studienbetriebs GmbH Garnisonstraße 21 4020 Linz/Austria Tel.: +43 (0)5 0804 -52170 Fax: +43 (0)5 0804 -52171 E-Mail: Thomas.Haslwanter@fh-linz.at Web: bim.fh-linz.at or work.thaslwanter.at

---

From: Ivan notifications@github.com Sent: Tuesday, January 9, 2018 11:18 PM To: thomas-haslwanter/scikit-kinematics Cc: Haslwanter Thomas; Mention Subject: Re: [thomas-haslwanter/scikit-kinematics] Drift compensation (#17)

...subject is in approximately the same position... How approximate is approximately? 20 cm, 1 m, 5 mm?

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/thomas-haslwanter/scikit-kinematics/issues/17#issuecomment-356432704, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABdaRXGjSBm1WDR9dT9JqPAPMBwzPrLFks5tI-WwgaJpZM4RMAgr.

[thomas-haslwanter]

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