Multiple stella_vslam components deacrease performance about stella_vslam HOT 5 CLOSED

I don't see why you would want to launch multiple stella_vslam_ros processes that do exactly the same thing. Why is that?

from stella_vslam.

The main reason is because mapping a large zone is quite difficult but creating multiple small maps is quick and have a better performance in relocalitzation tasks.

Having multiple components, each one with a different map running is giving us better results than with a single large map. Moreover, if we know in which zone the system is, we can unload or load the components (unload or load a map) to reduce the total ram memory.

from stella_vslam.

Multiple maps can be loaded into a process. See #380.

Why does splitting the map give better performance? How about separating bow_database::keyfrms_in_node_ by map and generating relocalization candidates for each one?

from stella_vslam.

Here we have to separte things. On the one side, there is the issue that the current system tends to have scalability problems with large maps:

• When creating large maps: loop closing drops performance, takes a long time and have problems to correct the deviation, creating less accurate maps.
• When locating: relocalization takes a lot of time (probably because it has too many keyframes to check) and when it locates it has a lot of problems to keep the tracking and tends to get lost easily.

We have tested these issues extensively in environments from 500m² to 40000m². According to our knowledge, this is something logical because of the increse of keyframes to check in the system.

The orignal issue of PR #380 was our first attempt to divide a large map into multiple small ones to adress the mapping issue and be able to map larger environments. Sorry for not finishing the PR and adding the sqlite version btw.

To adress the second issue (when locating), the solution of separatnig bow_database::keyfrms_in_node_ by map could improve the results as it would simulate what we are doing of launching multiple stella_vslam systems with a single map in each one. Anyway, we prefer the solution of having multiple stella_vslam system in separated components because this allows us to load and unload them whenever we need to.

On the other side, there is the problem of performance when using rclcpp components, which is the original topic of this issue and it is a different topic from the previous one. We are completely open to dicuss if there is a better way to target large maps, but at the moment our divide&conquer solution has given very good results and we are very happy with it. Basically, we divide the space into several maps, which are connected through a graph, each map is launched in a different component. When we are located in one of them, we keep the neighbour maps active, so relocalization is possible and we unload all the others. This works quite fine. However, when we don't know where we are (e.g. at the begining or when we are lost for more than certain ammount of time) we open all the small maps, here is where we see the dropping of performance.
It is clear that the performance of the component can be improved and that we are far away of being limited by the CPU, it makes no sense that the components drop their fps rate when we are still far away from the CPU limit. We are trying to understand the reason of this behaviour to try to address it. The repository I mention when creating the issue can reproduce the situation of having multiple stella_vslam components running and seeing that, even the CPU is not at its limit, the stella_vslam system is receiving the image at very low fps deacreasing the performance of the overall system.

from stella_vslam.

The map loading/unloading should simply be implemented as a function of stella_vslam, without the use of components. Close this issue. If necessary, open another appropriate issue. For example

• Relocalization performance degrades on large maps
• Dynamic map loading/unloading

from stella_vslam.