Chapter 9: Complete the Three Volumes as One Robot System — From Instruction to Verified Execution

Overview

The final question is not, “Which model is smartest?” It is: on the same tabletop assembly cell, what changed when one higher-level component was added, and which exact version can take over when that component fails? A vision-language-action model (VLA), world model, and agent can propose an action or skill, predict a candidate outcome, and compose a skill sequence. None of those proposals is a torque command or a safety approval.

This chapter does not presume that the physical cell described by S11 or the classical and learned execution spine described by S12 is currently installed or released. It inherits those interfaces only after the actual versions of the robot, sensors, frames, calibration, controllers, skill API, independent evaluator, watchdog, and responsible human have been verified. An absent receipt remains missing, not measured, not exercised, or incompatible; it does not become a model default. The existence of a previous manuscript is not release evidence.

The deliverable is consequently not a success video. A polished insertion can conceal the initial-state distribution, exclusions, failed attempts, and human interventions. Completion means a three-volume responsibility map, an immutable version lineage, stage-labelled success and failure evidence, a rehearsed rollback, and a human-reviewed bounded trial card that says which maintenance changes invalidate its approval.

After reading this chapter... - You can compare a specified task, classical skill, S12 policy, VLA, optional world model, and agent by changing one proposer at a time. - You can separate replay, offline, simulation, shadow, and bounded hardware denominators and receipts. - You can diagnose language variation, new objects and layouts, multi-skill sequences, and recovery with common metrics. - You can write a whole-cell rollback tuple and maintenance invalidation policy rather than saving only a model checkpoint. - You can bound a Codex implementation task by scope, prohibited authorities, verification, and a human release decision.

1. Seal the Cell Before Comparing Intelligence

1.1 Put all three volumes on one responsibility map

The volumes are not substitutes. S11 owns the physical basis that can move predictably. S12 owns the execution spine that turns a classical or learned proposal into a feasible trajectory and controller reference. S13 owns higher-level proposals across varied instructions and scenes. Independent safety authority crosses all three; no model inherits it.

The decisive boundary is proposal → projected → sent → accepted/executed. A VLA proposing “place the red pin in fixture B,” the skill executor projecting that request into a collision-free path and pre-contact pose, the transport sending a controller reference, and the controller accepting and executing it are four events. Each needs its own identifier and timestamps. Collapsing them into one action record makes a wrong skill choice indistinguishable from network delay, a safety rejection, or physical contact failure.

1.2 Freeze the comparison card and denominator

A fair comparison freezes the success definition, initial-state distribution, observation and action semantics, controller, safety supervisor, evaluator, denominator, permitted adaptation data, and stop rules. SIMPLER does not establish that simulation automatically substitutes for a deployment; small-sample evaluation can reverse apparent rankings; runtime-assurance results depend on their encoded dynamics and timing assumptions ^{[15] [6] [4]}. The complete comparison card below is therefore an S13 synthesis, not a universal standard validated by one source.

“The pin was inserted” is too weak a success definition. A usable definition says that the correct part reached the correct fixture, insertion depth and terminal pose were within tolerance, no collision or force event occurred, and the terminal state was recorded before the deadline. The initial distribution specifies object categories and pose ranges, occlusion and lighting, fixture poses, and how paraphrases are sampled. A trial excluded because of hardware or operator error remains in the original denominator with its exclusion reason.

Use explicit denominator units:

$$

R_k = \frac{n_k}{N_{eligible}}, \qquad

R_{unsafe\_proposal} = \frac{n_{unsafe\_proposal}}{N_{proposal}}, \qquad

R_{recovery} = \frac{n_{recovered}}{N_{recoverable\_failure}}.

$$

Here, N_eligible is the preregistered number of eligible trials, N_proposal is the deduplicated number of higher-level proposals, and N_recoverable_failure is the count of failures classified as recoverable before testing. A success rate per episode cannot be compared directly with an unsafe-proposal rate per control tick. Every metric records its numerator event, denominator unit, observation window, exclusion policy, and interval calculation.

1.3 Fix the tabletop assembly scenario

The base trial crosses seven states: identify the part and fixture, grasp, transport through collision-free free space, stop at a pre-contact pose, place or insert under bounded contact, detect success or failure, and finish with retreat, one approved retry, human request, or stop. The primary embodiment is one arm with a parallel gripper. Bimanual, dexterous-hand, and mobile manipulation branches receive separate cards rather than entering the same denominator.

Introduce one S13 variation at a time. Start with different phrases for the same goal. Then add a new color, object, layout, fixture, or occlusion within the declared envelope. Next require a sequence such as identify → grasp → transport → insert → inspect. Finally inject a missing precondition, ambiguous or forbidden request, grasp slip, or insertion jam. A combinatorial trial that changes two axes opens only after each single-axis gate passes, and it receives a new cross-condition denominator.

2. Change One Proposer at Each Gate

2.1 Start with the specified task and classical skill baseline

The lowest comparison point is a task whose target object, fixture, skill order, and termination conditions are written by a human. The next point is a classical skill composed of geometric perception, grasp selection, task and motion planning, trajectory generation, and bounded contact control. Hierarchical planning can instantiate only the continuous choices needed now, but it depends on modeled actions and geometry ^[1]. Behavior trees and CoSTAR expose status and failure transitions, while retaining human-authored task structure ^{[2] [3]}.

The classical baseline is not an obsolete straw man. On known parts and layouts, it may provide interpretable feasibility checks, deterministic replay, and a precise failure location. If a higher-level model cannot improve success, recovery, latency, or cost—or open a declared variation—the added complexity has no promotion case. If perception error or geometric mismatch dominates, repair calibration, scene representation, or fixture design before changing the model.

2.2 Keep a simple S12 learned policy

Classical execution and a simple S12 learned policy remain separate baselines before any VLA, world-model, or agent addition. Diffusion Policy demonstrates one expressive action-distribution and chunking choice but adds iterative inference and remains protocol-specific. Octo demonstrates multi-robot pretraining while documenting limits involving wrist cameras, new interfaces, and predominantly successful demonstrations ^{[8] [16]}. Their source benchmarks must be rerun on the fixed S13 task and denominator.

The S12 baseline should be the simplest approved policy that maps the frozen observation into a bounded action chunk. Freeze its dataset, observation window, action horizon, replan frequency, queue limit, and stale-command rejection. Record the chunk proposal time, projection result, send time, executed prefix, and stop reason. This baseline separates benefit from broad language and visual pretraining from benefit that merely comes from using a larger learned policy.

2.3 Add a VLA as a skill proposer

At the VLA gate, only the component that reads language and images and proposes an allowed skill and parameters changes. RT-2 reports physical trials connecting web knowledge to robot actions; OpenVLA and the π0 family supply different data mixtures and action heads ^{[12] [17] [18]}. Training overlap, robot adaptation, reset, and trial protocols differ, so their numbers cannot become a common leaderboard for this cell.

The executable proposal schema contains a skill_id and version, target object, target fixture, upper bounds on pose or force parameters, preconditions, expiry, explicitly unknown fields, and source-observation identifiers. Free text is retained as explanation but is never parsed by the executor. Paraphrase tests contain both meaning-preserving variants and semantically different controls. New-object tests separate visual novelty from geometry, grasp physics, and contact tolerance.

When the VLA selects the wrong skill, the evaluator assigns grounding_wrong_object, grounding_wrong_relation, or skill_precondition_violation. A correct skill rejected by feasibility projection is proposal_infeasible. A projected proposal that jams during insertion is contact_execution_failure. Those labels determine whether to repair grounding, geometry and calibration, or the contact skill; an aggregate failure count cannot.

2.4 Add a world model only for a decision it can improve

A world model is optional. Add it only to rank several feasible candidates or flag a likely insertion failure. Visual foresight can support short-horizon replanning, but a pixel goal may be physically wrong and prediction degrades with occlusion and horizon ^[14]. DayDreamer shows physical world-model learning on several robots, but its tasks are short and do not establish language-conditioned assembly contact or independent safety ^[13]. Recent diffusion-world-model policy refinement likewise remains evidence for its own data and evaluation envelope ^[21].

