ros_motion_planning: Path Planning and Navigation Algorithm Library for ROS Noetic

Path Searching and Trajectory Optimization for AGV and AMR Robots

Motion planning divides into two connected problems. The first is path searching: finding a valid sequence of positions that gets a robot from its start to its goal without hitting obstacles. The second is trajectory optimization: refining that raw path to respect the robot's physical constraints, such as maximum velocity and turning radius.

ros_motion_planning addresses both by providing C++ implementations of well-known planning algorithms as ROS plugin classes. Each algorithm plugs into the move_base navigation framework as either a global planner, which plans the full route from start to goal, or a local planner, which adjusts velocity commands in real time to follow that route. The repository targets robotics engineers working on AGVs (automated guided vehicles) or AMRs (autonomous mobile robots) who want to benchmark multiple algorithms on the same hardware stack, researchers who want working code alongside published theory, and students who need ROS implementations to match against classroom material. A companion blog covers the theory for each algorithm, and separate Python and MATLAB repositories support the same algorithms in scripting environments for those who want to study behavior without a full ROS stack.

Algorithm Coverage: Nineteen Named Planners Across Three Families

The repository description lists nineteen named algorithms. The global planner group includes graph-based methods (A*, JPS, D*, LPA*, D* Lite, Theta*), sampling-based methods (RRT, RRT*, RRT-Connect, Informed RRT*), and bio-inspired methods (ACO, PSO, Voronoi-based planning). The local controller group includes PID, LQR, MPC, DWA, APF, and Pure Pursuit. The description ends with "etc.", indicating additional algorithms beyond these nineteen are present.

Within the global planner group, the deterministic graph-based methods are well-suited to static grid maps and guarantee optimality under their respective conditions. JPS (Jump Point Search) is a grid-based improvement over A* that reduces explored nodes by exploiting grid symmetry. The D* family handles dynamic environments where the map changes after planning starts. Theta* allows any-angle paths rather than constraining movement to grid directions. Sampling-based methods handle continuous configuration spaces where grid discretization is impractical, with Informed RRT* reducing unnecessary sampling by constraining the search to an ellipse once an initial solution is found.

Among local planners, DWA (Dynamic Window Approach) samples velocity commands at each control cycle and scores them for safety and progress toward the goal. MPC (Model Predictive Control) predicts a trajectory over a finite horizon and minimizes a cost function across that window, which handles tight passages better than DWA but is computationally heavier. APF (Artificial Potential Field) treats the goal as an attractor and obstacles as repellers, a fast method that can trap the robot in local minima near obstacles. Pure Pursuit follows a look-ahead point on a reference path and suits predictable, smooth tracks.

Installing on Ubuntu 20.04 and Building with catkin-tools

The README states the project was tested on Ubuntu 20.04 LTS with ROS Noetic Desktop-Full. Start by installing the ROS packages and system libraries the project depends on:

sudo apt install python-is-python3 \
ros-noetic-amcl \
ros-noetic-base-local-planner \
ros-noetic-map-server \
ros-noetic-move-base \
ros-noetic-navfn \
libgoogle-glog-dev

The build system uses conan for C++ dependency management, pinned at version 1.59.0:

pip install conan==1.59.0
conan remote add conancenter https://center.conan.io

Clone the repository and run the provided build script, which wraps catkin build:

git clone https://github.com/ai-winter/ros_motion_planning.git
cd scripts/
./build.sh

If catkin-tools is missing, the README notes it can be installed with `sudo apt install python-catkin-tools`. After the build completes, open a new terminal or source `~/.bashrc`. The README flags a known libignition dependency error in issue #48.

To start the Gazebo simulation:

cd scripts/
./main.sh

Once Gazebo and RViz open, use the "2D Nav Goal" button in RViz to send the robot a destination. To stop all related processes at once:

cd scripts/
./killpro.sh

Configuring Planners and Running Multi-Agent Scenarios

All planner choices and environment parameters live in `src/user_config/user_config.yaml`. The README is explicit: launch files are regenerated from this YAML every time `main.sh` runs, so edits to the launch files themselves are overwritten on the next startup. To switch the active algorithm or change obstacle parameters, edit `user_config.yaml` before running `main.sh`.

