finds.dev← search

// the find

hungpham2511/toppra

★ 930 · Python · MIT · updated Aug 2026

robotic motion planning library

toppra implements time-optimal path parameterization via reachability analysis — given a geometric path and kinematic/dynamic constraints (joint velocity, acceleration, torque, cartesian velocity), it computes the fastest trajectory that doesn't violate them. It's aimed at robotics engineers doing motion planning who need provably time-optimal retiming rather than a heuristic smoother, and it's backed by a published IEEE T-RO paper rather than being an ad-hoc implementation.

The algorithm is grounded in actual published research (reachability-based TOPP), not a black-box heuristic, which matters for anyone who needs to reason about why a trajectory is optimal. It supports a real set of constraint types (linear joint velocity/acceleration, joint torque, cartesian velocity norm) that map to actual robot arm limits, not just a toy velocity cap. The solver layer is pluggable across qpOASES, GLPK, ECOS, cvxpy, and a custom Seidel LP implementation, so you can trade off speed vs. dependency weight. There's a real C++ core with a separate test suite (cpp/tests) plus a parallel Python test suite, and CI runs on every push.

The README leads with a deprecation notice: Python support is being dropped in favor of the C++ bindings, which is a serious problem if you're evaluating this for a Python robotics stack today — you're being told to not build on the API surface most users will reach for first. The solver backend sprawl (five different LP/QP wrappers) is also a maintenance liability; the README doesn't say which one is the recommended default, so picking wrong means a slower or less-numerically-stable path. Build complexity is non-trivial for the C++ side — it pulls in GLPK and qpOASES as system dependencies, and there's no prebuilt wheel/package story described for the newly-recommended C++ path. Documentation is thin on getting from 'I have a raw joint trajectory' to the toppra API — the examples assume you already understand geometric path parameterization, so there's a real ramp-up cost for anyone outside the academic motion-planning niche.

View on GitHub → Homepage ↗

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →