NeuPAN replaces the module pipeline with one optimisation

The planner is one optimisation, not a pipeline

NeuPAN expands to Neural Proximal Alternating-minimization Network, and the description calls it an end-to-end, real-time, map-free and easy to deploy MPC based robot motion planner.

The mechanism is stated directly. NeuPAN maps obstacle points data to control actions in real time by solving an end-to-end mathematical model with numerous point-level collision avoidance constraints. The stated benefit is that this eliminates middle module design, which avoids error propagation, and that it reaches high accuracy in cluttered and unknown environments.

That last phrase is doing the work. A traditional stack turns a depth camera into a point cloud, the point cloud into an occupancy map, the map into a global plan, and the global plan into local commands, and each arrow in that chain is a place where an error is introduced and never corrected. NeuPAN removes the arrows. The obstacle points are the input to the optimisation and the control actions are the output, with the collision avoidance expressed as constraints on the optimisation rather than as a separate stage that checks the plan afterwards.

The dependency list in `pyproject.toml` is consistent with that description. The package depends on `cvxpylayers` and `ecos` and `torch>=2.1.0` and `scipy<=1.13.0` and `numpy`, which is the machinery for differentiating through a convex program, and the name itself points at a neural network coupled to a proximal alternating-minimisation scheme. Whether that is the whole story of the algorithm is a question for the paper, which is linked from the README in both an IEEE and an arXiv version.

The audience is a robotics researcher or engineer working on local planning for a mobile robot, and the home page is a project page rather than a product site.

The comparison table is the project's real argument

The README contains a table comparing NeuPAN with two families of alternative, and the table is more useful than a feature list because it names the trade-off each approach makes.

The two comparison columns are traditional modular planners, with TEB and DWA named as examples, and end-to-end learning-based planners, with reinforcement learning and imitation learning named. The rows are architecture, environment handling, training data, training time, retraining, safety guarantee and deployment.

On architecture, the traditional planners are described as a modular pipeline with object detection, mapping and planning, the learning planners as an end-to-end policy network, and NeuPAN as an end-to-end framework without middle modules that avoids error propagation.

On environment handling, the traditional planners are limited by their map representation and object models, the learning planners depend on their training environments, and NeuPAN processes obstacle points directly, which is described as handling cluttered and unstructured environments with arbitrarily shaped objects.

The two rows that matter most for a decision are training data and retraining. The traditional planners need no training because they are rule based, and the learning planners need a large amount of real or simulated data, hours to days on GPU clusters, and often retraining for a new environment. NeuPAN's entry claims minimal training data, simply random points within a certain range, fast training of one to two hours on CPU for new robot geometry, and training once for the robot geometry so that it can be applied to various environments without retraining.

The safety row is the one to read carefully. The traditional planners rely on accurate perception, the learning planners have no formal safety guarantee, and NeuPAN is described as using mathematical optimisation with collision avoidance constraints for reliable deployment.

The deployment row adds that the learning planners are a black box and hard to debug, while NeuPAN is described as easy to deploy and flexible to integrate with global planners such as A* and VLN.

You train for the robot's geometry, not for the environment

The training story is the part of the design that most changes how you would use the planner, so it is worth being concrete about it.

NeuPAN is trained for the geometry of a particular robot. Once trained, the same model is applied to various environments without retraining. The training data is minimal, and the documented way to produce it is random points within a certain range.

That is a very different data regime from a learned policy. A reinforcement learning or imitation learning planner learns a mapping from observations to actions, so it has to see the distribution of environments it will face, and a new environment means new data. NeuPAN learns something about the robot, and the environment arrives at run time as points.

The practical consequence is that the expensive step happens once per robot, and it takes one to two hours on a CPU rather than on a GPU cluster. A team with a fleet of identical robots pays that cost once. A team with a robot whose geometry changes, a manipulator that reconfigures, or a vehicle with a detachable trailer, pays it again, and the cost scales with how often the shape changes rather than with how many places the robot drives.

The advanced usage section of the documentation covers a DUNE model training workflow, and the `example/dune_train` and `example/LON` directories hold the training examples, so the training procedure is meant to be run rather than taken on trust.

The other thing the training regime buys is the safety argument. Because the collision avoidance is a constraint in the optimisation rather than a learned behaviour, the planner's output respects the constraint by construction rather than by having seen enough examples. The table's claim of a mathematical guarantee is a claim about the formulation, and it is the claim a reviewer should test against the paper.

Running the examples in the IR-SIM simulator

The quick start is short and the requirements are modest: Python 3.10 or newer.

# Install NeuPAN
git clone https://github.com/hanruihua/NeuPAN
cd NeuPAN
pip install -e .

# Install IR-SIM for running examples
pip install ir-sim

# Run your first example
cd example
python run_exp.py -e corridor -d diff

