rtabmap_util

Standalone utility nodes for RTAB-Map pipelines: converting between sensor representations, cleaning up point clouds, assembling maps and replaying recorded sessions.

Every node is a composable node as well as a standalone executable. Composing them into one process with their producer avoids copying images and clouds between processes, which is worth doing for anything on the sensor path.

Contents

• Nodes
• Library
  • MapsManager
• Conventions

Nodes

One page per node.

Sensor conversion

RGBDImage plumbing

Point cloud processing

Maps and replay

Library

The package also installs a small C++ library, whose API is documented in the C++ API reference generated from the headers.

MapsManager is the piece worth knowing about: it turns a pose graph plus per-node occupancy grids into the assembled clouds, occupancy grid, octomap and elevation map, and publishes them. Both map_assembler and rtabmap_slam’s rtabmap node use it, which is why their map outputs and Grid/* parameters behave identically. It is described below.

MapsManager

Published topics. Everything is published only when subscribed, and – by default – latched, so a subscriber joining late immediately receives the current map.

In a component container with intra-process communication enabled (use_intra_process_comms), these publishers automatically opt out of it when latch is on, since intra-process communication does not support transient local durability. With latch off, they keep the container’s setting.

Parameters.

map_always_update and map_empty_ray_tracing only apply to the latest sensor data, not yet committed as a node, which only the rtabmap node has: they do nothing in map_assembler.

Every RTAB-Map Grid/*, GridGlobal/*, StereoBM/* and StereoSGBM/* parameter is also exposed, all documented in RTAB-Map’s parameter reference. The split between the first two is worth knowing: Grid/* decides how each node’s local grid is built from its sensor data – the same segmentation obstacles_detection does, and the parameters listed there apply here too – while GridGlobal/* decides how those local grids are merged into the global map, so it covers the map’s minimum size, its occupancy threshold, and how far the graph must move before the whole map is rebuilt.

Octomap tree type

RTAB-Map keeps a color per voxel, so the tree it publishes on octomap_binary and octomap_full reports its id as ColorOcTree, not the plain OcTree many examples assume.

That is deliberate and interoperable: octomap_msgs::binaryMsgToMap() and fullMsgToMap() branch on that id and hand you back an octomap::ColorOcTree, and octovis opens it without complaint. What does break is code that assumes the other branch:

```cpp

File truncated at 100 lines see the full file