Choosing parts for a robot sounds like a shopping problem: find a motor, battery, wheels, and frame that fit the budget and do the job. But a promising parts list can hide a more basic question: what exactly counts as “doing the job”? A motor’s peak power is not the same as its power over a long run. Battery capacity on a label may not equal usable energy. And parts that look compatible one at a time may fail when their requirements meet.
Researchers Andrew Wilhelm, Angelina Zhou, and Nils Napp propose a way to bring those assumptions into view before an optimizer settles on a design. Instead of asking a language model to pick the robot’s parts, they ask it to help build an explicit engineering model: a structured account of the parts, the relationships among them, the constraints a design must meet, and the goals it should balance.
That change in job description matters. A direct recommendation can sound convincing without showing how it handles every interaction. A model, by contrast, puts those choices on the table. A person can inspect and revise them, add information from manufacturers or measurements, and only then ask a formal optimizer to search for designs that satisfy the stated rules.
The team tested this workflow on two design challenges: a mini quadcopter and a differential-drive robot intended to follow a line. The possible combinations were enormous: over 7.73 × 1010 for the quadcopter and 2.18 × 1013 for the line-following robot. Each design also had competing aims, including cost, speed, and payload. There may be no single winner: one design can be cheaper, another faster, and another capable of carrying more. An optimizer can identify the strongest trade-offs under the model, rather than pretending every goal can be maximized at once.
The model-building process began with high-level requirements and catalogs listing component properties. A retrieval system supplied the language model with catalog details, including which properties were available often enough to be useful. The model then drafted relationships and constraints. For instance, a line-following robot’s speed depends on the selected motor and wheel, while a usable design also has to respect electrical, endurance, payload, and compatibility requirements.
Then came the human review. A designer could correct a relationship, add a missing compatibility rule, or ask for a more detailed account of a subsystem. If friction or drivetrain losses mattered, those could be added; if a crucial parameter was specific to the machine, it could come from measurement rather than guesswork. Once the model was finalized, a constraint-programming optimizer searched the catalogs and returned designs that were feasible and Pareto-optimal under that model.
That last qualification is essential. The solver can establish that a design meets the rules it was given; it cannot prove that those rules perfectly capture the physical world. The method makes the model’s assumptions inspectable, not automatically true.
The researchers tested why this distinction matters by comparing the workflow with a language model asked to select components directly. For each robot, they ran the direct-selection approach five times for each of three objectives. Across the 30 trials, none of the proposed designs could be verified as feasible under the finalized models. Twenty-three violated at least one constraint. The other seven could not be fully assessed because required component properties were missing.
One gap involved motor ratings. The finalized quadcopter model used continuous power to estimate sustained performance, while many selected motors lacked that property. A design based on a motor’s peak power might look attractive, but peak and continuous power are not interchangeable when the question is whether the robot can keep operating. The issue was not simply choosing a less impressive part. It was that the design could not be checked against the performance the model actually required.
The deeper surprise appeared when the researchers compared two models of the same line-following robot. One was built through the language-model-assisted process; the other was authored independently by an expert. Neither was treated as ground truth. Yet they produced markedly different sets of designs deemed feasible or optimal. Among 69 designs considered Pareto-optimal by the expert model, 29 satisfied all the constraints in the language-model-assisted model. In the reverse direction, 7 of the 34 designs favored by the assisted model satisfied all the expert model’s constraints.
The disagreement traced back to engineering choices, not merely to a solver making a mistake. The models handled battery endurance differently: the assisted model accounted for efficiency losses and assumed only part of the listed battery energy was usable, while the expert model used different power calculations and the full listed energy. Their representations of the power architecture also led to different motor-supply compatibility requirements. Those differences could change which designs passed the test and which sat on the apparent frontier of best choices.
Refinement changed the answer even within the assisted model. In an early version, 24 of 43 line-following designs remained feasible when checked against the finalized model, but all 24 were outperformed under its objectives. Later revisions added details such as drag at a rear contact point and more conservative empirical values. The model’s conclusions shifted as its assumptions were updated.
This is why the proposed approach is less like asking an AI to be a robot engineer and more like asking it to help lay out the engineering argument. The model can organize physical relationships and make a vast search tractable; a designer can bring in system-specific knowledge; and an optimizer can compare combinations consistently. None of those steps, on its own, guarantees a real machine will behave exactly as predicted.
The study evaluates component-selection models, not a fleet of newly built robots proving the predictions in the physical world. Its contribution is a method for exposing the decisions that usually hide inside a design calculation. Before a machine can be called optimal, someone must decide what counts as feasible—and the assumptions behind that decision can be as consequential as the parts themselves.
