pi-R-squared makes action-chunking robot policies reactive at 25 Hz, one denoising step per call

$π\mathbf{R}^2$: Reactive Real-time Flow Policies

Sungjae Park, Shubham Tulsiani

cs.RO, cs.AI, cs.LG

2026-07-29

pi-R-squared splits conditioning into a fast proprioception channel and an async vision-language channel, and adds a latency-adaptive one-step flow schedule. On GR00T-N1.7 it replans about 4x faster at 25 Hz and lifts success rate by up to 23% in sim and 30% on a real robot.

What problem this solves

Generalist manipulation policies increasingly take the form of action-chunking flow policies built on large pretrained backbones. Such a policy emits a whole chunk of actions and then executes them open-loop, so it cannot react to sensory input arriving mid-execution. Reactivity is sacrificed.

Replanning more often would restore it, but the perception-to-action pipeline, a large backbone plus multiple denoising steps, is too slow. GR00T-N1.7 takes about 140 ms per call (roughly 7 control ticks at 50 Hz), forcing the robot to commit to a long action chunk. Latency forbids frequent replanning and leaves committed actions stale, making these policies ill-suited to dynamic, closed-loop control.

Method

pi-R-squared keeps large backbones, expressive multi-modal policies, and multi-action prediction while making them reactive and real-time. It builds on the per-position noise schedule of diffusion forcing and adds two orthogonal ideas.

First, it splits conditioning into two asynchronously updated channels. A fast channel carries proprioception (joint positions, velocities, torques, contact forces), refreshed every tick; a slow channel carries vision-language features, updated asynchronously in a background thread. The reason is that proprioception is orders of magnitude cheaper to retrieve than images or text, and for dynamic tasks it carries enough information for local reactive corrections while vision and language supply global context. The policy can therefore react to proprioception within a chunk while tolerating stale vision.

Second, a latency-adaptive flow schedule parameterizes a per-position noise staircase by the inference delay d. The front range clamps in-flight actions clean as inpainting conditioning, the interior ramps linearly from clean to noise, and the tail is pure noise. The buffer slides d positions per call, and a single denoising step emits d clean actions. One trained model adapts to whatever hardware latency is measured on a given call.

The architectural change is minimal: the DiT's AdaLN conditioning becomes per-position with one parameter pair per chunk position instead of shared, so a pretrained policy can be fine-tuned without touching the backbone.

Results

Applied to GR00T-N1.7 on a real xArm6 with XHand platform: closed-loop replanning is roughly 4x faster than the base, about 25 Hz on an A5000 GPU, acting on a fresh observation every 40 ms. Success rate improves by up to 23% in simulation and 30% in the real world over the strongest baseline.

Across four real-world tasks pi-R-squared beats the strongest baseline (Train-Time RTC) on every one: Don't Spill 10/20 vs 4/20, Tidy Up Book 12/20 vs 4/20, Insert Box 16/20 vs 11/20, Catch Book 11/20 vs 4/20. The direct evidence of reactivity: pi-R-squared modulates grip from live force feedback and stops around 50 N, while Train-Time RTC reacts late and overshoots to about 120 N, crushing the book.

Why it matters

This attacks a hard constraint on deploying robot VLAs (vision-language-action models): the high latency of large backbones blocks high-frequency closed-loop control. Without swapping the backbone or sacrificing multi-modal expressiveness, fast/slow channel splitting plus a latency-adaptive schedule lifts control to 25 Hz, so heavy policies that could only run open-loop can now do contact-rich dynamic tasks like pouring without spilling or catching an object. The change is small and fine-tunes from a pretrained policy, making it a low-cost upgrade for teams that already run a VLA.

Limitations

The authors note this does not address external latency sources such as communication delay between the inference server and the robot client; it only covers inference itself. The backbone is unchanged, and designing it to emphasize proprioceptive features more strongly could amplify reactivity further. Two gaps remain: gains concentrate on dynamic tasks that need high-frequency reaction (pouring, catching), and the paper gives no data on static or quasi-static manipulation, where a 4x speedup may not buy the same success-rate gain. The 25 Hz figure is measured on an A5000, with nothing said about how latency adaptation holds up on weaker edge hardware.

Terms

Source

Related papers

All paper explainers