Gemini Robotics 2.5 aide Apollo 2 à trier des pièces Mercedes avec 96 % de réussite

Sur un poste d'assemblage, il faut sortir un support d'un tas en vrac et le placer dans la bonne case d'un bac. Pour un humain, c'est une routine. Pour un robot, chaque nouvelle rotation de la pièce modifie les conditions de préhension. C'est précisément cette opération que DeepMind a testée avec Apollo 2 dans des usines Mercedes-Benz : l'entreprise annonce 96 % d'exécutions réussies. Les développeurs d'automatisation ont de quoi étudier ici, et les product managers de quoi calculer avant leur propre pilote.

Comment une consigne devient un mouvement

Gemini Robotics 2.5 appartient à la famille des modèles VLA : ils relient l'image, la consigne en langage naturel et l'action physique. Concrètement, le robot reçoit l'ordre de ranger des pièces, voit le contenu de la caisse via des caméras et pilote la pince en tenant compte de la scène du moment. Sur la page du modèle, Google propose de s'inscrire sur la liste d'attente de l'accès anticipé.

Lors de l'essai en usine, les rôles ont été répartis. Gemini Robotics ER suivait l'avancement du travail, tandis que Robotics 2.5 commandait les bras d'Apollo 2. Le robot transférait des supports métalliques de caisses en vrac vers des conteneurs, en préparant les pièces dans l'ordre d'assemblage. Les essais se sont déroulés à Kecskemét et à Sindelfingen. DeepMind les qualifie explicitement de preuve de concept. Les détails figurent dans l'annonce de l'entreprise.

Pour un ingénieur, cette séparation est utile pour analyser les défaillances. Si une mauvaise pièce se retrouve dans le bac, il faut déterminer où l'erreur est née : le système a mal compris l'étape suivante, a mal choisi l'objet ou ne l'a pas retenu. Ce sont des problèmes différents, et un journal contenant seulement « opération échouée » aide peu au débogage.

Dans votre propre prototype, il est utile de conserver le lien entre la consigne, l'image avant la saisie, l'action choisie et le résultat de la vérification. On voit alors quelles erreurs se répètent et on peut décider quoi modifier : l'emplacement de la caméra, la pince, l'alimentation en pièces ou la logique de la tâche. C'est une conclusion pratique pour la conception du système, et non la description d'une implémentation publiée par Google.

Ce que signifie le résultat de 96 %

Supposons que votre opération affiche aussi 96 % de réussite. Sur cent tentatives, il en reste environ quatre ratées. Mais un même taux d'erreur peut représenter une charge très différente pour la production. Dans un cas, le robot répète simplement la saisie. Dans un autre, il fait tomber la pièce, compose un mauvais kit ou impose l'arrêt du poste.

Le chiffre seul ne répond donc pas à la question de la rentabilité. L'équipe a besoin du temps de cycle complet, de la fréquence d'appel de l'opérateur, de la durée de reprise et des conséquences d'une erreur non détectée. Il est particulièrement utile de compter à part les tentatives menées à terme sans aide humaine : sinon, la correction manuelle se dilue facilement dans une belle moyenne.

Le test doit porter sur les objets et les conditions du futur poste. Par exemple, inclure d'avance une caisse presque vide, des pièces qui se chevauchent et un support dans une position délicate. La liste doit refléter les vraies causes d'arrêt. Sinon, le pilote confirmera seulement que le robot fonctionne bien sur une scène préparée pour lui.

Par où commencer son propre pilote

La première étape consiste à choisir une opération répétitive avec un critère de réussite clair. Pour la préparation de kits, ce peut être la bonne pièce dans la bonne case, posée dans un temps acceptable. Avant les essais, il faut définir qui valide le résultat et ce qui se passe en cas de doute : nouvelle tentative, saut ou appel d'un humain.

Il convient ensuite de comparer plusieurs façons de réaliser cette opération, y compris en modifiant l'alimentation des pièces elle-même. Parfois, un bac pratique ou un simple outillage donnent un meilleur résultat qu'un contrôle plus complexe. Il est judicieux d'évaluer le modèle au sein de l'ensemble du système de travail : avec l'équipement, le contrôle qualité et la maintenance.

L'annonce de DeepMind donne une raison concrète de monter une telle expérience. La décision d'achat doit reposer sur des mesures effectuées sur votre propre poste. Si le robot tient la cadence voulue, si les erreurs sont détectées et si la reprise reste d'un coût acceptable, une discussion concrète sur le déploiement devient possible. Jusque-là, les 96 % restent le résultat du pilote d'un autre — un repère utile pour tester votre hypothèse.