hku-mars / FAST-LIVO

A Fast and Tightly-coupled Sparse-Direct LiDAR-Inertial-Visual Odometry (LIVO).
GNU General Public License v2.0
1.27k stars 203 forks source link

Memory management issues. #29

Closed FPSychotic closed 5 months ago

FPSychotic commented 1 year ago

Hi, I have the same issue than with R3Live when tested it, the map is being stored in RAM and it will fill the 16Gb DDR4 in a 3 min aprox. at 868x640 camera resolution. Lidar is publishing at 30hz. Is there any way to store that data in NVME or SSD to free the RAM?, this problem in make the software quite unreliable to be honest. I.e can save the map with a command, service,key and start, or a customizable timer and start a new one with different name could work in many cases. Maybe Im missing something and is my fault, not sure

Camilochiang commented 1 year ago

This is actually an engineering problem more that a code issue. Still, an interesting one when working with real time data.

My first fast though is that depending of the scanning strategy you could follow different strategies

What do you think?

FPSychotic commented 1 year ago

Thanks by your answer. For me can save a map automatically after a specified time, or key combination and every map having a different name to don't overwrite is enough. For me is ok need to make several maps. Yes, as you said a good idea could be choose a decitimation value, same of that % points your are saying, for saving but for realtime too, maybe there is already that option, with the step option in config file maybe?, but I don't know what mean most of the options, even some that are explained.

If you want octomaps you could do it with a x4 decitimation and the RAM would last much longer, if you want to scan, like a building for meshing, inspection, you could use x1 and get all the detail, you will need many maps, but that should not be a problem, maps can be aligned and make several maps is usual in terrestrial scanners, in my opinion nothing to complaint really, just would be nice have some solution as the above, or what you said, as is sad so nice software,with probably with a lot of effort, be limited in real use for that small limitations

Two bigger problems in my case are that I don't know programming, I barely can make changes in .launch files, sometimes in the code but only if it is very obvious. But I'm good tester, I can help in that

xuankuzcr commented 1 year ago

A simple way is to increase the size of your system's swap partition as the link.

FPSychotic commented 1 year ago

A simple way is to increase the size of your system's swap partition as the link.

Thanks by the advice I used zram but I will try that and see the result.

Camilochiang commented 1 year ago

I would recomend to keep this issue open as is a technicall limitation that could be improved @FPSychotic

FPSychotic commented 1 year ago

I would recomend to keep this issue open as is a technicall limitation that could be improved @FPSychotic

Hi my friend, you are right but I received an answer and I understand the Dev knows already the issue and he has enough tools to tracking and improve it if he wish . I would advice you try the fast loi2 color fork,r3live,Rtabmap and specially the new Instanesh from this same lab that will be released soon For other side the Dev can close the issue when wish so it looks reasonable follow your advice. Thank my friend

JJ353 commented 5 months ago

@FPSychotic Hello, I have also encountered a situation where when running my own dataset, the memory will die due to full memory, how did you solve this problem in the end?