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
As part of my research for my final thesis, in which I want to investigate alternative positioning options where determination via GNSS is not possible, especially for USVs, I came across your implementation. Since your implementation fits my topic well and it offered an implementation for a current ROS version and a prospect of promising results, I decided to use it for the investigations as part of my thesis. I wanted to thank you again for that.
Most of the time the algorithm delivered accurate positioning data when everything worked correctly. However, when evaluating the data I noticed something that I would like to hear your opinion on. I wanted to investigate how consistent the results are that the SLAM can deliver. I always ran it several times with the same LIDAR data (Velodyne VLP-16). I noticed that there are sometimes strong, sudden errors, especially during strong turns (see picture below). I am aware that particularly fast rotation is challenging for SLAM algorithms, but I was wondering why this always appears in different positions and not always the same deviations arise.
Hence my question, are there any random components in your algorithm, whereby not all points are always used for the calculation, which produces the different results. Could this also be caused by a non-terministic program flow for processing the lidar points? Are there any other posible causes for that?
Since I can currently only guess at this, I would be very happy to receive a brief assessment from you about it.
Thanks again for your help and the great implementation.
Have a nice day.
The text was updated successfully, but these errors were encountered:
Sorry for the delayed response. Hmm, unfortunately, I'm not very familiar with it. Maybe it's about parallel processing of point clouds during NDT matching(For more details, see ndt_omp.), parallel processing during map updates in scan matching, or some issue with ROS2?
As part of my research for my final thesis, in which I want to investigate alternative positioning options where determination via GNSS is not possible, especially for USVs, I came across your implementation. Since your implementation fits my topic well and it offered an implementation for a current ROS version and a prospect of promising results, I decided to use it for the investigations as part of my thesis. I wanted to thank you again for that.
Most of the time the algorithm delivered accurate positioning data when everything worked correctly. However, when evaluating the data I noticed something that I would like to hear your opinion on. I wanted to investigate how consistent the results are that the SLAM can deliver. I always ran it several times with the same LIDAR data (Velodyne VLP-16). I noticed that there are sometimes strong, sudden errors, especially during strong turns (see picture below). I am aware that particularly fast rotation is challenging for SLAM algorithms, but I was wondering why this always appears in different positions and not always the same deviations arise.
Hence my question, are there any random components in your algorithm, whereby not all points are always used for the calculation, which produces the different results. Could this also be caused by a non-terministic program flow for processing the lidar points? Are there any other posible causes for that?
Since I can currently only guess at this, I would be very happy to receive a brief assessment from you about it.
Thanks again for your help and the great implementation.
Have a nice day.
The text was updated successfully, but these errors were encountered: