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

NTU VIRAL dataset issues #374

Closed
jorgeffonte opened this issue Jul 25, 2024 · 1 comment
Closed

NTU VIRAL dataset issues #374

jorgeffonte opened this issue Jul 25, 2024 · 1 comment

Comments

@jorgeffonte
Copy link

jorgeffonte commented Jul 25, 2024

Hello,

I have been experiencing issues similar to those described in the following issues:

Issue #240
Issue #128
Issue #239

I have carefully followed the suggested solutions provided in these issues, but unfortunately, the problem persists. Here are the steps I have taken based on the recommendations:

For Issue #239, I applied the suggested patches and updates to the Voxelize method, but the errors still occur.

The dataset im using is public, specifically the NTU VIRAL dataset (eee2 sequence although it happens with all the ntu sequences I've tried.), using an Ouster 16-layer LiDAR.
The enviroment of the dataset looks like this:
Screenshot from 2024-07-25 11-02-35

The specific problem I am experiencing is that the algorithm does not correctly estimate changes in the Z coordinate (take-off). Instead of keeping the ground points as a "plane," it arranges them in a way that looks like a mountain, while the wall points are treated as if they are the same point and are kept in the same place. I believe the video shown below illustrates what I am describing. You can see how the white dots (from keyframes) on the wall stand still when they should be rising as the UAV elevates:

50_trimmed.mp4

I have tried various parameter configurations, and the only one that estimates odometry correctly is with a maximum distance of 20 meters to avoid registering the points from the walls.Here you can see how the path elevate with the takeoff:

20_trimmed.mp4

However, with such a short distance, there comes a point where the LiDAR doesn't detect anything at that distance and starts to lose track.

I have attempted to dynamically increase the distance, but as soon as the walls are detected, the problem reappears. Additionally, the computation time increases significantly (I suppose because generating the map incorrectly also makes it harder for the ICP to converge in subsequent iterations).

I am running on Ubuntu 20.04, and my setup includes ROS Noetic.

I am not seeking to have the authors work on solving this issue for me. My main intention is to document that the algorithm has issues with the NTU VIRAL dataset and its sparse LiDAR. This is for anyone who might find themselves in the same situation as I am.

Thank you for your assistance.

@benemer
Copy link
Member

benemer commented Jul 26, 2024

Thanks for sharing this insight! This dataset is indeed super hard.

As we discussed in the referenced issues, such sparse sensors are very challenging. The scan lines on the walls are pretty far apart, so our ICP tries to keep the lines in the current frame aligned with the lines in the local map (which would be correct if these lines were strings, for example, and not part of a wall).

This could be an edge case where a more sophisticated technique will work better. We should keep this dataset in mind and test possible solutions of #240, although this issue refers more to the density after downsampling.

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

3 participants