Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Case 2011_10_03_drive_0027_extract - what happened? #70

Open
scott81321 opened this issue Jan 11, 2022 · 0 comments
Open

Case 2011_10_03_drive_0027_extract - what happened? #70

scott81321 opened this issue Jan 11, 2022 · 0 comments

Comments

@scott81321
Copy link

scott81321 commented Jan 11, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant