Linear interpolation not working

[johnnyhoichuen]

I was checking the interpolation codes and I realise the leftAccel and rightAccel is always the same which eventually causing the interpolated acc_data equals to leftAccel and rightAccel.

I wonder if it only happens on my device (Samsung S8, Android 9) only.

Inside syncInertialData() in IMUManager

[DavidGillsjo]

Interesting! This code is from the mobile-ar-sensor-logger, so I have not developed it myself. I intend to build and try your pull request on my phone so then I can try this myself as well.

From the code I guess this means that either

1. Your device's accelerometer reuse values, maybe it does not support 100Hz and simple send the latest sampled in the buffer?
2. Something is not right the mAccelData buffer.

[johnnyhoichuen]

I ran the above test before the changes made on #10 (the original code).

I do see that the IMU frequency is 100Hz. I'd love to see the result on your phone just to make sure it was not device specific.

[DavidGillsjo]

Sorry, I have not yet had time to look at this. I'm currently finishing up my PhD and am a bit short on time.
Just wanted to let you know it is not forgotten.

[Shengnan-Zhu]

@DavidGillsjo @johnnyhoichuen bug here lead to "left val = right val" when linearinterpolation:

VideoIMUCapture-Android/android_app/app/src/main/java/se/lth/math/videoimucapture/IMUManager.java

Line 275 in 721f62d

SensorPacket sp = new SensorPacket(event.timestamp, event.values);

I am not familiar with java，but I guess in java, pass a non-basic type object like an array(timestamp is a basic type, so its ok), means like pass the address of the object. So each time the sensorpacket in accdata or gyrodata will point to the newest value.
You can try copy the value of event.values as below:
float[] val = Arrays.copyOf(event.values, event.values.length);
SensorPacket sp = new SensorPacket(event.timestamp, val);

[DavidGillsjo]

Thanks @Shengnan-Zhu, great catch!
Have you verified that is solves the bug? If you have an implementation you are very welcome to submit a pull request.

If this is the issue, it seems like Marslogger - which I forked this code from - might have this bug as well.

I'll defend my PhD by the end of this week, after that I should be able to find some time for this bug.

[kostov]

I confirm that there is a bug in the current code. If you run version 0.12 (without the changes made in the commit: #10 ), then the calibration is successful. And if you run the latest version from git, the calibration fails: the results are poor.

[kostov]

Maybe it helps. Same test smartphone OPPO Reno8 T.
Calibration results on video_meta.pb3 made on current code:

Transformation (cam0):
-----------------------
T_ci:  (imu0 to cam0):
[[ 0.17404695  0.93491288  0.30926619  0.04748523]
 [ 0.58995835 -0.35045497  0.72741354  0.14077234]
 [ 0.78845215  0.05585006 -0.61255528  0.59648332]
 [ 0.          0.          0.          1.        ]]

T_ic:  (cam0 to imu0):
[[ 0.17404695  0.58995835  0.78845215 -0.56161303]
 [ 0.93491288 -0.35045497  0.05585006 -0.02837382]
 [ 0.30926619  0.72741354 -0.61255528  0.24829373]
 [ 0.          0.          0.          1.        ]]

timeshift cam0 to imu0: [s] (t_imu = t_cam + shift)
-0.2701729725

Gravity vector in target coords: [m/s^2]
[-6.29013475 -5.60114021  5.02293301]

Results after Revert "support for uncalibrated magnetometer data (#10)":

Transformation (cam0):
-----------------------
T_ci:  (imu0 to cam0):
[[ 0.99995948  0.00337941  0.00834332  0.00251429]
 [ 0.00344041 -0.99996739 -0.00730701  0.0177881 ]
 [ 0.00831836  0.00733542 -0.9999385  -0.00237666]
 [ 0.          0.          0.          1.        ]]

T_ic:  (cam0 to imu0):
[[ 0.99995948  0.00344041  0.00831836 -0.00255561]
 [ 0.00337941 -0.99996739  0.00733542  0.01779646]
 [ 0.00834332 -0.00730701 -0.9999385  -0.00226751]
 [ 0.          0.          0.          1.        ]]

timeshift cam0 to imu0: [s] (t_imu = t_cam + shift)
0.014001082648

Gravity vector in target coords: [m/s^2]
[-0.07779599 -9.76065684 -0.94443039]