You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
The text was updated successfully, but these errors were encountered: