wild_visual_navigation, version 0.0.1 and a template description

The package description is still the template default

The metadata in setup.py describes a different project from the one in the README.

The package declares version 0.0.1 and a description of A small example package. Everything else in the repository is a published research system with a conference paper, a journal paper, five Python packages, ROS integration for two robots, and a Docker quick start.

So the description is a leftover from the packaging tutorial the project was scaffolded from, and it has not been touched since. On a package index that line is the only summary most people see, and version 0.0.1 is the only version number anywhere in the tree, since the repository has no releases.

The authorship is correct and current: Jonas Frey and Matias Mattamala, with contact addresses, matching the two papers the README asks you to cite.

What the metadata does not carry is any hint of the system requirements. There is no classifier for the ROS version, nothing for CUDA, and no extras. Anyone installing from an index rather than from source would get a package with no indication that it needs a GPU.

A CPython 3.8 CUDA 12.1 wheel is pinned against python_requires 3.7

One line in setup.py will decide whether an install resolves, and it has almost nothing to do with the code.

The dependencies field contains a single direct link to a torch wheel built for torch 2.1.0, CUDA 12.1, CPython 3.8, Linux, and x86_64. The same URL is repeated in dependency_links, which is itself a deprecated mechanism.

So the install expects one exact interpreter, one operating system, and one architecture, while python_requires on the line above says 3.7 or newer with no upper bound. Those two statements cannot both be true on a modern machine. On Python 3.10, on Apple Silicon, or on a Jetson with a different Python, that wheel does not exist and the resolution fails.

There is a related compatibility problem a few lines up. The file imports setup from distutils.core rather than setuptools, and distutils was removed from the standard library in recent Python releases. A python_requires floor of 3.7 combined with an import that recent interpreters do not provide means the supported range is narrower than advertised in both directions.

The README's answer is to use Docker, and inspecting the Dockerfile is recommended as the clean route. That is not a workaround for the metadata, it is an admission of it.

Two dependencies install from GitHub with no ref

Two entries in the install requirements are direct references to GitHub repositories.

The documented source install clones this project and a STEGO reimplementation side by side and then fetches pre-trained weights:

mkdir ~/git && cd ~/git
git clone [email protected]:leggedrobotics/wild_visual_navigation.git
git clone [email protected]:leggedrobotics/self_supervised_segmentation.git
./self_supervised_segmentation/models/download_pretrained.sh

pydensecrf comes from a fork under another account, and liegroups comes from the repository of one of this project's own authors. Neither pins a commit, a tag, or a branch.

That means the same install command run twice, on two machines, months apart, can produce different code. It also means a build is not reproducible from the requirements alone, and that an upstream change to either repository silently lands in your environment.

The rest of the list has its own character. There is an exact pin on opencv-python at 4.2.0.34, with a comment above the list explaining that a newer version would not build on the Jetson, which is the right reason for the pin. Several entries carry floors, kornia at 0.6.5, torch at 1.21, pytorch_lightning at 1.6.5, and many more carry nothing at all.

Three of the runtime dependencies are experiment tooling rather than something the system needs to run: pytest, optuna, neptune, wandb, seaborn, and matplotlib all sit in install_requires rather than an extra. pip itself is listed as well, which is not a dependency any package should declare.

Two command typos stop a first-time build

The ROS setup section has two commands that cannot work as written.

The build step ends with a target name that is missing its last three letters: catkin build wild_visual_naviga. Every other reference to the package in the file spells it wild_visual_navigation in full, so the truncated name is a typo rather than an alternative short name, and catkin will report no such package.

