IMU fusion data not plausible

Frequent questions asked online, offline, in forums are answered here
Post Reply
Posts: 3
Joined: Thu Dec 03, 2020 2:59 pm

IMU fusion data not plausible

Post by fsteinme »

we are trying to set up our Marvelmind System with the onboard IMU Beacon to locate our drone. We configured everything according to the Documentation (Including submap creation, the calibration of the IMU Beacon, etc.). We then tried to verify the positioning with the logs of the Marvelmind Dashboard, which works pretty well. Further, we verified the IMU via the Dashboard while connecting the Beacon to the PC and testing the different axis.

Then we wanted to verify the positioning with the IMU fusion as well. Therefore I wrote some python scripts to read the serial port of the IMU Becaon using the Marvelmind protocol. Then we plotted the positions and the data doesn't make sense. A snippet of the log reads as follows:

Hedge 8: X: -2.748, Y: -3.095, Z: 0.259, Angle: 0 at time T: 465.962
19 │ IMU fusion: X:-2.748, Y:-3.093, Z:0.261, QW:0.128, QX:-0.006, QY:0.016, QZ:0.992, VX:0.020, VY:-0.033, VZ:-0.030, AX:-0.028, AY:-0.001, AZ:-0.003, at time T: 465.962
20 │ IMU fusion: X:-2.748, Y:-3.094, Z:0.260, QW:0.129, QX:-0.006, QY:0.012, QZ:0.992, VX:0.019, VY:-0.032, VZ:-0.029, AX:0.003, AY:-0.045, AZ:-0.004, at time T: 465.962
21 │ IMU fusion: X:-2.747, Y:-3.094, Z:0.260, QW:0.129, QX:-0.004, QY:0.019, QZ:0.991, VX:0.018, VY:-0.031, VZ:-0.028, AX:0.032, AY:0.075, AZ:0.168, at time T: 465.962
22 │ IMU fusion: X:-2.747, Y:-3.095, Z:0.259, QW:0.129, QX:-0.005, QY:0.016, QZ:0.992, VX:0.016, VY:-0.029, VZ:-0.026, AX:0.036, AY:0.066, AZ:0.089, at time T: 465.962
23 │ IMU fusion: X:-2.747, Y:-3.095, Z:0.259, QW:0.129, QX:-0.005, QY:0.012, QZ:0.992, VX:0.013, VY:-0.026, VZ:-0.023, AX:-0.002, AY:-0.022, AZ:0.013, at time T: 465.962
24 │ IMU fusion: X:-2.747, Y:-3.096, Z:0.258, QW:0.129, QX:-0.008, QY:0.014, QZ:0.991, VX:0.009, VY:-0.022, VZ:-0.019, AX:-0.018, AY:0.023, AZ:0.014, at time T: 465.962
25 │ IMU fusion: X:-2.746, Y:-3.096, Z:0.258, QW:0.129, QX:-0.006, QY:0.012, QZ:0.992, VX:0.004, VY:-0.016, VZ:-0.014, AX:-0.176, AY:0.239, AZ:0.009, at time T: 465.962
26 │ IMU fusion: X:-2.746, Y:-3.096, Z:0.257, QW:0.129, QX:-0.006, QY:0.013, QZ:0.992, VX:-0.003, VY:-0.007, VZ:-0.006, AX:-0.022, AY:0.015, AZ:-0.006, at time T: 465.962
27 │ IMU fusion: X:-2.746, Y:-3.097, Z:0.257, QW:0.129, QX:-0.004, QY:0.015, QZ:0.991, VX:-0.006, VY:-0.004, VZ:-0.004, AX:-0.002, AY:-0.003, AZ:0.014, at time T: 465.962
28 │ Hedge 8: X: -2.747, Y: -3.092, Z: 0.259, Angle: 0 at time T: 466.052
29 │ IMU fusion: X:-2.746, Y:-3.097, Z:0.257, QW:0.129, QX:0.000, QY:0.014, QZ:0.992, VX:-0.009, VY:0.001, VZ:0.002, AX:0.039, AY:-0.005, AZ:0.128, at time T: 466.052
30 │ IMU fusion: X:-2.747, Y:-3.097, Z:0.257, QW:0.129, QX:-0.004, QY:0.013, QZ:0.991, VX:-0.008, VY:0.000, VZ:0.002, AX:0.148, AY:0.041, AZ:-0.121, at time T: 466.052
31 │ IMU fusion: X:-2.747, Y:-3.096, Z:0.257, QW:0.130, QX:-0.011, QY:0.013, QZ:0.991, VX:-0.006, VY:0.000, VZ:0.001, AX:-0.116, AY:0.014, AZ:0.089, at time T: 466.052
32 │ IMU fusion: X:-2.747, Y:-3.096, Z:0.257, QW:0.130, QX:-0.007, QY:0.012, QZ:0.991, VX:-0.003, VY:0.004, VZ:0.001, AX:-0.106, AY:0.032, AZ:-0.007, at time T: 466.052
33 │ IMU fusion: X:-2.747, Y:-3.095, Z:0.257, QW:0.130, QX:-0.006, QY:0.009, QZ:0.991, VX:0.000, VY:0.009, VZ:0.000, AX:-0.004, AY:0.053, AZ:-0.027, at time T: 466.052
34 │ IMU fusion: X:-2.747, Y:-3.095, Z:0.257, QW:0.130, QX:-0.002, QY:0.009, QZ:0.991, VX:0.005, VY:0.013, VZ:0.000, AX:-0.014, AY:0.006, AZ:0.030, at time T: 466.052
35 │ IMU fusion: X:-2.747, Y:-3.094, Z:0.258, QW:0.130, QX:0.002, QY:0.008, QZ:0.991, VX:0.008, VY:0.021, VZ:0.001, AX:-0.039, AY:0.162, AZ:0.029, at time T: 466.052
36 │ IMU fusion: X:-2.747, Y:-3.092, Z:0.258, QW:0.130, QX:-0.000, QY:0.009, QZ:0.991, VX:0.016, VY:0.030, VZ:0.002, AX:0.135, AY:-0.070, AZ:0.069, at time T: 466.052
37 │ IMU fusion: X:-2.746, Y:-3.091, Z:0.258, QW:0.130, QX:-0.001, QY:0.010, QZ:0.991, VX:0.018, VY:0.033, VZ:0.003, AX:0.036, AY:-0.042, AZ:0.089, at time T: 466.052

