Pith. sign in

REVIEW 3 major objections 5 minor 30 references

Prompt-to-Product: Generative Assembly via Bimanual Manipulation

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Prompt-to-Product claims to turn natural-language prompts into physically buildable and physically constructed LEGO assemblies, coupling an LLM-based designer with a bimanual robot builder through a shared structural-stability oracle.

desk verdict A real bimanual text-to-LEGO pipeline with honest limitations; the main caveat is that the stability oracle gating the whole pipeline is only validated by four human-assisted builds. read the letter →

arxiv 2508.21063 v1 pith:4WT46Q5J submitted 2025-08-28 cs.RO cs.AI

Ruixuan Liu , Philip Huang , Ava Pun , Kangle Deng , Shobhit Aggarwal , Kevin Tang , Michelle Liu , Deva Ramanan
show 3 more authors
Jun-Yan Zhu Jiaoyang Li Changliu Liu
This is my paper · ORCID
classification cs.ROcs.AI
keywords prompt-to-productLEGObrickassemblybimanualmanipulationstructuralstabilityreasoninggenerativedesigntext-to-3Dgenerationassembly-by-disassemblyrobotskilllearning
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Prompt-to-Product claims to remove both expert steps between an idea and a physical assembly product: generating the design and building it. Given a natural-language prompt, the paper's design stage runs eight parallel instances of a text-to-brick model, keeps only layouts that use the available inventory and pass a per-brick stability check, and renders the best candidate for the user. The construction stage then has two robot arms snap the bricks together in an order recomputed so that every partial structure is stable under the robot's own forces, with camera-based checks at each step. In a user study with 21 participants, the full pipeline significantly reduced self-reported physical and mental effort compared with manual creation, and the robot assembled four test products on the first attempt. If these results hold, the paper establishes a working end-to-end path from text to tangible modular objects.

What carries the argument

The shared load-bearing mechanism is the structural-stability oracle fstability(B), which solves a nonlinear force-balance program over all connection forces, friction, and gravity to assign every brick a stability score si > 0 if it can reach static equilibrium. The oracle is used in three places: it prunes unstable candidates after BrickGPT generates them; it rejects disassembly steps that would leave a partial structure unstable during assembly-sequence search; and, with virtual bricks of +1 kg and -1 kg added to model the placing hand and a supporting hand, it checks whether the partially built structure survives the robot's own actions. This single oracle is what couples the creative an

What would settle it

Have the robot attempt to build a set of, say, fifty structures the oracle scores as stable and fifty it scores as unstable using the same inventory and skills, then record collapse rates: if stable-scored structures frequently fall or unstable-scored ones stand, the oracle's threshold is not predictive. A more targeted test is to measure the end-effector force during real Place-Down and Support-Bottom actions and compare it with the virtual ±1 kg bricks; a large mismatch would indicate the dynamic-stability checks are protecting the wrong failure modes.

Watch

Extended reading notes

Core claim

On its own terms, the paper's claim is that the feasible space B(u | I, A, S)—prompts whose generated brick layouts satisfy inventory limits, system skills, and stepwise stability—can be navigated automatically, and the paper supports this with a working system rather than a theoretical guarantee. The design stage, BrickGPT, generates brick layouts as text and uses brick-by-brick rejection sampling plus physics-aware rollback to keep every output stable; the construction stage, BrickMatic, replans the generation order by assembly-by-disassembly, models each robot placement as a heavy virtual brick in a force-balance solver, and executes the resulting temporal plan graph with two arms and eye

Load-bearing premise

The pipeline's guarantees stand on the stability oracle accurately predicting which real brick structures collapse, and on the assumption that representing the robot's placing hand as a 1 kg virtual brick and its support hand as a -1 kg virtual brick captures the forces that actually act during construction.

Editorial extensions

If this is right

  • Users without assembly expertise can go from a text idea to a finished brick product; the user study reports significantly lower physical and mental effort with the full pipeline than with manual creation.
  • Perception-augmented bimanual assembly—checking every pick, place, and anomaly and pausing for human recovery instead of restarting—is what lets the system finish four designs in one attempt, where the comparison dual-arm system failed on one and needed multiple restarts on the others.
  • Running multiple generative heads with stability rollback raises the share of prompts that yield a buildable design from 19.4% to 66.6%, so inference-time filtering is an effective way to enforce physical constraints on a text-to-brick model.
  • Generated designs are not just end-state stable: the assembly-by-disassembly step reorders bricks so every intermediate structure is stable, which is why a design from the generator can actually be constructed.
  • For repeated production, users prefer robotic assembly over manual, while for a single one-off build they lean manual, indicating the pipeline's practical value is batch fabrication rather than one-off hobby assembly.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper does not test this, but the design/construction split means the stability oracle is the only physical coupling; swapping it for a different feasibility model would plausibly let the same designer target other modular materials, kits, or even manual build instructions.
  • A third of open-world prompts still produce no buildable design; a natural next step would be to use the stability score as a training objective rather than a post-hoc rollback filter, which could shrink the failure rate without more parallel samples.
  • The +1 kg/-1 kg virtual bricks used to model robot forces are chosen rather than calibrated; reading the force-torque sensors during real placement and support actions would test whether the dynamic-stability checks are conservative, permissive, or about right.
  • The user study found no significant preference between manual and generated starting designs, so the system may be most defensible as a fast scaffold that users then customize, rather than as an oracle that finalizes the design.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper describes Prompt-to-Product, a two-stage system that converts a natural-language prompt into a physical LEGO assembly. Stage 1, BRICK GPT++ (an LLM fine-tuned on StableText2Brick), generates brick layouts subject to inventory and collision checks, with physics-aware rollback and multi-head CLIP selection. Stage 2, BRICK MATIC, plans a bimanual construction sequence using assembly-by-disassembly, action masks, and APEX-MR-style temporal plan graphs, then executes it with two Yaskawa GP4 arms with custom Eye-in-Finger EOATs and a skill set including pick/place/support/handover and perception skills. The central coupling is a stability oracle from StableLEGO (Eqs. 4-6), used to certify final designs, prune intermediate structures, and model robot impacts as virtual bricks of +1kg and -1kg. Experiments report a buildable rate of 66.6% for BRICK GPT++ over 36 prompts (Table I), physical construction of four designs in one attempt each (Table II), and a 21-participant user study showing reduced effort.

Significance. If the claims hold, the paper is a worthwhile integration of generative design and bimanual manipulation for a concrete, replicable assembly domain. The strongest evidence is the physical construction of four nontrivial structures with a real dual-arm system; this distinguishes the paper from simulation-only pipelines. The staged architecture and the use of shared physics reasoning are sensible engineering contributions. The perception-skill additions (detect place/pick/anomaly/error) are a plausible reason for improved robustness over APEX-MR. However, the quantitative claims are narrower than their presentation: the buildability metric is oracle-based, the construction table has one attempt per design, and the stability oracle is uncalibrated against measured forces. These issues do not invalidate the demonstrated integrations but they materially limit the generality claimed in the abstract.

major comments (3)
  1. [Sec. III, Eqs. (5)-(6); Sec. V-C; Table I] The stability oracle f_stability is the single load-bearing gate for both design generation and construction planning, but it is never calibrated against physical outcomes. The dynamic-stability check models a place operation as a virtual brick with 1 kg mass and support as a -1 kg mass (Sec. V-C), yet the robot is instrumented with ATI FTS and the measured forces are not used to substantiate these values or the static friction capacity FT in Eq. (6). The only physical validation is the four builds in Table II, all of which are designs that the oracle presumably deemed stable. If the oracle is over-optimistic on larger or more open-ended designs, the buildable rate in Table I and the success in Table II will not transfer. Please add a calibration/validation study: for example, measure peak insertion/support forces, tune the virtual-brick masses, and test a set of designs spanning oracle-
  2. [Sec. VI-B, Table II] The construction comparison uses different success criteria. A successful build is defined as 'without manually stopping or restarting,' but the text then states that BRICK MATIC automatically pauses and requests human intervention, and continues once the failure is addressed without starting over. Thus an attempt that required one or more human interventions is still counted as a 1/1 success, while the APEX-MR baseline restarts after any failure. The reported '1/1' therefore does not demonstrate fully autonomous construction, and with n=1 per design there is no evidence of repeatability. Please report the number and type of human interventions per build, use a single success definition for both systems (e.g., fully autonomous completion vs. completion with human assistance), and provide multiple trials or at least state explicitly that these are single demonstrations.
  3. [Sec. IV-C, Table I; Sec. II-E] The central metric '% Buildable' in Table I is computed with the authors' own feasibility stack: f_stability from StableLEGO [13] and the action masks from [15]. This makes the comparison of BRICK GPT++ to BRICK GPT an oracle-level comparison, not a physical one. Since the same oracle is the thing whose accuracy is at issue (see first major comment), the 66.6% figure should be labeled as 'predicted buildable by the internal oracle' and, ideally, supported by a small physical spot-check on randomly selected designs from the 36 prompts. Without this, Table I's improvement may reflect oracle biases rather than real buildable rate.
minor comments (5)
  1. [Sec. II-B, Eq. (4)] The notation 'tau * ˙=' appears to be a typo; it should be an equality sign.
  2. [Sec. VI-A, Sec. VI-C] The full-pipeline user study used the Gazebo digital twin with physical interactions between bricks disabled, not the physical BRICK MATIC system. This is stated in Sec. VI-A but should be repeated as a limitation in Sec. VI-C so that the user-study claims about BRICK MATIC are not overread as physical-robot results.
  3. [Table II] The 'Time' column reports planning time, not total execution time. Please label it 'Planning Time' in the header or clarify in the caption.
  4. [Sec. VI-C] The statement 'manual creation time ranged from under 2 to over 7 minutes' would be more informative with a mean and standard deviation.
  5. [Sec. IV-A] The text states 'StableText2Brick ⊂ B(u | I, S)' but the notation B(u | I, S) depends on the prompt u; the inclusion should be 'StableText2Brick ⊂ ∪_u B(u | I, S)' or be phrased as 'each structure in StableText2Brick is physically buildable.'

Circularity Check

2 steps flagged · score 6.0 of 10

Physical buildability is operationally defined as passing the authors' own fstability oracle; the buildable-rate metric and the 'physically buildable' guarantee reduce by construction to that oracle, with only four physical builds as external anchor.

  1. self definitional [Sec. II-A/II-B (Eq. 1), Sec. IV-B, Sec. V-C]
    "S = {B | ∀i ∈ {1, 2, . . . , N}, si > 0}: the set of all physically stable brick designs. The physical feasibility constraint requires B ∈ S. ... Evaluating the physical feasibility (stability) is non-trivial: S = fstability(B), (1) ... the model uses the physics reasoning in Eq. (1) to verify ˆB ∈ S."

    The target predicate 'physically stable/buildable' is defined as si > 0 from Eq. (1). The same Eq. (1) is then used to filter BRICK GPT outputs (Sec. IV-B) and to gate every disassembly step via static/dynamic stability (Sec. V-C). Therefore the pipeline's claim that it produces B ∈ B(u|I,A,S) is true by construction: 'buildable' means 'passes fstability', and fstability is the filter. The paper's only independent physical grounding is the four real builds in Table II; the broad buildability claim and Table I rate are not independently established.

  2. fitted input called prediction [Sec. VI-B, Table I; Sec. V-C]
    "% Buildable: the percentage of prompts with a generated BRICK MATIC-buildable brick design. ... we model the robot place operation as a virtual brick ˆbp with heavy mass, i.e., 1kg. If support is needed, we add an additional virtual brick ˆbs with mass being −1kg."

    The headline '% Buildable' is computed using BRICK MATIC's own feasibility checks: the fstability oracle of Eq. (1) and the action mask of Sec. V-C. BRICKGPT++ is explicitly engineered to satisfy these exact checks (brick-by-brick rejection sampling and physics-aware rollback). Thus Table I largely measures how often the pipeline's internal filters accept the pipeline's own outputs; it is not a measured physical construction rate. The virtual-brick dynamic model (1 kg/-1 kg) that gates these checks is an uncalibrated assumption, not a fitted or measured quantity, so the 'buildable' prediction is forced by the same model that defines it.

