# I fused a GPS and IMU and I am wondering if my results make sense

I am trying to fuse a ublox M8 (https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221)_Public.pdf) with a MicroStrain IMU (http://www.microstrain.com/inertial/3dm-gx4-25) via a loosely coupled architecture.

I was wondering if there are any suggestions or insights based on the results that I am getting.

I based most of my code off of Paul Grove’s 2nd edition book. I did a six-point tumble test to calibrate my IMU to get the accelerometer fixed bias, the accelerometer scale factor and the accelerometer misalignment. I also got gyroscope fixed bias. I don’t have a rate table so I can’t get the gyroscope scale factor and misalignment yet. The filter is not currently estimating any calibration information.

I ran a test of the code for about 6 hours and 40 minutes.

I have a couple of questions about the procedure.

1) My main difficulty is that I am not sure what I should be expecting from the hardware/integration architecture that I am using. What would you expect after a test of 6 hours with a loosely coupled architecture?

2) I am also having difficulty deciding on how to tune the filter. Are there any papers/procedures that you recommend for deciding what should go into Q and R Matrices? I tried propagating the IMU standalone to see how quickly it diverged from it’s initial position. I also took gps data to see how it diverged from it’s initial position. I am wondering If the tuning would be a function of my update interval, as well as how long it takes the two systems to diverge to a specified distance.

For my R matrix, I am taking the uncertainty posted by the GPS. For my Q matrix, I am using the power spectral density. I do have some difficulty understanding the reasoning behind this.

3) Finally, I am wondering how much you think that estimating calibration information in my filter would help with a long term solution.

EDIT:: Please ignore the xlable for the figures. It says time in seconds was about 28 days. But the test lasted for just 6 hrs and 40 minutes.

• I haven't read your code thoroughly, but from the figures it looks like you haven't really solved drift (your x drifts about 1.5 meters per hour). Have you verified that the bias agrees with your test data? You might get more traction on this post by focusing your question - generally a list of questions is more difficult to digest and find an answer for. Sep 20 '17 at 15:59
• Hi @combo. How would I test that my bias agrees with my test data? Do you mean propagating the IMU state without biases and then seeing if the position divergence is consistent with the bias measurement? Sep 20 '17 at 16:08
• More like having the unit still and level, then compute the averages of the accelerometer xyz. You should be subtracting this bias from the raw readings before passing them as input to your kalman filter - after skimming your code it's not clear where you do this. By checking the bias I mean comparing the means you are subtracting with the observed mean over the long test duration. Sep 20 '17 at 16:58
• Why would averaging the outputs of the accelerometer be the bias? I used this method for Calibration: commons.erau.edu/cgi/… Or are we saying the same thing? Sep 20 '17 at 17:13
• The tumble test is a good method for calibration - and if the calibration is correct, then when you have the accelerometer stationary with $z$ aligned down, then after compensating for bias you should measure zero average acceleration in $x$ and $y$. Based on the figures you posted, this is not the case since introducing the imu data adds significant drift over long periods of time. Sep 20 '17 at 17:29