OmniPlanner: one graph-based planner for robots that fly, drive and swim

GBPlanner 2.0 won the challenge, GBPlanner 3.0 generalises it

The repository carries two generations of the same idea, and the distinction matters more than the version numbers suggest.

The README states that OmniPlanner builds upon GBPlanner 2.0, the exploration planning method that guided all robots of Team CERBERUS during the winning run at the DARPA Subterranean Challenge. An updated version of GBPlanner 2.0 remains available on the gbplanner2 branch of the same repository, so both generations sit side by side rather than one replacing the other. The default branch is gbplanner3, which is the OmniPlanner work.

What OmniPlanner adds is breadth. It is described as a unified graph-based planning framework that enables autonomous robots to explore unknown environments, inspect structures and regions of interest, and reach a specified target. Its modular formulation adapts the planning process to the motion and sensing characteristics of aerial, ground and underwater platforms, so the same framework is meant to produce feasible and informative paths across different morphologies and operating environments.

Three tasks in one sentence is worth pausing on, because it is a wider scope than the original exploration planner. Exploration asks where to go next, inspection asks how to observe a structure closely, and target reach asks how to get to a named place. A framework that unifies them has to make the planner aware of what kind of goal it is being given, and that shows up in the message layout of the codebase.

The project publishes a homepage, an arXiv entry and a video, and the documentation, installation instructions and demos live in a separate wiki repository rather than in the README. The primary method paper is an arXiv preprint from 2026 by Zacharia, Dharmadhikari, Singh and Alexis, and the README asks for it to be cited in that form.

The module list shows a planner split into reusable pieces

The top level of the repository is a set of packages that map onto the framework's structure.

planner_common/ holds the pieces shared by the planners, planner_control_interface/ defines the control side, planner_msgs/ and planner_semantic_msgs/ carry the message and semantic message definitions, and map_manager/ handles the map. There is a kdtree/ directory, which is the spatial index used for fast nearest-neighbour queries over the exploration graph, and a gbplanner/ directory for the planner itself. gbplanner_ui/ is the user interface, and there are two simulation-oriented packages, planner_gazebo_sim/ and ugv_simulator/, plus a vcstool/ directory that holds the dependency manifest used at install time.

Two details in that list are worth pausing on. The separation of planner_msgs/ and planner_semantic_msgs/ says the framework carries two layers of information, raw planning messages and a semantic layer above them, which is consistent with a framework whose goal types include inspection of a structure rather than only travel to a coordinate. And the presence of both a Gazebo package and a UGV simulator says the simulation side is a first-class part of the deliverable, not an afterthought.

The .clang-format file at the root says the code is formatted with clang-format, and the whole project is C++ under a BSD-3-Clause licence, which is a permissive choice for academic code that companies often build on.

Installation is three catkin workspaces that must extend each other

The install is the part you will spend your time on, and the README is unusually explicit about it. Everything lives under a single development environment directory, and there are three workspaces inside it.

The first is the simulator. If you intend to use Gazebo, you need Gazebo Garden built from source on Ubuntu 20.04, which means the usual ROS tooling first:

sudo apt install python3-pip lsb-release gnupg curl git
pip3 install vcstool
pip3 install -U colcon-common-extensions

Then you create a workspace for it, fetch the source list with vcs import, and build with colcon, disabling the test targets to save time:

colcon graph
colcon build --cmake-args -DBUILD_TESTING=OFF --merge-install

The second workspace is the ROS-GZ bridge, which is not the upstream one but a fork:

git clone [email protected]:ntnu-arl/ros_gz.git -b garden_noetic
cd ~/ros_gz_bridge_ws
catkin config --install
catkin build

The third workspace holds the planner itself. The dependencies are ROS packages, and the clone is into an exploration directory:

sudo apt install python3-catkin-tools \
libgoogle-glog-dev \
ros-noetic-joy \
ros-noetic-twist-mux \
ros-noetic-interactive-marker-twist-server \
ros-noetic-octomap-msgs \
ros-noetic-octomap-ros \
git-lfs

mkdir -p ~/omniplanner_dev_env/omniplanner_ws/src/exploration
cd ~/omniplanner_dev_env/omniplanner_ws/src/exploration

