Chapter 6: Policy Architectures — Balancing Generality and Execution

Overview

Reading policy architecture as a VLA leaderboard misses the manufacturing point. In a factory cell, architecture first decides action representation, control latency, sensor channels, and fallback authority. ACT predicts short bimanual action sequences as chunks ^[1]. Diffusion Policy treats continuous multimodal action as a denoising problem ^[2]. RT-1, RT-2, and RT-X push robot data mixtures and language-conditioned generalization ^[4], ^[5], ^[3].

OpenVLA, Octo, pi0, OpenPI, and FAST do not mean that a larger model is automatically factory-ready ^[6], ^[7], ^[8], ^[10], ^[11]. Manufacturers should first ask what the policy can observe, how often it can change action, which failures can be replayed, and which guard can block release.

The thesis of this chapter is that generality and execution reliability come from different places. Broad pretraining can provide semantic and behavioral priors. Short feedback loops, physical sensing, embodiment-specific controllers, and auditable failure traces determine whether those priors can safely become motion. Neither side substitutes for the other.

After reading this chapter... - Compare ACT, Diffusion Policy, RT-X/Open X, and OpenVLA/Octo/pi0 through action representation. - Explain how language grounding, embodiment mixture, and force/touch channels affect cycle time and release gates. - Define the logs and evaluations needed before turning a generalist policy claim into a factory deployment claim. - Recognize when a non-VLA architecture may be the better manufacturing policy. - Distinguish Cosmos 3 forward prediction, inverse action inference, and joint policy/world generation, including the evidence limits of each mode.

Architecture Decision Table

This table reframes architecture as a factory control interface rather than a model name. The same backbone can behave very differently depending on whether actions update at 5 Hz or 50 Hz, and whether a force guard is held by an external controller or by policy tokens.

Historical Shift: From One-Step Actions to Conditional Trajectories

A longstanding weakness of behavioral cloning is compounding error after a learner leaves the state distribution represented in its demonstrations. DAgger formalized a response by requesting expert labels on states visited by the learner, but expert intervention remains expensive in a manufacturing cell where unsafe contact states cannot simply be visited for annotation ^[25]. Visual control and robot reinforcement learning in the 2010s attacked the problem with more interaction and data. Assembly and bimanual work, however, exposed a second issue: the local temporal structure of motion matters, not only the action predicted at one frame.

ACT changed that representation by predicting overlapping future action sequences and temporally ensembling them ^[1]. This can smooth pauses and jitter in demonstrations while preserving a coherent bimanual routine. Diffusion Policy then relaxed the assumption that a scene has one unimodal correct action, representing a conditional distribution over receding-horizon trajectories ^[2]. Open X-Embodiment and RT-X moved the frontier from the grammar of one policy toward the problem of pooling heterogeneous robot data ^[3]. Octo and OpenVLA extended that line through open, adaptable observation/action interfaces and language-action representations ^[7], ^[6]. Pi0 took another route, adding a flow-matching action expert to a pretrained vision-language model to generate continuous action chunks ^[8].

Action chunks, diffusion, flow matching, and tokenized actions trade latency, multimodality, horizon, and closed-loop correction differently. They are not interchangeable labels for the same mechanism, and any ranking remains bounded by the cited tasks, embodiments, data regimes, control rates, baselines, and evaluation denominators ^[1], ^[2], ^[8], ^[6]. The historical shift is therefore not simply toward larger models. It runs from a one-step mean action to a conditional trajectory distribution, from a single robot coordinate system to cross-embodiment pretraining, and from vision-conditioned commands toward loops that can include force and touch.

That lineage leaves three decision questions. First, does the policy emit joint positions, end-effector velocity, pose deltas, discrete tokens, or typed skills? Second, how much of the predicted horizon executes before the system observes again? Third, who interrupts motion when an unobserved contact variable changes? A success rate without those answers is insufficient for architecture selection.

The table does not nominate a universal winner. It shows where each family moves risk. ACT packages temporally overlapping predictions into action chunks, but the published temporal-ensembling implementation queries the policy at every timestep; chunking therefore does not by itself reduce prediction-call count and still requires an interruption path. Diffusion and flow preserve multiple feasible behaviors but require compute and guard integration. Cross-embodiment VLA models buy a broader prior at the cost of action normalization and data-mixture audits. World-action models expand prediction and generation while moving physical consistency into a separate validation obligation.

Figure 6.1. Author-created comparison of ACT, Diffusion Policy, RT-X, OpenVLA, and pi0 by observation, policy core, action representation, and manufacturing gate. It is not a shared benchmark result or evidence from a Cosmos 3 tutorial.

ACT and the Risk of Action Chunking

ACT matters because it predicts short future action sequences instead of treating every timestep as an independent action ^[1]. That fits bimanual work such as holding and pulling a cable or aligning a small part with two hands. Its low-cost hardware and imitation setup also weaken the assumption that only expensive hardware can support fine manipulation.

The risk is that contact can change inside the chunk. If a part catches on a fixture lip and the policy continues pushing until the chunk ends, the result may be cosmetic damage or a jam. ACT-style policies therefore need chunk length, replan frequency, force stops, and human override latency designed together. Longer chunks may improve smoothness, but they slow reaction to contact events.

Figure 6.2. ACT's conditional VAE encoder infers a style variable z from demonstration action sequences, while its Transformer decoder generates action chunks from four camera views, joint state, and z. The architecture diagram itself does not establish safe mid-chunk interruption when contact changes. Source: Zhao et al. 2023, arXiv:2304.13705 Fig. 4.

Diffusion Actions Avoid Averaging Unsafe Motions

Diffusion Policy weakens the assumption that one scene has one correct action ^[2]. The same insertion may allow a slight left twist, a small rightward push, or a retreat-and-retry path. Modeling a distribution is valuable when averaging those actions would create an unsafe motion.

The cost is inference budget. Strict cycle times may not allow many denoising steps, and contact recovery often needs a fast low-level reflex or guard. The factory question is not only whether Diffusion Policy succeeds in a benchmark. It is who guarantees force limits while sampling is happening.

Latency Budget Is a Hidden Architecture Specification

In a factory cell, latency is not average inference time. It is worst-case response time. Vision-encoder latency, language-conditioned backbone latency, trajectory interpolation, and safety-stop response all add together. The same policy means different things in a cell that updates action every 200 ms and a cell that checks contact guards every 20 ms.

ACT-style chunking can stabilize high-level action, but it needs an interruption path when a contact event occurs inside the chunk. Diffusion-style action distributions can represent multiple feasible paths, but additional sampling steps stretch cycle time. RT-X and OpenVLA-style systems use instruction and visual context broadly, but low-level force response may be too fast to delegate to a language-conditioned backbone. Architecture comparisons therefore need reaction budgets next to success rates.

Many production systems separate the policy loop from the safety loop. The policy may propose the next motion segment at 5-20 Hz, while the controller and safety guard check force limits and collision zones at a higher rate. If that split is not explicit, a large policy appears to own more authority than it really should. When evaluating a vendor stack, the manufacturer should ask not only what the model can do, but what it is prevented from doing.

Decision Walkthrough: Flexible Cable Routing

Flexible cable routing exposes architecture differences. A cable has no fixed rigid pose, its shape changes during work, and the connector end and slack create different states. A human sees the coarse shape, feels tension through the fingers, and relaxes force where pulling would damage the jacket. A vision-language model may understand "route the cable into the clip," but cable tension and snagging appear late unless another channel observes contact.

ACT can represent a short routing subroutine, such as holding the cable at a clip and pushing it into place. Diffusion Policy can model several feasible routing paths. OpenVLA or RT-X-style models can use SKU descriptions, clip positions, and task order. The moment the cable catches on an edge, however, the cell needs force/tactile guards and quick retreat.

The architecture decision is therefore a handoff design, not a model-family choice. The high-level policy selects the next clip. The local controller watches tension and force limits. The failure detector classifies a snag as a contact event. Operator override records which retreat motion actually reduced jacket damage. Without this handoff, a generalist policy reduces cable routing to following a visible path in video.

