timestamp issue

[Ghostish]

Hi, i try to use this useful tool to convert a TUM dataset to klg format and I ran Kintinuous on the it. But as I run the evaluation tool, it said that :

Couldn't find matching timestamp pairs between groundtruth and estimated trajectory!

What should I do to fix it?

[HTLife]

The timestamp related code is here: https://github.com/HTLife/png_to_klg/blob/master/main.cpp#L236

png_to_klg will parse associations.txt and get timestamp. Kintinuous and ElasticFusion define timestamp as an int64_t (Range: -2^(64-1) ~ 2^(64-1)-1) number which adopt ICL-NUIM format. (Simply numbering from 1 to n)

TUM record timestamp as a floting point string. Therefore, after type casting, TUM format timestamp will not be the same as in associations.txt.

Quick fix

1. Converting all TUM timestamp(both associations.txt and ground truth) into integer numbering (124584.1246 => 1, 2, 3, 4).
2. Feed converted associations.txt into png_to_klg
3. ElasticFusion and Kintinuous will now output a pose graph with integer timestamp.
4. Compare interger timestamp with gt which is also in integer numbering.

[Ghostish]

Thanks for quick reply. I tried the quick fix above but I got something weird.

I converted the timestamp in both files. The associations.txt:

1 rgb/1305031229.528748.png 1305031229.528784 depth/1305031229.528784.png
2 rgb/1305031229.564425.png 1305031229.564442 depth/1305031229.564442.png
3 rgb/1305031229.596600.png 1305031229.596617 depth/1305031229.596617.png
4 rgb/1305031229.628753.png 1305031229.628790 depth/1305031229.628790.png
5 rgb/1305031229.664657.png 1305031229.664358 depth/1305031229.664358.png
6 rgb/1305031229.696827.png 1305031229.696843 depth/1305031229.696843.png
...
up to 694 lines

And the groundtruth.txt:

1 1.3357 0.6698 1.6180 0.6504 0.6012 -0.3056 -0.3496
2 1.3352 0.6704 1.6175 0.6509 0.5999 -0.3026 -0.3535
3 1.3356 0.6711 1.6174 0.6527 0.5997 -0.2962 -0.3557
4 1.3355 0.6719 1.6172 0.6541 0.5988 -0.2910 -0.3590
5 1.3352 0.6724 1.6169 0.6545 0.5976 -0.2871 -0.3634
6 1.3352 0.6729 1.6169 0.6555 0.5964 -0.2819 -0.3675
...
up to 2742 lines

and i ran the following commad:

./pngtoklg -w '~Downloads/slam_datasets/rgbd_dataset_freiburg1_rpy' -o 'rpy.klg' -t -s 0.0002 -r

then i ran kintinuous on that klg:

~/Downloads/Kintinuous-master/build/Kintinuous -s 7 -v ~/Downloads/Kintinuous-master/vocab.yml.gz -l rpy.klg  -ri -fl

after kintinuous finished, i got a file named rpy.klg.poses .

content in rpy.klg.poses is something like these:

0.000002 -0.00158429 0.00302863 0.0148349 -0.00123011 -0.0321893 0.00188223 0.999479
0.000003 0.00534415 0.000614882 0.00959444 -0.00288463 -0.0559715 0.00994968 0.998379
0.000004 -0.000406742 0.00660944 0.0173588 -0.00434961 -0.074743 0.0111711 0.997131
0.000005 0.00322151 0.0036149 0.020458 -0.00531706 -0.0954093 0.0126212 0.995344
0.000006 0.0010891 0.0059576 0.0242927 -0.0044992 -0.106173 0.0154882 0.994217
0.000007 -0.0117791 0.00821447 0.0257945 -0.00324715 -0.123675 0.0167361 0.992176
0.000008 -0.00840306 0.00691724 0.0239208 -0.00395946 -0.143919 0.0215003 0.989348

I fed the groudtruth txt and rpy.klg.poses to the evaluation tools then i got the same error as before.

so I eliminated the leading zeros in the file rpy.klg.poses :

2 -0.00158429 0.00302863 0.0148349 -0.00123011 -0.0321893 0.00188223 0.999479
3 0.00534415 0.000614882 0.00959444 -0.00288463 -0.0559715 0.00994968 0.998379
4 -0.000406742 0.00660944 0.0173588 -0.00434961 -0.074743 0.0111711 0.997131
5 0.00322151 0.0036149 0.020458 -0.00531706 -0.0954093 0.0126212 0.995344
6 0.0010891 0.0059576 0.0242927 -0.0044992 -0.106173 0.0154882 0.994217
7 -0.0117791 0.00821447 0.0257945 -0.00324715 -0.123675 0.0167361 0.9921
...

this time i successfully ran the evaluation tool but the result showed that there's a huge difference between the groundtruth and the estimated trajectory:

I removed the annoying red difference and got something like this:

I then tried another dataset and I got :

It seemed that the the shapes of the groundtruth and the estimated one are very similiar but some flip effects just happened.

Did I make any mistakes?

[HTLife]

I also met this orientation problem, too. TUM dataset did not start from zero position and pose. Put ground truth initial pose(first frame) into ElasticFusion might fix this. I haven't tried the suggestion above yet.

[Ghostish]

@HTLife Thanks, I think I now understand what the problem is.