OpenGrall presenta el modo «Ingeniero»: el robot escribe sus propios drivers y configura módulos

OpenGrall ha descrito un modo «Ingeniero»: una arquitectura en la que el robot, a partir de una orden de texto, puede crear plugins, escribir drivers y adaptar el código a hardware nuevo por sí mismo. La idea no es lograr la autonomía total a cualquier precio, sino delegar en un LLM la integración rutinaria sin que el control deje de estar en manos de una persona.

Cómo se reparten los roles

En el proyecto OpenGrall, la inteligencia del robot se divide en dos circuitos. El «Piloto» es un modelo local que funciona a bordo, toma decisiones rápidas y controla el movimiento en tiempo real. Ve los sensores, lee los archivos del proyecto y puede actualizar la memoria, pero no tiene permiso para modificar el código del sistema. Este modo existe para que el robot no dependa de la nube en las tareas básicas y no rompa su propia lógica durante el uso normal.

El «Ingeniero» se activa solo bajo petición o cuando la tarea exige acceso a herramientas de desarrollo. Es un LLM en la nube al que se le abre el código del proyecto, las configuraciones y la documentación. No se limita a generar un fragmento al azar, sino que actúa como un agente aparte: estudia la estructura de los plugins, busca ejemplos, edita archivos, ejecuta código en un entorno aislado y hace preguntas aclaratorias al propietario. Si la orden es del tipo «gira a la izquierda», trabaja el Piloto; si es «configura el manipulador», el relevo pasa al Ingeniero.

Cómo trabaja el Ingeniero

La idea central del modo es no escribirlo todo a mano para cada módulo nuevo. Si al robot se le conecta, por ejemplo, el servo de una cámara sobre un ESP32 mediante WebSocket, al propietario le basta con describir el dispositivo y sus comandos disponibles en un archivo de autodescripción. Después, el Ingeniero lee el proyecto, compara los plugins existentes y crea un módulo nuevo para ese hardware concreto. Para ello, OpenGrall ha reunido un conjunto de herramientas específico:

• búsqueda de documentación y ejemplos funcionales en la red
• lectura de artículos, especificaciones y archivos del proyecto
• análisis de la estructura de directorios y de los plugins ya existentes
• edición puntual de código y creación de archivos nuevos
• ejecución y verificación de lo escrito en un entorno aislado

Lo que sigue no es «magia de un solo botón», sino un ciclo de desarrollo controlado. Primero, el modelo construye el esqueleto de la clase y puede mostrárselo a la persona antes de generar el archivo completo. Después, los métodos se rellenan paso a paso en modo streaming, para no regenerar el módulo entero ni perder el contexto. Para la calibración, el Ingeniero puede incorporar a una persona al circuito: pedirle que coloque un objeto delante de la cámara, que mida la distancia hasta la carcasa o que confirme que el servo ha llegado al ángulo necesario. Esto es especialmente importante donde una descripción puramente textual no basta.

El autor no apuesta solo por conectar módulos nuevos, sino también por una reestructuración más profunda del sistema. El artículo cita un ejemplo con un navegador: una versión manual básica de aproximadamente 1,5 mil líneas de código puede sustituirse por una implementación mucho más voluminosa, con trayectorias suaves, recálculo de ruta sobre la marcha y menos tirones. Es decir, ya no se trata de generar un único driver, sino de intentar dar al robot una herramienta para reescribir sus propios subsistemas según la nueva tarea.

«La decisión final sigue en manos de una persona».

La seguridad descansa en tres mecanismos sencillos: un entorno aislado para ejecutar el código, copias de seguridad automáticas antes de cada cambio y una generación por etapas con verificación del resultado. El código se ejecuta con tiempo límite y sin llamadas al sistema, antes de cualquier edición se crea una copia del archivo, y la integración en el ciclo principal no ocurre de forma automática. Incluso si el modelo se equivoca o se desvía hacia una arquitectura errónea, una persona puede detener el proceso, revertir los cambios y tomar la decisión final manualmente.

Dónde están los límites del enfoque

Los autores de OpenGrall dicen sin rodeos que no conviene idealizar el primer código generado. Los LLM siguen con sus problemas crónicos: API obsoletas, dependencias innecesarias, wrappers incorrectos e incompatibilidad con el entorno. La diferencia es que el agente sabe leer los logs, relanzar las pruebas y corregir por su cuenta hasta que el módulo funciona. Pero en la práctica esta depuración autónoma puede llevar no minutos, sino horas de tiempo real, sobre todo si el hardware no es estándar o la documentación está a medio hacer.

Hay también limitaciones arquitectónicas más duras. Para configurar un manipulador, una cámara o un lidar, este modo resulta lógico: el modelo ve la descripción, entiende la geometría de la tarea y puede montar una interfaz funcional sobre comandos ya existentes. Pero para controlar la marcha de un hexápodo u otras tareas con exigencias estrictas de velocidad y adaptabilidad, el código Python autogenerado ya no basta. Ahí, en opinión del autor, hacen falta otros enfoques, como TinyML y el entrenamiento en simulación, donde el comportamiento se elabora a lo largo de millones de iteraciones en lugar de escribirse de forma superficial a partir de una petición de texto.

Qué significa

OpenGrall muestra un cambio interesante: el robot empieza a percibirse no como un dispositivo con firmware rígido, sino como una plataforma que puede reentrenarse y ampliarse con órdenes de texto. Queda mucho para una robótica totalmente autónoma, pero para integrar sensores, plugins y subsistemas concretos, un «Ingeniero» así ya puede reducir de forma notable el trabajo manual, siempre que el último interruptor siga en manos de una persona.