Use with RGB-D SLAM

[YESAndy]

Hi,

Thank you for sharing your work. I am trying this package with RGB-D SLAM however the computed frontier number is small and sparse (see the picture below).

Have you tried this before? What do you think is the reason?

Many thanks!

[hikashi]

From the map quality you showed to me, the RRT would not have performed nicely to it. The main reason is that that is some free space in between the map, which may cause the RRT to unable to grow to the actual freespace. Even though it detected a frontier in between the freespace, it would have been filtered out. Thus, it causes a lot unnecessary computation of the frontiers (and slowing down your simulation). Please refer to the picture below.

My suggestion is to refine the scan layer for the map and make sure the map is as close as the map generated by the Gmapping. Then you should be fine to use it with different SLAM algorithm to carry out exploration task.

Cheers, Billy

[YESAndy]

Thank you for your suggestion! To clarify, I am using an RGB-D camera in my case, so the scan layer refinement may not be applicable to me. I figured out the reason why there are fewer detected frontiers. It is because of the configured map topic name of the merged map and individual occupancy grid map. Please see the following result. .

As you can see from the above map, the update rate of the merged map is around 1hz. I checked the sensor rate is around 15hz which is pretty low for the visual SLAM to maintain a sufficient map update rate. The low update rate causes the robot to easily crash into obstacles.

I also observed that the robots also easily crashed into each other. Have you seen this before? I wonder if it is because the initial poses of the robots are too different from each other.

[hikashi]

I am glad you got that part sorted.

I do agree the merged map update rate is quite slow (in 1hz) but it might not affect the crashing part. The movebase in the configuration uses using local map (obtained from the laser scan), which rate is much higher as compared to merged map. If you suspect merged map is causing the crashing issue, I suggest you use the local map generated as input for the cost map. It will greatly mitigate the crashing into each other (other than the narrow corridor, which is mostly the movebase stack issue). Given that you are using RGB camera as sensing input for the SLAM, the movebase might perform slower than the laser scan. I believe that might cause an issue with the movebase. I suggest you fine-tune the movebase part to accommodate your sensing rate for avoiding any potential problems. Hope that solves your problems.