The interface should return candidate ID → predicted observation/contact/cost distribution → uncertainty → reason for ranking change. Define what happens when no prediction arrives: preserve the classical ranking, reject the proposal, or request a human. Prediction-service latency cannot stall the real-time controller. A candidate preferred by the model still passes the unchanged projector, collision and force gates, and human approval envelope.

2.5 Let an agent compose verified skills

At the final gate, an agent decomposes a long instruction into versioned skill calls, reads each terminal state, and selects the next call, bounded replan, or human handoff. SayCan combines language and learned skill affordance, but its library and value functions are predefined and its product score is not a safety certificate ^[7]. Code as Policies composes within a curated function namespace; generated programs inherit every API assumption ^[9]. AutoTAMP translates language into formal specifications and checks them, but formal checking covers only encoded constraints ^[10].

Start with read-only scene queries, skill-catalog lookup, bounded plan validation, execution-status reading, and human request. Prohibit arbitrary shell and network access, controller-setting changes, and immediate execution of generated code. Memory is retrievable evidence, not authority. A failure from another robot or old calibration receives compatibility metadata. BUMBLE provides evidence for long-horizon skill use and failure memory, while noting memory growth and skills whose parameters are hard to express in language ^[19].

Across the VLA, world-model, and agent gates, only bounded proposals may change; the lower execution and safety layers stay fixed. VLA action generation, world-model ranking, long-horizon agent composition, and predictive safety filtering each provide partial evidence, but no cited source implements this complete assembly stack or transfers safety authority to a model ^{[18] [21] [19] [5]}. That absence is a limitation of the integration claim, not a detail to hide.

3. Climb the Evidence Ladder One Rung at a Time

3.1 Replay, offline, simulation, shadow, bounded hardware

Offline, replay, simulation, shadow, and real-hardware evidence require separate denominators and receipts. SIMPLER's policy-level correspondence is configuration-bounded; DayDreamer's physical learning incurs real exposure; deployment-time monitoring separates complementary failure categories but does not supply local shadow evidence ^{[15] [13] [22]}. Explicit shadow evidence remains an obligation of this S13 cell.

Replay feeds recorded inputs through the same component to test deterministic outputs, state transitions, and timing. Offline evaluates grounding, calibration, precondition violations, and contamination on frozen splits. Simulation tests reachability, collision, injected delay and outage, and counterfactual candidates. Shadow reads live sensors but sends no commands, comparing proposals with the active approved baseline. Only a bounded hardware trial sends a real command, within a human-reviewed limit on trials, speed, force, objects, layout, and time.

Promotion is not triggered by one prior-stage success rate. Verify required event fields, actual execution of fault injections, observation-age and tail-latency deadlines, and rejection of unsafe proposals by an independent gate. Never translate a protective-stop test marked not exercised into “zero accidents.” Expanding trial count, speed, force, object set, layout, or operating window requires a new card.

3.2 Keep generalization axes separate

Instruction variation separates synonyms, reordered phrasing, negation and prohibition, and ambiguity. Object variation separates appearance, geometry, mass/friction, and contact tolerance. Layout variation separates camera visibility, reachability, obstacles, and fixture pose. Multi-skill evaluation records sequence length, branch count, retry budget, and partial observability. A new embodiment changes observation/action adapters and control mode, so it receives a separate adaptation card.

Label results as in_distribution, new_instruction, new_object_visual, new_object_physical, new_layout, multi_skill, failure_recovery, or cross_embodiment. Replace “80% object generalization” with “16 target-and-skill matches in 20 preregistered visually novel-object trials; physical novelty not tested.” π0.5's reported difficulty with unfamiliar handles, partial observability, and distracted subtask inference shows that broad training does not erase these axes ^[20].

3.3 Count latency, cost, and human exposure

A more accurate model may make the cell worse if observation age or tail latency increases. Timestamp sensor arrival, model input, inference completion, projection completion, send, acceptance, and execution start. Report p50, p95, and p99 plus deadline-miss rate, not only a mean. For remote services, measure connection timeout, retries, duplicate responses, stale-response discard, and time to fall back locally.

Cost includes data collection and review, resets, supervision, cleanup after failure, damaged parts, recalibration, and remote calls—not only GPU time. Physical exposure includes real trials, contact events, protective stops, and human entries into the safeguarded area. If a world model reduces trial count but adds missed deadlines or poor candidate rankings, recompute net value.

4. Failure Evidence Defines the System Boundary

4.1 Diagnose by the layer that could have caused the symptom

Final evidence includes phase-attributed failures, rejected proposals, interventions, retry/replan/handoff outcomes, and irreversible failures. REFLECT demonstrates experience summaries for explanation and correction without independently guaranteeing their causal accuracy. BUMBLE categorizes outcomes across 70 trials, while deployment-time monitoring separates erratic action changes from lack of task progress ^{[11] [19] [22]}. Because failure taxonomies differ, the local taxonomy must be frozen before trials.

Diagnose from physics upward. Inspect force, collision, stop, and controller-tracking evidence first; then projection and planning rejection; then skill preconditions and object-relation grounding; finally agent plan, memory retrieval, and tool calls. A model's narrative is a hypothesis, not causal adjudication. Promote it to diagnostic evidence only when synchronized raw evidence and counterfactual replay support it.

A retry is not blind repetition. Reobserve, determine whether the suspected cause changed, and generate a candidate only within approved parameter bounds. The task card fixes replan budget, maximum consecutive contacts, cumulative force events, and handoff time. Part damage, fixture motion, calibration loss, or safety-device activation ends automated recovery as an irreversible failure.

4.2 Read evidence beside counterevidence

Physical results show feasibility under a source's conditions, not direct transfer to this assembly cell. RT-2's more than 6,000 evaluations, SayCan's 101-instruction study, and OpenVLA's multi-task comparisons retain their own data, robots, resets, and scoring ^{[12] [7] [17]}. Formal checks and predictive filters search for violations only within encoded constraints; they do not exhaust friction, deformable parts, sensor drift, or human behavior ^{[10] [5]}.

Every evidence line therefore has a counterevidence line. Real-robot success is not independent safety approval. Simulation correspondence is not replacement of hardware evidence. A successful retry does not prove the explanation was causally correct. A novel-instruction result with unknown training membership cannot separate semantic transfer from recall. Recent 2026 preprints can motivate an operational test, but retain date and evidence tier until independent replication.

5. Human-Reviewed Bounded Trial Runbook

5.1 Preflight and execution order

The operator first verifies the frozen-card hash and signatures. Robot, gripper, camera, firmware, robot model and frame tree, calibration, controller settings, collision and force limits, watchdog, and E-stop test date must match the tuple. Then verify dataset, model, prompt, skill catalog, tool allowlist, memory, and evaluator versions. Any mismatch prevents reuse of the earlier card.

Execute the classical baseline first and verify that the simple S12 policy has not regressed on the current cell. Then open VLA shadow operation. Add a world model only for a stated ranking hypothesis after VLA passes. Open agent composition only after each individual skill's success, failure, and stop status is verified. A later component must never hide a lower-layer regression.

Use two roles for bounded hardware: an execution operator who follows initialization and task cards, and an independent approver who audits logs, safety gates, and termination. If the model developer is also the approver, record the conflict and add another reviewer. The E-stop must remain physically accessible without depending on software response.

5.2 A bounded Codex implementation prompt

This prompt does not authorize deployment to a robot. It scopes adapter and verification work in an isolated worktree.

