Wiki

Page

User

electric: Cannot load information on name: map_merger, distro: electric, which means that it is not yet in our index. Please see this page for information on how to submit your repository to our index.

fuerte: Cannot load information on name: map_merger, distro: fuerte, which means that it is not yet in our index. Please see this page for information on how to submit your repository to our index.

groovy: Cannot load information on name: map_merger, distro: groovy, which means that it is not yet in our index. Please see this page for information on how to submit your repository to our index.

Overview

The map_merger node uses the Ad hoc Communication to distribute local maps, i.e., maps created by each robot, to other robots which attempt to merge other robots' local maps into their own to create a global map. The following picture shows a global map created by merging local maps of two robots.

Note the areas with different opacities. The white area is the local map of one robot while the transparent parts of the map is the local map created by another robot and integrated into the robot's own local map to create the global map. The process is theoretically not limited to any number of robots though global map quality generally decreases with increasing number of robots.

Features

Attempting to merge local maps received by other robots by computing a transformation between the coordinate systems of the robots.

Allowing other packages to transform coordinates between different coordinate systems of multiple robots.

Maps are merged pair-wise.

Automatically attempts to determine the transformation between coordinate systems and attempts to continuously improve the transformation based on a quality metric.

Upon updates of the local map only parts of the map that have changed are distributed minimizing transmission overhead.

Storage of map updates sent to other robots for retransmissions.

Keeps track of received map updates distributed by other robots. If missing map updates are detected, the map_merger node automatically requests retransmission of the missing updates.

Transformation of Coordinates

Each robot starts with its own coordinate system. To allow correct map merging between two robots having their own coordinate systems, a transformation between these coordinate systems needs to be determined. The transformation is determined based on overlapping areas of local maps by different robots, i.e., map_A by robot A and map_B by robot B need to overlap at some point to allow determination of the transformation.

Especially in environments with repetitive structures, such as office floors, this method is error prone, i.e., maps are not merged correctly. To prevent erroneous merging a sanity check is integrated requiring robots to start within a range of a couple of meters with respect to each other with approximately the same heading. This allows to reject transformations which suggest transformations in x- or y-direction bigger than a threshold or rotations bigger than 5° in either direction. Sanity checking is freely configurable and may be deactivated any time.

Map Merging

Changes in local maps are detected by the map_merger node which then automatically distributes the changes in the network using the Ad hoc Communication node. Upon reception of map updates by other robots, the map_merger node integrates the update using an existing transformation. If no transformation is available, the remote map update is stored for later processing. Upon availability of a transformation, the remote map is merged into a robot's own map. The map_merger node regularly publishes the global map on a distinct topic (see below) to which other nodes are required to subscribe to in order to receive the global map.

Related Documentation

Please refer to the following paper to retrieve more information on the node:

Tutorial

The map_merger always needs the adhoc_communication node [seehttp://wiki.ros.org/adhoc_communication] running on the machine. The map_merger node may run in two modes: 1. a robot creating its own local map (the common case); 1. a PC without sensor not capable of creating a local map; the map_merger may be used to display the global map created by all robots in the system.

Running the map_merger on a robot with a local map

After the start the map_merge waits for the meta_informaion of the local map. This information is published by the mapping node you are running, for example gmapping or hector_mapping. It is important that you set the size of your map so that it will not grow over time, because the map_merger is not able to handle maps which change their size.

Then it is important that the map_merger is connected to all needed topics. It should look like this:

Now the robots should start exchanging their maps. Take care that the robots are members of each others multicast group. Take a lot at the documentaion of the adhoc_communication to see how to do that. Often the robots do not find a transformation between their maps instantly, it is a good to start exploration with a rotation to gather map information. After the rotation, robots often get an instantaneous transformation. Robots continue to try to determine a computation in regular intervals based upon extended maps - both due to a robots own exploration and due to updated maps received by other robots.

After a transformation is found, the global map is published under /map_merger/global_map. If there is no transformation, this topic publishes the local map. If it finds a robot with a map, it uses this as local map. It is important that the map width and height are set correct. While gmapping allows to extend the size of maps during exploration, the map_merger node does currently only support maps of fixed size. All robots are required to have the same map size which should be defined large enough at the beginning of the exploration to map the complete environment.

Running the map_merger on a robot without a local map

Here, the computer running the map_merger node does not create a map on its own, so there is no meta_information of the local map. Instead, it uses a foreign map as its own local map. Using a local map of another robot, the node works the same way described above.