[Documentation] [TitleIndex] [WordIndex

Only released in EOL distros:  

Package Summary

Map merger is a package to merge several maps on the fly to one global map, if possible

  • Maintainer status: developed
  • Maintainer: Peter Kohout <peter_kohout AT gmx DOT at>
  • Author: Peter Kohout <peter_kohout AT gmx DOT at>, Torsten Andre <torsten.andre AT aau DOT at>
  • License: BSD
  • Source: git https://github.com/aau-ros/aau_multi_robot.git (branch: hydro)

Package Summary

Map merger is a package to merge several maps on the fly to one global map, if possible

  • Maintainer status: developed
  • Maintainer: Peter Kohout <peter_kohout AT gmx DOT at>
  • Author: Peter Kohout <peter_kohout AT gmx DOT at>, Torsten Andre <torsten.andre AT aau DOT at>
  • License: BSD
  • Source: git https://github.com/aau-ros/aau_multi_robot.git (branch: indigo)


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.


The map_merger node offers the following features:

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.

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

  Title                    = {Coordinated Multi-Robot Exploration: Out of the Box Packages for {ROS}},
  Author                   = {Andre, T. and Neuhold, D. and Bettstetter, C.},
  Booktitle                = {Proc. of IEEE GLOBECOM WiUAV Workshop},
  Year                     = {2014},
  Month                    = dec,

You may obtain the paper from IEEEXplore or search in Google Scholar.



map merger automatically merges maps received by other robots to a robots own map constructing a global map

Subscribed Topics

map (nav_msgs/OccupancyGrid) odom (nav_msgs/Odometry) control (adhoc_communication/MmControl) map_other (adhoc_communication/MmMapUpdate) position_other_robots (adhoc_communication/MmRobotPosition) adhoc_communication/new_robot (std_msgs/String)

Published Topics

global_map (nav_msgs/OccupancyGrid) all_positions (adhoc_communication/MmListOfPoints)


map_merger/logOutput (map_merger/LogMaps) map_merger/transformPoint (map_merger/TransformPoint)

Services Called

adhoc_communication/get_neighbors (<<SrvLink: execution failed [string index out of range] (see also the log)>>) adhoc_communication/send_control (adhoc_communication/SendMmControl) adhoc_communication/send_map_update (adhoc_communication/SendMmMapUpdate) adhoc_communication/send_point (adhoc_communication/SendMmPoint) adhoc_communication/send_position (adhoc_communication/SendMmPpsition) adhoc_communication/send_map (adhoc_communication/SendOccupancyGrid)


~has_local_map (bool, default: true) exchange_position (bool, default: false) max_size_map_part (int, default: 512) seconds_pub_timer (int, default: 3) seconds_send_timer (int, default: 5) seconds_recompute_transform (int, default: 15) max_rotation_robots (double, default: 5) local_map_topic (string, default: "/map") local_map_metadata_topic (string, default: "/map_metadata") local_map_frame_id (string, default: "map") map_topic_over_network (string, default: "map_other") position_local_robot_topic (string, default: "slam_out_pose") position_other_robots_topic (string, default: "position_other_robots") control_topic (string, default: control) robot_prefix (string, default: "") log_path (string, default: "")


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.

2020-03-28 12:51