PaperlayerView exact revision on arXiv

Source-linked AI summary

PACE: Phase-Aware Chunk Execution for Robot Policies with Action Chunking

Junnan Nie, Jiayi Li, Chenghao Liu, Junyi Lao, Jiachen Zhang, Tianle Zhang, Liang Lin, Songfang Huang

arXiv:2606.00537v3cs.RO

TL;DR

Action-chunking policies leave deployment to choose how much of each predicted chunk to execute, while fixed horizons show task-dependent, non-monotonic success. PACE chooses replanning boundaries from low-speed valleys in predicted chunks without retraining or policy-internal signals. It reports improved simulation and real-robot results.

  • Problem

    Fixed execution horizons trade feedback frequency against motion continuity, yet success is task-dependent and non-monotonic in the horizon.

    Source: §1 · p. 2

  • Method

    PACE selects execution horizons online from low-speed valleys in predicted action chunks, without retraining or access to policy internals.

    Source: §6 · p. 9

  • Results

    57.8% to 64.2% average success rate on 50 RoboTwin2.0 tasks; real-robot average task score rose from 60.7 to 77.7, and average success rate from 50.7% to 70.4%.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Matched-horizon comparisons indicate that gains come from better replanning timing rather than simply querying the policy more often.

    Source: §6 · p. 9

    PACE cannot recover a rollout when the base policy fails to generate actions needed to complete a required subtask.

    Source: §7 · p. 9

Abstract

from arXiv · show

Recent vision-language-action and diffusion-based robot policies often use action chunking, where each policy query predicts a sequence of future actions and the robot executes an open-loop prefix before re-querying. While this interface improves local motion continuity, deployment still requires choosing the execution horizon: how much of each predicted chunk should be executed before acquiring a new observation. However, our experiments show that success is strongly task-dependent and non-monotonic with respect to the execution horizon, making a single constant horizon an unreliable deployment rule. We propose PACE (Phase-Aware Chunk Execution), a training-free test-time execution method that selects the execution horizon online from the predicted chunk itself. PACE exploits the phase-dependent kinematic structure of manipulation trajectories by identifying low-speed transition points in the predicted speed profile and using them as candidate replanning boundaries. Because PACE uses only the predicted action chunk, it is plug-and-play and requires no retraining or access to policy internals. We validate PACE through large-scale evaluations in both simulation and real-robot settings. On 50 RoboTwin2.0 tasks, PACE raises the average success rate from 57.8% to 64.2%. In real-robot experiments on bimanual ALOHA and single-arm Franka platforms, PACE improves the average task score from 60.7 to 77.7 and the average success rate from 50.7% to 70.4%. Ablations and rollout-level analyses show that PACE adapts execution horizons across manipulation phases, shortening near transitions while preserving longer execution during coherent motion.

1 Introduction

Action-chunking policies still require a separate execution-horizon choice, and fixed horizons perform non-monotonically across tasks. PACE selects replanning points from predicted motion profiles, and evaluations report gains in simulation and on real robots.

1 Introduction

  • A fixed horizon trades more frequent feedback against motion continuity, yet one constant interval is used regardless of the predicted chunk.Shorter horizons can interrupt coherent motion, while longer ones delay reactive correction.Source: §1 · p. 2
  • Success is non-monotonic in the execution horizon and task-dependent; on Click bell it peaks near H ≈6, drops nearly 40 points around H ≈25, then peaks again near H ≈35.The best horizon on one task does not transfer reliably to new tasks or real-robot deployment.Source: §1 · p. 2
  • PACE selects the executed prefix online from phase-dependent kinematic structure, using low-speed valleys as candidate replanning boundaries.It preserves a coherent motion segment and re-queries before the next begins, without a learned component, policy-internal access, or policy modification.Source: §1 · p. 2
  • 57.8% to 64.2% average success rate on 50 RoboTwin2.0 tasks; real-robot average task score rose from 60.7 to 77.7, and average success rate from 50.7% to 70.4%.The comparisons are against the best fixed-horizon baseline in simulation.Source: §1 · p. 2
  • Ablations, sensitivity analyses, and rollout-level diagnostics examine PACE’s design choices and the mechanism behind its gains.The evaluation includes 50 RoboTwin2.0 tasks and real-robot experiments.Source: §1 · p. 2

2 Related Work

