Gemini Robotics 2.5 помогла Apollo 2 сортировать детали Mercedes с успехом 96%

На сборочном участке нужно достать кронштейн из общей кучи и положить в нужную ячейку лотка. Для человека это рутина. Для робота каждый новый поворот детали меняет условия захвата. Именно такую операцию DeepMind проверила с Apollo 2 на заводах Mercedes-Benz: компания сообщает о 96% успешных выполнений. Разработчикам автоматизации здесь есть что изучить, а продактам — что посчитать перед собственным пилотом.

Как команда превращается в движение

Gemini Robotics 2.5 относится к моделям VLA: они связывают изображение, языковое задание и физическое действие. На понятном примере: робот получает задачу разложить детали, видит содержимое ящика через камеры и управляет захватом с учётом текущей сцены. На странице модели Google предлагает записаться в лист ожидания раннего доступа.

В заводском испытании обязанности разделили. Gemini Robotics ER отслеживала ход работы, а Robotics 2.5 управляла руками Apollo 2. Робот переносил металлические кронштейны из общих ящиков в контейнеры, подготавливая детали в порядке сборки. Испытания прошли в Кечкемете и Зиндельфингене. DeepMind прямо называет их проверкой концепции. Подробности опубликованы в анонсе компании.

Для инженера такое разделение полезно как способ разбирать сбои. Если в лотке оказалась неверная деталь, нужно выяснить, где возникла ошибка: система неправильно поняла следующий шаг, выбрала предмет или не удержала его. Это разные проблемы, и журнал с одной записью «операция провалена» мало поможет при отладке.

В собственном прототипе стоит сохранять связку: задание, кадр перед захватом, выбранное действие и результат проверки. Тогда можно увидеть, какие ошибки повторяются, и решить, что менять: расположение камеры, захват, подачу деталей или логику задания. Это практический вывод для проектирования системы, а не описание опубликованной реализации Google.

Что означает результат 96%

Допустим, ваша операция тоже показывает 96% успеха. На каждые сто попыток остаются примерно четыре неудачные. Но одинаковая доля ошибок может означать совершенно разную нагрузку на производство. В одном случае робот просто повторяет захват. В другом — роняет деталь, собирает неправильный комплект или требует остановить участок.

Поэтому сама цифра ещё не отвечает на вопрос об окупаемости. Команде нужны время полного цикла, частота вызова оператора, длительность восстановления и последствия незамеченной ошибки. Особенно полезно отдельно считать попытки, завершённые без помощи человека: иначе ручное исправление легко растворяется в красивом среднем результате.

Проверку стоит проводить на предметах и условиях будущего участка. Например, заранее включить почти пустой ящик, перекрывающие друг друга детали и неудобное положение кронштейна. Список должен отражать реальные причины простоев. Иначе пилот подтвердит лишь то, что робот хорошо работает на подготовленной для него сцене.

С чего начинать собственный пилот

Первый шаг — выбрать одну повторяющуюся операцию с понятным критерием успеха. Для комплектования это может быть правильная деталь в правильной ячейке, уложенная за допустимое время. До испытаний нужно определить, кто подтверждает результат и что происходит при сомнении: повторная попытка, пропуск или вызов человека.

Затем стоит сравнить несколько способов выполнить эту операцию, включая изменение самой подачи деталей. Иногда удобный лоток или простая оснастка дают более выгодный результат, чем усложнение управления. Модель имеет смысл оценивать внутри всей рабочей системы: вместе с оборудованием, проверкой качества и обслуживанием.

Анонс DeepMind даёт конкретный повод поставить такой эксперимент. Решение о закупке должно опираться на измерения собственного участка. Если робот выдерживает нужный темп, ошибки обнаруживаются, а восстановление обходится приемлемо, появляется предметный разговор о внедрении. До этого 96% остаются результатом чужого пилота — полезным ориентиром для проверки вашей гипотезы.