Goal: Without modifying the existing tabletop executor, implement an S13 proposal adapter that maps natural-language instructions into versioned allowed-skill candidates, plus a shadow evaluator. Context: Treat the input schema, skill API, baseline logs, safety/stop authority, and version tuple as read-only contracts. Fail a missing value as missing; never infer it. Allowed changes: New proposal adapter, schema validation, event logging, replay/offline/simulation/shadow tests, and documentation. Do not modify controllers, collision or force limits, watchdogs, E-stop, calibration, or approved baselines. Prohibited: Arbitrary shell or network tools, execution of free text, safety bypass, real-robot commands, automatic deployment, or unapproved skills. Verification: Run deterministic replay, rejection of wrong-target/missing-precondition/expired proposals, latency and outage injection, shadow disagreement against the baseline, and lineage checks. Done: Every artifact has a version and hash; denominators and exclusions are recorded; failure tests actually ran; unknowns remain not measured; a human separately signs any hardware promotion.

Codex-generated tests also need evidence-stage labels. Unit tests are offline evidence, simulator tests are simulation evidence, and only live sensing without commands is shadow evidence. No automatic report substitutes for the independent approver.

5.3 Manufacturing Cell Checkpoint

6. Version Lineage, Rollback, and Maintenance Receipt

6.1 Roll back the tuple, not one checkpoint

Hardware promotion requires an immutable version tuple, independent sign-off, rehearsed rollback, and maintenance invalidation triggers. Runtime-assurance architectures separate advanced proposals from a verified fallback only under stated model and timing assumptions. Deployment-time reliability work motivates monitors around a policy, but a model checkpoint omits calibration, safety settings, and human authority ^{[4] [22]}.

The rollback tuple binds task and initial distribution; skill API; robot, tool, sensors, and firmware; frames, calibration, and time synchronization; planner, projector, and controller; collision, force, watchdog, and stop settings; dataset, split, and normalization; S12 policy, VLA, world model, and agent; prompt, tools, and memory; evaluator, failure taxonomy, and denominators; runtime dependencies and remote services; approver and validity window. Each entry has an identifier, content hash, provenance, compatibility envelope, and last verification time.

Rollback is a rehearsal, not a button name. On higher-level service loss, cancel the active skill, flush its queue, discard late responses, transition to the classical or approved S12 baseline, and measure time to restart from a safe state. Do not assume a fallback can seize an insertion already in contact. Use the contact skill's defined termination pose or protective stop followed by human reset.

6.2 Know when maintenance invalidates approval

Remounting a camera or changing a lens alters both scene transforms and VLA input distribution. Changing gripper pads, part supplier, fixture tolerance, or lubricant changes contact and force assumptions. Firmware, driver, or controller-rate changes alter queue and deadline semantics. Prompt, skill description, tool list, and memory retrieval changes modify the executable system even when model weights are identical.

Invalidation can be scoped. A display-only documentation correction may require schema diff and replay. A prompt or skill-description change requires replay, offline evaluation, and shadow. Camera recalibration adds simulation and shadow. Force-limit or controller changes require lower-layer regression, bounded hardware, and a new safety signature. A new embodiment remains a new system despite an adaptation adapter.

6.3 Hand off the system, not the highlight reel

The handoff bundle begins with machine-readable task cards, responsibility map, version tuple, data and model cards, test inventory and raw denominators, event-log index, failure/intervention/recovery table, bounded-trial signatures, rollback rehearsal, and maintenance-invalidation table. A video may point to a specific event ID as supporting context; it is not independent evidence.

The recipient must answer five questions from durable records: Which proposer is active? What lower execution tuple was last independently verified? Which generalization axes and failures remain untested? If today's model or service disappears, which baseline resumes and how long does that take? Which receipt will the next calibration, firmware, or fixture change invalidate? If those answers cannot be replayed, the system is not complete.

This conclusion does not imply that S11 or S12 has been publicly released. Interfaces attributed to them remain prerequisites whose current versions and receipts must be checked. Do not finalize reader crosslinks to those volumes until valid release receipts exist. Nor does S13 claim general autonomous operation outside the human-reviewed envelope.

Related Deep Dives