For scenarios with more than one robot, the repository provides `user_config_multi.yaml`. The multi-agent workflow differs from single-robot use in one step: after initialization, goals are published through a provided ROS node rather than through RViz's interactive tool:

# 1. Replace with user_config_multi.yaml in main.sh
# 2. Wait for initialization
# 3. Publish goals
rosrun sim_env goal_publisher.py

The README does not describe which planner combinations support multi-agent operation or how conflicts between multiple robots' paths are handled.

Repository Structure and Doxygen Interface Documentation

The source tree separates algorithm code from simulation infrastructure. Under `src/core`, the `path_planner` subdirectory holds global planner plugins and `controller` holds local planner plugins. Under `src/sim_env`, the simulation environment lives: maps, Gazebo worlds, robot URDF models, meshes, and the RViz configuration templates that `main.sh` regenerates. The `src/plugins` directory holds supporting ROS plugins, including dynamic XML and RViz configuration generators and Gazebo pedestrian plugins for building dynamic test environments. Third-party dependencies resolved by conan reside in the `3rd/` directory.

Interface documentation can be generated with Doxygen. Install the required tools:

sudo apt-get install doxygen graphviz

Then run `doxygen` from the repository root. The output lands in `./docs/html/index.html`. This provides a browsable class and function reference beyond what the README covers. The repository also links to separate documentation pages for configuration options, Docker usage, real-world deployment, and update history.

Platform Lock, Conan Version Pinning, and the libignition Issue

The project's support boundary is Ubuntu 20.04 with ROS Noetic. Engineers on Ubuntu 22.04 or other platforms will need Docker. The repository includes a `docker/` directory and a `docs/docker.md` file for that path, but the quick-start section does not walk through it.

The conan version pin at 1.59.0 is a real constraint. Conan's 2.x release changed the recipe format, remote infrastructure, and command interface; installing a newer conan version will break the build scripts. Engineers who manage shared Python environments with other projects that use newer conan need to isolate this environment.

The README explicitly flags a libignition dependency error reported in issue #48. This error can block the first build on certain system configurations. Resolving it requires reading that issue rather than the main documentation. Because the planners implement the nav_core plugin interface specific to ROS 1's move_base, porting one to ROS 2's nav2 stack requires adapting to nav2_core base classes and its lifecycle management architecture.

Comparison with nav2 and the nav_core Plugin Ecosystem

The ROS Navigation stack and its move_base framework are what ros_motion_planning extends, not an alternative to them. move_base loads global and local planner plugins through nav_core interfaces; ros_motion_planning supplies those plugins with a wide algorithm selection that the original navigation stack does not provide.

nav2 is the ROS 2 successor to the Navigation stack. It follows a plugin architecture with different base classes (nav2_core::GlobalPlanner and nav2_core::Controller) and adds lifecycle management and action server interfaces. nav2's built-in planner set includes Smac Planner, which covers grid-based A* and hybrid-A*, and DWB, a DWA variant. Engineers who need the broader algorithm selection of ros_motion_planning on a ROS 2 platform cannot reuse the existing plugins without adapting to these different interfaces.

The Python and MATLAB repositories linked in the README (python_motion_planning and matlab_motion_planning) are learning references rather than deployment tools. They implement the same algorithms in scripting environments, useful for studying algorithm behavior without requiring a full ROS stack.

Editorial conclusion

Engineers who want to compare multiple path-planning and trajectory-optimization algorithms inside a working ROS simulation, or who need plugin implementations to study alongside theory, will find ros_motion_planning useful. The setup requires Ubuntu 20.04, ROS Noetic, and conan 1.59.0; verify that scripts/build.sh completes without the libignition error documented in issue #48 before investing time in integration. Engineers targeting ROS 2 and nav2 cannot use the plugins directly, as the nav_core interface is specific to ROS 1. The last push was on 2026-04-24.

Frequently asked questions

Official sources

1. ai-winter/ros_motion_planning on GitHub
2. Issues
3. License: GPL-3.0
4. README