517 files make a readable algorithm atlas, not a robot stack
PythonRobotics contains 517 files and about 36,496 lines of source, yet its best promise is modest: each algorithm is meant to be read, run, and understood. The repository pairs small Python implementations with an online textbook, papers, and animations. That makes an extended Kalman filter, RRT*, Dynamic Window Approach, or Stanley controller easier to examine than it would be inside a large framework. It does not supply the surrounding hardware, messaging, deployment, and safety systems needed to operate a robot.
The README covers 8 broad areas, including localization, mapping, SLAM, path planning, path tracking, arm navigation, aerial navigation, and bipedal motion. Individual examples show the state that matters: a particle-filter plot separates ground truth, dead reckoning, and the estimate, while D* Lite visibly reroutes as obstacles appear. References sit near many examples, so you can move from the animation to the paper instead of treating the code as an unexplained recipe.
The 15-second install is easier than the execution model
Our sandbox installed 68 packages in 15 seconds, and the environment occupied 589 MB. The checkout itself was only 14.6 MB. That is a reasonable cost for NumPy, SciPy, Matplotlib, cvxpy, and the other requirements used across a wide algorithm collection. Pip-audit reported 0 known vulnerabilities in the dependency set we installed. This audit result describes commit ec422d3 on October 4, 2026, not every future dependency update.
Setup still feels like coursework rather than a library contract. The README tells you to clone the repository, install a requirements file with pip or conda, enter an example directory, and run its script. It calls for Python 3.13.x, while our container used Python 3.12. The installation succeeded on 3.12, but that does not turn it into a documented target. No credential, database, or outside service is required for the advertised local examples.
What happened when we ran it
Our run at commit ec422d3 used an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Installation completed in 15 seconds, and the build completed in 1 second. The repository had 6 CI workflow files and a tests directory, while our scan found no Dockerfile. Those facts make the project easy to inspect and cheap to build, but they do not prove that a chosen simulation behaves correctly.
Pytest failed after 2 seconds with exit code 5. It reported 0 passed, 0 failed, and the final log said, "no tests ran in 0.00s." That is the whole finding. The log does not identify a missing system package, a discovery configuration error, or an incompatible Python version, so assigning any of those causes would be guesswork. A team adopting code from the collection must establish its own repeatable test command before changing an algorithm.
Six CI workflows do not make the empty test run green
PythonRobotics had 6 CI workflow files and a tests directory at the measured commit, yet the command in our sandbox collected 0 tests. Both details matter. The repository plainly contains testing and cross-platform automation signals, but a fresh user cannot treat those signals as a passing local gate. The practical response is to read the workflow for the example you plan to use, reproduce its exact invocation, and add a focused test for your own inputs.
That caution matters because these scripts encode assumptions you may not share. The README describes 2D planners, simulated RFID landmarks, known yaw in one histogram-filter example, and interactive Matplotlib controls for an arm example. Those choices are useful because they keep the lesson visible. They also mark the point where copying ends and engineering begins: sensor models, coordinate conventions, collision geometry, and failure behavior all need review against the real system.
An October 5 push shows activity, but there is no release channel
GitHub recorded the latest push on October 5, 2026, with 30,628 stars and 53 open issues and pull requests. The search API split that combined figure into 15 issues and 38 pull requests. New work included path tracking, flocking, planner fixes, and documentation changes. This is an active repository by both code and issue signals. The latest-release endpoint returned no release, however, so adopters choose a commit rather than a published version.
One current defect shows why that distinction matters. Open issue 1396 has 12 comments about RRT obstacle circles whose displayed radius changes when the Matplotlib figure is resized, even though collision checks use data coordinates. An open pull request proposes a shared plotting fix and a regression test. The issue concerns visualization rather than proof that the planner collides, but an educational display that disagrees with its geometry can still teach the wrong picture.
Three alternatives fit narrower or more operational jobs
Robotics Toolbox for Python is the better pick when you need an installable API, robot models, kinematics, and dynamics. PathPlanning narrows the material to animated search and sampling planners. MRPT goes the other direction with a C++ mobile-robotics framework, sensor support, SLAM, maps, applications, and ROS integration. These 3 projects solve different jobs. PythonRobotics wins when readable source and visual explanation matter more than a packaged interface.
Use PythonRobotics as a bench book you can execute. The 1-second build and broad textbook make it unusually easy to inspect an unfamiliar method, and the MIT license leaves room to adapt code. The failed 0-test run sets the boundary: before any example influences a real robot, pin commit ec422d3 or another reviewed revision, reproduce the relevant upstream check, and write tests around the assumptions your machine cannot afford to get wrong.