These Terry posts are optional cross-reading, not evidence for this chapter's claims: ForceVLA, the π0 flow model, DexForce, the π0.6 recap, CaP-X, RoboClaw, force/torque-guided compliant manipulation, and global planning with contact. Links to the preceding volumes remain pending their release receipts.

What to Learn Next

After three volumes, do not begin by collecting more model names. Close one gate. Reproduce the classical baseline on today's cell and confirm the simple policy has not regressed. Connect a VLA only as a shadow proposer and fill one denominator for instruction variation. Open a bounded hardware trial only after failure, rejection, and latency logs are complete and an independent approver signs.

Let the failure ledger select the next study. Wrong targets point to grounding and scene representation; projection rejection points to geometry, calibration, and skill parameters; contact failures point back to the S12 execution skill; long-task loops point to state machines and agent recovery. Add a world model only when candidate-selection error is demonstrably dominant. The three volumes are complete not when every layer is learned, but when the changed layer is identifiable, its evidence is bounded, and the system can return safely to a known tuple.

Supplementary evidence map

The following verified primary-source groups come from the independent S13 ledger. They document search coverage without changing existing claims or denominators.

• touch and soft bodies: Generalize by Touching: Tactile Ensemble Skill Transfer for Robotic Furniture Assembly, UBSoft: A Simulation Platform for Robotic Skill Learning in Unbounded Soft Environments, PAVLM: Advancing Point Cloud based Affordance Understanding Via Vision-Language Model, ManiGaussian: Dynamic Gaussian Splatting for Multi-task Robotic Manipulation — source-specific tasks, data, and evidence stages remain separate.
• representation and multitask learning: Contrastive Imitation Learning for Language-guided Multi-Task Robotic Manipulation, DexDiff: Towards Extrinsic Dexterity Manipulation of Ungraspable Objects in Unrestricted Environments, Hierarchical Diffusion Policy for Kinematics-Aware Multi-Task Robotic Manipulation — source-specific tasks, data, and evidence stages remain separate.
• skill decomposition and adaptation: DexSkills: Skill Segmentation Using Haptic Data for Learning Autonomous Long-Horizon Robotic Manipulation Tasks, AdaDemo: Data-Efficient Demonstration Expansion for Generalist Robotic Agent, Policy Adaptation via Language Optimization: Decomposing Tasks for Few-Shot Imitation — source-specific tasks, data, and evidence stages remain separate.

References

