Comments (3)
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.
from tm-rrt_exploration.
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
from tm-rrt_exploration.
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.
from tm-rrt_exploration.
Related Issues (7)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tm-rrt_exploration.