NavDP: a navigation diffusion policy trained without real robot data

A policy that never sees a real robot

NavDP is an end-to-end mapless navigation model from the Shanghai AI Laboratory and its collaborators, published at ICRA 2026, with the paper on arXiv as 2505.08712. The authors are Wenzhe Cai, Jiaqi Peng, Yuqiang Yang, Yujian Zhang, Meng Wei, Hanqing Wang, Yilun Chen, Tai Wang and Jiangmiao Pang, across the Shanghai AI Laboratory, Tsinghua University, Zhejiang University and the University of Hong Kong.

The claim in the project description is the interesting one: the model achieves cross-embodiment generalisation without any real world robot data. The route to that is a highly efficient simulation data generation pipeline combined with the model design, and the outcome the documentation claims is real-time path planning and obstacle avoidance across several navigation tasks.

That is a different starting point from most navigation research, which collects demonstrations on a handful of robots and then tries to generalise. Here the data generation is simulated and the embodiment generalisation is supposed to fall out of the training setup. The audience is navigation researchers and robotics engineers who want a policy that transfers, and who are also willing to work inside a simulation stack.

The repository is a research monorepo rather than a library. The top level holds a baselines directory, a configs directory, a utils_tasks directory, a wheeled_robots directory, and a set of evaluation and teleoperation scripts named for the task they handle. There is no package index entry, no versioned release, and the last push to the repository was on 2026-09-07.

Three tasks share one policy

NavDP covers three navigation settings, and the repository has matching scripts for each.

No-goal exploration is the free-form case, where the robot has no destination and is expected to explore. Point-goal navigation gives a target position. Image-goal navigation gives a target image rather than coordinates, which is the case that matters for a robot asked to go somewhere it has only seen a picture of.

The evaluation entry points in the repository make the split explicit. There is an eval script for image-goal navigation, one for no-goal, one for point-goal and one for start-goal, each suffixed for wheeled robots, and teleoperation scripts for the image-goal, no-goal and point-goal tasks. The teleop_ prefix marks these as teleoperation scripts, letting a human drive the robot through the same tasks.

The model itself is described as a diffusion policy, which is worth noting because it explains the shape of the code. Rather than regressing a single action or trajectory, a diffusion policy generates a trajectory by denoising, so the output is a path rather than a heading. That is a good fit for navigation, where the useful output is a short plan that a lower-level controller then follows.

The same repository also hosts several related projects under the InternRobotics organisation, released around the same period: X-NavDP, an RL post-training framework for navigation diffusion policies across heterogeneous embodiments, accepted at CoRL 2026; LoGoPlanner, a localisation-grounded end-to-end navigation framework; InternVLA-N1, an end-to-end navigation dual-system; and InternNav, described as an all-in-one open-source toolbox for embodied navigation.

The benchmark talks HTTP to your policy

The InternVLA-N1 System-1 benchmark is the part of the repository with the wider audience, and its two headline design choices are worth explaining.

The first is a decoupled framework between navigation approaches and the evaluation process. The evaluation calls the navigation method API with HTTP requests, so the model implementation and the scoring process are separate. The stated benefit is that it is much easier to evaluate the performance of novel navigation methods, which matters when the thing you want to test is your own policy and the thing you do not want to write again is the harness.

The second is a fully asynchronous framework between trajectory planning and following. An MPC-based controller constantly tracks the planned trajectory, and because planning and following run at different rates, the evaluation metrics end up related to the decision frequency of the navigation approach. The documentation argues that this aligns the numbers with real-world navigation performance, which is a fair point: a policy that replans at 2 Hz and one that replans at 20 Hz should not score identically on a path-tracking metric.

The evaluation runs in IsaacSim and IsaacLab, with realistic physics simulation and realistic scene assets, and the stated aim of the platform is to minimise the sim-to-real gap in system-1 evaluation. It supports no-goal exploration, point-goal and image-goal tasks, and it supports diverse scene assets including random cluttered environments, realistic home scenarios and commercial scenarios.

Setting up the environment, and the server your policy runs in

The installation is a conda environment and a pinned dependency file. You clone the repository and move into the NavDP baseline directory:

git clone https://github.com/InternRobotics/NavDP
cd NavDP/baselines/navdp/

Then you create the environment and install the dependencies:

conda create -n navdp python=3.10
conda activate navdp
pip install -r requirements.txt

That requirements file is fully pinned, to the patch level, and it is large. A few entries tell you what you are getting into:

isaaclab==2.0.2
diffusers==0.33.1
hydra-core==1.3.2
gymnasium==0.29.0
huggingface-hub==0.29.2
einops==0.8.1

The diffusers and einops entries are the diffusion policy and the tensor manipulation layer it needs, hydra is the configuration system, and isaaclab pins the simulation stack. Pinning everything exactly is what makes a research environment reproducible, and it is also what makes it hard to combine with an existing environment that needs a different version of anything.

The policy runs as a server process, which is the shape the HTTP based benchmark expects:

python navdp_server.py --port ${YOUR_PORT} --checkpoint ${SAVE_PTH_PATH}

After that, the documented path is to follow the tutorial for building the IsaacSim environment and start the evaluation in simulation, and the benchmark ships example runs for the no-goal, point-goal and image-goal tasks.

The checkpoint is behind a form, and the licence is unstated

Two things about the distribution are worth knowing before you plan around this repository.

The first is the InternVLA-N1 System-1 model checkpoint. To download it, you are asked to fill in a form, and the resulting link is what gives access to the latest checkpoint. So the weights are not fetched from a public URL or a Hugging Face repository the way the scene assets are. That is a normal arrangement for a research release tied to a paper, and it also means the checkpoint is not reproducible by a script, so a build pipeline that expects to fetch it automatically will not work as written.

The second is the licence. The repository listing at the top level does not include a licence file, and the licence recorded for the project is unknown. That is a genuine blocker for adoption rather than a formality. Code in a public repository without a stated licence is not licensed for reuse, and while a research group will normally grant one, the terms have to come from the authors.

The scene assets take a different route, which is worth noting for contrast. The evaluation scenes come from a separate dataset, InternScene-N1 on Hugging Face, and the README points at the n1_eval_scenes directory there. The dataset and the code are therefore distributed through different channels with different conditions, which is a common pattern in this field and a common source of confusion when you try to reproduce a result.

A monorepo, and how it fits with the wider InternRobotics stack

The repository layout tells you how to read the project. There is a baselines directory holding the navigation methods to be evaluated, including a logoplanner directory whose README documents an open-sourced deploy process based on LeKiwi, from hardware setup through to algorithm deployment. There is a configs directory, a utils_tasks directory, a wheeled_robots directory, and the evaluation and teleoperation scripts at the top level.

That deploy process is the most practically interesting line in the news section, because it covers hardware setup as well as the algorithm, and it is based on LeKiwi. For a team that wants to move from simulation to a physical robot, having the deployment path written down next to the training code shortens a project considerably.

The related releases matter for the same reason. InternNav is described as an all-in-one open-source toolbox for embodied navigation, which is a broader entry point than this repository. X-NavDP is an RL post-training framework for navigation diffusion policies across heterogeneous embodiments, and its acceptance at CoRL 2026 was announced on 2026-09-04, which suggests the post-training direction is where the group is putting its effort. LoGoPlanner, a localisation-grounded end-to-end navigation framework, and InternVLA-N1, a dual-system model, fill in the localisation and system-level parts of the picture.

None of these are packaged releases. The repository publishes no GitHub releases, so there is no version to pin, and the last push was on 2026-09-07. Anyone building on this should treat the repository as a moving research artefact and pin a commit hash.

Editorial conclusion

NavDP suits a robotics team that needs a navigation policy generalising across embodiments and a benchmark harness that can score any navigation method, and it is the wrong choice for a team that needs the checkpoint immediately or that needs clear usage terms, since the model is released through a form and the repository records no licence. Verify first what the licence actually is before you build on the code, since there is no licence file in the repository listing, and confirm your simulation stack matches the pinned environment, because the requirements file pins isaaclab and the rest exactly and the evaluation path runs through IsaacSim.

Frequently asked questions

Official sources

1. InternRobotics/NavDP on GitHub
2. Issues
3. README