πR² makes flow policies react in real time

Anyone building robot policies knows the failure mode: the model commits to a chunk of actions, then the world changes before the chunk finishes.

πR² makes flow policies react mid-execution by splitting fast and slow inputs and using one-step latency-adaptive denoising.

• Research org: Unspecified in arXiv abstract
• Core data: up to 30% real-world success-rate gain
• Breakthrough: Splits conditioning into fast and slow channels, then uses latency-adaptive one-step flow scheduling

That is the core problem this paper targets. Modern manipulation systems often rely on action-chunking flow policies built on large pretrained backbones, which are powerful but typically run open-loop for the duration of a chunk. In a static scene, that can be fine. In a dynamic one, it means the robot may keep executing stale actions even after new sensory input arrives.

The authors argue that the obvious fix—replan more often—runs into latency. A large backbone plus multiple denoising steps can make the perception-to-action pipeline too slow for tight feedback loops. So the paper is not trying to replace large policies with a tiny controller. Instead, it tries to keep the expressive backbone and multi-action prediction, while making the policy responsive enough for closed-loop control.

What πR² changes

πR² is built on the per-position noise schedule of diffusion forcing, and it adds two mechanisms on top of that foundation. The first is a split conditioning path: proprioception goes through a fast channel that is refreshed every tick, while vision-language features go through a slow channel that can be updated asynchronously. That design lets the policy react to the robot’s own state immediately, even if visual features are slightly stale.

The second mechanism is a latency-adaptive flow schedule. Instead of treating the policy as something that must always burn through several denoising steps before producing an action chunk, πR² treats in-flight actions as inpainting conditioning and emits actions in one denoising step per call. In plain terms, it is trying to make each control cycle cheap enough that the same trained model can keep up even when hardware latency changes.

That matters because real robots do not run on a perfect schedule. GPU load, sensor timing, and model size all affect how often a policy can replan. πR² is designed to absorb that variability without requiring a full architectural rewrite.

How it works in plain English

Think of the policy as having two kinds of inputs. One kind is the robot’s immediate body state: joint positions, gripper state, and other proprioceptive signals that change every control tick. The other kind is slower, heavier context from vision and language. The paper’s split-channel design says those two streams should not be treated the same way, because they age at different rates.

That is a practical engineering move. If a robot’s hand position changes right now, the policy should be able to respond right now. If the camera embedding is a few milliseconds old, that may be acceptable for a chunked policy, especially if the controller can still condition on the fresh proprioception. πR² makes that trade-off explicit instead of forcing all inputs through the same update cadence.

The latency-adaptive part is equally pragmatic. Rather than assuming a fixed compute budget, the method adjusts to the time available and uses in-flight actions as conditioning for inpainting. That is what lets it emit actions in a single denoising step per call. For developers, the important point is not the diffusion jargon; it is that the policy is meant to stay usable when the runtime environment is not perfectly stable.

What the paper actually shows

The abstract gives a concrete deployment story: the authors finetune πR² from a pretrained policy, specifically GR00T-N1.7, and test it on a real xArm6+XHand platform. On that setup, the method replans closed-loop roughly 4× faster than the base policy, reaching about 25 Hz on an A5000 GPU and acting on a fresh observation every 40 ms.

That is the strongest operational result in the abstract, and it is the one practitioners will care about first. The paper is not claiming that the robot suddenly became smarter in some abstract sense; it is claiming that the control loop became fast enough to stay reactive.

The abstract also reports success-rate gains across simulation and real-world manipulation tasks. It says πR² improves success rate by up to 23% in simulation and 30% in the real world over the strongest baseline. Those are meaningful numbers, but the abstract does not provide the full task list, the exact baseline identity, or per-task breakdowns, so those details remain outside what we can safely infer here.

What the abstract does not include is just as important. It does not give benchmark tables, confidence intervals, ablation numbers, or failure-case statistics. It also does not say how much of the gain comes from the split conditioning path versus the latency-adaptive schedule. So while the result is promising, the abstract alone does not let us separate the contribution of each design choice.

Why developers should care

If you build robotic systems, this paper sits right at the intersection of model quality and system latency. A lot of policy work assumes the model can think first and act later. Real robots do not get that luxury. They need policies that can update fast enough to remain synchronized with the physical world.

πR² is interesting because it does not ask engineers to abandon large pretrained backbones or multi-action prediction. Instead, it shows a path to make those models more usable in closed-loop control with minimal modification to existing architectures. That lowers the barrier to adoption: if a pretrained policy can be finetuned rather than rebuilt, the deployment story becomes much more realistic.

There is also a broader systems lesson here. The paper treats latency as a first-class design constraint, not an afterthought. That is a useful mindset for anyone shipping embodied AI: the best policy on paper is not necessarily the best policy on hardware if it cannot react in time.

What is still open

Even with the reported gains, a few questions remain. The abstract does not tell us how robust the approach is across very different robot embodiments, sensor setups, or compute budgets. It also does not say whether the one-step denoising approach holds up when tasks demand longer-horizon planning or more complex multimodal reasoning.

Another open question is how general the latency-adaptive schedule really is. The paper says one trained model can adapt to varying hardware latency, which is attractive, but the abstract does not explain the range of latencies tested or how gracefully performance degrades when conditions worsen.

Still, the main idea is clear: reactive control does not have to mean giving up expressive flow policies. πR² proposes a way to keep the model class and make the runtime behavior much closer to what real robots need.

• Reactive control is achieved by separating fast proprioception from slower vision-language features.
• The method uses latency-adaptive one-step denoising to keep replanning close to real-time.
• Reported gains include roughly 4× faster replanning, up to 23% better simulation success, and up to 30% better real-world success.

For teams working on manipulation, that combination is the headline: preserve the power of large flow policies, but make them responsive enough to matter on hardware.