Prior action-chunking work has mainly focused on generating better chunks, while execution is often governed by a separate test-time rule. PACE instead treats horizon selection as a policy-agnostic execution problem using the predicted chunk.

Robot policies with action chunking

  • Action-chunking research has emphasized architectures, representations, tokenization, data scaling, and pretraining to improve generated chunks.PACE addresses the complementary deployment question of how much of an already-predicted chunk to execute.Source: §2 · p. 2

Test-time execution of action chunks

  • Execution commonly uses fixed rules, while other methods address latency, stability, multi-horizon reasoning, or online horizon selection through internal action self-attention.AutoHorizon is the closest comparison described, but it relies on action self-attention inside flow-based VLAs.Source: §2 · pp. 2–3
  • PACE identifies low-speed valleys in the predicted chunk’s kinematic profile, executes the selected prefix, discards the suffix, and queries the policy again.Unlike AutoHorizon, PACE requires no attention maps, confidence scores, denoising states, auxiliary heads, retraining, or inference-engine changes.Source: §2 · p. 3, Figure 2 · p. 3

3 Method

PACE replaces a constant execution interval with a deterministic, training-free rule conditioned on each predicted chunk. It extracts smoothed speed profiles, selects accepted low-speed valleys as replanning boundaries, and uses the earliest boundary across arms when applicable.

3.1 Problem Formulation

  • The execution horizon is the number of predicted actions executed before the next policy query; PACE replaces a chunk-agnostic fixed H with a deterministic, training-free rule h_i = g(A_i).The policy’s training prediction horizon L remains unchanged.Source: §3.1 · p. 3

3.2 Kinematic Profile Extraction

  • PACE maps each executed arm group’s motion component to a one-dimensional speed profile, smooths it to suppress spurious minima, and treats low-speed regions as candidate phase boundaries.The method relies on the predicted profiles retaining phase structure from expert action sequences.Source: §3.2 · p. 3

3.3 Phase-Aware Execution Horizon Selection

  • PACE selects separated low-speed valleys that pass a pronounced-deceleration criterion, then uses the earliest accepted boundary across arms or a longer horizon if none is found.The task-level threshold is calibrated from training demonstrations; multi-arm settings replan before any arm crosses a predicted boundary under stale observations.Source: §3.3 · pp. 3–4
  • Table 1 reports success rates on six representative RoboTwin2.0 tasks and a 50-task average, with 900 episodes per task and 45,000 episodes per method for the average.The caption describes fixed-horizon baselines and PACE’s online chunk-conditioned selection, but does not provide the table’s cell values.Source: Table 1 · p. 4

4 Simulation Experiments

The simulation evaluation compares PACE with fixed execution schedules using the same policy checkpoints and predicted chunks; its four analyses assess performance, rollout behavior, design choices, and adaptive timing. The 50-task evaluation averages success equally across tasks, with 900 episodes per task-method pair.

4.1 Simulation Results

  • PACE raises the 50-task average success rate from 57.8% for the strongest fixed-horizon baseline (H = 25) to 64.2%, a 6.4-point gain.It also outperforms that baseline on all six displayed tasks across short-, medium-, and long-duration groups.Source: §4.1 · p. 4

4.2 Visualizing Adaptive Execution Horizons

  • In a place_shoe rollout, PACE varies execution horizons across phases, discarding each chunk’s unexecuted suffix before replanning from a new observation.Longer horizons accompany coherent motion, while shorter ones occur near low-speed transitions; newly predicted chunks can differ from discarded suffixes.Source: §4.2 · pp. 4–5, Figure 3 · p. 5

4.3 Ablation Analysis

  • Training success increased monotonically with Htrain; the gain from Htrain=50 over the shortest feasible target shrank from +20.7 at Heval=10 to +3.3 at Heval=40.The authors adopt Htrain=50 as the default; the training-horizon ablation uses six representative tasks, with each row fixing Heval.Source: §4.3 · pp. 5–6, Table 2 · p. 6
  • The default dmin=10, ρ=5 setting achieved 64.2% success with a 24.3-step average horizon; very strict settings reduced success while pushing average horizon above 30 steps.Increasing ρ makes boundary acceptance stricter and lengthens the average horizon; the reported sensitivity analysis covers all 50 tasks.Source: §4.3 · p. 6, Table 3 · p. 6

