Hello I ran main_kitti.py in default mode and it produced 10 different sets of graphical
results. All looked rather good, great in fact.
The worst case was 2011_10_03_drive_0027_extract
It starts off well enough but about midway of the graph the errors start increasing and the
trajectory goes off-course. Now the program main_kitti.py itself mentions in a comment:
'2011_10_03_drive_0027_extract' has trouble at N = 29481 which is about t=307 seconds for the ground truth. I am sure Martin was aware because his data validation scheme only selected the earlier part of the ride [0,18000] i.e. to about 183.5 seconds. At this point the SO(3) error is sharp and noticeable at around that point. This suggests a discontinuity in the SO(3) Lie Group.
I have found a number of instances where the time stamps were not properly sorted and also time gaps of greater than 0.1 sec. According to the comments in Brossard's program, such time gaps are bad.
File '2011_10_03_drive_0028_extract.p' ie the test case has only one such gap: at the very beginning of its data file a huge gap of more than 1 second between point 0 and point 1. Likewise for 2011_10_03_drive_0027_extract. Why is that?
Hello I ran main_kitti.py in default mode and it produced 10 different sets of graphical results. All looked rather good, great in fact.
The worst case was 2011_10_03_drive_0027_extract
It starts off well enough but about midway of the graph the errors start increasing and the trajectory goes off-course. Now the program main_kitti.py itself mentions in a comment:
'2011_10_03_drive_0027_extract' has trouble at N = 29481 which is about t=307 seconds for the ground truth. I am sure Martin was aware because his data validation scheme only selected the earlier part of the ride [0,18000] i.e. to about 183.5 seconds. At this point the SO(3) error is sharp and noticeable at around that point. This suggests a discontinuity in the SO(3) Lie Group.
I have found a number of instances where the time stamps were not properly sorted and also time gaps of greater than 0.1 sec. According to the comments in Brossard's program, such time gaps are bad.
File '2011_10_03_drive_0028_extract.p' ie the test case has only one such gap: at the very beginning of its data file a huge gap of more than 1 second between point 0 and point 1. Likewise for 2011_10_03_drive_0027_extract. Why is that?