OpenPlan Labs

Open tools for automated planning.

OpenPlan Labs builds open-source libraries for PDDL planning, multi-agent pathfinding, and GPU-accelerated search.

Everything here is an implementation of published work, written to be read as well as run. Each project says what it does and what it does not do. None of it is a product, a service, or a hosted API — they are libraries you install and call.

Browse the projects GitHub organisation
A* on a grid, drawn with the Frontier legend A sixteen-by-nine grid with obstacles. Grey squares are obstacles; 42 small filled dots mark the nodes A* expanded; 22 hollow rings mark the nodes still on the frontier when the goal was reached; a single warm stroke runs from a hollow start ring to a filled goal disc along the 22-node plan it returned.
  • Obstacle
  • Unvisited
  • Expanded
  • Frontier
  • Plan
A* (Hart, Nilsson & Raphael, 1968) with a Manhattan heuristic on a 16 × 9 four-connected grid: 42 nodes expanded, 22 still on the frontier when the goal was expanded, and the 21-step plan it returned — optimal, because Manhattan distance is admissible under unit costs. Start is a hollow ring, goal a filled disc: open versus closed, in the search sense. Every figure across these repos uses this legend, which is also the brand palette: the only warm colour in the system is the solution. Drawn by tools/make_figure.py, which runs the search rather than placing the dots.

Projects

Eight repositories, three threads

Star counts and versions below were checked against the GitHub and PyPI APIs when this page was last built. Where a project is not released, it says so.

PDDL and classical planning

Modelling language in, plan out.

  • PythonPDDL jupyddl

    A dependency-free, pure-Python PDDL framework: parser, grounder, classical-to-modern planners, heuristics, and a benchmarking harness. No Julia and no native extensions — the standard library only, so it installs anywhere Python does.

    • Python
    • Apache-2.0
    • 35 stars
    • jupyddl 2.3.0

  • pddl-examples

    Eight hand-written domain and problem pairs, plus a growing mirror of the planning.domains classical collection that a daily job extends. Domain files and problem files only — planners not included.

    • PDDL
    • MIT
    • 3 stars

  • awesome-pddl

    A curated list of PDDL resources — planners, parsers, editors, domain collections, competitions, and learning material. Readable as a README or as a filterable directory.

    • MIT

  • docker-pythonpddl

    PythonPDDL in a container. Parse, ground and solve a PDDL instance with nothing installed but Docker; the planner and heuristic are chosen by environment variable.

    • Dockerfile
    • Apache-2.0
    • 1 star

Multi-agent pathfinding

Many agents, one shared grid, conflicts to resolve.

  • pymapf

    Multi-agent planning and pathfinding in Python: CBS, weighted CBS, PIBT, LaCAM, LNS and space-time A* on the centralized side; decentralized NMPC, velocity obstacles and swarm behaviours on the other. Includes a multi-agent RL environment benchmarked against the optimal planner.

    • Python
    • MIT
    • 77 stars
    • pymapf 0.8.0

GPU acceleration

The same algorithms, batched onto a device.

  • cuda-planning cuplan

    CUDA-accelerated MAPF and planning: batched BFS, space-time search, prioritized planning, PIBT, velocity obstacles and flocking. Every algorithm has a vectorized NumPy reference implementation alongside its CUDA one behind a single backend="auto" | "cpu" | "cuda" argument, with CPU–CUDA equivalence enforced by tests. The solvers it ships today are fast and incomplete; optimal search is on the roadmap, not in the box.

    • Python
    • MIT
    • Not yet on PyPI

Measured results, with the machine and problem set stated: summary · methodology · phases · BFS · PIBT · prioritized planning · velocity obstacles · flocking

Shared

What the other repos are built out of.

  • branding

    Frontier — the design system: palette, mark, type, figure conventions, CSS tokens, and a matplotlib stylesheet so notebook output matches the docs without anyone thinking about it. This page is built from its tokens. If a repo's colours drift from it, it wins.

  • .github

    Org-wide defaults: the contributing guide, code of conduct, security policy, and the issue templates that ask for the things we would otherwise have to ask you for.

What we work on

One problem, seen from three distances

Classical planning, multi-agent pathfinding, and GPU search are usually three literatures with three vocabularies. They are the same problem at three scales: a state space, a way of ordering the states you look at, and the plan you return. The tools here are separate because the data structures differ, not because the ideas do.

Classical planning

A domain and a problem in PDDL, parsed and grounded into a state space, searched with an admissible heuristic. The hard part is the heuristic, and the interesting number is nodes expanded.

Multi-agent pathfinding

The state space is a product of per-agent spaces, so it is exponential in the number of agents. The hard part is deciding which conflicts to resolve and which to plan around, which is what separates CBS from PIBT from LaCAM.

GPU acceleration

A GPU is fast at doing the same thing to a thousand items at once, and slow at following a pointer. So the win comes from batching — one distance map per agent, one wavefront per timestep — not from putting a serial search on device threads.

Three things hold the projects together in practice. Shared instances: the PDDL tools are exercised on the domains in pddl-examples, so a benchmark run in one repo is comparable to a benchmark run in another. Shared references: every accelerated algorithm in cuda-planning keeps a plain NumPy implementation next to it, and the two are tested for equivalence — a speed-up that changes the answer is not a speed-up. Shared figures: every plot in every repo uses the legend in the figure above, so a grid render from pymapf and one from cuplan can be read side by side without a key.

Get involved

Ways in, roughly by effort

The org-wide contributing guide covers the pull-request flow and what a useful bug report contains; a project's own CONTRIBUTING.md wins on specifics.

  1. Add a domain to pddl-examples

    A domain you wrote for a course, a paper, or a robot is exactly what that collection is for. Open a pull request adding a top-level directory with a domain.pddl and at least one problem file, say what it models, and the validate workflow will check the parentheses balance and the (define …) form. Do not hand-edit anything under domains/ — the daily sync regenerates it. How to contribute a domain

  2. Add an entry to awesome-pddl

    A planner, parser, editor, course, or domain collection that is not on the list yet. One entry per pull request, with a sentence saying what it is and, for a planner, what it guarantees. Contribution rules

  3. File a bug with its input attached

    For the PDDL tools that means the domain and problem files, the exact version, the algorithm and heuristic you ran, and the command. A planner bug without its instance is usually unreproducible. Issue templates

  4. Pick up a labelled issue

    Every repo carries good first issue and help wanted labels, though the queue is often empty — these are small projects. If nothing is open and you want something to do, open an issue describing what you would like to add and it will get an answer. Open good first issues

  5. Report a security problem privately

    Not in a public issue. The security policy has the address and what to include.