Use for long continuous SLAM about fast_lio HOT 12 CLOSED

You are right. Rviz definitely will use too much RAM if working too long. There are two method may help:

1. set the Decay time parameter of the topic cloud_registered in Rviz to a smaller one like 100 seconds.

2. The publish_dense only control the rviz shows, it will not influence the pcd saving. so you can set it to 0 to save the rviz.

May I ask how long is the duration of your bag usually? I am a little afraid that the pcd saving function may meet problem if the duration is too long.

from fast_lio.

Hey @XW-HKU , thanks for the quick answer. I tried changing the decay time, it does help somewhat yes so I will use it. My bag duration in most cases is around 15-20 min long. Yesterday while testing some more I noticed that sometimes the publish rate of the cloud_registered topic varies and is sometimes less than 10hz ( which is the lidar frequency ). Is that due to there being a lot of points to process in a very little time so the publishing is slowing down due to all the calculation or is there some other reason for this?

from fast_lio.

Hey @XW-HKU , thanks for the quick answer. I tried changing the decay time, it does help somewhat yes so I will use it. My bag duration in most cases is around 15-20 min long. Yesterday while testing some more I noticed that sometimes the publish rate of the cloud_registered topic varies and is sometimes less than 10hz ( which is the lidar frequency ). Is that due to there being a lot of points to process in a very little time so the publishing is slowing down due to all the calculation or is there some other reason for this?

The runtime performance of fastlio will not be influenced by the duration, but rviz will eat much computation resources and also the pcd saving function. You can close the rviz and disable the pcd saving function and test again to varify if the runtime performance is influenced.

from fast_lio.

And what's your lidar type, computer and its cpu?

from fast_lio.

So, after turning off both RViz and the pcd saving function, RAM usage no longer goes up and stays pretty much stable, I also tested with just pcd saving but not RViz and saw that it still takes RAM but a lot less than if RViz is working as well. The sensor I am using is an OS1-128 from Ouster and the pc has an 8-core ARM v8.2 64-bit CPU with 32GB RAM

from fast_lio.

But I noticed also that when switching between the publish_dense option for the same exact bag in ros, one scan ended up with 2.1mil points without the dense scan published, and with over 20 mil points when i set the publish_dense back to 1, which was a bit weird to me cause I thought it shouldn't make a difference for the end map

from fast_lio.

But I noticed also that when switching between the publish_dense option for the same exact bag in ros, one scan ended up with 2.1mil points without the dense scan published, and with over 20 mil points when i set the publish_dense back to 1, which was a bit weird to me cause I thought it shouldn't make a difference for the end map

The dense_publish is the switch to control the point number of the rostopic \cloud_registered. I am a bit confused about the "end map" you mentioned. What's that? If you are talking about the pcd file containing every registered scans, the topic \cloud_registered shouldn't change the pcd point number (if pcd's point number changed, there must be a bug I need fix, please tell me). As for the localization, it only need a sparse map which is not published and irrelevant to publish_dense parameter.

from fast_lio.

@XW-HKU yes, the dense_publish for me changed the number of points in the end pcd file that is being saved ,in one case it was 729MB file with about 21mil points and with dense_publish off it was 66MB with around 2.1mil points for the exact same bag file

from fast_lio.

@XW-HKU yes, the dense_publish for me changed the number of points in the end pcd file that is being saved ,in one case it was 729MB file with about 21mil points and with dense_publish off it was 66MB with around 2.1mil points for the exact same bag file

Thank you very much for finding this problem, I will fix it ASAP.

from fast_lio.

@XW-HKU thank you, perhaps the problem is in publish_world_frame function the size of the laserCloudWorld is determined by whether you have dense_publish enabled or not

from fast_lio.

@XW-HKU yes, the dense_publish for me changed the number of points in the end pcd file that is being saved ,in one case it was 729MB file with about 21mil points and with dense_publish off it was 66MB with around 2.1mil points for the exact same bag file

I just test the conditions the parameter scans_dense_enable is ON/OFF, but the result in my computet shows that the two pcd file are totally same size. So could you please update to the newest code and check again?

from fast_lio.

Hi, @XW-HKU, thank you for fixing it, I pulled the latest code and tried it again and now the pcd is the same size with and without dense_pub_en

from fast_lio.