Gemini Robotics 2.5 helped Apollo 2 sort Mercedes parts with a 96% success rate

On an assembly line, a bracket needs to be picked out of a mixed pile and placed in the correct tray compartment. For a person, this is routine. For a robot, every change in the part’s orientation changes the conditions for grasping it. DeepMind tested precisely this operation with Apollo 2 at Mercedes-Benz factories, reporting a 96% success rate. Automation developers have something to study here, and product managers have some calculations to make before launching their own pilot.

How an instruction becomes movement

Gemini Robotics 2.5 belongs to the VLA family of models, which connect vision, language instructions and physical actions. In practical terms, a robot receives a task to sort parts, sees the contents of a bin through its cameras and controls its gripper based on the current scene. On the model page, Google offers a waitlist for early access.

In the factory trial, responsibilities were split. Gemini Robotics ER tracked work progress, while Robotics 2.5 controlled Apollo 2’s arms. The robot transferred metal brackets from bulk bins into containers, arranging parts in assembly order. The trials took place in Kecskemet and Sindelfingen. DeepMind explicitly describes them as a proof of concept. Details are available in the company announcement.

For engineers, this division is useful when investigating failures. If the wrong part ends up in a tray, they need to determine where the error occurred: did the system misunderstand the next step, select the wrong object or fail to hold it? These are different problems, and a log containing only “operation failed” offers little help with debugging.

In your own prototype, it is worth recording the task, the frame before the grasp, the selected action and the verification result together. This makes recurring errors visible and helps determine what to change: camera placement, the gripper, the way parts are supplied or the task logic. This is a practical recommendation for system design, rather than a description of Google’s published implementation.

What the 96% result means

Suppose your operation also achieves a 96% success rate. That leaves roughly four failures for every hundred attempts. But the same error rate can place very different burdens on production. In one case, the robot simply retries the grasp. In another, it drops a part, assembles an incorrect kit or requires the work area to be shut down.

The figure alone therefore does not establish whether the investment will pay off. The team needs the full cycle time, how often an operator is called, recovery time and the consequences of an undetected error. It is particularly useful to track attempts completed without human assistance separately; otherwise, manual corrections can easily disappear into an impressive average result.

Testing should use the objects and conditions expected in the future work area. For example, include a nearly empty bin, overlapping parts and an awkwardly positioned bracket from the outset. The list should reflect actual causes of downtime. Otherwise, the pilot will establish only that the robot works well in a scene prepared specifically for it.

Where to start with your own pilot

The first step is to choose one repetitive operation with a clear success criterion. For kitting, that might mean placing the correct part in the correct compartment within the allowed time. Before testing, define who verifies the result and what happens when there is uncertainty: a retry, a skip or a call for human assistance.

Next, compare several ways to perform the operation, including changing how parts are supplied. Sometimes a well-designed tray or a simple fixture delivers better economics than more complex controls. The model should be evaluated as part of the entire working system, together with equipment, quality checks and maintenance.

DeepMind’s announcement provides a concrete reason to run such an experiment. A purchasing decision should be based on measurements from your own work area. If the robot maintains the required pace, errors are detected and recovery costs are acceptable, there is a solid basis for discussing deployment. Until then, 96% remains the result of someone else’s pilot—a useful benchmark for testing your hypothesis.