Action Representation Decides the Grammar of Recovery

Action representation is not just the shape of the policy output; it is the grammar of failure recovery. Discrete action tokens are easier to log and align with language, but they can become rough near contact boundaries. Continuous actions are smoother, but they are harder to audit and constrain symbolically. Flow and diffusion actions can represent several trajectories, but sampling and guard integration become central. That is why the FAST and pi0 discussions matter for manufacturing ^[8], ^[11], ^[10].

Imagine a press-fit insertion where a discrete policy emits an "insert" token. The controller still needs to know the velocity, force ramp, and retreat threshold encoded by that token. A continuous policy can output velocity directly, but a QA engineer may struggle to explain why it pushed harder in one failure. A diffusion trajectory can propose multiple recovery paths, but only paths that pass safety guards should execute.

Manufacturing architectures often need a typed action layer between policy output and actuator command. Define action types such as approach, align, probe, insert, retreat, and inspect, then attach parameters and guards to each type. The learning policy proposes the type and parameters, the controller applies guards, and the release board reads failure rate by type. With this structure, even a generalist policy is managed in units that quality teams understand.

Data-Mixture Audit: Does the Corpus Represent This Cell?

Open X-Embodiment and DROID provide diversity ^[3], ^[19]. Diversity, however, is a representation prior, not plant certification. A manufacturer should ask what dataset mixture produced the candidate policy: how much tabletop picking, how much bimanual assembly, how much force-rich insertion, how much deformable-object handling, how many failure episodes, and how much operator correction.

A data-mixture audit is not only SKU coverage. It also covers camera angle, robot morphology, gripper type, action frequency, sensor modality, reset protocol, and success definition. If a public dataset defines success as reaching a target pose, while the plant defines success as inspection pass and downstream-test pass, the gap is material. Without this audit, a generalist model's broad prior becomes local false confidence.

RT-X and Cross-Embodiment Are Priors, Not Certification

Cross-embodiment VLA pretraining supplies a broad prior, but deployment remains conditioned on action-space normalization and embodiment-specific adaptation ^[3], ^[7], ^[6]. Open X-Embodiment's normalization of heterogeneous datasets is both an engineering achievement and a warning. A common schema enables joint learning while discarding or routing around some robot-specific joint limits, control semantics, gripper compliance, and sensor timing. Octo's adaptable observation/action heads and OpenVLA's disclosed fine-tuning paths do not remove that last-mile work.

RT-1, RT-2, and Open X-Embodiment connect robot data with web knowledge, language instructions, and multiple embodiments ^[4], ^[5], ^[3]. Octo and OpenVLA extend that line toward open generalist policies and VLA models ^[7], ^[6]. For manufacturers this is a strong prior: new SKU descriptions, similar tool-use patterns, and visual routines from other robots can become useful faster.

Figure 6.3. Open X-Embodiment Figure 1 summarizes one million episodes from 34 research labs and 21 institutions, spanning 22 embodiments, 527 skills, and 60 datasets. Breadth alone does not certify transfer of action conventions or calibration into manufacturing. Source: Open X-Embodiment Collaboration 2024, arXiv:2310.08864 Fig. 1.

Cross-embodiment is not certification. A public dataset label such as "pick" does not guarantee compatibility with a plant's torque limits, gripper-pad wear, or inspection-camera timing. Open X-style pretraining can make the initial policy smarter, but release still needs plant-specific replay sets, fixture splits, sensor-dropout tests, and operator overrides.

RT-X, Octo, OpenVLA, and pi0 should not be placed on a single ordinal leaderboard. RT-X asks whether positive transfer emerges from a robot data mixture. Octo emphasizes flexible input-output adapters and an open generalist-policy recipe. OpenVLA couples a 7B vision-language backbone with discrete action tokens and discloses fine-tuning and quantized serving paths. Pi0 emphasizes a flow-based action expert for continuous chunks. The tokenized path can be easier to log and align with language, but contact-boundary quantization and decoding latency need tests. The flow path expresses continuous trajectories naturally, while incomplete disclosure of the private training mixture and compute narrows independent reproducibility ^[6], ^[8].

