RoboTwin 2.0: A Scalable Data Generator and Benchmark with Strong Domain Randomization for Robust Bimanual Robotic Manipulation
1. Paper overview
In one sentence: RoboTwin 2.0 uses simulation-tested programs and randomized demonstrations to improve bimanual policy robustness, while broad task coverage and reliable visual error diagnosis remain unresolved. identitymotivationpipelinecode-resultsall-task-coderobustnessreal-results
| At a glance | What to know |
|---|---|
| Research problem | Source description Collecting diverse dual-arm demonstrations is expensive. The authors identify three simulation bottlenecks: weak automatic quality control, overly clean scenes and grasp strategies that ignore robot kinematics. RoboTwin 2.0 addresses the data pipeline rather than proposing a new learned dynamics model. motivationpipeline |
| Core mechanism | |
| A key reported result | Real-world transfer under unseen backgrounds and clutter: 10 clean real + 1,000 synthetic: 42.0%; 1,000 synthetic only: 29.5%. Average executed-task success. RDT on COBOT-Magic; Stack Bowls, Handover Block, Pick Bottle and Click Bell; Table 4’s unseen/cluttered configuration. 10 clean real demonstrations: 9.0%. Gains are 33.0 and 20.5 percentage points, approximately 367% and 228% relative, respectively. The headline is configuration-specific; synthetic-only seen-background cells are unreported. real-resultsmotivation |
| Reading caution | Reader analysis The observer diagnostic reports accuracy 0.431 and localization in only 12 of 40 recognized failures. Its confusion counts imply success-positive labels, conflicting with prose interpreting recall as failure detection. Missed orientations and invisible grasp parameters remain documented failure modes. observer |
Core contributions
- Source description
The framework combines feedback-driven program repair, five-axis domain randomization and embodiment-aware grasp candidates, and supplies a benchmark separating clean training from randomized evaluation. pipelinerepairrandomizationgrasp-methodbenchmark
Figure 2. Two stages connect program synthesis to robust policy learning. Original paper, p. 3 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Start with the toy-car-and-basket instruction at upper left. RoboTwin-OD supplies object information and the API library supplies reusable manipulation operations. Inside the blue box, follow Code to Exec to Images and Error Feedback, then the return through Observation Retrieval and the MLLM. This is a program-revision loop. The right-hand strip shows expert execution, while the middle strip illustrates clutter, background, lighting, height and instruction variation. The large downward training arrow connects these demonstrations to the bottom policy illustration. The bottom’s unseen-scene label communicates the intended generalization outcome; it is not a future-image prediction target. pipelinerepairobjectsrandomization
What it supports. The mechanism separates generating expert behavior from fitting a policy to demonstrations. Object geometry and APIs carry manipulation structure; simulated feedback improves programs; randomized observations broaden the training distribution. This makes RoboTwin 2.0 a data-generation framework that can serve multiple downstream policy architectures.
Where the evidence stops. The figure does not establish a jointly trained world/action network or guarantee expert quality. The annotations, skill library and simulator remain prerequisites, and program validation has a finite, imperfect repair budget.
2. Motivation
2.1 The problem and the proposed response
Collecting diverse dual-arm demonstrations is expensive. The authors identify three simulation bottlenecks: weak automatic quality control, overly clean scenes and grasp strategies that ignore robot kinematics. RoboTwin 2.0 addresses the data pipeline rather than proposing a new learned dynamics model. motivationpipeline
2.2 What this reading follows
A robot can succeed on a clean demonstration table and still fail when the background, clutter or grasp geometry changes. RoboTwin 2.0 addresses that gap by building a data engine around annotated objects, reusable manipulation APIs and language-model-generated programs. Programs are tested and repaired in simulation before supplying demonstrations for downstream policies. The important reading distinction is between generating a successful expert program, learning a robust policy from its trajectories and transferring that policy to real hardware. The paper tests all three, but on different task sets and with different denominators. This edition follows the supplied August 2025 arXiv v2 and preserves its protocol inconsistencies. identitymotivationpipelinecode-resultsall-task-coderobustnessreal-results
3. Research context
We place the paper in the collection through its world–action interface. The catalog labels and the reading’s assessment are shown separately.
| Catalog dimension | Recorded classification |
|---|---|
| Major category | Datasets |
| Architecture | Not applicable |
| Prediction paradigm | Not applicable |
| Quadrant | Not applicable |
3.1 Evidence-based assessment
Supports the recorded classification
The catalog’s Datasets category fits the asset library, synthetic demonstrations and manipulation benchmark. Architecture, prediction paradigm and quadrant remain not applicable: simulation feedback and code synthesis do not establish a single learned world-action model, joint future/action prediction or inverse dynamics. pipelineobjectsdatasetbenchmark
This is the collection’s architectural analysis, not a new related-work survey. Benchmark comparisons and their protocols appear in Section 6.
4. Problem formulation
4.1 Inputs and outputs
| Inputs | Outputs |
|---|---|
|
|
4.2 Equations and their role
5. Method in detail
5.1 Turn object annotations into reusable expert behavior
Begin with the manipulation interface, because it explains what the language model is allowed to leave to the simulator. RoboTwin-OD annotates functional points, placement points, grasp points and axes. A generated program can therefore ask for a grasp or placement relative to an object instead of specifying every joint movement. The printed shoe example obtains an object pose, selects an arm, calls grasp and placement functions, and records intermediate observations. Embodiment adaptation then searches among candidate grasp directions and perturbed poses using motion planning. Reusing the task program across arms consequently does not mean replaying one robot’s joint trajectory on another. The demonstration generator still depends on valid annotations, geometric APIs and feasible planning. Successful code synthesis and successful low-level execution are separate requirements that the feedback loop attempts to connect. objectsgrasp-methodcode-examplerepair
Figure 3. Execution feedback and visual diagnosis repair a task program. Original paper, p. 4 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Read the top path from task information, API list and function examples into the Code Agent, then Program and Task Exec. The explicit Run ×10 label means each revision receives a batch of simulated trials. The pass branch is labeled Success Rate >0.5, consistent with Appendix G.1’s threshold above 50%. Below, execution history records distinct errors, including grasp failures and incorrect placement. The lower route labels error selection and visual observation before the repair path returns to the agent. The feedback changes the executable program, not the weights of the downstream manipulation policy. repaircode-metricsobserverobserver-cost
What it supports. The design combines a numerical execution signal with an attempt to identify the failing step. That distinction matters when a program executes syntactically but places an object incorrectly. However, the appendix’s observer study reports only 30% localization among correctly recognized failures, so diagnosis is a demonstrated weakness rather than a solved component.
Where the evidence stops. The failure branch says Iterations >5; Section 2.1 says five consecutive refinements. The counting convention is unresolved. Appendix F also describes the observer as failure-triggered and optional, qualifying the main text’s broader observation description.
5.2 Ask what survives clean downstream adaptation
The robustness experiment asks a stronger question than whether random-looking training images can be fitted. RDT and Pi0 first receive clean or randomized pretraining demonstrations, then the adapted variants receive clean demonstrations for downstream tasks. Testing returns to randomized scenes. A reader interpretation is that useful invariances must survive the clean adaptation stage if randomized pretraining still helps. Table 3’s reported means support that possibility, while its mixed task-level outcomes prevent a universal claim. The experiment also bundles visual, spatial and linguistic changes, so it cannot identify the active ingredient. Reproduction requires resolving the stated five unseen tasks versus eight table rows and clarifying baseline adaptation. The prompt’s train/evaluation language split helps specify intended variation, but is not evidence that semantically similar descriptions never cross that split. robustnessrandomizationtraining-settingslanguage-splits
5.3 Keep the success denominators attached to each claim
There are several different notions of success in this paper. Code ASR averages executions and candidate programs across tasks; best-five selection changes that population. Grasp-adaptation results measure whether expert programs can collect trajectories across embodiments. The policy benchmark asks whether learned controllers succeed after limited clean demonstrations, and the physical study tests four tasks under background/clutter shifts. None of these denominators is interchangeable. This is why the 71.3% code result must be paired with its ten-task subset and the 43.34% full-task result, while the physical 42.0% must retain its unseen-background, cluttered configuration. The observer’s weak diagnostic results further show that an improved pipeline average does not prove reliable error attribution. Together, these distinctions locate the evidence for useful synthetic data without treating automation, robustness and transfer as a single solved problem. code-metricscode-resultsall-task-codegrasp-resultsbenchmarkreal-resultsobserver
5.4 Training and inference
During training
Section 4.3 compares clean versus randomized pretraining on 9,600 trajectories from 32 tasks, followed by 50 clean demonstrations per downstream task. RDT uses 100,000 pretraining and 10,000 fine-tuning steps; Pi0 uses 100,000 and 30,000. The text says five unseen tasks, whereas Table 3 contains eight. It also describes baseline weights as un-fine-tuned, leaving their relationship to downstream adaptation unclear. robustnesstraining-settings
The separate 50-task benchmark trains each policy on 50 clean demonstrations per task. RDT/Pi0 start from released weights; ACT, DP and DP3 use their stated training recipes. No new policy loss, joint future/action objective or module-freezing schedule is specified for RoboTwin itself. benchmarktraining-settingspipeline
During inference
Program synthesis and simulated repair occur during expert data generation. Downstream deployment uses the trained policy: real-world experiments run RDT on COBOT-Magic. These experiments measure executed manipulation success, not predicted-video quality or inference-time search through a learned world model. pipelinereal-results
The VLM observer is optional and described in Appendix F as invoked on execution failure, qualifying the main text’s broad description of observation across trials. Generated-code token counts exclude its separately estimated observation cost. repairobserver-costcode-results
5.5 Implementation flow
- Ground programs in object affordances
Object annotations expose placement, functional and grasp points plus axes. Assets comprise 534 in-house reconstructions, 153 Objaverse objects and 44 articulated PartNet-Mobility instances. These geometric interfaces reduce how much low-level manipulation code the language model must generate. objectspipeline
- Generate, execute and repair
DeepSeek-V3 synthesizes API-based Python programs. Each iteration runs a program ten times; execution logs and moonshot-v1-32k-vision-preview diagnostics inform repair. Success must exceed 50%. The prose allows five consecutive refinements, but Figure 3 labels failure at iterations >5; counting conventions are unclear. repaircode-metrics
- Adapt feasible grasps
Candidate poses span approach directions and grasp axes, with reachability-biased angular perturbations and parallel motion-planning attempts. Curobo supports embodiment-specific planning; the expert program operates through object-centric APIs rather than copying identical joint trajectories between robots. grasp-methodcode-example
- Diversify demonstrations
Randomize clutter, textures, lighting, height and instructions. Distractors resembling targets are excluded, limiting ambiguity. The texture library contains 11,000 filtered images; height varies up to 3 cm. Language generation prescribes 50/10 training/evaluation templates and 12/3 descriptions per object. randomizationtraining-settingslanguage-splits
6. Experiments & results
RoboTwin 2.0 turns task descriptions, annotated objects and manipulation APIs into simulation-tested expert programs, then generates randomized demonstrations for bimanual policy learning. Its value lies in data construction and evaluation: real-world transfer improves in the tested settings, while broad code-generation coverage and reliable visual error diagnosis remain incomplete.
6.1 Read the original evidence
Table 4. Real-world transfer gains depend on the test configuration. Original paper, p. 10 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. First select background type and clutter status, then compare training columns within that same row. All results use RDT on COBOT-Magic. The first column uses 10 clean real demonstrations; the next adds 1,000 randomized synthetic trajectories; the final column uses synthetic data alone. Slashes mark omitted seen-background tests for the synthetic-only setting, not zero success. At the bottom, each average aggregates four tasks within one configuration. The green additions are absolute changes from the real-only baseline, despite being printed with percent signs. Preserve that denominator before comparing them with the abstract’s much larger relative percentages. real-resultsmotivation
What it supports. For unseen backgrounds with clutter, mixed training reaches 42.0% versus 9.0% real-only, a 33-point gain or about 367% relative improvement. Synthetic-only training reaches 29.5%, a 20.5-point gain or about 228% relative. These are executed robot results, but the large relative numbers partly reflect the low baseline.
Where the evidence stops. The study covers four tasks on one physical platform and gives no trial counts or uncertainty. Some individual settings regress, and mixed training increases data quantity, so it does not isolate domain randomization from additional demonstrations.
Table 5. A clean-training benchmark exposes a persistent robustness gap. Original paper, p. 11 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Each policy has paired Easy and Hard columns. Training stays fixed at 50 clean demonstrations per task; evaluation changes from clean scenes to randomized conditions, with 100 rollouts per task on Aloha-AgileX. This differs from the randomized-pretraining experiment in Table 3. The ellipsis belongs to the paper’s own subset table, and the averages match the full 50-task table in Appendix K; they are not averages of only the visible rows. Compare within each pair to study distribution shift, then compare policies while remembering that DP3 receives segmented three-dimensional observations. benchmarktraining-settings
What it supports. DP3 has the highest Easy mean, 55.2%, but falls to 5.0% on Hard. Pi0 leads Hard at 16.3%, from 46.4% on Easy; RDT falls from 34.5% to 13.7%. Thus good clean-scene imitation and resilience to randomized scenes remain distinct capabilities even among the stronger policies.
Where the evidence stops. These are simulation scores with differing policy inputs and pretraining histories. DP3 benefits from ideal point clouds and precise segmentation. The table cannot establish a modality-controlled architectural ranking or predict the four-task real-world results directly.
6.2 Results and evaluation conditions
| Task & protocol | Reported result | Comparison & interpretation |
|---|---|---|
| Expert code generation on ten shared tasks RoboTwin 1.0/2.0 shared-task simulation subset; identical named feedback configurations. | R2.0 MM FB: 71.3%; 78.6%; 1.76. ASR; Top5-ASR; CR-Iter | R2.0 Vanilla/FB ASR: 62.1/66.7%; R1.0 MM FB: 63.9%, CR-Iter 2.42. Within R2.0, multimodal feedback adds 4.6 percentage points over log feedback. The abstract’s 10.9-point difference corresponds to R1.0 FB (60.4%), not the matched MM FB baseline. code-resultscode-metricsmotivation |
| Expert code generation across all 50 tasks Appendix G.3, R2.0 MM FB on the full supported task set. | 43.34%. Average success rate | The ten-shared-task subset reaches 71.3%; these are different task populations. Automation is substantially less reliable on the broader suite; multiple tasks have zero reported success. all-task-codecode-results |
| Embodiment-aware expert data collection 50 tasks, five embodiments; R1.0 pipeline without grasp augmentation versus R2.0. | Table 2: 60.5%, versus 52.2%; Piper 25.1%, versus 2.4%. Reported average success rate | Franka 67.2% versus 67.3%; UR5 57.1% versus 57.6%. Benefits concentrate in constrained embodiments. Appendix L has conflicting R1.0 means, so precise gains are table-specific, not reconciled estimates. grasp-resultsgrasp-method |
| Robustness after synthetic pretraining Table 3, domain-randomized simulation evaluation with clean downstream adaptation specified for adapted variants; baseline adaptation and the five/eight task discrepancy remain unresolved. | Randomized pretraining: RDT 24.8%; Pi0 29.1%. Reported average task success | Baseline RDT/Pi0: 18.8/22.5%; clean pretraining: 14.6/24.9%. Randomized pretraining improves reported means, but not every task. These results do not isolate individual randomization axes. robustness |
| Real-world transfer under unseen backgrounds and clutter RDT on COBOT-Magic; Stack Bowls, Handover Block, Pick Bottle and Click Bell; Table 4’s unseen/cluttered configuration. | 10 clean real + 1,000 synthetic: 42.0%; 1,000 synthetic only: 29.5%. Average executed-task success | 10 clean real demonstrations: 9.0%. Gains are 33.0 and 20.5 percentage points, approximately 367% and 228% relative, respectively. The headline is configuration-specific; synthetic-only seen-background cells are unreported. real-resultsmotivation |
| Clean-to-randomized benchmark generalization 50 Aloha-AgileX tasks; 50 clean training demonstrations/task; 100 evaluation rollouts/task under Easy and Hard conditions. | Pi0 46.4 / 16.3%; RDT 34.5 / 13.7%; DP3 55.2 / 5.0%. Average success, Easy / Hard | ACT 29.7 / 1.7%; DP 28.0 / 0.6%. All methods degrade under randomization. DP3’s Easy lead uses ideal segmented point clouds, and the best Hard mean remains low. benchmarktraining-settings |
6.3 Ablations and diagnostic examples
Read component removals and qualitative examples within their stated evaluation conditions.
Table 1. Multimodal feedback improves the shared-task average, with a separate observation cost. Original paper, p. 8 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Compare rows within each version before comparing across versions. Vanilla generates once; FB repairs using execution logs; MM FB adds vision-language diagnostics. ASR averages task success across the ten shared tasks. Top5-ASR selects the five highest-performing programs per task, so it answers a best-candidate question rather than ordinary average performance. CR-Iter measures refinement until the threshold or budget, and Token counts generated policy code. Read the final three rows as the closest comparison of feedback modes within RoboTwin 2.0. The upper three rows additionally change the underlying version and API design. code-resultscode-metricscode-per-taskall-task-codeobserver-cost
What it supports. R2.0 rises from 62.1% ASR in Vanilla to 66.7% with logs and 71.3% with multimodal feedback; MM FB adds 4.6 percentage points over FB. It reports 78.6% Top5-ASR and 1.76 iterations. Improvement is not universal: Appendix G.2’s handover task falls from 50% with FB to 27% with MM FB.
Where the evidence stops. This is the ten-task subset; all-task ASR is 43.34%. Token is not total inference cost: Appendix F separately estimates 6,894 tokens per observer call. Candidate count and uncertainty are unspecified, limiting efficiency and reliability comparisons.
Table 3. Randomized pretraining improves reported averages but has task-specific regressions. Original paper, p. 9 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Use the last four columns to compare clean and randomized pretraining within each VLA backbone. Section 4.3 describes 9,600 demonstrations from 32 pretraining tasks, followed by 50 clean demonstrations per downstream task and evaluation under randomization. The RDT and Pi0 columns are the paper’s baselines; their adaptation status is not consistently explained by the prose. Then inspect individual rows: Stack Bowls Two benefits for both backbones, while Pi0 on Pick Dual Bottles is lower with randomized pretraining than with clean pretraining. The average row summarizes a heterogeneous response, not an improvement on every manipulation behavior. robustnesstraining-settings
What it supports. The reported randomized-pretraining means are 24.8% for RDT and 29.1% for Pi0, compared with 14.6% and 24.9% after clean pretraining. The result supports the usefulness of pretraining diversity under these test conditions. It does not establish that every randomization axis helps or that clean adaptation always preserves robustness.
Where the evidence stops. The text specifies five unseen tasks, but this table lists eight. Its ACT/DP averages also differ from simple displayed-row averages. The crop preserves these source inconsistencies; the VLA means are reported with the unresolved protocol boundary.
7. Analysis & limitations
7.1 What the evidence leaves open
The observer diagnostic reports accuracy 0.431 and localization in only 12 of 40 recognized failures. Its confusion counts imply success-positive labels, conflicting with prose interpreting recall as failure detection. Missed orientations and invisible grasp parameters remain documented failure modes. observer
Source inconsistencies remain unresolved: Table 3 lists eight tasks after describing five and its ACT/DP means do not match displayed-row arithmetic; Tables 2 and 11 disagree on R1.0 embodiment averages. The report retains source-specific values rather than combining them. robustnessgrasp-results
Four real tasks on one platform do not establish arbitrary cross-embodiment physical transfer. Table 4 lacks trial counts and uncertainty; mixed-data training also changes data quantity. Neither its gains nor Table 3 identify which randomization axis causes improvement. real-resultsrobustness
7.2 Questions for discussion
- Does visual feedback still improve code success when total tokens and simulator executions are matched?
- Which randomization axes transfer after clean adaptation, and which create task-specific regressions?
- How much does verified simulator state improve observer error localization compared with images alone?
8. Reproducibility audit
8.1 Requirements and known gaps
Required resources include annotated assets, skill APIs, simulator/planner configuration, named language/vision models and policy checkpoints. Appendix D specifies RDT pretraining on 8 GPUs and fine-tuning on 4, batch 16 per GPU, but omits GPU models, software versions and optimizer details. objectsgrasp-methodcode-metricstraining-settings
Other stated recipes are ACT: 6,000 epochs, batch 8, chunk 50, temporal aggregation; DP: 600 epochs, batch 128, horizon 8; DP3: 3,000 epochs, batch 256, horizon 8, 1,024 segmented points. Match these observation advantages before interpreting policy rankings. training-settingsbenchmark
Exact candidate-program counts, detailed randomization distributions, camera angular bounds, full dataset allocation and asset licensing remain unspecified in the supplied paper. Resolve these and the downstream task split before claiming replication. A useful proposed check holds data count fixed while comparing clean and randomized pretraining. code-metricsrandomizationreal-resultsdatasetrobustness
8.2 Proposed reproduction checks
The following checks are proposals motivated by the paper. They have not been run as part of this reading.
Check 1: Does visual diagnosis help under a matched repair budget?
Reader-proposed check, not performed: use the ten shared code-generation tasks, fixed initial programs and paired simulator seeds. Compare execution-log feedback, multimodal feedback, and a control that receives a diagnostic shuffled from another failed trial. Give all arms identical simulator execution and refinement budgets; separately run a total-token-matched comparison that counts images and observer outputs. Declare the iteration-count convention and candidate count. Evaluate final programs on fresh trials, reporting per-task ASR and localization against manually verified failure steps. Multimodal feedback should beat both controls; disappearance of its gain under budget matching, or equal performance with shuffled diagnoses, would weaken the claim that accurate visual attribution drives repair. repaircode-resultscode-metricscode-per-taskobserverobserver-cost
Check 2: Separate pretraining diversity from extra data and language overlap
Reader-proposed check, not performed: construct paired clean and randomized pretraining sets with the same 32 tasks, 300 trajectories per task, policy initialization and training budget. Add visual/spatial-only and language-only randomization arms. Predeclare the downstream task identities to resolve the paper’s five/eight mismatch, then give every adapted model the same 50 clean demonstrations per task. Freeze disjoint evaluation scenes and audited instruction pools; report per-task success, seed variation and confidence intervals under clean and randomized evaluation. A retained advantage at matched data volume would support a diversity effect; gains confined to overlapping language or a few tasks would narrow the generalization claim. robustnessrandomizationtraining-settingslanguage-splitsbenchmark
8.3 Reading coverage
Visual audit: Visually inspected the title/author/version block; all Figures 1–12 and Tables 1–11; method and success-rate equation pages; Appendix C–D training/randomization settings; Appendix G observer diagnostics and printed code examples; Appendix H–I language specifications; and Appendix J–L benchmark/embodiment details. All six final original crops were individually viewed and retain their complete graphic/table bounds and headers without surrounding body prose. Figure 3’s >5 failure label was checked against the five-refinement prose, and Table 3/Table 11 discrepancies remain explicit. Reference-only pages 13–15 were read in the complete text but not rendered for this visual pass. No separate supplement, linked codebase, live leaderboard or reproduced experiment is included.
PDF pages inspected for this edition: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 16, 17, 18, 19, 20, 21, 22, 23, 24. Appendix coverage: reviewed.
Original figures and tables remain the work of the source’s authors. Extractions preserve their scientific content; any HTML wrapper layout is disclosed with each figure. The surrounding reading notes are our own.
Text reading scope & known omissions
- Title and author block; Abstract
- 1 Introduction
- 2 Method: 2.1 expert code generation, 2.2 domain randomization, 2.3 grasp adaptation
- 3 Data Generator, Benchmark and Large Scale Dataset: 3.1–3.2
- 4 Experiments: 4.1–4.5
- 5 Related Work: 5.1–5.3
- 6 Conclusion; 7 Acknowledgments
- References
- Appendices A–B: contributions and benchmark comparison
- Appendices C–D: randomization and policy training
- Appendices E–F: embodiment combinations and codebase improvements
- Appendix G.1–G.5: metrics, task results, observer diagnosis and printed code examples
- Appendices H–I: language examples and generation prompts
- Appendices J–L: benchmark setting, full benchmark and embodiment results
Outside the original text pass
- Text extraction does not reconstruct figure images; inspect the retained PDF for figures and equation/table layout.
- Separate supplemental material availability has not been fully verified.
- Identity/version scope: the matching title and 26-author list are verified on arXiv:2506.18088v2, dated 27 August 2025 (identity). The catalog lists ICML 2026, but no venue edition or revision chain was supplied; equivalence to that edition is unverified.
- Acquisition noted that text extraction does not reconstruct figure images. This gap was resolved by inspecting the retained PDF, including all numbered figures and tables and the equation layout.
- Separate supplemental material availability has not been fully verified. No separate supplement was supplied.
- All seven supplied text chunks were read individually, covering all 24 PDF pages. Pages 1–12 and 16–24 were visually inspected; reference-only pages 13–15 were read as text.
- Linked code, documentation, datasets and leaderboard were not opened. Printed code examples were read as source text only; no code was executed and no experiments were reproduced.
The visual audit above records the subsequent illustrated pass.
8.4 Traceable evidence
identityPDF p. 1, title, author/affiliation block and arXiv margin stamp
The full title and all 26 authors match the supplied catalog. The artifact identifies itself as arXiv:2506.18088v2 [cs.RO], 27 August 2025. Its title page does not establish the catalog’s ICML 2026 edition.
Go to primary source ↓motivationPDF pp. 1–2, Abstract and Section 1
The authors motivate automated bimanual demonstration generation by the cost of real data and insufficient task, scene and embodiment diversity. The abstract’s real-world relative gains require the configuration-specific denominators in Table 4.
Go to primary source ↓pipelinePDF p. 3, Section 2 and Figure 2
Task language, RoboTwin-OD and a skill API feed code synthesis with simulated execution feedback; generated trajectories receive domain randomization and train downstream manipulation policies. No new learned future-state predictor is specified.
Go to primary source ↓repairPDF pp. 3–4, Section 2.1 and Figure 3
The code agent receives task information, APIs, examples and constraints. Each iteration executes a program ten times; logs and VLM diagnostics support repair. Figure 3 labels success >0.5 and failure at iterations >5, whereas the prose says five consecutive refinements. The exact iteration-count convention is unresolved.
Go to primary source ↓randomizationPDF pp. 5–6, Section 2.2 and Figure 4
Randomization covers distractors, textures, lighting, tabletop height and trajectory language. Collision-aware clutter sampling excludes distractors resembling target objects. A human-filtered library contains 11,000 textures, from 20,000 generated candidates. Language combines templates and object descriptions.
Go to primary source ↓objectsPDF pp. 6–7, Section 3.1 and Figure 7
RoboTwin-OD has 731 objects in 147 categories: 534 reconstructed in-house, 153 from Objaverse, and 44 articulated PartNet-Mobility instances. Annotations include placement/functional/grasp points, grasp axes and 15 descriptions per object, with human verification of descriptions.
Go to primary source ↓grasp-methodPDF p. 6, Section 2.3, Figures 5–6; PDF p. 17, Appendix E and Figure 11
Object-centric candidate poses, preferred approach directions, reachability-biased angular perturbations and parallel planning adapt grasps to embodiments. Appendix E identifies Curobo and support for Franka, Piper, UR5, ARX-X5 and Aloha-AgileX, with heterogeneous arm pairings.
Go to primary source ↓datasetPDF p. 7, Section 3.2 and Figure 8
The paper describes a 50+ task suite and reports over 100,000 pre-collected trajectories across 50 tasks and five robot platforms. It provides resource links but no complete per-task/per-embodiment allocation or asset licensing terms here.
Go to primary source ↓code-resultsPDF p. 8, Table 1, all rows, and Section 4.1
On ten shared tasks, R2.0 Vanilla/FB/MM FB ASR is 62.1/66.7/71.3%; R1.0 is 47.4/60.4/63.9%. R2.0 MM FB Top5-ASR is 78.6%, CR-Iter 1.76 and generated-code Token 839.7. R1.0 MM FB CR-Iter is 2.42. These are code-execution metrics, not downstream learned-policy scores.
Go to primary source ↓code-metricsPDF p. 18, Appendix G and G.1, unnumbered success-rate equations
DeepSeek-V3 generates programs; moonshot-v1-32k-vision-preview provides visual diagnostics. Program success averages over executions, task success over programs, ASR over ten tasks and Top5-ASR over the five highest-performing programs per task. CR-Iter stops above 50% or at the budget. The number N of candidate programs is not specified.
Go to primary source ↓code-per-taskPDF p. 18, Appendix G.2, Table 8, handover_block row
On handover_block, R2.0 FB reaches 50% but R2.0 MM FB reaches 27%; R1.0 MM FB reaches 45%. Thus average improvement does not imply improvement on every task.
Go to primary source ↓all-task-codePDF p. 19, Appendix G.3, Table 9
R2.0 MM FB averages 43.34% across all 50 listed tasks, with multiple zero-success tasks. This broader evaluation must remain separate from Table 1’s ten-task 71.3%.
Go to primary source ↓observerPDF pp. 19–20, Appendix G.4, error detection, localization and failure modes
The observer diagnostic uses 130 sequences: 101 failures and 29 successes. Reported TP/FP/TN/FN are 16/61/40/13; accuracy is 0.431 and F1 is 0.302. Localization succeeds in 12 of 40 correctly recognized failures (30%). Counts imply success is the positive class, conflicting with the prose’s failure-recall interpretation. Failure modes include missed orientation errors and invisible grasp-axis issues.
Go to primary source ↓grasp-resultsPDF pp. 8–9, Section 4.2 and Table 2; PDF p. 24, Appendix L and Table 11
Table 2 reports average data-collection success 52.2% to 60.5%; Piper 2.4% to 25.1%; Aloha 65.1% to 78.8%. Table 11 says identical expert programs are used across embodiments, but reports different R1.0 averages: Aloha/ARX/Franka/Piper/UR5 = 65.3/68.8/67.6/2.3/57.7%, versus Table 2’s 65.1/68.6/67.3/2.4/57.6%. R2.0 means agree; the R1.0 differences are unexplained.
Go to primary source ↓robustnessPDF p. 9, Section 4.3 and Table 3
The protocol describes 9,600 pretraining trajectories from 32 tasks, clean versus randomized, then 50 clean demonstrations per downstream task. Prose says five unseen tasks; the table lists eight. The description of released baseline weights without additional fine-tuning leaves baseline adaptation ambiguous. Reported RDT averages are 18.8/14.6/24.8% for baseline/clean/randomized; Pi0 averages are 22.5/24.9/29.1%. Table 3’s ACT and DP means do not reproduce the simple averages of their displayed rows.
Go to primary source ↓real-resultsPDF pp. 9–10, Section 4.4, Figure 10 and Table 4
RDT on COBOT-Magic performs four tasks under seen/unseen backgrounds with/without clutter. Training uses 10 clean real demonstrations, those demonstrations plus 1,000 randomized synthetic trajectories, or 1,000 synthetic trajectories alone. Unseen/cluttered averages are 9/42/29.5%; unseen/uncluttered are 15.5/39/36.5%. Synthetic-only seen-background entries are omitted. Camera displacement is bounded by 1 cm; orientation perturbations are mentioned without an angular bound. Trial counts and uncertainty are not reported here.
Go to primary source ↓benchmarkPDF p. 11, Section 4.5 and Table 5; PDF p. 22, Appendix J and Figure 12; PDF p. 23, Appendix K and Table 10
The 50-task Aloha-AgileX benchmark trains on 50 clean demonstrations per task and evaluates 100 rollouts under Easy/Hard conditions. Training is identical for both conditions. Easy/Hard averages: RDT 34.5/13.7%, Pi0 46.4/16.3%, ACT 29.7/1.7%, DP 28.0/0.6%, DP3 55.2/5.0%. The authors qualify DP3’s advantage by perfect point clouds and clean segmentation. Figure 12’s generic caption repeats Figure 11’s title, while Appendix J and the diagram identify the benchmark setting.
Go to primary source ↓training-settingsPDF p. 16, Appendices C–D
Height variation is up to 3 cm. Section 4.3 RDT pretraining uses 100,000 steps, 16 samples/GPU on 8 GPUs; single-task fine-tuning uses 10,000 steps on 4 GPUs at the same per-GPU batch. Pi0 uses 100,000 pretraining steps and 30,000 fine-tuning steps, batch 32. ACT uses chunk 50, batch 8, one GPU, 6,000 epochs and temporal aggregation; DP uses 600 epochs, batch 128, horizon 8; DP3 uses 3,000 epochs, batch 256, horizon 8 and 1,024 segmented points. GPU models, optimizer details and software versions are not specified.
Go to primary source ↓language-splitsPDF pp. 21–22, Appendices H–I, examples and Listing 3
The prompt requests 60 task templates split 50/10 for training/evaluation and 15 object descriptions split 12/3. Half of instructions should omit arm references. These are prescribed generation/splitting rules; no semantic-deduplication audit is reported.
Go to primary source ↓observer-costPDF pp. 17–18, Appendix F and Table 7
The VLM observer is described as optional and triggered on failure. Its estimated cost on three representative tasks is 6,894 tokens per observation, assuming 1,024 tokens per image. This differs from Table 1’s generated-policy-code token count and is not a measured complete pipeline budget.
Go to primary source ↓code-examplePDF pp. 20–21, Appendix G.5, Listings 1–2
The generated place_shoe program explicitly records intermediate camera observations, obtains object/functional-point poses, selects an arm and calls grasp/place/motion APIs. The human example is shorter. Printed examples establish program structure, not independent execution or codebase availability.
Go to primary source ↓8.5 Primary sources
RoboTwin 2.0: A Scalable Data Generator and Benchmark with Strong Domain Randomization for Robust Bimanual Robotic Manipulation ↗
PDF · 12,095 extracted words
Source fingerprint
316ae82a97968e1a2d88540665401645a190d2699d7d8652e8fc0053ba609bda