4.4 PACE versus Fixed-Horizon Sweeps

  • Across six diagnostic tasks, fixed-horizon success curves differed substantially, while PACE reached high-success regions without task-specific sweeps; it outperformed matched-average-horizon fixed schedules on all six.The matched comparison controls for average replanning frequency, so the remaining difference is where boundaries fall within a rollout; the hindsight-best fixed horizon is a non-deployable reference because it requires sweeping test-task horizons.Source: §4.4 · p. 7, Table 4 · p. 7

5 Real-Robot Experiments

Real-robot evaluations show that PACE improves performance across bimanual ALOHA and single-arm Franka settings. Rollouts illustrate phase-dependent horizon changes, while a failure case shows that execution timing cannot supply missing behavior from the base policy.

5 Real-Robot Experiments

  • The evaluation covers two RoboChallenge tasks on bimanual ALOHA and a five-object place_object_on_plate task family on single-arm Franka.Each RoboChallenge task uses 30 trials per method; the Franka family uses 5 × 20 trials per method.Source: §5 · p. 8

5.1 Real-Robot Results

  • Across three real-robot evaluations, PACE raises average Score from 60.7 to 77.7 and Succ. from 50.7% to 70.4%.The baseline and PACE share the same fine-tuned checkpoint within each task, isolating the test-time execution rule.Source: §5.1 · p. 8

5.2 PACE Horizon Selection in a Successful Rollout

  • In a successful stack_bowls rollout, PACE uses long horizons during approach and transport, contracts to 7 actions near contact-sensitive alignment, then expands to 43 actions.The rollout illustrates horizon adaptation rather than a fixed replanning cadence.Source: §5.2 · p. 8

5.3 Failure Case and Scope of Test-Time Execution Control

  • In the failed put_pen_into_pencil_case rollout, short horizons refresh chunks near insertion, but the case remains partly open as the right arm moves the pen toward it.The authors attribute this failure to the base policy rather than feedback timing; PACE cannot recover when the policy lacks actions for a required subtask.Source: §5.3 · p. 9, Figure 6 · p. 9

6 Conclusion

The conclusion frames execution horizon as a task-dependent deployment choice and presents PACE as a training-free way to select it from predicted chunks. Simulation and real-robot results support adaptive replanning as a complement to training-side improvements.

6 Conclusion

  • Execution horizon has a large, task-dependent, non-monotonic effect on success, making a single fixed horizon unreliable.The conclusion presents this as a deployment issue for action-chunking policies.Source: §6 · p. 9
  • PACE selects execution horizons online from predicted chunks, using low-speed valleys as candidate replanning boundaries while preserving coherent motion segments.It requires no retraining, auxiliary heads, policy-internal signals, or inference-engine changes.Source: §6 · p. 9
  • Across 50 RoboTwin2.0 tasks and real-robot settings, PACE improves over fixed-horizon execution, with analyses indicating gains from better replanning timing rather than simply more queries.The conclusion positions execution-horizon selection as a complement to training-side improvements.Source: §6 · p. 9

7 Limitations

PACE changes how predicted chunks are executed, not the underlying policy's action distribution. Its boundary signal depends on kinematic structure, and the reported experiments use one VLA policy family.

7 Limitations

  • PACE cannot recover a rollout when the underlying policy does not generate actions that complete a required subtask.In the cited failure, the refreshed chunks do not fully open the pencil case before the pen moves toward it.Source: §7 · p. 9
  • PACE assumes useful replanning boundaries appear as low-speed valleys; tasks without them or policies with noisy motion profiles may provide weaker signals.The stated assumption is common in manipulation phases involving contact, grasping, release, or alignment.Source: §7 · p. 9
  • The experiments cover broad simulation and real-robot settings but use only the π0.5 VLA policy family.The authors identify evaluation on other chunk-generating policies as future work.Source: §7 · p. 9

A PACE Implementation Notes

  • PACE constructs a speed profile from predicted arm motion, suppresses short-range fluctuations, and uses prominent low-speed regions as candidate boundaries.For multiple arms, it considers candidate boundaries jointly and uses the earliest accepted one; absent a valid boundary, it executes a longer prefix up to a maximum horizon.Source: A PACE Implementation Notes · p. 11

