RL Policy or cuMotion — They All Plug Into the Same Socket

The "brain" controlling a robot arm is not one thing. Path planning uses cuMotion, precision insertion uses an RL policy, compliant motion uses RMPFlow, AI grasping uses a foundation model — the optimal method differs by task. The problem is: how do you connect these fundamentally different brains to the same system?

One Interface, Many Implementations

The solution is to agree on a common contract. Every policy must honor the same interface shape: take an observation, return an action.

Rendering diagram…

Five completely different brains, one socket. From the runner's perspective: "give PolicyAdapter an observation, get an action back" — it doesn't care whether the implementation is RL, a planner, or a foundation model.

💡 This is the Strategy pattern — "Encapsulate an algorithm behind an interface so it can be swapped" is the classic Strategy pattern. When a new policy arrives (a new RL checkpoint, a new foundation model), implementing the interface is all it takes — zero code changes in the runner. This is the policy-side counterpart of the manifest-driven robot onboarding philosophy.

Why This Matters

⚠️ Branching on policy type in the runner is a maintenance nightmare — Adding if RL: this path, elif planner: that path to the runner means it grows more complex with every new policy type, and regressions multiply. Once the runner knows what kind of policy it is calling, coupling explodes. Behind the adapter, the runner remains permanently ignorant of policy type.

This separation also makes it straightforward to compare multiple policies on the same task — plug both cuMotion and an RL policy into the same observation stream and compare KPIs side by side. Policy swappability is a core value of a validation platform.

In a nutshell

📌 Robot brains — RL, motion planner, foundation model — are all different, but PolicyAdapter Protocol (observation → action common interface) makes them plug into the same socket. The runner remains agnostic to policy type (coupling ↓), new policies are added with zero code changes by implementing the interface, and comparing multiple policies on a single task becomes trivial.