Sudden jumps in Sensor fusion

kustra

We're experiencing sudden jumps in the sensor fusion's quaternion output on Mbient sensors. It works as expected for 10-20-30 seconds or more, without any drift, then suddenly, in the course of a second, the sensor's output rotates sometimes 20°, sometimes 40°, sometimes 90° around the vertical axis (parallel with gravity). Then it stays like that for a while, and moves with sensor movement.
We use sensor fusion in NDoF mode, accelerometer's range is 16g, gyroscope range is 2000°/s. The movements that we test with are slower than 500°/s, just holding the sensor in hand and moving it around. The sudden jump usually happened for us when the sensor didn't move at all, but has been stationary for more than 5 seconds.

We've done successful calibration and stored the calibration data on the sensor in an execOnBoot macro.

Laura

https://mbientlab.com/community/discussion/3167/how-to-report-an-issue#latest
data? screenshots?
reproducible steps maybe?

kustra

We may have found the solution to this one.
Turns out, if we do the accelerometer and magnetometer parts of the calibration process a few seconds longer after it signals high calibration accuracy, it improves the sensor fusion output and the sudden jumps don't happen anymore.

Thanks for responding. We'll keep testing.

Laura

Thank for the update to let everyone else in the community know!

mohsen

I'm experiencing the same issue. The data (Pitch angle in this case) suddenly jumps for about 50 degrees and returns back after a few samples.
I have encountered this on other MotionR sensor but seems to be random overall. During some sessions a sensor exhibits this behavior but other times it doesn't. I'm using the iOS app by the way.

simmi

Hi ,
I am also facing the same problem of sudden jumps in quaternion values while using sensor fusion (NDOF). Kindly elaborate on the steps taken to overcome the above problem.
I am first calibrating the sensor using the python script given with sdk. Thereafter, I am using sensor fusion python script to acquire the quaternion data.
Kindly elaborate the steps you have taken to overcome the problem. I am just stuck because of it.
It would be really helpful!!!
Thanks

Laura

You should get jumps in euler streams (from gimbal lock) but not from quaternion stream.

kustra

@Laura said:
data? screenshots?
reproducible steps maybe?

I've found a way to reliably reproduce the issue where the quaternion stream has a jump that doesn't correspond to physical sensor movement.

Earlier in this thread, I posted:

@kustra said:
If we do the accelerometer and magnetometer parts of the calibration process a few seconds longer after it signals high calibration accuracy, it improves the sensor fusion output and the sudden jumps don't happen anymore.

However, after testing the system a lot more, we still experienced this, though more rarely. Even when we took painstaking care to follow the video's instructions, we just couldn't get rid of the jumps completely.

So I started digging, and found this statement on the website:

All of the sensors on MetaWear devices should be factory calibrated to produce an accurate reading out of the box. However, in some extreme cases, additional calibration may be required to get the best performance of our sensors in sensitive applications.

This led me to consider that we may not need an explicit calibration workflow at all. (Discussed in another thread. Edit: based on Matt's last comment, this may not be true.)
But if I don't do any calibration, the jump happens reliably after a sensor soft reset, or if sensor fusion is stopped long enough on the sensor. (Where "long enough" is less than 1 hour.)

Here's a video of the jump.
Here's a video of the intended movement.

It reliably happened for all the sensors that I've tried so far. Steps to reproduce:
1. Issue a soft reset: MetaWear.clearAndReset() then reconnect the sensor.
2. Configure sensor fusion (ndof, 16g, 2000dps, quaternion output).
3. Hold the sensor steady, then start sensor fusion.
4. Do a 90° rotation around one horizontal axis (in the room's reference frame, let's call it X), then back to the starting position. Then 90° around the other horizontal axis (Y), and back. Then -90° around the Y axis. See videos above. It'll jump before you can complete the movement.

After it jumped once, it seems to work without further issues - until sensor fusion is stopped for long enough, or a soft reset is issued.

To summarize:

• Manually calibrating the sensors is rather hard to get right. We could barely do it, or not at all. Or we may be missing something.
• Relying on the sensors' factory calibration and the sensor fusion auto-calibration creates this jumping data issue every time we stop sensor fusion or reset the sensor.

My questions:

1. Is this the expected behaviour? I'm asking this for both points of the summary above.
2. Is there a way to avoid having to do this "mini-calibration", i.e. rotating the sensor as in the videos to make the data jump once, and the working well afterwards?
3. Let's say that we asked the end user to rotate the sensor like in the videos at the beginning of their session. Do you think that this "mini-calibration" will hold? How long?

Laura

1. Is this the expected behaviour? Not sure
2. Is there a way to avoid having to do this "mini-calibration", i.e. rotating the sensor as in the videos to make the data jump once, and the working well afterwards? No, this is real life.
3. Let's say that we asked the end user to rotate the sensor like in the videos at the beginning of their session. Do you think that this "mini-calibration" will hold? How long? We keep the calibration until the next user session for some of our apps (usually 1 day)