1. Kaelbling, L. P., & Lozano-Pérez, T. (2011). Hierarchical Task and Motion Planning in the Now. IEEE ICRA. arXiv:1011.0010.
2. Paxton, C., et al. (2017). CoSTAR: Instructing Collaborative Robots with Behavior Trees and Vision. IEEE ICRA. arXiv:1611.06145.
3. Colledanchise, M., & Ögren, P. (2018). Behavior Trees in Robotics and AI: An Introduction. CRC Press. arXiv:1709.00084.
4. Mehmood, U., Sheikhi, S., Bak, S., Smolka, S. A., & Stoller, S. D. (2022). The Black-Box Simplex Architecture for Runtime Assurance of Autonomous CPS. NASA Formal Methods. DOI: 10.1007/978-3-031-06773-0_12. arXiv:2102.12981.
5. Wabersich, K. P., & Zeilinger, M. N. (2021). A Predictive Safety Filter for Learning-Based Control of Constrained Nonlinear Dynamical Systems. Automatica. arXiv:1812.05506.
6. Agarwal, R., et al. (2021). Deep Reinforcement Learning at the Edge of the Statistical Precipice. NeurIPS. arXiv:2108.13264.
7. Ahn, M., et al. (2022). Do As I Can, Not As I Say: Grounding Language in Robotic Affordances. CoRL. arXiv:2204.01691.
8. Chi, C., et al. (2023). Diffusion Policy: Visuomotor Policy Learning via Action Diffusion. Robotics: Science and Systems. arXiv:2303.04137.
9. Liang, J., et al. (2023). Code as Policies: Language Model Programs for Embodied Control. IEEE ICRA. arXiv:2209.07753.
10. Chen, Y., et al. (2023). AutoTAMP: Autoregressive Task and Motion Planning with LLMs as Translators and Checkers. IEEE ICRA. arXiv:2306.06531.
11. Liu, Z., et al. (2023). REFLECT: Summarizing Robot Experiences for Failure Explanation and Correction. CoRL. arXiv:2306.15724.
12. Brohan, A., et al. (2023). RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control. CoRL. arXiv:2307.15818.
13. Wu, P., et al. (2023). DayDreamer: World Models for Physical Robot Learning. CoRL, PMLR 205.
14. Finn, C., & Levine, S. (2017). Deep Visual Foresight for Planning Robot Motion. IEEE ICRA. arXiv:1610.00527.
15. Li, X., et al. (2024). Evaluating Real-World Robot Manipulation Policies in Simulation. arXiv:2405.05941.
16. Octo Model Team, et al. (2024). Octo: An Open-Source Generalist Robot Policy. arXiv:2405.12213.
17. Kim, M. J., et al. (2024). OpenVLA: An Open-Source Vision-Language-Action Model. arXiv:2406.09246.
18. Black, K., et al. (2024). $\pi_0$: A Vision-Language-Action Flow Model for General Robot Control. arXiv:2410.24164.
19. Shah, R., et al. (2024). BUMBLE: Unifying Reasoning and Acting with Vision-Language Models for Building-wide Mobile Manipulation. arXiv:2410.06237.
20. Physical Intelligence, et al. (2025). $\pi_{0.5}$: A Vision-Language-Action Model with Open-World Generalization. arXiv:2504.16054.
21. Jiang, Z., et al. (2025). World4RL: Diffusion World Models for Policy Refinement with Reinforcement Learning for Robotic Manipulation. arXiv:2509.19080.
22. Agia, C. (2026). Deployment-Time Reliability of Learned Robot Policies. arXiv:2603.11400.
23. Lin, H., et al. (2024). Generalize by Touching: Tactile Ensemble Skill Transfer for Robotic Furniture Assembly. arXiv primary preprint (2024-04-26). arXiv:2404.17684.
24. Lin, C., et al. (2024). UBSoft: A Simulation Platform for Robotic Skill Learning in Unbounded Soft Environments. arXiv primary preprint (2024-11-19). arXiv:2411.12711.
25. Liu, S., et al. (2024). PAVLM: Advancing Point Cloud based Affordance Understanding Via Vision-Language Model. arXiv primary preprint (2024-10-15). arXiv:2410.11564.
26. Lu, G., et al. (2024). ManiGaussian: Dynamic Gaussian Splatting for Multi-task Robotic Manipulation. arXiv primary preprint (2024-03-13). arXiv:2403.08321.
27. Ma, T., et al. (2024). Contrastive Imitation Learning for Language-guided Multi-Task Robotic Manipulation. arXiv primary preprint (2024-06-14). arXiv:2406.09738.
28. Ma, C., et al. (2024). DexDiff: Towards Extrinsic Dexterity Manipulation of Ungraspable Objects in Unrestricted Environments. arXiv primary preprint (2024-09-09). arXiv:2409.05493.
29. Ma, X., et al. (2024). Hierarchical Diffusion Policy for Kinematics-Aware Multi-Task Robotic Manipulation. arXiv primary preprint (2024-03-06). arXiv:2403.03890.
30. Mao, X., et al. (2024). DexSkills: Skill Segmentation Using Haptic Data for Learning Autonomous Long-Horizon Robotic Manipulation Tasks. arXiv primary preprint (2024-05-06). arXiv:2405.03476.
31. Mu, T., et al. (2024). AdaDemo: Data-Efficient Demonstration Expansion for Generalist Robotic Agent. arXiv primary preprint (2024-04-11). arXiv:2404.07428.
32. Myers, V., et al. (2024). Policy Adaptation via Language Optimization: Decomposing Tasks for Few-Shot Imitation. Conference on Robot Learning, 2024. arXiv:2408.16228.