OpenGrall Apresentou Arquitetura para Robôs com IA onde o Modelo de Linguagem Lida com Estratégia

A OpenGrall propõe uma mudança simples, mas importante na robótica: um modelo de linguagem não deve controlar um robô no nível de motores e reações instantâneas. Aqui, o modelo de linguagem é responsável apenas por significado, planejamento e escolha do próximo passo, enquanto segurança, movimento e reflexos de baixo nível são separados em um circuito de realimentação distinto. Por meio dessa abordagem, o projeto visa eliminar o principal problema da maioria das demonstrações de "robô GPT", onde a máquina fala lindamente, mas depois congela por vários segundos antes de cada ação.

Os autores começam com o problema mais doloroso — segurança. Um LLM é não-determinístico: a mesma solicitação pode produzir respostas diferentes, o que significa que confiar a ele o controle direto de motores é perigoso. A OpenGrall introduz um esquema híbrido para isso, onde o papel de "medula espinhal" é executado por um modelo TinyML ou outro circuito de execução rígido em um microcontrolador.

É exatamente isso que compreende a física da plataforma específica, gerencia suspensão, navegação de obstáculos e tem poder de veto sobre qualquer comando. Se um operador ou LLM disser para se mover para frente, mas um medidor de distância detectar um objeto mais próximo que 10 centímetros, o comando simplesmente não será executado. O tempo de reação de parada de emergência declarado é menor que 10 milissegundos.

A lógica aqui é pragmática: o LLM pensa, enquanto o módulo de execução age e pode parar a ação perigosa a qualquer momento. A segunda grande força da OpenGrall é a modularidade. O projeto separa "pensar" e "fazer" para que ambas as partes possam ser alteradas independentemente.

O papel do cérebro pode ser desempenhado por um LLM local, VLM ou modelo em nuvem se uma tarefa mais complexa, como planejamento multi-etapas ou busca na web, for necessária. O papel do executor — modelo TinyML, VLA ou até mesmo um algoritmo comum codificado se a plataforma for simples. Todo o sistema é conectado via um servidor WebSocket, e os dispositivos se conectam como clientes regulares com papéis como agent, operator, lidar ou esp.

Isso permite adicionar novos sensores sem reescrever o núcleo e até construir um esquema em que um agente funciona com vários corpos simultaneamente: por exemplo, uma plataforma com rodas e um drone. Para um projeto de código aberto em hardware fraco, essa ênfase é particularmente importante: a arquitetura não está vinculada a um tipo de robô ou a um modelo específico. O bloco de engenharia chave é a ligação de SensorMemory e WeightCalculator.

Em vez de enviar indiscriminadamente todos os fluxos brutos para o LLM, o sistema coleta dados de forma assíncrona, avalia sua atualidade e confiabilidade e os transforma em um prompt curto. Se um lidar fica sujo ou um VLM fica cego sob o sol, seu peso diminui antes do momento da tomada de decisão. Se algum sensor é lento, ele não bloqueia os outros.

O artigo fornece um exemplo ilustrativo: uma nuvem de pontos lidar é acumulada em oito setores, e objetos próximos são descritos por ângulo, distância, tamanho e velocidade. Para o LLM, isso não é mais ruído, mas uma situação estruturada. Uma nuance importante é que a OpenGrall não tenta escrever manualmente regras complexas de fusão de dados.

O próprio LLM atua como árbitro, vendo a fonte, idade e peso de cada sinal e escolhendo uma ação em formato JSON com base nisso. Ao mesmo tempo, o prompt do sistema é incorporado ao modelo com antecedência, por exemplo através do Ollama, portanto no ciclo de trabalho apenas a parte operacional "nua" entra na solicitação. De acordo com a estimativa do autor, isso reduz o prompt de aproximadamente 450 para 150 tokens.

Um foco separado do artigo é combater a "lentidão". Em muitos frameworks clássicos, o robô espera o sensor mais lento e, por causa disso, a telemetria rápida fica efetivamente ociosa. A OpenGrall rejeita essa sincronização: o lidar, VLM e odometria escrevem dados na memória de forma independente, e o agente toma os valores mais frescos e confiáveis no momento atual.

Mas mesmo após isso, o LLM ainda pensa por centenas de milissegundos, então no lado do ESP32, movimento inercial foi adicionado: se ainda não houver novo comando, o robô não congela de pé, mas continua suavemente sua última ação segura com amortecimento de velocidade. Outra camada de otimização é o cache de decisões por hash de contexto. Se o robô novamente enfrenta o mesmo corredor vazio, o sistema não chama o modelo novamente, mas toma a solução já verificada do cache.

Depois, essa ideia se desenvolve em direção a hábitos familiares e reflexos de alto nível: estratégias bem-sucedidas já podem ser executadas sem o LLM, e o feedback humano fortalece seu peso. Além disso, o projeto armazena memória episódica de instruções humanas e até permite fixação de objetivos autônoma, quando o robô escolhe de forma independente o que explorar, o que lembrar ou com quem começar um diálogo em tempo ocioso. Olhando mais amplamente, a OpenGrall é interessante não como mais uma tentativa de "prender GPT a um robô", mas como uma tentativa de trazer a robótica com LLM para uma arquitetura mais madura.

Não há promessa de um cérebro universal mágico, mas há uma clara divisão de responsabilidades, trabalho com hardware limitado, proteção contra ações perigosas e um caminho para aprendizado gradual sem retreinamento total de todo o sistema. Para desenvolvedores, isso significa uma forma mais realista de construir robôs baseados em modelos modernos: usar o LLM onde é forte e não forçá-lo a fazer o que é mais adequado para um circuito de execução pequeno, rápido e previsível.