OpenGrall Presentó Arquitectura para Robots con IA donde el Modelo de Lenguaje Maneja la Estrategia

OpenGrall propone un cambio simple pero importante en robótica: un modelo de lenguaje no debe controlar un robot a nivel de motores y reacciones instantáneas. Aquí, el modelo de lenguaje es responsable solo de significado, planificación y elección del siguiente paso, mientras que la seguridad, el movimiento y los reflejos de bajo nivel se separan en un circuito de retroalimentación distinto. A través de este enfoque, el proyecto pretende eliminar el principal problema de la mayoría de demostraciones de "robots GPT", donde la máquina habla hermosamente pero luego se congela durante varios segundos antes de cada acción.

Los autores comienzan con el problema más doloroso — la seguridad. Un LLM es no determinista: la misma solicitud puede producir respuestas diferentes, lo que significa que confiarle el control directo de motores es peligroso. OpenGrall introduce un esquema híbrido para esto, donde el papel de "médula espinal" lo ejecuta un modelo TinyML u otro circuito de ejecución rígido en un microcontrolador.

Es precisamente esto lo que comprende la física de la plataforma específica, gestiona la suspensión, la navegación de obstáculos y tiene poder de veto sobre cualquier comando. Si un operador o LLM dice que se mueva hacia adelante, pero un medidor de distancia detecta un objeto más cercano que 10 centímetros, el comando simplemente no se ejecutará. El tiempo de reacción de parada de emergencia declarado es menor a 10 milisegundos.

La lógica aquí es pragmática: el LLM piensa, mientras que el módulo de ejecución actúa y puede detener la acción peligrosa en cualquier momento. La segunda gran fortaleza de OpenGrall es la modularidad. El proyecto separa "pensar" y "hacer" para que ambas partes puedan cambiarse independientemente.

El papel del cerebro puede ser desempeñado por un LLM local, VLM o modelo en la nube si se necesita una tarea más compleja como planificación multietapa o búsqueda web. El papel del ejecutor — modelo TinyML, VLA o incluso un algoritmo ordinario codificado si la plataforma es simple. Todo el sistema se conecta a través de un servidor WebSocket, y los dispositivos se conectan como clientes normales con roles como agent, operator, lidar o esp.

Esto permite agregar nuevos sensores sin reescribir el núcleo e incluso construir un esquema donde un agente funciona con múltiples cuerpos simultáneamente: por ejemplo, una plataforma con ruedas y un dron. Para un proyecto de código abierto en hardware débil, este énfasis es particularmente importante: la arquitectura no está vinculada a un tipo de robot o un modelo específico. El bloque de ingeniería clave es el enlace de SensorMemory y WeightCalculator.

En lugar de enviar indiscriminadamente todas las corrientes sin procesar al LLM, el sistema recopila datos de forma asincrónica, evalúa su actualidad y confiabilidad, y luego los transforma en un prompt corto. Si un lidar se ensucia o un VLM se queda ciego bajo el sol, su peso disminuye antes del momento de la toma de decisión. Si algún sensor es lento, no bloquea a los otros.

El artículo proporciona un ejemplo ilustrativo: una nube de puntos lidar se condensa en ocho sectores, y los objetos cercanos se describen mediante ángulo, distancia, tamaño y velocidad. Para el LLM, esto ya no es ruido sino una situación estructurada. Un matiz importante es que OpenGrall no intenta escribir manualmente reglas complejas de fusión de datos.

El propio LLM actúa como árbitro, viendo la fuente, la edad y el peso de cada señal y eligiendo una acción en formato JSON sobre esta base. Al mismo tiempo, el prompt del sistema se incrusta en el modelo de antemano, por ejemplo a través de Ollama, por lo que en el ciclo de trabajo solo la parte operacional "pura" entra en la solicitud. Según la estimación del autor, esto reduce el prompt de aproximadamente 450 a 150 tokens.

Un enfoque separado del artículo es combatir la "lentitud". En muchos marcos clásicos, el robot espera el sensor más lento y, por eso, la telemetría rápida permanece efectivamente ociosa. OpenGrall rechaza tal sincronización: el lidar, VLM y odometría escriben datos en memoria de forma independiente, y el agente toma los valores más frescos y confiables en el momento actual.

Pero incluso después de eso, el LLM aún piensa durante cientos de milisegundos, por lo que en el lado del ESP32 se ha añadido movimiento inercial: si aún no hay un comando nuevo, el robot no se congela quieto sino que continúa suavemente su última acción segura con amortiguamiento de velocidad. Otra capa de optimización es el almacenamiento en caché de decisiones por hash de contexto. Si el robot nuevamente se enfrenta al mismo pasillo vacío, el sistema no llama al modelo nuevamente sino que toma la solución ya verificada del caché.

A continuación, esta idea se desarrolla hacia hábitos familiares y reflejos de alto nivel: las estrategias exitosas ya se pueden ejecutar sin el LLM, y la retroalimentación humana fortalece su peso. Además de esto, el proyecto almacena memoria episódica de instrucciones humanas e incluso permite el establecimiento autónomo de objetivos, cuando el robot elige de forma independiente qué explorar, qué recordar o con quién comenzar un diálogo en tiempo de inactividad. En términos más amplios, OpenGrall es interesante no como otro intento de "pegar GPT a un robot", sino como un intento de llevar la robótica con LLM a una arquitectura más madura.

No hay promesa de un cerebro universal mágico, pero hay una clara división de responsabilidades, trabajo con hardware limitado, protección contra acciones peligrosas y un camino hacia el aprendizaje gradual sin reentrenamiento total de todo el sistema. Para los desarrolladores, esto significa una forma más realista de construir robots basados en modelos modernos: usar el LLM donde es fuerte y no obligarlo a hacer lo que es más adecuado para un circuito de ejecución pequeño, rápido y predecible.