Motion-Core, the control system behind the Astral Twin installations, uses PyBullet for IK and collision checking. This spike asked whether GPU motion planning should replace it.
The question
Motion-Core validates every robot move in simulation before it touches hardware: collision checks, joint-speed limits, TCP-speed limits, per frame, exhaustively. PyBullet handles this today. It works, but it's CPU-bound, its solver is local (one IK solution per call, no global search), and its self-collision API has known bugs that need manual workarounds.
Does GPU planning buy enough to replace a stable baseline? Genesis is a GPU physics platform, NVIDIA cuRobo a GPU motion-planning library.
What each tool is
| PyBullet | Genesis | cuRobo | |
|---|---|---|---|
| What it is | Physics sim + basic IK | Full GPU simulation platform | GPU motion-planning library |
| IK | Damped least squares, 1 local solution per call | Jacobian iterative, batched across environments | L-BFGS over 1000+ seeds — effectively global |
| Collision-aware IK | No (separate check) | No (separate check) | Yes — SDF gradients inside the solver |
| Trajectory optimization | No (path only, via OMPL) | No (OMPL-based) | Yes — time-optimal, jerk-minimizing |
| Planning time | 100 ms – seconds | similar | 10–100 ms |
| Maturity | Stable, aging, unmaintained | Research-grade (v0.3.x) | Production-tested (Isaac ecosystem) |
The headline finding: cuRobo is the only tool where collision avoidance lives inside the solver. SDF distance gradients steer the optimization away from obstacles, rather than rejecting bad solutions after the fact. Combined with continuous (not waypoint-sampled) collision checking along the trajectory, that's a qualitatively different capability, not just a faster one.
Genesis is impressive on throughput (batched IK across thousands of parallel environments) but its planning is the same sampling-based OMPL approach as PyBullet's: GPU physics, CPU-era planning. It matters if you're training RL policies; it doesn't solve my planning problem.
What the spike looked like
cuRobo ran in Docker with CUDA, talking to Motion-Core over a WebSocket bridge, planning for the same xArm UF850 URDF the production system uses. Trajectories came back in tens of milliseconds, smooth enough to stream without the quintic smoothing pass PyBullet's output needs.
PyBullet kept one clear advantage: getClosestPoints, a clean, standalone signed-distance query that needs no simulation step. For debugging collision geometry on a laptop with no GPU, it's still the tool I reach for.
Why production stayed on PyBullet
The installations don't need it yet.
Motion-Core's playback model validates motion offline, exhaustively and before the show, then streams pre-validated trajectories. Planning latency isn't in the critical path. cuRobo's strengths (fast collision-aware planning, global IK) matter most when targets change at runtime, in interactive modes where the robot responds to live input. That mode exists in Motion-Core but is still in development, not in production.
Adding a CUDA dependency, a Docker GPU runtime, and a second planning backend to a system whose reliability argument is "boring and validated" is a real cost. The spike stays a spike until the interactive mode ships.
What transfers
The spike mapped where the production baseline's ceiling is (local IK, no trajectory optimization, buggy self-collision), what the GPU option buys (collision-aware solving, 10–100 ms plans), and what it costs (CUDA infrastructure, ecosystem lock-in). If the future architecture goes there, this is the path:
Motion-Core ├─ cuRobo (Docker/GPU) — planning + trajectory optimization ├─ Genesis (watch) — RL training, dynamic-object sim, if ever needed └─ PyBullet (keep) — CPU fallback, collision debugging