full rationale

The paper's formal definition of physical stability as si>0 from fstability (Eq. 1) makes the design-generation guarantee B∈B(u|I,S) tautological: outputs are filtered by the very function that defines the property. The same oracle, imported from the authors' StableLEGO [13], is reused to label the StableText2Brick training set (Sec. IV-A), to roll back unstable generations (Sec. IV-B), and to plan the assembly sequence through static/dynamic action masks (Sec. V-C). Consequently, Table I's '% Buildable' is a self-consistency score rather than an independently verified physical success rate. The paper does provide real external evidence — four physical LEGO builds in Table II and a 21-participant user study — so the central construction claim is not wholly circular. However, those four builds are human-intervention-tolerant and are too few to validate the oracle for the 36 open-world prompts or the general 'physically buildable' claim. This is partial circularity (score 6): the main 'buildable' metric and guarantee reduce by construction to the authors' own feasibility model, with limited independent anchoring.

Assumptions & free parameters 4 free parameters · 4 assumptions · 2 invented entities

The pipeline depends on several empirically chosen or borrowed parameters: the stability solver hyperparameters alpha and beta from prior work, the measured friction capacity FT, and two ad hoc virtual-brick masses for dynamic stability. The core stability model is a domain assumption from StableLEGO, and the generative stage assumes StableText2Brick generalization. No new physical entities are proposed beyond the virtual bricks, which have no independent evidence.

free parameters (4)
  • FT (friction capacity) = measured
    A measured constant friction capacity between brick connections used as a threshold in Eq (6) to classify bricks as stable. It is an empirical input, not fit in this paper, but it determines which structures are deemed stable.
  • alpha, beta (stability solver hyperparameters) = same as in [13]
    Hyperparameters of the nonlinear program in Eq (5) taken without change from StableLEGO [13]. They influence the force distribution solution and thus the stability classification of every design.
  • Virtual brick mass for place operation = 1 kg
    In Sec V-C, a robot place operation is modeled as a virtual brick with 1 kg mass to evaluate dynamic stability. The value is chosen ad hoc and affects which assembly sequences pass the action mask.
  • Virtual brick mass for support = -1 kg
    In Sec V-C, support is modeled as a virtual brick with -1 kg mass. This ad hoc value is not calibrated against measured robot forces in the paper.
assumptions (4)
  • domain assumption Static equilibrium force balance (Eq 4) with non-negativity, non-coexistence, and Newton's third law constraints is a valid model of LEGO stability.
    The paper relies on this model from [13] to classify structures as stable or collapsing; all buildable-rate claims in Table I depend on it.
  • domain assumption The minimum-internal-friction solution to the nonlinear program (Eq 5) yields a stability score that correctly thresholds at FT.
    The stability score si in Eq (6) is derived from the solved force distribution; the paper assumes this optimization is both solvable and physically meaningful.
  • ad hoc to paper Modeling external impact as virtual bricks with heavy (1 kg) and negative (-1 kg) mass captures robot assembly forces.
    Sec V-C introduces these virtual bricks to evaluate dynamic stability in the action mask, but no calibration of the 1 kg value to actual robot forces is reported.
  • domain assumption Fine-tuned BRICK GPT on StableText2Brick generalizes sufficiently to user prompts in the ten categories.
    The generative stage assumes that the fine-tuned LLM produces useful designs for prompts similar to its training captions; the Discussion admits this degrades on open-ended prompts.
invented entities (2)
  • Virtual brick with 1 kg mass
    purpose: Models the dynamic impact of a robot place operation in the action mask stability check.
    A computational construct introduced in Sec V-C with a chosen mass that is not calibrated against measured robot interaction forces.
  • Virtual brick with -1 kg mass
    purpose: Models a support action in the dynamic stability check, allowing the planner to determine when support is needed.
    A computational construct with no physical counterpart; negative mass is used to mimic support forces and its validity is not independently tested.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Prompt-to-Product: Generative Assembly via Bimanual Manipulation." pith.science (2026). https://pith.science/paper/4WT46Q5J

@misc{pith2026250821063,
  author       = {Pith},
  title        = {Pith review of: Prompt-to-Product: Generative Assembly via Bimanual Manipulation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4WT46Q5J}},
  note         = {Machine review of arXiv:2508.21063}
}
read the original abstract

Creating assembly products demands significant manual effort and expert knowledge in 1) designing the assembly and 2) constructing the product. This paper introduces Prompt-to-Product, an automated pipeline that generates real-world assembly products from natural language prompts. Specifically, we leverage LEGO bricks as the assembly platform and automate the process of creating brick assembly structures. Given the user design requirements, Prompt-to-Product generates physically buildable brick designs, and then leverages a bimanual robotic system to construct the real assembly products, bringing user imaginations into the real world. We conduct a comprehensive user study, and the results demonstrate that Prompt-to-Product significantly lowers the barrier and reduces manual effort in creating assembly products from imaginative ideas.

Figures

Figures reproduced from arXiv: 2508.21063 by the authors.