Integration Pattern: Separate Planner, Policy, and Controller

A manufacturing architecture is not one giant model block. The task planner decides which step to run for a SKU and fixture. The policy proposes an action type and parameters from the current observation. The controller applies robot-specific dynamics and force guards. The safety layer keeps authority over people, equipment, and product damage. Separating these layers preserves process responsibility even when a VLA or diffusion policy is inserted.

Suppose an OpenVLA-style model understands the instruction "insert the blue connector into the left socket" ^[6]. The planner still needs to select the socket variant and inspection rule. The policy proposes approach and probe actions. The controller limits the force ramp. If a sensor drops out, the safety layer switches to guarded retreat. Without this split, language-conditioned success is easily mistaken for production authority.

Open stacks such as Octo and OpenPI are valuable because they make this separation easier to test and audit ^[7], ^[10]. But open weights do not solve integration by themselves. Controller frequency, robot driver, safety PLC, QA database, and MES trace must still connect. Buying an architecture means managing those boundaries, not just selecting model weights.

The final integration question is rollback. Can the planner rule be reverted without reverting the policy? Can the policy checkpoint be reverted without changing controller guards? Can a force threshold be restored independently? If all layers are hidden inside one vendor package, rollback is slow and opaque. If layers are separated, the rollback can match the failure cause.

Acceptance testing should follow the same layer structure. Planner tests check whether the wrong SKU or fixture is selected. Policy tests check whether action type and parameters remain appropriate on replay. Controller tests verify force and collision guards. Safety tests exercise sensor dropout, emergency stop, and human entry. A single aggregate success rate hides which layer is weak.

This layered view also clarifies ownership. The manufacturer may accept a vendor policy while keeping planner rules and safety thresholds internal. Or it may use an open policy stack while buying a certified controller. The technical choice and the commercial boundary should match. Otherwise the team discovers too late that the party responsible for a failure does not control the layer that caused it.

The same boundary should be visible in logs. A failure record should say whether the planner selected the wrong task, the policy chose a risky action, the controller clipped the motion, or the safety layer stopped the robot. If the log only says "model failed," the next update becomes guesswork. Layered architectures need layered telemetry.

This is also how architecture choices remain comparable over time. A plant may begin with ACT for a narrow bimanual routine, test a diffusion action head for recovery, and later evaluate an OpenVLA-style policy for instruction handling. If the planner, policy, controller, and safety logs stay stable, those changes become controlled experiments rather than resets of the entire automation program.

Stable logs also protect the training corpus. A future model should be able to learn from old failures even if the architecture family changes. That only works when action names, guard events, and QA outcomes survive the model transition.

Questions That Separate OpenVLA, Octo, and pi0

Open checkpoints and disclosed interfaces improve auditability but do not by themselves establish manufacturing performance. Replay, version pinning, latency measurement, and controlled adaptation can become easier ^[6], ^[7], ^[12]. An open model can still inherit training-mixture bias, robot-driver mismatch, nondeterministic serving behavior, and distribution shift after sensor replacement. “Can we obtain the weights?” and “Does this cell maintain an acceptable defect rate over its service interval?” are separate release questions.

OpenVLA increases auditability because it is an open-source VLA ^[6]. Octo offers an open recipe for comparing generalist robot policies across embodiments ^[7]. pi0 pushes flow-style action modeling for general robot control, and OpenPI exposes a usable stack ^[8], ^[10]. FAST proposes another route through efficient action tokenization ^[11].

These differences matter in production. A manufacturer that needs audit may prefer open weights and data recipes. A cell with tight cycle time cares about inference latency and action-token cost. A cell with high fault liability cares which layer owns stop authority. Those distinctions disappear when every system is summarized as "a VLA."

Compute is part of releaseability. A large policy may benchmark well on a server while tail latency grows after camera transfer, preprocessing, network round trips, action decoding, and controller queues are included. Asynchronous inference, as explored by SmolVLA, can overlap execution with the next prediction and improve average throughput, but a rapidly changing scene can make the queued chunk stale ^[12]. A cell should therefore log p95 and p99 latency, observation-to-execution age, and canceled-action rate in addition to average throughput.

