tare_planner: a hierarchical exploration planner for ground vehicles

Two levels of detail, and the insight that separates them

TARE Planner involves a hierarchical framework for highly efficient exploration, and the README describes the architecture in terms of the two levels rather than in terms of components.

One level maintains data densely and computes a detailed path within a local planning horizon. The other maintains data sparsely and computes a coarse path at the global scale. The paths at both levels are joined together to form the exploration path.

The insight behind the split is stated in the README and it is the whole idea. Detailed processing is most effective close to the vehicle, while coarse processing provides sufficient utility far away from the vehicle. The framework trades off details at the global scale for computational speed, and in practice it prioritises exploration in the surroundings of the vehicle while keeping the global picture in mind.

That is a different shape from the single-resolution planners that preceded it. A planner that treats every cell of a building the same way spends its computation on the far end of the map, where the robot will not be for another twenty minutes. TARE moves that budget to where the robot actually is, and keeps only a cheap representation of the rest so it still knows the way back and knows which direction has not been explored yet.

The project page at cmu-exploration.com is where the detailed instructions live, and the README points there for setup. The author is Chao Cao, and the research behind the planner is published: the framing paper is Representation Granularity Enables Time-Efficient Autonomous Exploration in Large, Complex Worlds in Science Robotics, volume 8, number 80, 2023, and the earlier TARE paper was presented at the Robotics: Science and Systems conference in July 2021, where it received a Best Paper Award and a Best System Paper Award. A related ICRA 2021 paper from the same group covers exploring large and complex environments fast and efficiently.

The repository is small in the way research code usually is, with only `.gitignore`, `README.md`, `img/` and `src/` at the top level.

Clone, checkout the melodic-noetic branch, catkin_make

The build is a catkin workspace, so the sequence is the standard ROS one and the README gives it explicitly.

git clone https://github.com/caochao39/tare_planner.git

Then, in a terminal, go to the folder, check out the melodic-noetic branch, and compile:

cd tare_planner
git checkout melodic-noetic
catkin_make

The branch name is the important part: melodic-noetic is both the default branch and the one you want, and its name covers both supported ROS distributions, which tells you the same source supports Melodic and Noetic.

Before that, the README asks you to follow the instructions in the Autonomous Exploration Development Environment at cmu-exploration.com to set up the development environment, and to make sure you check out the branch that matches the computer setup, compile, and download the simulation environments. The simulation environments are not optional extras here, since the planner is exercised inside them.

The repository has been tested in Ubuntu 18.04 with ROS Melodic and Ubuntu 20.04 with ROS Noetic, and those two combinations are the tested matrix rather than a general claim about versions. The code is C++, the licence is not classified, and the last push was on 2026-05-25, with no GitHub releases, so the branch is the version reference.

Running the exploration needs two terminals and two launch files

The running instructions are unusual enough to be worth quoting, because they show the shape of the system: the simulator is launched separately from the planner.

To run the code, you go to the development environment folder in a terminal, source the ROS workspace, and launch:

source devel/setup.sh
roslaunch vehicle_simulator system_garage.launch

In another terminal, you go to the TARE Planner folder, source the ROS workspace, and launch:

source devel/setup.sh
roslaunch tare_planner explore_garage.launch

You then see autonomous exploration in action. The two-terminal arrangement is a consequence of the simulation environment being a separate package with its own workspace, and it is the normal pattern for this family of ROS work.

Switching environments means switching both launch files together, and the README lists the environment names as campus, indoor, garage, tunnel and forest:

roslaunch vehicle_simulator system_<environment>.launch
roslaunch tare_planner explore_<environment>.launch

A separate path is given for Matterport3D, which requires setting up the Matterport3D environment from the development environment page first, and then the same pattern with different names:

roslaunch vehicle_simulator system_matterport.launch
roslaunch tare_planner explore_matterport.launch

The Matterport3D route matters because it is how you get large photorealistic indoor environments rather than the built-in ones. The names are a reminder that the planner and the environment are coupled by naming convention rather than by a configuration file, so the two must be kept in step.

The README also carries a rendering of the method as an image, `img/method.png`, which is the clearest short description of the two-level structure available in the repository.

OR-Tools decides the processor architecture you can run on

There is one dependency decision that will block you on an ARM machine, and the README explains it.

Because of usage of the OR-Tools library, the code previously only supported the AMD64 architecture. A recent upgrade to the library made it compatible with both AMD64 and ARM computers. On ARM computers, the instruction is to download the corresponding binary release for the target platform from the OR-Tools releases, for example the archive named `or-tools_arm64_debian-11_cpp_v9.8.3296.tar.gz`, extract it, and replace the `include` and `lib` folders under `tare_planner/src/tare_planner/or-tools`.