Figure 1
Figure 1. An Overview of Prompt-to-Product. Given the user design ideas, input as text prompts, Prompt-to-Product 1) generates the assembly designs using BRICKGPT, and 2) physically constructs the assembly products with BRICKMATIC, bringing user imaginations into real products. to build them. Zhang et al. [28] transform a monolithic 3D object into an assembly by decomposing it into sub￾components. However, they assume an unli… view at source ↗
Figure 2
Figure 2. Brick Order. (a) The sequence of BRICKGPT generating the design Bˆ. (b) The assembly sequence Q planned by BRICKMATIC to physically construct the structure. The check mark indicates that the partial structure satisfies the physical feasibility constraint. BRICKGPT [22], an end-to-end approach, to generate the brick design Bˆ ∈ B(u | I, S) as Bˆ =fBRICKGPT(u), s.t. ci ∈ I, ∀i ∈ {1, 2, . . . , N}, Bˆ ∈ S, (2) where N … view at source ↗
Figure 3
Figure 3. Assembly Physics Reasoning. (a) All possible forces that could be exerted on a brick. (b) The force model F of an example structure. (c) Given a brick structure B (top), the physics reasoning solves S = fstability(B) to determine each brick’s stability score si and evaluate the structural stability (bottom). Darker color indicates higher stability. Red: collapsing bricks, i.e., si = 0. Q, BRICKMATIC leverages APEX-M… view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: BRICKGPT for Generative Assembly Design. BRICKGPT is fine-tuned on StableText2Brick [22]. At inference time, multiple BRICKGPT candidates generate multiple assembly designs in parallel, and the best design is output as the final design. stability S = fstability(B) by s…
Figure 5
Figure 5. Figure 5: BRICKMATIC Embodiment Design. Our BRICKMATIC includes two Yaskawa GP4 robots, each equipped with an FTS and an EiF EOAT, detailed in the bottom-left corner. A baseplate is placed in the middle of the workstation for the robots to construct brick assembly structures. Tw…
Figure 6
Figure 6. Figure 6: Our skill set has three major categories of skills: 1) [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 6
Figure 6. Figure 6: BRICKMATIC Skill Set. The skill set A of BRICKMATIC with the presented embodiment. 4) Detect Error: The system’s knowledge of the environ￾ment could deviate from reality due to, for instance, calibration error, tilted structures, etc. Following [24], we use the endosco…
Figure 7
Figure 7. Figure 7: BRICKMATIC Multi-Level Reasoning for Bimanual Assembly Construction. Given an assembly design, BRICKMATIC (a) reasons the assembly structure and generates a physically executable step-by-step assembly task plan Q. It then (b) reasons the tasks, distributes the assembly…
Figure 8
Figure 8. Figure 8: Brick assembly designs for comparing bimanual assembly [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Prompt-to-Product User Study Procedure. We recruit participants through public online advertisements, internal Slack channels, and physical bulletin boards. Each user completes a pre-study survey and interacts with our system. They also fill out a post-study survey in …
Figure 10
Figure 10. Figure 10: Prompt-to-Product User Study Results. Individual and mean ratings of key survey questions for BrickGPT-only, BrickMatic-only, and entire Prompt-to-Product. (a) Physical demands of designing or building brick assembly structures. (b) Mental demands of designing or buil…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

30 extracted references · 24 canonical work pages

  1. [13]

    Stablelego: Stability analysis of block stacking assembly

    Ruixuan Liu, Kangle Deng, Ziwei Wang, and Changliu Liu. Stablelego: Stability analysis of block stacking assembly. IEEE Robotics and Automation Letters (RA-L) , 9(11):9383–9390, 2024

    work page 2024

  2. [15]

    Physics- aware combinatorial assembly sequence planning using data-free action masking

    Ruixuan Liu, Alan Chen, Weiye Zhao, and Changliu Liu. Physics- aware combinatorial assembly sequence planning using data-free action masking. IEEE Robotics and Automation Letters (RA-L) , 10(5):4882–4889, 2025

    work page 2025

  3. [1]

    Carbon X1, 2022

    Bambu Lab. Carbon X1, 2022. URL https://bambulab.com/en/x1

    work page 2022

  4. [2]

    π0: A vision-language-action flow model for general robot control

    Kevin Black, Noah Brown, Danny Driess, Adnan Esmail, Michael Equi, Chelsea Finn, Niccolo Fusai, Lachy Groom, Karol Hausman, Brian Ichter, et al. π0: A vision-language-action flow model for general robot control. arXiv:2410.24164, 2024

    arXiv 2024

  5. [3]

    Blox-net: Generative design-for-robot- assembly using vlm supervision, physics, simulation, and a robot with reset

    Andrew Goldberg, Kavish Kondap, Tianshuang Qiu, Zehan Ma, Letian Fu, Justin Kerr, Huang Huang, Kaiyuan Chen, Kuan Fang, and Ken Goldberg. Blox-net: Generative design-for-robot- assembly using vlm supervision, physics, simulation, and a robot with reset. In IEEE International Conference on Robotics and Automation (ICRA) , 2025

    work page 2025

  6. [4]

    Wolfgang Hoenig, T. K. Kumar, Liron Cohen, Hang Ma, Hong Xu, Nora Ayanian, and Sven Koenig. Multi-agent path finding with kinematic constraints. In International Conference on Automated Planning and Scheduling (ICAPS) , 2016

    work page 2016

  7. [5]

    Apex-mr: Multi-robot asynchronous planning 11 Fig

    Philip Huang, Ruixuan Liu, Shobhit Aggarwal, Changliu Liu, and Jiaoyang Li. Apex-mr: Multi-robot asynchronous planning 11 Fig. 10: Prompt-to-Product User Study Results. Individual and mean ratings of key survey questions for BrickGPT-only, BrickMatic-only, and entire Prompt-to-Product. (a) Physical demands of designing or building brick assembly structure...

    work page 2025

  8. [6]

    π0.5 : a vision-language-action model with open-world generalization

    Physical Intelligence, Kevin Black, Noah Brown, James Darpinian, Karan Dhabalia, Danny Driess, Adnan Esmail, Michael Equi, Chelsea Finn, Niccolo Fusai, et al. π0.5 : a vision-language-action model with open-world generalization. arXiv:2504.16054, 2025

    arXiv 2025

Show all 30 references
  1. [7]

    Jocher, A

    G. Jocher, A. Chaurasia, and J. Qiu. Ultralytics YOLOv8, 2023. URL https://github.com/ultralytics/ultralytics

    2023

  2. [8]

    Openvla: An open-source vision-language-action model

    Moo Jin Kim, Karl Pertsch, Siddharth Karamcheti, Ted Xiao, Ashwin Balakrishna, Suraj Nair, Rafael Rafailov, Ethan Foster, Grace Lam, Pannag Sanketi, et al. Openvla: An open-source vision-language-action model. arXiv:2406.09246, 2024

    2024 arXiv

  3. [9]

    Koenig and A

    N. Koenig and A. Howard. Design and use paradigms for gazebo, an open-source multi-robot simulator. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) , 2004

    2004

  4. [10]

    Kuffner and S.M

    J.J. Kuffner and S.M. LaValle. Rrt-connect: An efficient approach to single-query path planning. IEEE International Conference on Robotics and Automation , 2000

    2000

  5. [11]

    Speech to reality: On-demand production using natural language, 3d generative ai, and discrete robotic assembly

    Alexander Htet Kyaw, Se Hwan Jeon, Miana Smith, and Neil Gershenfeld. Speech to reality: On-demand production using natural language, 3d generative ai, and discrete robotic assembly. arXiv:2409.18390, 2024

    2024

  6. [12]

    Jerk-bounded position controller with real-time task modification for interactive industrial robots

    Ruixuan Liu, Rui Chen, Yifan Sun, Yu Zhao, and Changliu Liu. Jerk-bounded position controller with real-time task modification for interactive industrial robots. In 2022 IEEE/ASME Interna- tional Conference on Advanced Intelligent Mechatronics (AIM) , pages 1771–1778, 2022. do...

    2022

  7. [14]

    A lightweight and transferable design for robust lego manipulation

    Ruixuan Liu, Yifan Sun, and Changliu Liu. A lightweight and transferable design for robust lego manipulation. International Symposium on Flexible Automation (ISF A) , 2024

    2024

  8. [16]

    Legolization: optimizing lego designs

    Sheng-Jie Luo, Yonghao Yue, Chun-Kai Huang, Yu-Huan Chung, Sei Imai, Tomoyuki Nishita, and Bing-Yu Chen. Legolization: optimizing lego designs. ACM Transactions on Graphics (TOG) , November 2015

    2015

  9. [17]

    Shapeshift: Towards text-to-shape arrangement synthesis with content-aware geometric constraints

    Vihaan Misra, Peter Schaldenbrand, and Jean Oh. Shapeshift: Towards text-to-shape arrangement synthesis with content-aware geometric constraints. arXiv:2503.14720, 2025

    2025

  10. [18]

    Legobot: Automated planning for coordinated multi- robot assembly of lego structures

    Ludwig Nägele, Alwin Hoffmann, Andreas Schierl, and Wolf- gang Reif. Legobot: Automated planning for coordinated multi- robot assembly of lego structures. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) , 2020

    2020

  11. [19]

    Dinov2: Learn- ing robust visual features without supervision

    Maxime Oquab, Timothée Darcet, Théo Moutakanni, Huy V o, Marc Szafraniec, Vasil Khalidov, Pierre Fernandez, Daniel Haz- iza, Francisco Massa, Alaaeldin El-Nouby, et al. Dinov2: Learn- ing robust visual features without supervision. arXiv:2304.07193, 2023

    2023 arXiv

  12. [20]

    Brickfem an automated finite element model for static and dynamic simulations of simple lego® sets

    Martin Pletz and Matthias Drvoderic. Brickfem an automated finite element model for static and dynamic simulations of simple lego® sets

  13. [21]

    Data-efficient deep reinforcement learning for dexterous manipulation

    Ivaylo Popov, Nicolas Heess, Timothy Lillicrap, Roland Hafner, Gabriel Barth-Maron, Matej Vecerik, Thomas Lampe, Yuval Tassa, Tom Erez, and Martin Riedmiller. Data-efficient deep reinforcement learning for dexterous manipulation. arXiv, 2017

    2017

  14. [22]

    Generating physically stable and buildable brick structures from text

    Ava Pun, Kangle Deng, Ruixuan Liu, Deva Ramanan, Changliu Liu, and Jun-Yan Zhu. Generating physically stable and buildable brick structures from text. In IEEE International Conference on Computer Vision (ICCV) , 2025

    2025

  15. [23]

    Learning transferable visual models from natural language supervision

    Alec Radford, Jong Wook Kim, Chris Hallacy, Aditya Ramesh, Gabriel Goh, Sandhini Agarwal, Girish Sastry, Amanda Askell, Pamela Mishkin, Jack Clark, et al. Learning transferable visual models from natural language supervision. In International Conference on Machine Learning (IC...

    2021

  16. [24]

    Eye-in-finger: Smart fingers for delicate assembly and disassembly of lego

    Zhenran Tang, Ruixuan Liu, and Changliu Liu. Eye-in-finger: Smart fingers for delicate assembly and disassembly of lego. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2025

    2025

  17. [25]

    Willis, and Wojciech Matusik

    Yunsheng Tian, Jie Xu, Yichen Li, Jieliang Luo, Shinjiro Sueda, Hui Li, Karl D.D. Willis, and Wojciech Matusik. Assemble them all: Physics-based planning for generalizable assembly by disassembly. ACM Transactions on Graphics (TOG) , 2022

    2022

  18. [26]

    Triposr: Fast 3d object reconstruction from a single image

    Dmitry Tochilkin, David Pankratz, Zexiang Liu, Zixuan Huang, , Adam Letts, Yangguang Li, Ding Liang, Christian Laforte, Varun Jampani, and Yan-Pei Cao. Triposr: Fast 3d object reconstruction from a single image. arXiv:2403.02151, 2024. 12

    2024 arXiv

  19. [27]

    Robot assisted additive manufacturing: A review

    Pinar Urhal, Andrew Weightman, Carl Diver, and Paulo Bartolo. Robot assisted additive manufacturing: A review. Robotics and Computer-Integrated Manufacturing, 59:335–345, 2019. ISSN 0736-5845

    2019

  20. [28]

    Bang: Dividing 3d assets via generative exploded dynamics

    Longwen Zhang, Qixuan Zhang, Haoran Jiang, Yinuo Bai, Wei Yang, Lan Xu, and Jingyi Yu. Bang: Dividing 3d assets via generative exploded dynamics. ACM Transactions on Graphics (TOG), 2025

    2025

  21. [29]

    Physics-aware robotic palletization with online masking inference

    Tianqi Zhang, Zheng Wu, Yuxin Chen, Yixiao Wang, Boyuan Liang, Scott Moura, Masayoshi Tomizuka, Mingyu Ding, and Wei Zhan. Physics-aware robotic palletization with online masking inference. arXiv:2502.13443, 2025

    2025 arXiv

  22. [30]

    Hunyuan3d 2.0: Scaling diffusion models for high resolution textured 3d assets generation, 2025

    Zibo Zhao, Zeqiang Lai, Qingxiang Lin, Yunfei Zhao, Haolin Liu, Shuhui Yang, Yifei Feng, Mingxin Yang, Sheng Zhang, Xianghui Yang, Huiwen Shi, Sicong Liu, Junta Wu, Yihang Lian, Fan Yang, Ruining Tang, Zebin He, Xinzhou Wang, Jian Liu, Xuhui Zuo, Zhuo Chen, Biwen Lei, Haohan W...

    2025 arXiv

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.