FAST's efficient tokenization should be read through the same lens ^[11]. A shorter token sequence can reduce autoregressive decoding cost, yet the plant must test whether compression preserves small velocity changes before contact and the boundary between insertion and retreat. Openness, compactness, and fast decoding are important engineering properties. None is a proxy for contact quality.

World-Action Models: Keep Predictor, Inverse Model, and Policy Distinct

The learned-world-model lineage began with action-conditioned prediction and model-based control. Visual Foresight predicted future images under candidate actions and used them for planning, while DayDreamer showed a path to learning world models from pixels and sparse rewards on multiple physical robots ^[26], ^[27]. A newer world-action model goes further by modeling future scene and action jointly. Ye et al.^[28] probe whether a video-diffusion backbone that models both can operate as a zero-shot robot policy. The scientific result remains bounded to that paper's tasks, rate, embodiments, and evaluation; it does not establish immediate use in an unvalidated factory state.

NVIDIA's Cosmos 3 strategy attempts to package this frontier as reusable physical-AI components. The research release presents Cosmos 3 as an omnimodal world-model platform spanning generation, reasoning, action simulation, open checkpoints, datasets, and benchmarks ^[29]. The official technical guide describes three modes after post-training on action-labeled data ^[30]. Forward dynamics takes a current visual state, task description, and action trajectory to predict a future video. Inverse dynamics takes a task video and description to infer an observable action trajectory. Joint policy/world mode takes an initial observation and task description and generates a next action chunk together with a predicted video. The modes may share a modeling substrate, but their questions and outputs differ; they should not be collapsed into one capability.

Most importantly, inverse-dynamics output is not a directly measured physical variable. A system may estimate end-effector motion from video without recovering ground-truth occluded force, internal finger pressure, micro-slip, or actuator torque. A visually plausible forward prediction likewise does not certify accurate contact physics. NVIDIA's official Cosmos3-Super model card documents action-state drift, morphing objects, unrealistic collisions, and physically implausible motion ^[33]. A world-model prediction can help rank candidate actions, inspect data, or generate failure hypotheses, while force limits and product-damage decisions still need instrumented sensing and real-cell tests.

Cosmos action-model demonstrations are first-party capability evidence; no universal few-shot or teleoperation-reduction claim follows without controlled cross-task evaluation. NVIDIA's tutorial shows post-training on YAM data in LeRobot format, checkpoint export, and forward-dynamics inference, and its description says that alternate configurations support inverse-dynamics and policy modes ^[31]. It provides no denominator for task success, no controlled cross-task comparison, and no independent replication. In particular, the video does not substantiate “100 demonstrations” as a sample-efficiency result that transfers across tasks and embodiments ^[31], ^[29].

That boundary also clarifies the relationship to GR00T. GR00T N1 is a generalist humanoid policy family intended to map language and visual context toward robot action, whereas Cosmos 3 is a world-model family for prediction, reasoning, and action-conditioned generation ^[14], ^[29]. Cosmos-derived trajectories or videos may become training material or evaluation candidates for a GR00T-like policy, but composing the systems does not remove real demonstrations, robot calibration, or safety validation. Generated data needs provenance, generation settings, filters, physical-consistency checks, and a recorded ratio to real data. At release time, measured force, quality inspection, retries, and stop events on the physical robot must outrank a predicted successful video.

At the policy layer, an NVIDIA-centered strategy can be read as a division of responsibilities. Omniverse and OpenUSD exchange scenes and assets; Isaac Sim and Isaac Lab provide robot/sensor simulation and parallel learning workflows; Cosmos generates or evaluates visual-action scenarios; GR00T supplies one policy-training line. This is not an end-to-end assurance claim. Visual realism, contact-physics accuracy, policy action quality, and real-cell safety require different tests. The architectural discipline is to trace which data entered which model and which release gate accepted its output, instead of drawing one undifferentiated “physical AI” box.

Force and Touch Are Not Peripheral Channels

