Glossary

Fictionlab > Glossary > OctoMap

OctoMap

OctoMap – definition

OctoMap is a probabilistic three-dimensional occupancy mapping framework based on octrees. It represents free, occupied, and unknown space in a hierarchical voxel structure. Each voxel stores an occupancy estimate, typically updated from range-sensor observations using a log-odds Bayesian formulation. The reference implementation is the open-source octomap library described by Hornung et al. in Autonomous Robots in 2013.

In mobile robotics, OctoMap is used to convert LiDAR, depth-camera, or stereo point clouds into a 3D representation of the robot’s surroundings. This is useful when a UGV must reason about obstacles above ground level, uneven terrain, ramps, shelves, vegetation, construction elements, or sensor blind spots. Unlike a 2D occupancy grid, an OctoMap can preserve vertical geometry and explicitly model unknown space in three dimensions.

On Leo Rover or Raph Rover, OctoMap is normally an optional perception component. Neither platform becomes autonomous by adding an OctoMap alone. A complete system also requires calibrated sensors, a valid tf2 transform tree, localization or SLAM, robot footprint data, and a navigation or motion-planning stack.

How OctoMap represents occupancy

An octree recursively divides a cubic volume into eight child cells. Large homogeneous regions can remain at a coarse level, while areas near measured obstacles can be subdivided into smaller voxels. This reduces memory use compared with a fixed-resolution dense 3D grid.

The occupancy update is commonly expressed in log-odds form. For a voxel m and a sensor measurement z, the updated belief can be written as:

l(m | z₁:ₜ) = l(m | z₁:ₜ₋₁) + l(m | zₜ) - l(m₀)

Here, l(m | z₁:ₜ₋₁) is the previous log-odds occupancy value, l(m | zₜ) is the inverse sensor-model update, and l(m₀) is the log-odds value of the prior. Rays between the sensor origin and a measured endpoint are normally updated as free space. The endpoint voxel is updated as occupied. The exact hit, miss, clamping, and occupancy thresholds are configurable in the OctoMap library and ROS integration packages.

OctoMap in ROS and ROS 2

The ROS ecosystem provides message definitions in octomap_msgs and mapping integration through packages such as octomap_server. An octomap_msgs/Octomap message contains the map identifier, resolution, a binary flag, and serialized octree data. The map can be published in compact binary form or as a full map representation.

For a UGV, the most relevant input is usually sensor_msgs/msg/PointCloud2. The cloud must be transformed into a stable mapping frame, typically map or odom. ROS frame naming and coordinate conventions should follow REP 105, which defines the semantic roles of frames such as map, odom, and base_link.

A typical ROS 2 data path contains the following components:

  • A LiDAR or depth camera publishes sensor_msgs/msg/PointCloud2.
  • The robot publishes transforms between the sensor frame, base_link, odom, and optionally map.
  • octomap_server raycasts sensor observations into the octree.
  • A navigation or inspection application consumes occupied-space information directly or projects it into a 2D costmap.

ROS 1 and ROS 2 integrations should not be treated as interchangeable. ROS 1 packages use ROS 1 message transport and launch conventions. ROS 2 deployments use DDS-based communication, ros2 launch, and ROS 2 message namespaces. Package availability and executable names can also differ between distributions, so the installed package documentation should be checked before deployment.

ros2 run octomap_server octomap_server_node \
  --ros-args \
  -r cloud_in:=/points \
  -p frame_id:=map \
  -p resolution:=0.10

The 0.10 value above is an example voxel resolution in metres. It is not a required Leo Rover or Raph Rover setting. Smaller voxels retain more geometry but increase processing time, memory consumption, and map size.

Sensor integration for mobile UGVs

OctoMap requires range observations with a known sensor origin and pose. A 3D LiDAR produces direct spatial measurements. A depth camera produces depth images that can be converted into point clouds. A 2D LiDAR can contribute only if the sensor is tilted, mechanically scanned, or combined with robot motion and reliable pose estimation.

Sensor integration should be validated before map tuning. The following conditions have direct effects on map quality:

  • Extrinsic calibration between the sensor frame and base_link.
  • Timestamp consistency between point clouds, odometry, IMU data, and transforms.
  • Filtering of ground returns, self-observations, out-of-range points, and depth-camera artefacts.
  • A stable localization source when observations are accumulated in the map frame.
  • Appropriate maximum range, raycasting limits, and occupancy-update parameters.

Leo Rover supports ROS 2 natively on a Raspberry Pi-based compute unit. A lightweight OctoMap configuration may therefore require point-cloud downsampling or offboard processing, depending on sensor data rate and voxel resolution. Raph Rover can be a better fit where a larger payload permits a higher-performance compute unit, a 3D LiDAR, or multiple perception sensors. These are integration decisions, not default platform features.

Use cases with Leo Rover and Raph Rover

On Leo Rover, OctoMap can support indoor research tasks such as mapping laboratory obstacles, detecting elevated objects that are absent from a planar laser scan, or collecting 3D environment data during supervised navigation experiments. A depth camera or compact LiDAR should be rigidly mounted and represented in the robot URDF or TF configuration.

On Raph Rover, OctoMap can support larger outdoor inspection or field-research setups. Typical examples include recording obstacle geometry around construction-site structures, mapping vegetation boundaries, or building an occupied-space model around terrain features. Outdoor operation requires additional care because rain, dust, direct sunlight, moving vegetation, and GNSS drift can degrade sensor measurements or pose estimates.

Limitations and trade-offs

OctoMap is an occupancy representation, not a complete navigation system. It does not provide global localization, semantic classification, traversability assessment, or collision-free trajectory generation by itself. A voxel marked as occupied also does not identify whether the object is a person, a rock, foliage, or a structural element.

Map quality depends on sensor coverage and pose accuracy. Incorrect transforms can create duplicated walls, tilted floors, or obstacles floating above the ground. Dynamic objects can leave stale occupied voxels unless the application applies clearing, decay, temporal filtering, or periodic remapping. For many differential-drive UGV navigation tasks, a 2D costmap remains computationally simpler, while OctoMap provides additional value when vertical obstacle structure matters.

References and technical sources

The following sources describe the main concepts, interfaces, and frame conventions used with OctoMap in ROS-based UGV systems.

See also