Comments (13)
How do the maps you are trying to merge look?
Have you tried your setup with maps that are used in tests (just publish them with map_server)? see https://github.com/hrnr/m-explore-extra and
from m-explore.
Hi hrnr,
Thanks for prompt reply. Now merging problem is solved. It is merging perfectly in both the cases. I have installed the package from my local Repo and it was old version, just replaced with new master version.
But now I am facing new problem that the merged map is coming with some offset (may be you call it origin of merged map). I am attaching picture of maps for more detail. what could be the possible reasons? and any suggestion. I am using octomap_server to create occupancygrid map.
--
from m-explore.
I think it is bug, because map merger does not take into account offset of original maps. You can try this workaround:
Set world_frame
param to map_merged
Add this to your launch file:
<node pkg="tf" type="static_transform_publisher" name="map_merged_tf" args="-halfX -halfY 0 0 0 0 world robot_ns/map_merged 100" />
where halfX, halfY
- a half of size of the map, robot_ns
- namespace of robot
from m-explore.
thanks @MaxGsomGsom ,
I am trying online map merging with increasing size of maps and the initial size of robot's individual maps depends upon environment around the robots (halfX, halfY will be random and unknown). So it will not solve my problem. And initial offset of robot frames I am providing through static tf.
from m-explore.
The merged map is in the world tf_frame. Sadly map_merger is not providing any tf transform (world -> robotX). It is on my TODO list, but it has never been implemented as I didn't need it for my research.
If you are providing those transforms yourself, you need to adjust them, so that the merged map is aligned with the robots.
Another thing is that the merged map has its origin in the (0,0) corner, so it shows off the centre in rviz (in the world frame). If you agree I can put the origin of the map in the centre of the grid, if that seems more natural. That might break setup for some people, but will be probably ok for release to the new ROS.
from m-explore.
"If you agree I can put the origin of the map in the centre of the grid, if that seems more natural. " I thing this would solve my problem because maps always builds around the robots. Tell me how can I do in code. I have all tfs available with me.
from m-explore.
Implemented in d59acfa
Merged grid has its origin set to its centre. You still need to provide correct tf transforms by yourself, but as you say that should no be an issue for you.
Note that still the origin might be in an inaccessible area.
from m-explore.
Thanks @hrnr, I will check modified code and let you know the result by tomorrow.
"Note that still the origin might be in an inaccessible area."===== inaccessible area or unknown area??
Its very nice package but for online multi robot exploration & mapping we need few more enhancements in this package:
- Taking initial positions of robot automatically using available TFs instead of taking it as parameters: - In online multi-robot exploration all required TFs always will be available so use it. It is a painful job to give initial position every time to every robot (when restart the localization). After implementation of this....any time anywhere I can start/restart my localization node.
- In known initial pose case also using of feature-matching algorithm (if I am not wrong, after seeing the results it seems not using for this case): - after putting all local maps together first level of merging do it with known position and along with that apply feature-matching algorithms. After implementation of this.....we will be able to reduce the odometry drift and other localization errors effects.
- publishing position and a valid orientation of occupancy grid map..........this you already completed it in d59acfa.
Great work friend....hope soon will get improved package.
from m-explore.
-
The reason to take initial positions though parameters rather than tf is that I plan to implement publishing of tf transformations world -> robotX by map_merger. This would conflict with user provided transforms. Use launchfiles to give initial positions to avoid "painful job".
-
I have experimented with this, but I didn't found a real use for that. When robots are starting from the same room they quickly discover enough overlapping space, so that it can be merged with feature matching algorithm, so there is not need to provide initial positions if you can't measure it precisely. When robots are starting from different positions it is usually very hard to measure initial positions, so you usually need to wait one way or another for overlapping space.
Odometry drift is a problem for your SLAM, I don't see how map merging can help there. If using a graph slam, set it to optimise from initial node to avoid map origin moving (so your initial transformation will be always correct).
- yep, now the origin will be always strictly in the centre of the map and the orientation is an identity.
from m-explore.
- We both are thinking totally 180 deg apart.
yours initial poses====>Tfs
and mines Tfs=====> initial poses
two points I would like to mention here:
** plan to implement publishing of tf transformations world -> robotX by map_merger====>This will always create conflict as SLAM algorithms are already publishing the same tfs. And let SLAM algorithms take care about TFs as map merger will also take data from SLAM only to publish tfs.
** When robots are starting from different positions it is usually very hard to measure initial positions:==> in out door case (GPS available area) we can easily find out initial poses of robots form its TFs/odometry. And in case of any failure of localization node like, some random behaviour of robot, power failure, loose connections etc when we restart it will take current position as its initial position and no need to bring robot at initial position or measuring again position of robot in world frame.
from m-explore.
Result after modification: ==== didn't solve problem (image attached). It is merging but in real time use of merged map may be not possible due to offsets of position of robots. I think to remove this offsets we need to consider the position value of occupancyGrid maps (generated by each robot) also along with initial position values.
from m-explore.
-
What I mean by
world -> robotX
is transform from world frame to robots map frame. SLAM usually publishesmap -> odom
transform, your odometryodom -> base_link
. map_merge would publishworld -> map
for each robot (I call here map frame robotX, to distinguish between robots). Maybe I should call that mapX frame to avoid confusion. -
Interesting. My experience with GPS was that it is too imprecise for map merging. Sure, it is usable for initially navigating robots towards themselves to create a overlapping space (if you want), but the error is usually too high (esp. in rotation) for creating a usable map. In my experience it was better to use feature-based merging in that scenario.
from m-explore.
Yes. In general GPS does not provide such high Accuracy that we can use it for merging. Just try to find out how to remove these offsets and bring map and robots in correct position, then merged map can be reused for online multi robot exploration and mapping.
Thanks.
from m-explore.
Related Issues (20)
- map drifting HOT 2
- Build fails. [Error] : ‘xfeatures2d’ has not been declared` HOT 1
- Merge is not including all robots' maps HOT 1
- Shift in merged map origin even with static transforms HOT 1
- ERROR: cannot launch node of type [explore_lite/explore]: Cannot locate node of type [explore] in package [explore_lite].
- How to pause an exploration
- 0 Frontiers Found HOT 1
- Detailed working of the explore_lite package HOT 1
- Improper merging when robots have different orientations HOT 3
- Getting error while merging two agents in ROS Melodic
- Need help understanding your explore algorithm
- Merge with one robot
- Potential vulnerability: topic names from ROS parameters HOT 1
- Trying to build package in ROS melodic
- Melodic: Exploration Stopped HOT 1
- Waiting to connect to move_base server HOT 2
- Simulate communication delay mapping
- Merged map is not centered and does not overlap the single maps correctly HOT 3
- Exploration with two robots HOT 1
- Moving to the last marker suddenly stops
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 m-explore.