About | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange

Only released in EOL distros:   hydro indigo

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

The map_merger node offers the following features:

• Keeping track of changes in the local map and automatically distributes them in the network using the Ad hoc Communication package.

• 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:

@InProceedings{Andre2014,
  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.

ROS API

map_merger

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

Subscribed Topics

map (nav_msgs/OccupancyGrid)

• The local map

odom (nav_msgs/Odometry)

• Odometry of the robot (only used if position is exchanged)

control (adhoc_communication/MmControl)

• Control messages which are exchanged with other robots.

map_other (adhoc_communication/MmMapUpdate)

• Map updates from other robots

position_other_robots (adhoc_communication/MmRobotPosition)

• Position received by other robots (this positions are not in my coordination system).

adhoc_communication/new_robot (std_msgs/String)

• Publishes the name of a new robot which entered the network

Published Topics

global_map (nav_msgs/OccupancyGrid)

• The global map which contains the data of all maps together

all_positions (adhoc_communication/MmListOfPoints)

• Array of the positions of the other robots in my coordination system

Services

map_merger/logOutput (map_merger/LogMaps)

• logs debug output to the folder

map_merger/transformPoint (map_merger/TransformPoint)

• transforms the point of a other robot into my own coordinate system

Services Called

adhoc_communication/get_neighbors (<<SrvLink: execution failed [string index out of range] (see also the log)>>)

• Returns all direct neighbors of the robot.

adhoc_communication/send_control (adhoc_communication/SendMmControl)

• Serializes a messege of the type MmControl and delivers it with the service send_string to the destination. The sender will deserialize it and publish it on the given topic.

adhoc_communication/send_map_update (adhoc_communication/SendMmMapUpdate)

• Serializes a messege of the type MmMapUpdate and delivers it with the service send_string to the destination. The sender will deserialize it and publish it on the given topic.

adhoc_communication/send_point (adhoc_communication/SendMmPoint)

• Serializes a messege of the type MmPoint and delivers it with the service send_string to the destination. The sender will deserialize it and publish it on the given topic.

adhoc_communication/send_position (adhoc_communication/SendMmPpsition)

• Serializes a messege of the type MmPpsition and delivers it with the service send_string to the destination. The sender will deserialize it and publish it on the given topic.

adhoc_communication/send_map (adhoc_communication/SendOccupancyGrid)

• Serializes a messege of the type OccupancyGrid and delivers it with the service send_string to the destination. The sender will deserialize it and publish it on the given topic.

Parameters

~has_local_map (bool, default: true)

• If set to false, the robot does not use his local map and he can run as a "Base"

exchange_position (bool, default: false)

• If set to true, positions will be exchange, otherwise set it to false

max_size_map_part (int, default: 512)

• max width/height of a map part that is send over the network, if it is 32, max size of the map pat in byte is 32*32 = 1024

seconds_pub_timer (int, default: 3)

• after how much seconds the global map will be updated and published

seconds_send_timer (int, default: 5)

• send local map changes all N seconds to the other robots

seconds_recompute_transform (int, default: 15)

• try all N seconds to recompute all transforms

max_rotation_robots (double, default: 5)

• the max rotation which should be allowed between robots at the start up, in degrees

local_map_topic (string, default: "/map")

• topic where the local map is published

local_map_metadata_topic (string, default: "/map_metadata")

• topic where the local map_metadata is published

local_map_frame_id (string, default: "map")

• frame id of the local map

map_topic_over_network (string, default: "map_other")

• topic where the map updates of the other robots are published

position_local_robot_topic (string, default: "slam_out_pose")

• topic where the local position is published

position_other_robots_topic (string, default: "position_other_robots")

• topic where the position updates of the other robots are published

control_topic (string, default: control)

• topic where control messages of other robots are published

robot_prefix (string, default: "")

• prefix before all normal topics, useful in simulation

log_path (string, default: "")

• path where to write log information

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.