The `-e` flag selects the scenario and `-d` selects the robot model. The three model names are `diff` for differential drive, `acker` for Ackermann steering, and `omni` for omnidirectional. The scenario list in the documentation is longer: `convex_obs` for convex obstacles, `corridor`, `dyna_non_obs` for dynamic nonconvex obstacles, `dyna_obs` for dynamic obstacles, `non_obs` for nonconvex obstacles, `pf` for path following, `pf_obs` for path following with obstacles, `polygon_robot`, `reverse` for car reverse parking, plus the DUNE and LON training directories.

The simulator is IR-SIM, which is also by the same author, and the package declares an optional extra for it, `irsim = ['ir-sim>=2.4.0']`. Installing with the `all` extra gives you the same set.

The examples are organised one directory per scenario, with a shared `run_exp.py` at the top of `example/`, and there is an `example/model` directory and an `example/animation` directory, which suggests that trained models and recorded runs are both part of the example flow rather than something you have to produce from scratch before you can see anything happen.

The scenarios are chosen to stress the parts of the problem that are hard for a planner of this kind. Nonconvex and dynamic obstacles test the point-level constraint formulation, `polygon_robot` tests a non-circular footprint, and `reverse` is a car reverse parking case, which is where a controller that always moves forward has to fail.

Deployment paths: ROS, global planners and real robots

The README links a ROS and ROS2 wrapper in a separate repository, `neupan_ros`, and the advanced usage section covers ROS integration and real world deployment as well as the DUNE training workflow.

The wrapper being separate is a sensible arrangement. A ROS node has to deal with topics, transforms, timers and the ROS distribution version, and none of that belongs in a planner core that has to be testable in isolation. Keeping the Python package independent of ROS means the planner can be developed and tested against a simulator, as the examples do, and the ROS layer stays a thin adapter.

The integration story is also stated in the comparison table, where NeuPAN is described as flexible to integrate with global planners, with A* and VLN named. That is the intended division of labour. A global planner works out a route, and the local planner handles the part where the robot actually is, among the obstacles that the global planner knew nothing about. A map-free local planner is exactly the component that a global planner needs behind it, and the ability to take a goal or a reference path as input is what makes the pairing work.

The news list shows how the project has been picked up. On 2025-12-25 the NeuPAN planner was integrated into the odin-nav-stack project, and the news entry invites people to try it there. On 2025-04-24 a Python 3.8 compatible version was published on a `py38` branch, which is the sort of accommodation a research group makes for a robot platform that cannot move to a newer Python.

For a reader evaluating this, the demo videos and the project page are the most direct evidence of behaviour in clutter, and the demonstrations section of the README points at them.

Where a point cloud planner is the wrong tool

The limitations are structural and follow from the same decision that gives the project its advantages.

The first is the input. NeuPAN processes obstacle points directly, and that is what lets it handle unstructured environments with arbitrarily shaped objects. It also means it needs a source of points. A depth camera or a lidar gives you points, and a semantic map gives you labelled geometry. If the task needs a robot to reason about a door, a person or a room rather than about a shape to avoid, this planner is not the component that will do it.

The second is the training dependency on geometry. The one to two hour training is a small cost paid once, but it is a cost that recurs whenever the robot's shape changes, and it is a cost paid before the first deployment rather than as part of it. A team that has not yet fixed the robot's geometry is making a bet on a workflow that assumes they have.

The third is the dependency stack. The package needs `torch>=2.1.0`, `cvxpylayers`, `ecos` and `numpy`, and `scipy<=1.13.0`, which is an upper bound that will eventually be a problem when a user needs a newer SciPy for something else in the same environment. A system that must run on a robot also has a size and a start-up cost that a rule based planner does not, and the safety argument, strong as it is, rests on the constraint formulation being right for the robot's footprint and dynamics.

The alternative to consider, and the difference in approach is real, is the classical local planner in the table, TEB or DWA, which needs no training, at the cost of the modular pipeline and its error propagation. The other alternative is the learned policy, which is a black box and has no formal safety guarantee. NeuPAN's position is between them, taking the training cost of the learned approach and the safety property of the optimisation, and paying for it with the dependency stack and the retraining whenever the geometry changes.

For a research or evaluation setting that is a good trade. For a product, the retraining story and the dependency footprint are the two questions to answer first.

Editorial conclusion

NeuPAN suits a robotics team that has a point cloud from a depth camera or lidar and wants a local planner that takes it directly to control commands, with collision avoidance enforced as optimisation constraints rather than hoped for. It is the wrong tool for a task that depends on a semantic map, on a global plan, or on perception the robot does not have, and the wrong tool if the robot's footprint changes often, since the model is trained for its geometry. Check first the Current Limitations section in the project documentation, then run the corridor example in the simulator to see how the planner behaves in clutter before you put it on hardware.

Frequently asked questions

Official sources

1. hanruihua/NeuPAN on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases