Closed SwiftGust closed 4 years ago
yes this is a known issue. When you use a map of size 100×100×100 with resolution 0.1, the cell number is 10^9. Suppose that a cell stores 6 bytes of data,then the map costs 6G memory.
We can easily solve the problem by using a circular buffer instead of allocating a huge memory for the whole mapped area,like some recent work such as Ewok. But since the current map is enough for our experiment and serve for no purpose for large scale commercial usage,I may delay the circular buffer map a little bit... So I suggest you to carefully select the global map size. Like setting z size to 100 meters,I think that's totally unnecessary.
Thank you for kind reply. Yes of course, this is not a priority at all but a reporting an issue that I found.
I'm not understanding this ESDF map implementation yet but I was curious that although ESDF is storing much more information than just occupancy that Octomap represents.
When using simpler map representation like Octomap, it is hard to see it consumes up to giga-byte level even it is global mapper with unknown map size and increasing explored space infinitely.
So I wanted to know the some reason behind this much of memory usage that it is pre-allocating memory for cells so does needs map size parameters maybe for faster querying or else.
Yes of course. I appreciate your testing and expect more valuable feedbacks to help us improve our project.
Octomap is a very good framework mainly optimized for memory efficiency. Only observed regions are allocated with nodes in the octree, and for unknown regions no memory is consumed. So the overall memory consumption depends on how much space is observed and recorded. The drawback of octomap is its higher data access complexity which is linear to the tree depth.
For our project, we target fast local planning so run-time efficiency is our major consideration. Since a fixed length array is most efficient for accessing data for both map fusion and motion planning, we preallocated memory for a fixed volume of regions. Also, each cell contains more information than octomap, like a few vars for ESDF updating,some other vars for accelerated ray casting. So the overall memory efficiency is low. Admittedly there are many things we can do to improve memory usage in a large margin, in theory. I will release the optimized one when finish. But it is not the major requirement for fast flight, so I might finish a little bit later…
Please star our project if it helps you, thanks!
I'm playing with the simulator and found that increasing map size tremendously consumes memory. On my 64GB RAM desktop maximum available size is roughly 100 x 100 x 100 m with 0.1m resolution (removed uav simulator from launch) and increasing size further throws std::bad_alloc error
I think memory usage should be optimized much further if planner to be used at wider space or outdoor.
Only plan_manage/launch/simulation.launch is launched in this test.
Reducing map resolution reduces memory usage significantly but I'm worrying about the bad impact on planner solution.
Memory usage Memory usage is 52.5GB
Before launch - using 6.8GB
After launch - using 59.3 GB
Simulation.launch file diff from master is as following
Console output