git clone [email protected]:ntnu-arl/gbplanner_ros.git

The remaining packages come from the repository's own manifest rather than by hand, and the cave simulation is pulled with git lfs because it holds large assets:

cd ~/omniplanner_dev_env/omniplanner_ws/
vcs import < ./src/exploration/gbplanner_ros/vcstool/packages.repos
cd src/sim/subt_cave_sim
git lfs pull

The build is a release build, and each workspace has to extend the others:

catkin config -DCMAKE_BUILD_TYPE=Release
catkin build

source ~/omniplanner_dev_env/omniplanner_ws/devel/setup.sh

The README is explicit that the planner workspace must extend the Gazebo workspace install, the bridge workspace install and /opt/ros/noetic. Skip that and the nodes will build and then fail to find their simulator.

The simulator expects a patched gz-sim and a pinned gz-common

Two setup notes in the README save you from a class of confusing failures, and both concern the simulator rather than the planner.

The first is a note under the dependency install step: replace the files of the gz-sim folder with the files from the maintainers' own fork branch and switch gz-common to the 82a649e1 commit. The simulator is therefore not the stock Gazebo Garden, it is Garden plus a change to the multicopter control code, and the common libraries have to be pinned to a specific commit to match. Without that pin, the versions drift and the behaviour of the simulated vehicle changes underneath you.

The second note is about how the workspaces are layered. The ROS-GZ bridge workspace must extend the Gazebo Garden install and the Noetic installation, and the planner workspace must extend both of those in turn. That layering is the reason the README repeats the instruction three times in three different sections, and it is the single most common setup mistake in a stack of this shape: a package resolves against a different version of the bridge than the one you built.

The source install of Gazebo Garden itself is the reason this is heavy. The README follows the upstream Gazebo instructions for Ubuntu 20.04, adding the OSRF keyring and repository, installing the packages that the collection list resolves, and building with colcon. It is a long sequence, and it is the price of running a simulator version that the project needs rather than a distribution package.

The payoff for that work is the cave environment. The subt_cave_sim assets are fetched with git lfs, so the simulation is a subterranean cave rather than an empty world, which is the environment the whole method was developed for.

No releases means the branch is the release

The packaging story here is unusual, and it is the main practical difference between this project and a library you would consume.

The repository publishes no GitHub releases. The last push was on 2026-10-13, so work continues, but there is no version tag to pin a dependency to, no changelog to read before upgrading and no binary to download. What you consume is a branch, and the branch names carry meaning: gbplanner3 is the OmniPlanner line, and gbplanner2 is the maintained version of the method that ran in the challenge.

The consequence is that your fork of this project becomes your release engineering. If you take the code into a company, you will want to snapshot a commit, because the default branch will move under you and there is no upstream mechanism telling you what changed. The README's citation block is a small but telling detail: the ask is to cite an arXiv preprint with a 2603.04284 identifier, which is the method description of record for the current work, while earlier generations are cited through the published journal and conference papers for the 2020 aerial and legged exploration work and the 2022 teamed subterranean exploration paper.

Licensing is simple by comparison. BSD-3-Clause is a permissive licence with the usual attribution requirement, and for a research codebase that companies have to modify, it is a much easier starting position than a copyleft licence with a network clause. No commercial licence negotiation is involved here, and the wiki, rather than the repository, is where installation instructions, demos and the extended documentation live.

Editorial conclusion

Adopt OmniPlanner if your team works on exploration or inspection path planning for autonomous platforms and wants a framework that spans aerial, ground and underwater morphologies rather than a planner written for one vehicle. Do not adopt it expecting a packaged release, because the repository publishes no GitHub releases and the install path is three source-built catkin workspaces on Ubuntu 20.04 with ROS Noetic. Before you start, read the gbplanner2 branch documentation, since that is the version that guided the Team CERBERUS robots at the DARPA Subterranean Challenge and is the better tested starting point, and follow the setup note that pins gz-common to commit 82a649e1 and replaces the gz-sim sources with the multicopter_control branch.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. ntnu-arl/gbplanner_ros on GitHub
4. README