B Simulation Evaluation Details

  • The simulation appendix provides the protocol and task-level results for the main comparison, with ablations and fixed-horizon sweeps assigned separate evaluation budgets.The main simulation results use the 50-task RoboTwin2.0 benchmark under the demo_clean setting.Source: B Simulation Evaluation Details · p. 11, §B.1 · p. 11

B.1 Benchmark and Execution Schemes

  • PACE and fixed-horizon baselines use the same predicted chunks; fixed horizons H ∈ {5, 25, 50} are global rules, not task-specific tuned values.PACE's threshold is calibrated from training demonstrations only, without evaluation rollouts, success labels, or fixed-horizon sweeps.Source: §B.1 · p. 11, A PACE Implementation Notes · p. 11

B.2 Evaluation Metric and Aggregation

  • The 50-task simulation average weights tasks equally, regardless of task duration or the number of policy queries in a rollout.Each task-method pair uses 900 episodes across three seeds and three 100-episode batches per seed.Source: §B.2 · p. 11

B.3 Full 50-Task Results

PACE raises the 50-task RoboTwin2.0 average success rate over the strongest global fixed-horizon baseline. The accompanying ablation appendix describes the evaluation budgets for phase-profile and training-horizon studies.

B.3 Full 50-Task Results

  • 64.2% versus 57.8%: PACE improves the 50-task average success rate over the strongest global fixed-horizon baseline, H = 25.The comparison uses the same task checkpoints for PACE and the fixed-horizon baselines; Table 6 reports task-level results averaged over 900 episodes per task-method pair.Source: §B.3 · p. 11, Table 6 · p. 12

C Additional Ablation Details

  • The phase-profile construction and selection-parameter sensitivity studies cover all 50 RoboTwin2.0 tasks under the full evaluation protocol.For PACE variants, average horizon is the mean selected horizon over policy queries in the evaluation rollouts.Source: C Additional Ablation Details · p. 13, §C.1 · p. 13

C.1 Ablation Protocol

  • The training-prediction-horizon ablation uses six representative tasks, seed 0, and 300 episodes per setting; each row fixes evaluation horizon while varying training horizon.Settings with Htrain < Heval are infeasible because the policy predicts too few actions for the requested prefix.Source: §C.1 · p. 13

C.2 Expanded Training-Horizon Results

Longer training prediction horizons generally benefit non-trivial fixed execution horizons, but the gain is weaker for very short or already-long executed prefixes. The appendix also frames fixed-horizon sweeps as diagnostic analyses of task sensitivity, not as the primary simulation comparison.

C.2 Expanded Training-Horizon Results

  • +20.7 at Heval = 10, +13.0 at Heval = 15, and +6.6 at Heval = 20 are success-rate gains from increasing Htrain over the shortest feasible training horizon.The reported gains support the interpretation that longer supervised chunks provide useful sequence-level supervision for executed prefixes.Source: §C.2 · p. 13
  • At Heval = 5, most gains from longer Htrain are near zero or negative, unlike the gains at non-trivial execution horizons.The passage attributes this exception to high-frequency feedback dominating when the policy is queried after a very short prefix.Source: §C.2 · p. 13
  • The benefit of increasing Htrain shrinks as Heval grows, because later chunk supervision contributes less to actions executed before replanning.Longer training horizons are most beneficial when the executed prefix is short but non-trivial, the operating regime of PACE.Source: §C.2 · p. 13

D Fixed-Horizon Sweep Details

  • The fixed-horizon sweep is diagnostic: it characterizes sensitivity to constant execution horizons and compares PACE with schedules of similar average replanning frequency.It is not the primary simulation comparison; that comparison is reported in Sec. 4.1 and Appendix B.Source: D Fixed-Horizon Sweep Details · p. 13

D.1 Sweep Protocol

The appendix specifies how fixed-horizon sweeps and reference schedules are constructed, then interprets them as diagnostic evidence about horizon sensitivity and replanning timing. Real-robot comparisons use the same fine-tuned checkpoint for baseline and PACE within each task.

D.1 Sweep Protocol

  • The fixed-horizon sweep tests every integer H from 1 to 50 on six tasks, using seed 0 and three 100-episode batches per horizon; PACE uses three seeds and 900 episodes per task.The different evaluation budgets are intentional because the fixed-horizon sweep is diagnostic.Source: §D.1 · pp. 13–14

