Merged map origin is off the centre about m-explore HOT 13 CLOSED

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:

1. 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.
2. 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.
3. 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.

1. 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".

2. 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).

3. yep, now the origin will be always strictly in the centre of the map and the orientation is an identity.

from m-explore.

1. 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.

1. What I mean by world -> robotX is transform from world frame to robots map frame. SLAM usually publishes map -> odom transform, your odometry odom -> base_link. map_merge would publish world -> map for each robot (I call here map frame robotX, to distinguish between robots). Maybe I should call that mapX frame to avoid confusion.

2. 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.