A planner table where the unimplemented cells are the interesting part

The repository splits motion planning into four directories, not one

The source tree does the conceptual work that most motion planning repositories leave to a reader. There is a common directory, and inside it an environment with map, robot and world subpackages, a utilities package, and a visualiser. Then a controller directory containing a path tracker subpackage. Then a path planner directory split three ways: graph search, sample search and hybrid search. Then a trajectory optimiser containing a curve generator. That four-way split is the project's thesis, and it maps onto a distinction the readme makes in prose. Path planning is described as planning an optimal sequence of positions under constraints such as obstacles, so the robot can travel from start to goal without conflict. Trajectory planning is described as planning the motion state to approach the global path, based on kinematics, dynamics constraints and the path sequence. Path planning answers where, trajectory planning answers how the machine moves along the way, and the third and fourth directories are the tracking and smoothing layers that make a geometric path into something a vehicle can follow. The readme also distinguishes this from the pure path-finding problem by opening with the definition of motion planning as planning a state sequence without conflict between start and goal. For a newcomer that vocabulary is the most valuable thing in the repository.

The coverage matrix is the honest document, and version 2 is a removal

Every algorithm table in the readme has two columns, one for a 2D grid and one for a 3D grid, and a good proportion of cells say not implemented. Reading the graph search table: Dijkstra, greedy best-first search, A star, jump point search, Theta star and Lazy Theta star are all implemented in both dimensions, and have images for both. D star, LPA star and D star Lite are marked as implemented in version 1.1.1 but not migrated, in both columns. Anya is not implemented at all. The sample search table has RRT, RRT star, RRT-Connect implemented in 2D and 3D, with informed RRT marked as implemented in the older release and not migrated, and probabilistic roadmaps not implemented. The evolutionary search table is entirely in the not-migrated column, with three algorithms. That last point is the one to hold on to: version 2 of this repository contains less than version 1 did. A rewrite that reorganised the source tree also dropped a set of planners and controllers, and the readme records it by pointing at the old tag rather than by listing a changelog. If you are upgrading from a version 1 release, the matrix is your migration guide, and it is worth reading before you upgrade rather than after your import fails.

The simulator is a toy, and the readme calls it one

The controller section is where the project is most honest about its limits, and the honesty is useful. It provides what it calls a toy simulator with simple physical simulation for testing path trackers, and it supports multiple agents. Two robot models are available: a circular omnidirectional robot and a differentially driven robot, the latter described as only supporting forward and backward motion. The demos label the first robot blue and the second orange, so you can see which behaviour belongs to which. Then the caveat that matters: currently only a 2D simulator is provided and a 3D simulator has not been implemented, which is consistent with every 3D cell in the tracker table being empty. The implemented trackers are the simpler ones: a path tracker, pure pursuit, PID, artificial potential field, dynamic window approach, and a pure pursuit variant. Linear quadratic regulation and model predictive control are both marked as implemented in the older release and not migrated, and four more are marked as never implemented, including a time extension controller and two reinforcement learning approaches. Read that list as a map of where a working robotics stack usually needs to be. Pure pursuit and PID are what an undergraduate robot uses. Model predictive control and a time extension controller are what a warehouse robot uses. This repository currently covers the first list.

Curve generators are the layer between a path and a trajectory

The trajectory optimiser directory is smaller than the planner directories and its contents are a useful complement to them. It splits into point-based generators and pose-based generators, which is a distinction worth pausing on even if the readme does not explain it. Point-based generators take a sequence of positions and produce a curve through them: a cubic spline and a B-spline are the two implemented. Pose-based generators produce a path that respects a vehicle's kinematic constraints rather than just passing through waypoints. A polynomial, a Bezier curve, a Dubins curve and a Reeds-Shepp curve are all implemented, all in 2D only. The kinematic constraint is the point. A Dubins path is composed of circular arcs and straight segments, so a car-like vehicle can follow it without stopping; a Reeds-Shepp path adds reverse motion. A spline through the same waypoints may be shorter and smoother and completely infeasible for a car that cannot move sideways or turn in place. So this layer is not smoothing for its own sake, it is the step that converts a graph searcher's output into something a specific vehicle can drive. The future works list notes sample search with Dubins or Reeds-Shepp curves, which is exactly the coupling a real planner needs and which the current architecture keeps separate.

Install, dependencies, and the two environments the readme describes

The install is short and the readme recommends a conda environment. The tested interpreter is Python 3.10, the readme says other similar versions should also work, and the packaging metadata requires 3.8 or later. The environment creation is two commands:

conda create -n pmp python=3.10
conda activate pmp

Then the package itself, and it is a real published package rather than something you clone and add to a path:

pip install python-motion-planning

The dependency list is where you should slow down. It includes numpy, numba, scipy and matplotlib, which you would expect. It also includes a quadratic programming solver, a reinforcement learning environments package, a CPU vector search library, and two visualisation packages where one is a Qt backend for the other. So a planning library that a robotics engineer might reach for to get one algorithm now installs a just-in-time compiler, a similarity search index and a Qt graphics stack. Whether that is acceptable depends on your environment. In a research container it is nothing. In a deployment where you wanted the pure Python planner with no compiled extensions, or on a machine without a display, the Qt backend in particular is a real consideration. The documentation is generated with a static site generator whose build is driven by a script in the repository, and the tutorials directory is where the runnable walkthroughs live, which the readme points you to instead of documenting usage inline.

Where the boundaries are, and what the future list admits

Three things constrain use, and the readme states all of them. The first is dimension. Every 3D cell in the controller tables is empty, the simulator is 2D only, and the future work list opens with N-dimensional controllers. The second is the vehicle model. Two robots, one of which cannot reverse, and the path trackers are therefore being tested against models much simpler than a real machine. The third is the environment coupling: there is no simulator integration, and the future work list names mainstream simulators and robot simulation frameworks as things to come, along with a ROS2 application. That list is a fair summary of the project's ambition and its current state, and it also names two features a robotics developer will look for first: path planning for robotic arms, and path planning on a topological map, which is a qualitatively different problem from planning on a metric grid. The readme notes the theoretical background lives in an external blog series rather than in the repository, and that ROS C++ and Matlab versions of the same collection exist. So if you need this in a ROS stack you have a sibling project, and if you need the theory in one place you have to go outside the repository for it. What you get here is a well-organised, honestly scoped Python implementation with a visualiser, and the readme is careful to say so.

Editorial conclusion

Adopt python_motion_planning if you are teaching or prototyping robot motion planning and want twenty working algorithms with pictures and a visualiser to compare them in one place, since the coverage matrix lets you pick an implemented planner and a trackable controller without reading the source first. Do not adopt it for a robot that has to work, because the readme itself marks the 3D case as not implemented across the board, the simulator is described as a toy, and several algorithms that existed in the previous release were not migrated. Four things to verify. Which algorithms you actually need against the matrix, since the unimplemented column includes model predictive control, a time extension controller widely used in real stacks. That the dependency list is acceptable, because it pulls in a just-in-time compiler, a CPU vector search library and a visualisation toolkit with a Qt backend, which is heavy for a planning library. Whether the release you install matches the documentation, since planners marked as implemented in an earlier tag are not migrated into the current one. And how the path trackers behave when the path they are given is infeasible, which no cell in the matrix answers. The licence is GPL-3.0 and version 2.1 was released on 2026-09-15.

Frequently asked questions

Official sources

1. ai-winter/python_motion_planning on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases