Gemini Robotics 2.5 ajudou Apollo 2 a separar peças da Mercedes com 96% de sucesso

Em uma área de montagem, é preciso retirar um suporte de uma pilha de peças misturadas e colocá-lo no compartimento correto de uma bandeja. Para uma pessoa, isso é rotina. Para um robô, cada mudança na orientação da peça altera as condições de preensão. Foi exatamente essa operação que a DeepMind testou com o Apollo 2 em fábricas da Mercedes-Benz: a empresa relata 96% de execuções bem-sucedidas. Há o que estudar para os desenvolvedores de automação e contas a fazer para os responsáveis por produto antes de iniciar um piloto próprio.

Como uma instrução se transforma em movimento

O Gemini Robotics 2.5 pertence à família de modelos VLA, que conectam imagens, instruções em linguagem natural e ações físicas. Em um exemplo simples: o robô recebe a tarefa de organizar peças, observa o conteúdo de uma caixa pelas câmeras e controla a garra de acordo com a cena atual. Na página do modelo, o Google oferece inscrição em uma lista de espera para acesso antecipado.

No teste em fábrica, as funções foram divididas. O Gemini Robotics ER acompanhava o andamento do trabalho, enquanto o Robotics 2.5 controlava os braços do Apollo 2. O robô transferia suportes metálicos de caixas com peças a granel para recipientes, preparando as peças na ordem de montagem. Os testes ocorreram em Kecskemet e Sindelfingen. A DeepMind os descreve explicitamente como uma prova de conceito. Os detalhes foram publicados no anúncio da empresa.

Para um engenheiro, essa divisão é útil na análise de falhas. Se a peça errada foi parar na bandeja, é preciso descobrir onde ocorreu o erro: o sistema interpretou incorretamente a próxima etapa, escolheu o objeto errado ou não conseguiu segurá-lo? São problemas diferentes, e um registro com uma única entrada de “operação falhou” ajuda pouco na depuração.

Em um protótipo próprio, vale registrar de forma vinculada a tarefa, a imagem anterior à preensão, a ação escolhida e o resultado da verificação. Assim, é possível identificar erros recorrentes e decidir o que mudar: a posição da câmera, a garra, a alimentação de peças ou a lógica da tarefa. Essa é uma recomendação prática para o projeto do sistema, e não uma descrição da implementação publicada pelo Google.

O que significa o resultado de 96%

Suponha que sua operação também alcance 96% de sucesso. A cada cem tentativas, restam aproximadamente quatro falhas. Mas a mesma taxa de erro pode representar impactos muito diferentes na produção. Em um caso, o robô simplesmente tenta pegar a peça novamente. Em outro, derruba uma peça, prepara um conjunto incorreto ou exige a parada da área de trabalho.

Por isso, o número isolado ainda não responde se o investimento terá retorno. A equipe precisa conhecer o tempo do ciclo completo, a frequência com que um operador é chamado, o tempo de recuperação e as consequências de um erro não detectado. É especialmente útil contabilizar separadamente as tentativas concluídas sem ajuda humana: caso contrário, as correções manuais podem facilmente ficar escondidas em uma média atraente.

A avaliação deve usar os objetos e as condições da futura área de trabalho. Por exemplo, incluir desde o início uma caixa quase vazia, peças sobrepostas e um suporte em uma posição difícil. A lista deve refletir as causas reais de paradas. Caso contrário, o piloto apenas confirmará que o robô funciona bem em uma cena preparada para ele.

Por onde começar um piloto próprio

O primeiro passo é escolher uma operação repetitiva com um critério claro de sucesso. Na preparação de kits, isso pode significar colocar a peça certa no compartimento certo dentro do tempo permitido. Antes dos testes, é preciso definir quem valida o resultado e o que acontece em caso de dúvida: uma nova tentativa, pular a tentativa ou chamar uma pessoa.

Depois, vale comparar várias maneiras de executar essa operação, incluindo mudanças na própria alimentação de peças. Às vezes, uma bandeja adequada ou um dispositivo de fixação simples oferecem um resultado econômico melhor do que tornar o controle mais complexo. Faz sentido avaliar o modelo dentro de todo o sistema de trabalho, junto com os equipamentos, a verificação de qualidade e a manutenção.

O anúncio da DeepMind oferece um motivo concreto para realizar esse experimento. A decisão de compra deve se apoiar em medições da própria área de trabalho. Se o robô mantém o ritmo necessário, os erros são detectados e a recuperação tem um custo aceitável, há uma base concreta para discutir a implantação. Até lá, os 96% continuam sendo o resultado de um piloto de outra empresa — uma referência útil para testar sua hipótese.