dddmr_navigation: a 3D navigation stack for robots that leave the flat floor

The problem dddmr_navigation is built around

A 2D navigation stack collapses the world into a plane. That works until the robot meets a ramp, a mezzanine, or a factory floor that occupies two heights at once. The README states the project's intent directly: it is designed to solve issues that Nav2 cannot handle, naming multi-layer floor mapping and localization, path planning in stereo structures, and perception markings and clearings in a 3D point cloud map. The target user is not a research lab with a custom perception pipeline. It is someone with a mobile base or a quadruped, a 16-line LiDAR, an Intel NUC or Jetson Orin Nano, and a consumer-grade IMU. The README says the authors are trying to keep the hardware cost low, and the package list reflects that: mapping, localization, perception, global planning, local planning and a point-to-point move base, all under one repository. The stated workflow is deliberately familiar to 2D users: map and refine, turn off mapping and localize with MCL from an initial pose, then send a goal and let the global and local planners do the rest.

How the stack is split across packages

The repository is organized as a set of ROS packages under src/, each with its own documentation link in the README. dddmr_lego_loam handles mapping. dddmr_mcl_3dl handles localization, and the README describes the operating mode as Monte Carlo localization seeded with an initial pose, matching the classic 2D workflow rather than a full SLAM-only loop. dddmr_perception_3d covers perception, which the README frames as markings and clearings in a 3D point cloud map. Planning is split into dddmr_global_planner and dddmr_local_planner, and execution goes through dddmr_p2p_move_base. A navigation_diagram.png in the documentation materials repository illustrates how these connect, though the diagram itself is an image and its contents cannot be read from the README text. The semantic segmentation work lives in a separate repository, dddmr_semantic_segmentation, and the README labels its navigation integration as forthcoming rather than shipped. That separation matters: if you need learned perception fused into the planner today, the README does not claim that path is complete.

The CI/CD suite for tilted LiDAR mounts

The most concrete engineering claim in the README is about sensor mounting. Configuring a 3D LiDAR at a non-zero tilt is described as a common source of corrupted maps, bad ground-plane filtering, and broken coordinate transforms. The project's answer is an automated CI/CD test suite that validates sensor configuration and navigation compatibility before deployment. It tests three mounting cases: flat, forward-tilted, and custom-angled geometry. The checks cover TF and point cloud accuracy, ground projection, and obstacle clearing, with the goal of keeping those consistent across mounting angles. The README also presents the preconfigured scenarios as reference setups for custom builds, which is a reasonable use: if your robot resembles one of the tested geometries, the test configuration is a starting point rather than a blank file. The documentation for running the tests locally lives under CICD_setup in the repository, with a section anchor named dddmr_lego_loam-ci. This is the part of the project worth reading first if your LiDAR is not mounted level, because it is the only place the README describes an explicit verification procedure rather than a capability.

Getting it running: simulation before hardware

The README's entry point for new users is the beginner guide under src/dddmr_beginner_guide. It includes a Gazebo simulation built around the Unitree Go2 quadruped, described as integrated with the navigation stack for simulation and testing. The README lists multi-level mapping, ramp navigation, and obstacle handling as the features exercised there, and contrasts them with what Nav2 alone achieves. For a first evaluation, that simulation is the lowest-cost path: it requires no LiDAR, no IMU, and no robot. The README does not reproduce the launch commands inline; it points to the beginner guide file and to the CICD_setup directory for the test suite. That is a real friction point for anyone trying to judge the project from the repository page alone, because the exact launch invocations, topic names and configuration keys are not in the README. What the README does confirm is the intended sequence: map first with the mapping package, then switch to localization with an initial pose, then send a navigation goal. Treat that sequence as the frame, and read the per-package READMEs for the parameters.

Where the approach runs into trouble

The repository lists no releases. Installation therefore means building from the main branch, and the README does not state which ROS distribution the packages target, which is the first thing to confirm before investing time. The stack is also not a drop-in replacement for Nav2 in the sense of sharing its plugin interfaces. The README describes a parallel package set with its own mapping, localization, planning and move base components, so adopting dddmr_navigation means adopting that set, not extending an existing Nav2 configuration. The semantic segmentation integration is explicitly labeled as still to come, so it should not be counted as a current feature. And the CI/CD suite, while useful, validates sensor configuration and navigation compatibility across mounting angles; it is not a claim that the stack has been validated on every platform, and the README's statement that it has been tested in many fields is not backed by any published test matrix in the material available here.

How it differs from Nav2

Nav2 is the default ROS 2 navigation framework, and its costmap layers, behavior trees and planner plugins assume a planar representation of the environment. dddmr_navigation makes the opposite assumption: the map, the localization and the planning all operate in three dimensions, which is what allows multi-level floor mapping and path planning through stereo structures. The practical difference shows up at the boundary. On a single-level warehouse floor, Nav2 has the larger ecosystem, the more predictable upgrade path, and the documentation depth that comes with being the standard. On a wheelchair ramp, a mezzanine, or a building where the robot must change floors, the planar assumption is the limiting factor, and that is the case dddmr_navigation is built for. The README's own framing of this is a comparison figure between 2D and 3D navigation stacks, plus the claim that the standard procedures are the same so 2D users can transition without difficulty. That claim is about workflow familiarity, not about API compatibility.

Licence and maintenance considerations

The repository is BSD-3-Clause, which permits commercial use and modification provided the copyright notice and disclaimer are retained. That is a permissive licence and it removes the copyleft questions that would arise from a GPL-licensed planner or mapping package, but it does not settle the licences of any dependencies you link against. The README asks users to cite a BibTeX entry when using the code or parts of it; citation is a request, not a licence condition, and it does not restrict commercial deployment. Maintenance cost is harder to judge. There are no releases to pin to, so upgrades mean tracking main, and the repository's own CI/CD suite is the mechanism the project offers for catching regressions in sensor configuration. If you fork it, that suite is the part worth keeping current, because it encodes the mounting-angle assumptions that the rest of the stack depends on.

Editorial conclusion

Adopt dddmr_navigation if your robot has to localize and plan across more than one floor level, or over ramps and stereo structures that a 2D costmap cannot represent, and you are willing to work inside its package set rather than assemble your own. Do not adopt it if a single-level floor plan is your entire operating domain; Nav2 is the better-supported choice there. Before committing, verify the CICD_setup documentation against your own LiDAR mount angle and confirm which ROS distribution the dddmr_lego_loam and dddmr_mcl_3dl packages actually build against, since the repository lists no releases.

Official sources

1. dfl-rlab/dddmr_navigation on GitHub
2. Issues
3. License: BSD-3-Clause
4. README