›

MetaMotionR+: Calibration, Bias, Data Accuracy Etc.

ZhannaZhanna
edited September 2017 in General

I have some questions regarding the data gathered from a few experimental tests. I'm using pictures and breaking this into 2 posts to account for the character limit...


Test 1. The sensor is resting on a horizontal plane. We leveled a desk with a bubble level. The sensor was aligned against a ruler and left on the desk for ~ 20 sec. Sampling frequency = 100 Hz.


Acceleration statistics:

imageimage
We used the conversion factor 9.8 m/s^2.


Question: Do the nonzero X and Y components correspond to the sensor bias or to the admixture of the gravity or both?
Question: How do you recommend eliminating the bias? 
Question: How can you recommend separating the gravity and the user/linear acceleration?


Gyroscope / Angular rotation rates statistics:
image

The rotation rates for a resting sensor should fluctuate around zero. The mean values are much larger than STDs, which implies some bias. This can lead to a drift in angles. 

Question: How do you recommend eliminating the bias? 

Orientation (quaternions and the Euler angles). - The quaternions and the Euler angles (roll, pitch, yaw) are very stable for this test: the values (roll, pitch, yaw) =  [ -0.241, -0.832, 138.721] remain practically unchanged during the testing session.


Question: How is the initial orientation obtained/calculated?
Question: How do you compensate for the gyroscope bias (see above)?

Comments

  • ZhannaZhanna
    edited September 2017


    Test 2. 3D rotations.     Setup: We leveled a desk with a bubble level. The sensor was aligned against a ruler. Recording started. The sensor was lifted and randomly rotated for ~ 20 sec. Then it was returned to the initial position and orientation. Sampling frequency = 100 Hz.


    Orientation (quaternions) - The quaternions and the Euler angles returned after the test to the initial values with a noticeable drift.

    For example, the initial (roll, pitch, yaw) = [ -0.759,   -1.287,  131.696] 
    and the final (roll, pitch, yaw) = [ 0.187,   -1.013,  138.132] 

    Question: How is the initial orientation obtained/calculated? (e.g. where 31.696 is coming from?)

    Question: How do you compensate for the gyroscope bias (see above)?

    Data accuracy question For some sensors/tests there is no enough accuracy (digits) for time representation. For example, there are three repetitions of "2017-09-13T14:26:23.369" Do you have any recommendation for how to handle this?

    image

  • EricEric
    edited September 2017
    Pretty much all of your questions regarding bias and are addressed with the sensor fusion algorithm.  Sensors are never 100% accurate and will always have noise and bias.  Sensor fusion combines data from the other sensors to address the individual shortcomings.  The algorithm can also determine acceleration from gravity and movement.  Regarding the specifics of the algorithm i.e. how it's calculating initial values, that I do not know as that is code we license from Bosch, not developed internally.  You can lookup articles about sensor fusion to get a general idea of what the algorithm does.

    The sensor fusion mode used by MetaBase does take into account magnetometer data.  It's possible there are other magnetic fields on the table or nearby enough to distort magnetometer values.  Curiously, your title says "quaternions" but the data you provided is Euler angles?

    Timestamps for streaming data are discussed in this thread:
  • keviheadkevihead
    I think I can help with the first question. The accelerometer has a zero-g offset and it's documented in the BMI160 data sheet. There is also 1% cross axis sensitivity.

    The way to deal with that is to exploit the fact that no matter what the orientation of the snsor when it's stationary, the total acceleration should be equal to 1g. So what I do is I calibrate it by putting the sensor at 9+ different orientations and leaving it stationary for a few seconds and then use CalibAccel to get my bias and scale factors matrices.

    Before and after looks something like this - total acceleration and XYZ accelerations. 

    I wanted to use the same sort of thing to correct linear accelerations from sensor fusion because they have a zero-g offset as well, but I have no idea how Bosch subtracts gravity from the raw accelerometer data, so this method ends up not working.

    As far as the timestamps go, you get the repetitions only if you stream data or save it in MetaWear. This doesn't happen if you log it in MetaBase, at least in my experience. Not sure if you can avoid streaming in your application.

This discussion has been closed.