Closed zoidzilla closed 1 year ago
I'm not sure anyone is going to have a good answer here - the codebase is about 12-15 years old, and the original authors have long since moved on.
Do you have any links to the "number of publications"?
Hello and thank you for your answer. The publications I am referring to are: Optimal Wheelchair Multi-LiDAR Placement for Indoor SLAM, where you can find exactly the same Memory behavior in figures 5.16, 5.17, 5.18 related to Karto SLAM and SLAM toolbox (they using Karto as basis)! Also you can find a similar behavior in Comparison and benchmarking for SLAM in mobile robots at Figure 30 (not so obvious as the previous one but still clear that is there!). For the last publication/Thesis, if you have problems downloading it and you want me to send it to you please let me know. Now, this behavior is clearely happening due to open Karto implementation and not due to the Back end of any SLAM algorithm that use open Karto. I have tested it without any global optimization (loop closures) and it is still there. That is why it is present in both Karto SLAM and SLAM toolbox figures in the first stated publication/thesis. It is also present in any other available alternatives to Karto SLAM, which use different optimization libraries as back-end (tested with Ceres, g2o, GTSAM). I understand that the Open Karto has been implemented for some time now. However, what I do not fully agree is your statement that "anyone is going to have a good answer" since Karto SLAM is the basis for the newly developed SLAM Toolbox for ROS 2. If that is the case indeed and the developers of this package do not have any clue to what they are using as basis and its behavior in resources consumption, then the whole project is highly problematic. In any case thank you for your comments and please keep this issue alive in case someone knows...
Best regards,
However, what I do not fully agree is your statement that "anyone is going to have a good answer" since Karto SLAM is the basis for the newly developed SLAM Toolbox for ROS 2. If that is the case indeed and the developers of this package do not have any clue to what they are using as basis and its behavior in resources consumption, then the whole project is highly problematic
Welcome to open source software - I think you'll find it is quite common that if something works reasonably well people will use it without knowing all of the internals of how it is implemented. That's not exactly "not having any clue", it's just not knowing every detail of the underlying system (such as exactly where memory is allocated along the way).
I've been maintaining this package and open_karto package since 2014 - in that time, every PR has been related to either build compatibility for newer libraries/OSes or tweaks to the interfaces/API, so I somewhat doubt that anyone has spent the time to dig down to that level with regards to memory allocation. If it matters that much to you, you will likely have to dig in yourself.
If the same issue exists with SLAM Toolbox, then you might find that there are more developers active over there who might be able to point you in a particular direction.
In any case thank you for your comments and please keep this issue alive in case someone knows...
I was planning to leave this open, just being honest about the likelihood of someone actually arriving with an answer.
Please refer to Steve Macenski's repository of SLAM Toolbox for an answer. Thank you for the help!
I think this can be closed - I know the reason from the discussion in SLAM Toolbox
Hello,
I am running Karto SLAM and I am monitoring the RES memory using the cpu_monitor package. What I am getting is the following figure. Now, I understand that the memory usage builds up. What I don't understand is the memory behavior after 70MB (it continually allocates and frees a lot of memory blocks). I have seen and verify this behavior related to Karto in a number of publications that I found online. However, I have not obtained any good explanation so far. Can you help?
Thank you!