So between each Marvlelmind system message about 8 IMU messages are sent, which makes sense since the rate should be much higher. Now the log raises the question of whether the sent data is plausible. For instance, the time stamp at which the IMU data is sent is the same for each message between two Marvelmind messages. How is this plausible.
Then we walked at the edges of the flight space with the IMU on a constant height with a rolling table and logged the data via the serial port. The corresponding plot is attached. The orange dots is the positioning sent by the MM System, the blue dots by the IMU fusion. At the top left corner, the MM System loses connection (is at the edges of our flight space so this is kinda expected) and the dots jump around a bit. Now this should be prevented by the IMU fusion, so in my opinion the positioning of the IMU fusion should balance out the wrong data of the MM system. Instead, the IMU fusion escalates completely and the dots are completely moving around (means the fusion further reinforced the mistakes sent by the MM system).

Now is the question, how can we guarantee a proper fusion of the IMU and MM data for a better positioning when errors of the MM system occur?

User avatar
Site Admin
Posts: 313
Joined: Tue Jan 26, 2016 7:06 pm

Re: IMU fusion data not plausible

Post by admin »


And thank you very much for a very detailed study.

The IMU fusion can serve at least three different purposes:

1) To accelerate the update rate, for example, for AR/VR, drones and other applications where a high update rate and a low latency is important. High update rate per se is rather easy to achieve. Low latency is a much more difficult task, because you need to forecast a location by doing a double-integration of an non-perfect accelerometer in a presence of drifting gyro that is also not perfect and not perfectly calibrated. Drifting gyro is very well corrected by the paired beacons and reasonably well corrected by a single-beacon case scenario with a moving mobile Beacon HW v4.9. That is what we offer as an IMU sensor fusion currently.

In static, it would not be possible to correct the gyro drift around Z even in theory. So, imbalances of accelerometer (and it always takes place) are multiplied with the error of gyro and the whole IMU fusion simply doesn't work over the long period of time - minutes. For 30-60 seconds the drift of gyro can be assumed acceptable and the double-integration of the accelerometer works well to stay within +-2-10cm and providing at the same time about 100Hz update rate with latency on location of 12-15ms. When mobile beacon is moving, the drift of gyro is calibrated by the SW based on the ultrasonic positions.

At the same time, when the object is static, you usually don't need 100Hz location update. And when it starts moving, after the first 30-100cm of movement, the system would lock to the right relative position of axes and the gyro drift would be corrected.

Notice, that the purpose 1) was focused on the location update rate increase and nothing else. And it relies on a pretty high quality ultrasonic tracking. If you have a bad ultrasonic tracking, then its badness is simply amplified by the IMU, because its drift is not corrected, but the IMU is trusted. So, if you want a low latency and to use IMU fusion, you shall provide a very good ultrasonic tracking first. Then, ultrasonic would correct the IMU and the information from IMU would be good.

I see a rather good tracking in your case most of the time. So, when the tracking is good and the object is moving, you shall have a good location data from IMU as well. So, let's double-check that part.

Another aspect to check is vibration. We played with VR/AR. There wasn't much vibration. But with drones it is a different story. When sensor fusion is done, it is assumed that the ultrasonic location noise is higher than the IMU noise. Ultrasonic must correct the drift of IMU, but IMU provides a very noiseless info albeit drifting. If you have a high noise from IMU because of vibration, then we recommend to damper the potential IMU noise from vibration first - mechanically - and then repeat. On a moving object, with good ultrasonic tracking the IMU sensor fusion worked rather well.

2) The next purpose is to increase the accuracy. You may fuse with ultrasonic data and highly decrease the noise of positioning - x10 magnitude or more. We haven't played with this much, because +-2cm is sufficient for 95% of our customers. But, yes, we will. And, yes, it is possible to achieve mm-level accuracy.

3) The third purpose is to eliminate jumps, to fill in data with IMU, etc. That is, what you, presumably, wanted. Doable. We partially played with it, but haven't made a big thing just yet, because of lack of time with many other projects.

So, currently, we have Type 1) supported for Beacons HW v4.9. It assumes high-quality ultrasonic tracking and location update rate based on ultrasound of >=4Hz. 8Hz or is even better.

In the near future, we finally hope to find time and move the same functionality to be supported by Super-Beacons, since they are newer and more powerful. But the SW changed quite a bit and we didn't have time to transfer the very complex functionality of IMU fusion to Super-Beacons yet.

Also, remember that it is impossible or very problematic to have all options - 1), 2) and 3) - at the same time, because there is an inherent trade off between the option. One must choose either-or.


Post Reply