wh200720041/floam

laserCloudSurfMap and laserCloudCornerMap growth leads to excessive processing

Opened this issue · 0 comments

I have limited CPU and I am finding that if I explore a large enough area, my laserCloudSurfMap and laserCloudCornerMap point clouds get so large that my system gets bogged down and can't complete odom estimation sufficiently quickly. It seems to me that for the purpose of odometry, we shouldn't care about points that are very far away, yet from what I can tell, they are still included in the computation. Are there any forks out there that have addressed this issue? Any suggestions for how to address this issue. I have some ideas, but I don't want to waste time reinventing the wheel. I realize FLOAM is a bit dated now -- are there more current/actively worked-on packages that could achieve the same thing. Something optimized to run with CUDA on an NVIDIA Jetson computer would be ideal.

Edit: It seems I can mitigate the issue quite a bit by shrinking the crop box size (it is hard coded as +/- 100 in x,y,z). I tried +/- 15 and it was much better; however, I am still noticing a steady rise in odom estimation time, even when laserCloudSurfMap and laserCloudCornerMap remains constant. Not sure why.