Point interpolation error about loam_velodyne HOT 8 OPEN

By replacing the current point interpolation based on the horizontal angle of a point with a simple linear interpolation based on the index of a point within its ring, I get a noticeably improvement in the mapping performance on the test data set.

Example code (surely not compiling):

point.intensity = ringID + SCAN_PERIOD * pointInRingIdx / ringSize;

However, I'm not sure if points of rings always arrive in order and scans may also pose wholes due to several reasons. So the above approach is certainly not the final answer to the problem, but it shows that the current implementation has some flaws with negative effects on the resulting performance. I'll look into this in more detail and let you know once I've figured out a proper and efficient solution. Shouldn't be that tough... ;)

from loam_velodyne.

@StefanGlaser for your information, I am planning to send a PR to the velodyne driver itself to avoid the issue of the starting index :)

from loam_velodyne.

Another FYI ;-)
I plan to port to ROS (anytime this or next week?) our C++ implementation of Velodyne driver that, among other things, collect "rings" / "scans" in a consistent order, always pack them in 360deg segments, includes options to programmatically change the Dual/Single return mode, etc. etc.

I'll push changes to: https://github.com/mrpt-ros-pkg/mrpt_sensors
I totally don't recommend using it for production, but testing will be more than welcome ;-)

from loam_velodyne.

Well it must be true that "great people think alike" ;)

That is very cool, thanks for mentioning it

from loam_velodyne.

To be honest, I didn't think about changing the driver. And I wonder if we would loose backward compatibility with certain datasets if we do so. I've already solved this issue with a refactoring of the corresponding logic. Just want to do some further testing before announcing my results.

On the other hand, getting reliable structured data would certainly simplify data extraction logic and probably also benefit the overall performance. Definitely worth a try.

from loam_velodyne.

@StefanGlaser in fact, i prefer to compute the ring and time in the driver, and make every scan a sorted pointcloud that the size for every ring is constant and same. similar with this https://github.com/01001HR/velodyne

from loam_velodyne.

After thinking about thins for some days I agree with you that changing the driver is certainly the best option. Getting reliable input data is crucial and ist's not the task of LOAM to handle all sort of driver issues.

from loam_velodyne.

Hello all,
This is really interesting an interesting issue. Since I am using the velodyne driver in my application, I was wondering if there was an update to it regarding the scan indices?
Thank you!

from loam_velodyne.