So the fix is a manual replacement of a vendored library rather than a package manager install, and the version matters. The example release is a Debian 11 C++ build of OR-Tools 9.8, so a different target platform or a different library version means picking a different archive, and the mismatch between the bundled headers and the system libraries is exactly the kind of thing that produces link errors rather than build errors.

The good news is the OR-Tools version in the example is new enough to be the one that made ARM support possible in the first place, and the credit section in the README credits OR-Tools to Google, which is where the library comes from.

The reason OR-Tools is in the picture at all is not stated in the repository. What the README says is that it is used, and that the architecture support followed from its version. For a planner that computes paths under constraints, a constraint solver is a plausible component, but the repository does not describe how the library is applied, so the details would have to be read in the source.

The DARPA Subterranean Challenge numbers and what they measure

The application section gives the planner's strongest evidence, and it comes with a specific figure that is worth reading carefully.

TARE Planner was used by the CMU-OSU Team in attending the DARPA Subterranean Challenge. In the final competition, which took place in Louisville Mega Cavern, Kentucky, the team's robots conducted the most complete exploration across the site, 26 out of 28 sectors, among all teams, winning a Most Sectors Explored Award.

A separate result is quoted for the Urban Circuit, which took place in Satsop Nuclear Plant, Washington. The vehicle traveled over 886m in 1458s to explore the site, fully autonomously.

The 26 of 28 sectors figure is a coverage metric with a clear definition, which is what makes it useful as evidence rather than a claim. Sectors are marked regions of the course, and exploring 26 of them means the robot reached almost all of the venue, which is a direct measure of whether a planner can keep an unmapped, large, unstructured environment covered. It is the right metric for an exploration planner, and the venue, a megacavern, is a hard case: wide, dark, and full of structure the robot has to interpret.

The 886 metres in 1458 seconds figure is a different kind of number. It is a single vehicle run on one circuit, so it measures an average speed of traversal rather than any quality of the resulting map. The interesting number in it is the autonomy, since nothing was driven by a person.

The team itself is worth noting for the robotics context, since the DARPA Subterranean Challenge was a multi-year programme of hard problems in perception, mapping and mobility, and a shared exploration planner across the team's robots is a plausible part of how they ran a common fleet.

The repository is not archived and has no releases, so the citation list in the README and the branch are the only version and provenance references.

A research package, and the difference that means for anyone else

The honest framing is that this is a paper implementation, and its strengths and weaknesses come from the same source.

What it gives you is a two-level planner that has been through a competition and a published review, written by the same group that wrote the papers. The architecture is legible from the README, the environment list is broad for a research package, and the Matterport3D path means you can test in large photorealistic indoor scenes rather than only in a simulator built for the purpose. For a student or researcher picking up autonomous exploration, the value is that you can read a small amount of code and see how a hierarchical representation granularity argument was actually implemented.

What it does not give you is a navigation stack. There is no localisation component described, no obstacle avoidance layer, no sensor pipeline, no hardware abstraction, and no configuration surface beyond the launch files and environment names. The planner is the piece, and the surrounding robot system comes from the development environment, which is a separate download and a separate set of instructions.

There is also the platform question. ROS Melodic and Noetic are the tested combinations, and both are distributions whose support windows have closed in the intervening years, so a new build on a current Ubuntu will need work that the README does not cover. A ROS 2 port would be a substantial job, since the planner's launch files, message types and node structure are all ROS 1 idioms.

The comparison worth making is with the other options. A commercial exploration stack would give you localisation, mapping, planning and hardware support together, at the cost of a licence and a closed design. A general-purpose SLAM stack with a custom exploration layer on top gives you a maintained foundation and leaves you to write the hierarchical planning yourself, which is precisely the part TARE implements. That last option is the honest alternative, and TARE is most valuable as a reference implementation to read rather than as a dependency to install.

Editorial conclusion

Adopt tare_planner if you are working on autonomous exploration in large environments and want the two-level local and global planner with the code that produced the DARPA Subterranean Challenge results. Do not adopt it as a productised navigation stack, because it is a research package tested against ROS Melodic and Noetic, and check first that the OR-Tools binary you install matches your processor architecture, since the ARM64 build is supplied separately and has to replace the bundled include and lib folders by hand.

Frequently asked questions

Official sources

1. caochao39/tare_planner on GitHub
2. Issues
3. README