Vision-language-action policies without force or touch cannot be assumed to infer hidden contact state reliably. Contact force, slip, and compliant deformation can differ under nearly identical RGB observations. ForceVLA places real-time six-axis force into a mixture-of-experts action decoder, while Tactile-VLA combines tactile input with a hybrid position-force controller ^[16], ^[17]. ForceVLA2 further connects force prompts and cross-scale experts to closed-loop hybrid control ^[32]. These studies support the value of an explicit physical channel; they do not show that video alone recovers hidden force truth. Their limited task counts, single-platform setups, sensor-specific calibration, and lack of lifecycle evaluation also preclude universal superiority claims.

In manufacturing manipulation, force and tactile signals cannot be afterthoughts. Gemini Robotics and GR00T foreground physical-task generalization ^[13], ^[14], while ForceVLA and Tactile-VLA put force or tactile observations directly into VLA-style policies ^[16], ^[17]. Tactile-Language-Action work also shows how tactile tokens and language can interact when RGB is weak ^[18].

The core issue is release responsibility, not sensor fusion alone. Once tactile data enters the policy, the cell inherits calibration drift, sensor replacement, gel wear, cable noise, and threshold mismatch. Even when a force-aware MoE uses force, the final authority to prevent over-force may still need to live in a controller guard or safety PLC. The architecture diagram should include calibration jobs, sensor health checks, and fallback controllers alongside model blocks.

Multimodal evaluation cannot stop at aggregate success. Test nominal sensing separately from saturation, zero-offset drift, replacement units, and dropped frames. Record which channel wins when vision and force disagree, whether stale tactile frames influence the next action, and whether sensor loss triggers a guarded stop. Additional modalities improve observability while adding calibration and synchronization failure surfaces.

Manufacturing Cell Checkpoint

First, write a latency budget for every architecture candidate: perception latency, policy inference, action hold, controller cycle, and safety-stop response. Second, connect action representation to task failure. Use replay sets to see whether chunking notices jams too late, diffusion sampling exceeds cycle time, or tokenized actions become rough near boundaries.

Third, align sensor channels with failure modes. Do not group vision-only pick-and-place and force/tactile insertion under one policy without evidence. Fourth, separate evidence tiers. arXiv papers justify methods and benchmarks; company developer pages justify product direction and supported stacks. Production readiness requires plant-specific canaries, rollback, and maintenance logs.

Open Questions and Failure Modes

Large backbones do not automatically recover missing process variables. Language instructions still leave lot, fixture revision, adhesive age, and tool wear outside the model unless those variables are provided. Cross-embodiment pretraining supplies useful action priors while hiding calibration mismatch. Tactile and force channels unlock contact-rich work but introduce sensor drift and maintenance burden. Finally, a closed vendor stack can make independent release-gate audits difficult.

Figure 6.4. Policy architecture gate from observation to safety guard. This diagram is not a performance claim; it summarizes the operational chain that carries capability evidence through replay and quality decisions into release authority. Source: author-created SVG.

What to Learn Next

The next chapter asks where the data for these architectures comes from. UMI, DexUMI, DEXOP, and EgoScale scale human data while handling embodiment gap and force observability in different ways. Even a strong policy architecture will not stabilize a factory cell if the human data was transformed incorrectly.

References

