Descripción general del sistema
Esta estructura se sitúa entre el middleware robótico clásico y la robótica reciente basada en lenguaje. Los sistemas basados en LLM y Vision-Language-Action (VLA) demuestran priors potentes a nivel de tarea y una gran capacidad de generalización.
Poses de objetos y parámetros de operación
La tercera transferencia convierte la percepción en objetos orientados al tiempo de ejecución. Un WorldObject contiene una pose 6D, un ID de marco de referencia, confianza, roles, habilidades y metadatos. La frontera de servicio de FoundationPose es ahora un protocolo HTTP/RGB-D concreto: el agente envía consultas sobre los objetivos, un marco de salida, los parámetros intrínsecos de la cámara, RGB, profundidad y máscaras opcionales; el servicio del lado de la GPU devuelve nombres de objetos, marcos, confianza, habilidades, roles, poses y metadatos de malla. El servicio también expone endpoints de estado, modelo y objetos, además de un modo simulado para la integración de software antes de disponer de la pila de percepción en GPU y de las máscaras.
A continuación, el prototipo enriquece los registros WorldObject con parámetros de operación deterministas. A partir de la pose, el tamaño calculado, los roles, las habilidades disponibles y los enlaces del tiempo de ejecución, el planificador de parámetros de operación genera parámetros de aproximación, agarre, elevación, colocación, inserción, vertido, dispensación, toque, deslizamiento y giro. Estos valores predeterminados se almacenan como perception_args, skill_args y target_skill_args, y el tiempo de ejecución los combina al compilar una llamada a una habilidad.
Esta transferencia actúa como un puente interpretable entre las salidas de percepción y las plantillas de habilidades, de modo que una traza de ejecución en seco pueda explicar exactamente por qué se eligió una pose de recogida, una pose de colocación, una profundidad de inserción o una holgura de vertido determinadas.
Representación de objetivos y tareas
Esta política de detenerse ante el primer fallo es deliberadamente conservadora. Evita que un planificador lingüístico disimule carencias de percepción o habilidades no compatibles. También facilita la depuración de las transferencias de representación: un fallo puede localizarse en la preparación del origen de la escena, la puesta en referencia del mundo, la validación del planificador, la cobertura de habilidades, la resolución de parámetros de operación, la comprobación previa del tiempo de ejecución, la validación de seguridad, el direccionamiento del ejecutor o la ejecución en el hardware.
Lecciones de campo
Lección 1: La pose 6D es necesaria, pero no suficiente
Las salidas de FoundationPose son valiosas, pero un sistema de manipulación móvil necesita, además de la pose, el marco de referencia, la confianza, la identidad del objeto, la geometría, las habilidades, los roles y los parámetros de operación específicos del objetivo. El planificador posterior debe recibir un objeto accionable, no un resultado de percepción en bruto.
Lección 2: Los perfiles son representaciones, no meras configuraciones
Los perfiles de uso, calibración y desarrollo codifican tres formas distintas de estado: priors de objetos, datos geométricos del despliegue y contratos de capacidades. Tratar estos perfiles como representaciones de primer nivel hizo que las comprobaciones de arranque y las trazas de ejecución en seco fueran más informativas que los archivos de configuración improvisados.
Lección 3: Las formas intermedias restringidas hacen depurable la planificación con LLM
El LLM solo propone llamadas a habilidades registradas bajo un contrato de banco de habilidades. No puede inventar comandos ROS arbitrarios, ignorar requisitos de roles, utilizar argumentos no declarados ni ejecutar rutinas de recuperación no registradas. Este diseño sacrifica flexibilidad, pero hace visibles las capacidades no compatibles como unmapped_requests, en lugar de ocultarlas tras supuestos del modelo.
Lección 4: Los bloqueos del despliegue son bloqueos de representación
El trabajo restante con el robot real no consiste únicamente en poner en marcha el hardware. También requiere completar las representaciones que faltan: transformaciones medidas de la cámara, el lidar y el carro; localización del marco de la mesa; mallas de objetos; máscaras o detecciones RGB-D reales; y límites calibrados del espacio de trabajo.
El valor del informe de campo es que estos bloqueos aparecen en las interfaces de representación, donde pueden someterse a pruebas.
Conclusión
Este informe replantea un prototipo de inteligencia corporeizada basado en OpenArm como un conjunto de transferencias de representación a lo largo de la integración del sistema. El artefacto central no es un nuevo modelo de percepción ni un controlador, sino una ruta auditable que va desde las instrucciones de laboratorio, los mapas, las poses de objetos, los priors de objetos y los contratos del banco de habilidades hasta las llamadas a habilidades validadas, los parámetros de operación, los objetivos de movimiento y la retroalimentación del tiempo de ejecución.
La implementación actual aporta evidencias a nivel de software y mediante ejecuciones en seco de que estas transferencias son ejecutables, y al mismo tiempo deja claro qué falta antes de poder afirmar que existe manipulación visual en escenas reales. El siguiente paso consiste en sustituir los activos de calibración y los modelos provisionales por datos de campo medidos, alinear el servicio de FoundationPose con el registro de objetos del perfil de uso actual, activar una puesta en referencia estricta en escenas reales y evaluar los fallos a nivel de tarea en tareas de recogida, colocación, inserción, vertido, limpieza e interacción con pantallas.
Agradecimientos
Este trabajo cuenta con el apoyo del Shenzhen Fundamental Research Program, mediante la subvención n.º JCYJ20200109141235597; de la National Natural Science Foundation of China, mediante las subvenciones n.º 72401122 y 61761136008; de la Guangdong Basic and Applied Basic Research Foundation, mediante las subvenciones n.º 2024A1515012241 y 2021A1515110024; del Shenzhen Peacock Plan, mediante la subvención n.º KQTD2016112514355531; del Program for Guangdong Introducing Innovative and Entrepreneurial Teams, mediante la subvención n.º 2017ZT07X386; y del Australian Research Council (ARC), mediante las Discovery Grants DP210101093 y DP220100803.
Preguntas frecuentes
¿Qué convierte la tercera transferencia de representación? Convierte la percepción en objetos orientados al tiempo de ejecución que contienen poses, marcos, confianza, roles, habilidades y metadatos.
¿Por qué es conservadora la política de detenerse ante el primer fallo? Evita que los planificadores lingüísticos oculten carencias de percepción o habilidades no compatibles y facilita la localización de los fallos.
¿Qué información debe recibir el planificador posterior? Debe recibir un objeto accionable con pose, marco, confianza, identidad, geometría, habilidades, roles y parámetros de operación específicos del objetivo.
¿Qué falta antes de poder afirmar que existe manipulación visual en escenas reales? Hay que sustituir los activos de calibración y los modelos provisionales por datos de campo medidos, activar una puesta en referencia estricta en escenas reales y evaluar los fallos a nivel de tarea.