Un equipo de la Universidad Tecnológica de Sídney y la Universidad de Ciencia y Tecnología del Sur de China ha construido un manipulador móvil de laboratorio alrededor de dos brazos OpenArm. Su aportación no es prometer un científico robótico autónomo, sino ordenar y hacer auditable el recorrido entre una instrucción en lenguaje natural y el movimiento que ejecutaría la máquina.
El prototipo, presentado en un informe para un taller de Robotics: Science and Systems 2026, combina los dos brazos, pinzas, una columna vertical, una base móvil, cámara RGB-D y lidar. Sobre ese hardware, el equipo conecta ROS 2, MoveIt, navegación, FoundationPose y una biblioteca de habilidades con límites definidos. El código del proyecto también se ha publicado, de modo que la arquitectura se puede inspeccionar más allá del diagrama del artículo.
Del lenguaje a una lista cerrada de habilidades
El problema que aborda el trabajo aparece cuando un modelo de lenguaje deja de describir una tarea y pasa a dirigir una máquina física. Una orden como mover un recipiente, colocar un tubo en una gradilla o preparar un vertido no debería convertirse directamente en comandos de motores: entre ambos extremos hay que localizar objetos, conocer sus funciones, transformar coordenadas, comprobar el espacio de trabajo y decidir qué acciones admite realmente el robot.
La propuesta divide ese recorrido en «traspasos de representación». El usuario formula una petición y un planificador apoyado en un modelo de lenguaje solo puede responder con llamadas a habilidades ya registradas. Cada llamada especifica el objeto, el destino y los argumentos aceptados. Después, un orquestador determinista valida el plan y lo convierte en objetivos de movimiento como acercarse, abrir o cerrar la pinza, elevar el brazo, desplazarse con la base o retirarse.
El sistema permite un intento de reparación si la primera salida del planificador no cumple el contrato. Si la petición exige una función inexistente, el robot no improvisa: la registra como no disponible. Es una limitación deliberada que sacrifica flexibilidad para evitar que el modelo invente comandos de ROS, argumentos o maniobras de recuperación fuera del repertorio autorizado.
Cámara, mapa y objetos tienen que hablar el mismo idioma
La plataforma utiliza el lidar para construir el mapa de navegación y la cámara RGB-D para observar la mesa. Unas etiquetas AprilTag ayudan a fijar el marco de referencia del tablero, mientras que FoundationPose aporta la posición y orientación tridimensional de los objetos. Pero el artículo insiste en que una pose de seis dimensiones no basta para manipular de forma fiable.
Cada objeto debe llevar asociados su nombre, dimensiones, malla o nube de puntos, nivel de confianza, posibles funciones y habilidades compatibles. Así, un tubo puede ser a la vez un objeto móvil, un recipiente de muestras y un elemento insertable; una gradilla puede funcionar como superficie, estructura fija y destino de colocación. Estas propiedades permiten transformar la percepción en parámetros concretos de aproximación, agarre, elevación, inserción o vertido.
Antes de cada habilidad, el tiempo de ejecución vuelve a consultar el estado del robot y del entorno. Si falta un objeto, la confianza de la detección es baja, la pinza sostiene algo incompatible o un objetivo rebasa los límites de seguridad, la secuencia se detiene y deja un registro. Esa trazabilidad es el núcleo del trabajo: permite localizar si el fallo nació en el mapa, la calibración, la detección, el plan del modelo, la biblioteca de habilidades o el controlador físico.
Un prototipo útil que todavía trabaja en seco
La distinción importante es que el equipo aporta por ahora trazas de ejecución en seco y comprobaciones de arranque, no tasas de éxito con el robot manipulando muestras reales. El flujo de software puede producir una secuencia completa para trasladar un objeto, y también exponer de forma explícita aquello que no sabe resolver. Eso demuestra integración y capacidad de diagnóstico, pero no precisión de agarre, vertido o inserción en un laboratorio operativo.
Los propios autores enumeran lo que falta: medir las transformaciones entre cámara, lidar y columna; localizar bien la mesa; completar mallas y nubes de puntos; sustituir datos simulados por imágenes RGB-D reales con máscaras o detecciones; y calibrar los límites del espacio de trabajo. Hasta cerrar esos puntos, no se puede afirmar que exista un bucle autónomo de percepción y manipulación.
El valor del proyecto está precisamente en no ocultar esa frontera. OpenArm es una plataforma de brazo humanoide abierta, con CAD, firmware, control y simulación publicados, pero convertir componentes accesibles en un sistema fiable sigue siendo un problema de integración. Este prototipo propone que cada supuesto —qué objeto se ve, qué acción admite y en qué coordenadas puede hacerse— quede expresado y verificable antes de que el robot se mueva.
Para la automatización de laboratorios, esa disciplina puede resultar más útil que una demostración vistosa. Una máquina que manipula recipientes químicos o muestras no solo necesita acertar; necesita explicar qué comprobó antes de actuar y detenerse cuando faltan datos. El siguiente paso será medir el rendimiento físico del conjunto en tareas reales. De momento, el trabajo ofrece una arquitectura abierta para llegar a esa prueba sin confundir una orden plausible con una acción segura.
![Imagen: diagrama técnico del prototipo publicado por los autores [en]](https://github.com/yshenfab/xEI/blob/main/fig/overview.png){kind=link}