1. Zhao, Tony Z. (2023). Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware. arXiv.
2. Chi, Cheng (2023). Diffusion Policy: Visuomotor Policy Learning via Action Diffusion. arXiv. #34 · KO
3. O'Neill, Abby et al. (2024). Open X-Embodiment: Robotic Learning Datasets and RT-X Models. ICRA.
4. Brohan, Anthony (2022). RT-1: Robotics Transformer for Real-World Control at Scale. arXiv.
5. Brohan, Anthony (2023). RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control. arXiv.
6. Kim, Moo Jin (2024). OpenVLA: An Open-Source Vision-Language-Action Model. arXiv.
7. Octo Model Team (2024). Octo: An Open-Source Generalist Robot Policy. arXiv. #55 · KO
8. Black, Kevin (2024). pi0: A Vision-Language-Action Flow Model for General Robot Control. arXiv. #2
9. Physical Intelligence (2024). pi0: A Generalist Robot Policy. Company research post.
10. Physical Intelligence (2025). OpenPI: Open Source Robot Policy Stack. GitHub.
11. Pertsch, Karl (2025). FAST: Efficient Action Tokenization for Vision-Language-Action Models. arXiv.
12. Shukor, Mustafa (2025). SmolVLA: A Vision-Language-Action Model for Affordable and Efficient Robotics. arXiv.
13. Gemini Robotics Team (2025). Gemini Robotics: Bringing AI into the Physical World. arXiv.
14. Bjorck, Johan (2025). GR00T N1: An Open Foundation Model for Generalist Humanoid Robots. arXiv.
15. NVIDIA (2025). Isaac GR00T N1 Open Foundation Model for Humanoid Robots. NVIDIA Developer.
16. Yu, Jiawen (2025). ForceVLA: Enhancing VLA Models with a Force-aware MoE for Contact-rich Manipulation. arXiv. #1 · KO
17. Huang, Jialei (2025). Tactile-VLA: Unlocking Vision-Language-Action Model's Physical Knowledge for Tactile Generalization. arXiv.
18. Hao, Peng (2025). TLA: Tactile-Language-Action Model for Contact-Rich Manipulation. arXiv.
19. Khazatsky, Alexander (2024). DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset. arXiv.
20. AgiBot-World-Contributors (2025). AgiBot World Colosseo: A Large-scale Manipulation Platform for Scalable and Intelligent Embodied Systems. arXiv.
21. Li, Xuanlin (2024). Evaluating Real-World Robot Manipulation Policies in Simulation. arXiv.
22. Mandlekar, Ajay (2021). What Matters in Learning from Offline Human Demonstrations for Robot Manipulation. arXiv.
23. Ha, Huy (2024). Universal Manipulation Interface: In-The-Wild Robot Teaching Without In-The-Wild Robots. arXiv.
24. Toyota Research Institute (2024). Large Behavior Models for Robot Manipulation. Company technical post.
25. Ross, Stephane et al. (2011). A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning. AISTATS.
26. Finn, Chelsea and Levine, Sergey (2017). Deep Visual Foresight for Planning Robot Motion. ICRA.
27. Wu, Philipp et al. (2023). DayDreamer: World Models for Physical Robot Learning. CoRL.
28. Ye, Seonghyeon et al. (2026). World Action Models are Zero-shot Policies. arXiv.
29. Aditi et al. (2026). Cosmos 3: Omnimodal World Models for Physical AI. arXiv.
30. Bhide, Asawaree et al. (2026). Develop Physical AI Reasoning, World, and Action Models with NVIDIA Cosmos 3. NVIDIA Technical Blog.
31. NVIDIA Developer (2026). How to Post-Train NVIDIA Cosmos 3 for Robot Action Prediction. Official tutorial video.
32. Li, Yang et al. (2026). ForceVLA2: Unleashing Hybrid Force-Position Control with Force Awareness for Contact-Rich Manipulation. arXiv.
33. NVIDIA (2026). Cosmos3-Super Model Card. Hugging Face.
34. Scott Fujimoto et al. (2018). Addressing Function Approximation Error in Actor-Critic Methods. ICML 2018.
35. Jonathan Ho et al. (2020). Denoising Diffusion Probabilistic Models. NeurIPS 2020.
36. Scott Reed et al. (2022). A Generalist Agent. Transactions on Machine Learning Research.
37. Nur Muhammad Mahi Shafiullah et al. (2022). Behavior Transformers: Cloning k Modes with One Stone. NeurIPS.
38. Mohit Shridhar et al. (2022). Perceiver-Actor: A Multi-Task Transformer for Robotic Manipulation. CoRL.
39. Siddhant Haldar et al. (2024). BAKU: An Efficient Transformer for Multi-Task Policy Learning. NeurIPS 2024 / arXiv.
40. Taowen Wang et al. (2024). Exploring the Adversarial Vulnerabilities of Vision-Language-Action Models in Robotics. Primary publication.