D.2 Diagnostic Reference Points

  • The hindsight-best fixed horizon varies across tasks, from H = 7 or H = 8 on some tasks to H = 37 on others, and is an oracle rather than a deployable baseline.The matched schedule uses the integer horizon nearest PACE’s mean selected horizon; Table 7 summarizes these references and the PACE gains.Source: §D.2 · pp. 14–15, §D.3 · p. 15, Table 7 · p. 15

D.3 Interpretation

  • PACE outperforms the matched fixed-horizon schedule on all six representative tasks, a comparison that controls for average replanning frequency and distinguishes when queries occur.The sweep is diagnostic rather than the main benchmark; the primary deployable comparison uses global fixed-horizon baselines without task-specific test-task sweeps.Source: §D.3 · p. 15

E Real-Robot Evaluation Details

  • For each real-robot task, baseline and PACE use the same fine-tuned checkpoint and differ only in the test-time execution rule.The appendix covers task setups, metrics, scoring rules, fine-tuning configurations, evaluation protocol, and Franka per-object results.Source: E Real-Robot Evaluation Details · p. 15

E.1 Task Setups

The real-robot appendix describes ALOHA RoboChallenge tasks and a Franka object-placement task, their scoring and training setups, and the shared-checkpoint evaluation protocol. Per-object results report improvement with PACE across all five Franka object variants.

E.1 Task Setups

  • The evaluation covers two bimanual ALOHA RoboChallenge tasks and a single-arm Franka object-placement task family, testing transfer beyond the bimanual setting.The Franka task uses five object variants; the ALOHA tasks are bowl stacking and placing a pen into a pencil case.Source: §E.1 · pp. 15–16, Table 8 · p. 16

E.2 Metrics and Scoring Rules

  • RoboChallenge Score measures partial credit on a 0–100 scale, while Succ. counts only trials that complete the entire task.For Franka placement, the binary success rule makes Score and Succ. identical.Source: §E.2 · p. 16

E.3 Fine-Tuning Details

  • RoboChallenge uses task-specific fine-tuned π0.5 policies, while place_object_on_plate uses one π0.5 checkpoint trained across five variants with 301 demonstrations.The RoboChallenge and Franka configurations both deploy their 30,000-step checkpoints.Source: §E.3 · p. 17

E.4 Evaluation Protocol

  • Within each task, baseline and PACE use the same checkpoint and inputs; evaluation compares full-chunk H = 50 execution with PACE’s online prefix selection, without task-specific horizon tuning.Each RoboChallenge method receives 30 trials; the Franka family has 100 trials per method across five objects.Source: §E.4 · p. 18

E.5 Per-Object Franka Results

  • PACE improves performance on all five place_object_on_plate object variants, so the aggregate gain is not attributed to a single object category.Table 9 reports results for each variant, evaluated over 20 trials per method.Source: §E.5 · p. 18, Table 9 · p. 18

F Additional PACE Rollout Visualizations

  • Additional rollout visualizations show PACE’s online execution horizons adapting across task families and robot platforms.The figures highlight policy-query timesteps and horizons selected from the predicted motion profile.Source: F Additional PACE Rollout Visualizations · p. 19

F.1 RoboTwin2.0 Rollouts

The rollout examples show PACE selecting longer prefixes during smoother motion and shorter ones near task transitions. This phase-aware pattern appears in three RoboTwin2.0 tasks and RoboChallenge bowl stacking.

F.1 RoboTwin2.0 Rollouts

  • In place_can_basket, PACE shortens the horizon near the basket-placement transition and uses longer prefixes during smoother transport.The visualization presents this as a contact-sensitive placement rollout.Source: §F.1 · p. 19, Figure 10 · p. 19
  • In hanging_mug, PACE reduces the horizon near the hanging transition and lengthens it again when motion becomes smoother.The rollout has a pronounced interaction phase.Source: §F.1 · p. 20, Figure 11 · p. 20
  • In scan_object, PACE uses longer prefixes during steady motion and shorter ones when the predicted chunk enters a low-speed transition.The example highlights a more gradual motion structure.Source: §F.1 · p. 20, Figure 12 · p. 20

F.2 RoboChallenge Rollout

  • In RoboChallenge stack_bowls, PACE keeps longer horizons during approach and transport, then shortens them near stacking contact.The example applies the same phase-aware behavior to a bimanual task.Source: §F.2 · p. 21, Figure 13 · p. 21
Loading 2606.00537v3…