The rosbag replay line reads robag play --clock path_to_mission/*.bag, which is rosbag with the s missing. The --clock flag is correct and is what you want when replaying recorded data into a system that publishes a simulated clock.

Both are in the ROS setup section rather than the minimal setup section, so someone following the quick start on Docker will not hit them. Someone building the workspace will hit both, in sequence, and the first one fails before the second is reached.

The rest of that section is careful. It creates a catkin workspace, extends it against the Noetic install, sets a build type of RelWithDebInfo, clones the ANYmal robot description and a process manager, symlinks the WVN repository into the source tree rather than copying it, runs rosdep with --from-paths and --ignore-src, and then builds. The symlink choice is the right one for development, since edits show up without a rebuild.

Three config files and one of them is rewritten at runtime

Configuration is spread across three files, and one of them does double duty.

The general configuration lives in a Python file under cfg/experiment_params.py, and it is used by both the offline model training mode and the online ROS mode. The online ROS mode adds a second file, cfg/ros_params.py, and the README says both of these are filled based on the ROS parameter server during runtime. Defaults for that layer are in a YAML file under the ROS package's config directory.

The ambiguity is in ros_params.py. It is described first as the place where additional configuration for the individual nodes is defined, and then as a configuration that is filled from the parameter server during runtime. Those are two different roles: one is a source you edit, the other is an output you read. A Python file inside a cfg/ directory, next to a hand-written experiment config, reads as the former.

Using Python for the first two rather than YAML is a deliberate choice in a research codebase, since it allows expressions, and it means the configuration can import from the package. It also means a configuration error is a Python error rather than a parse warning.

The YAML default lives under a path that repeats the package name twice, wild_visual_navigation/wild_visual_navigation_ros/config/wild_visual_navigation/, which is the usual layout for a ROS package nested in a Python package but is easy to mistype.

A .deprecated directory sits at the root

The repository keeps its own history in the tree, which is unusual and useful.

Alongside the five packages and the tests directory there is a .deprecated/ directory. Nothing in the visible documentation explains what is in it or whether it is still importable.

For a research codebase the practice is defensible. The alternative is that superseded experiment code gets deleted and then rewritten three months later, or that it survives in a branch nobody can find. Keeping it visible at the root at least tells you it exists.

The risk is the other direction. A directory named .deprecated at the top level, next to importable packages, is a plausible import target for something with a stale path. There is no note in the README steering people away from it.

The package layout itself is the interesting part. There is the core wild_visual_navigation package, then wild_visual_navigation_anymal and wild_visual_navigation_jackal for the two robot integrations, wild_visual_navigation_msgs for message definitions, and wild_visual_navigation_ros for the ROS nodes. The ROS nodes are two Python scripts you can run directly for debugging, a feature extractor and a learning node, which is the shape that makes a two-node pipeline debuggable without a launch file.

One paper, two publication dates

The citation block is thorough, and it contains a small inconsistency worth resolving before you cite it.

The first reference is the 2023 Robotics: Science and Systems paper on fast traversability estimation, with authors Frey, Mattamala, Chebrolu, Cadena, Fallon, and Hutter, published in Daegu with a DOI.

The second is the extended system. The README dates it 2024 and links a preprint from 2024, while the bibliography entry underneath is an article in Autonomous Robots, volume 49, number 3, dated 18 July 2025, with its own DOI. Same work, two dates, and the README's own year matches the preprint rather than the version of record.

If you are citing the journal version, the 2025 date is the one that belongs in your bibliography. If you are citing the preprint, 2024 is correct and the preprint link is the right thing to point at.

The README also asks for a third citation, the MEM multi-modal elevation mapping paper, but only if you use the elevation_mapping_cupy integration. That integration is listed as a feature in its own right, and the mapping repository is a separate project with its own citation requirement.

Three citations for one package is a good sign about how the work is meant to be used, and a reminder that the elevation mapping path is a dependency with its own obligations rather than an optional extra.

Editorial conclusion

Use this repository if you want the published WVN system rather than a reimplementation, and if you already have ROS 1 Noetic and a CUDA GPU. The simulation quick start on Docker is the cheapest way to find out whether it fits your setup before you build a catkin workspace. Before you start, check four things. Whether your Python version can satisfy a setup.py that imports distutils, which removed in recent interpreters. Whether you are on a CPython 3.8 linux x86_64 machine, because the pinned torch wheel link is built for exactly that combination. Whether you can accept two dependencies installed straight from GitHub with no ref. And whether the typos in the ROS build and rosbag lines have been fixed in the copy of the README you are reading.

Frequently asked questions

Official sources

1. Issues
2. leggedrobotics/wild_visual_navigation on GitHub
3. License: MIT
4. Project website
5. README