RynnBrain 1.1: la prueba de aceptación de manipulación de robots con conexión a tierra 3D para operadores

Un robot puede identificar el objeto correcto y aun así estropear el trabajo. La taza es visible. El modelo así lo señala. Luego, la pinza se acerca desde el marco de coordenadas equivocado, atrapa la pared curva en lugar de la zona del asa, sujeta el objeto que está junto a ella y convierte una ganancia de percepción en un fracaso de manipulación. Esa brecha, entre ver y actuar de forma segura, es donde debería vivir una prueba de aceptación de RynnBrain 1.1.

Alibaba DAMO Academy presenta RynnBrain 1.1 como una familia de modelos de base incorporados abiertos en escalas 2B, 9B y 122B-A10B. La página y el artículo del proyecto describen la conexión a tierra 3D nativa para modelos compactos, la predicción de puntos de contacto con orientación de agarre en el plano y RynnBrain-VLA con un espacio de acción unificado entre encarnaciones más enmascaramiento específico de encarnaciones. Los mismos materiales también informan evaluaciones de robots reales en los sistemas Unitree G1, Astribot-S1 y Tianji-Wuji. Trate esos resultados de referencia y de robots reales como afirmaciones informadas por el autor hasta que su equipo los reproduzca.

Para los operadores, el lanzamiento es interesante. Ésa no es la pregunta difícil. La pregunta difícil es si transmite sus artefactos, robots, escenas, procesos de seguridad, presupuesto de latencia y ruta de recuperación. Si su equipo está comparando pilas de robótica abierta relacionadas, combine este artículo con la planificación de infraestructura de robótica perimetral de Optijara, aceptación de recuperación de modelo abierto testing y evaluación del servicio de producción.

Por qué RynnBrain 1.1 necesita una prueba de aceptación

RynnBrain 1.1 no es una tarjeta modelo para hojear mientras se toma un café. Sus afirmaciones se sitúan en el límite entre la percepción, el razonamiento espacial, el control de robots y el contacto físico. La página oficial afirma que RynnBrain 1.1 introduce la predicción de puntos de contacto para ubicaciones de interacción relevantes para la tarea y orientaciones de agarre en el plano, mientras que los modelos 2B y 9B reciben supervisión 3D explícita para una conexión a tierra condicionada por el lenguaje en un espacio físico métrico. El documento arXiv debe tratarse como la principal referencia técnica, utilizándose GitHub, Hugging Face y ModelScope para confirmar los artefactos ejecutables.

Aquí está la versión contundente: una tabla de referencia no es un límite de control. Le indica dónde empezar a realizar las pruebas. No le dice qué automatizar.

Mantenga los reclamos separados. Las tablas de referencia, las comparaciones de escala y las declaraciones de superioridad de los robots reales son informadas por el autor hasta que su equipo las reproduce con código fijado, puntos de control fijados, hardware documentado y su distribución de escena de destino. Eso no debilita las afirmaciones. Los hace comprobables. La adopción de la robótica sale mal cuando los equipos confunden un resultado en papel con una decisión de producción.

La prueba de aceptación de manipulación 3D de Optijara está diseñada para ese problema. Separa la percepción 2D de la conexión a tierra métrica 3D, la conexión a tierra métrica del contacto utilizable, el contacto de la ejecución específica del robot y la ejecución del despliegue seguro. La regla es simple: si una versión no puede pasar una versión restringida del flujo de trabajo real, debe permanecer en evaluación.

Qué verificar primero: artefactos, licencias y ajuste del modeloAntes de cualquier prueba de robot, cree un registro de adopción. Capture la URL oficial del proyecto, el documento arXiv, el repositorio de GitHub, la colección Hugging Face, la colección ModelScope, los nombres de los puntos de control, las tarjetas de modelo, el texto de la licencia, las versiones de dependencia, los comandos de inferencia de muestra y cualquier declaración de seguridad o limitación. El repositorio de GitHub anuncia una licencia Apache-2.0 en la instantánea del repositorio en vivo verificada durante la verificación de hechos, pero los operadores aún deben confirmar si cada artefacto del modelo, dependencia del conjunto de datos e integración posterior tiene términos de redistribución y uso comercial coincidentes.

No descargue un punto de control y llame al artefacto verificado. Guarde los identificadores de confirmación, las marcas de tiempo de publicación cuando estén disponibles, los archivos hash si están publicados, sus propios hashes de archivos descargados, archivos de bloqueo del entorno, versiones del controlador GPU, scripts de inferencia y líneas de comando de evaluación. Seis meses después, ese rastro de evidencia es lo que le indica si un punto de referencia se desvió debido al modelo, el hardware, el preprocesamiento o su configuración.

Matriz de decisión 2B vs 9B vs 122B-A10B

Para plataformas de robots, evalúe la plataforma antes de evaluar el modelo. Unitree G1, Astribot-S1 y Tianji-Wuji se mencionan en el documento y los materiales del proyecto de RynnBrain. Representan diferentes supuestos de encarnación: movilidad y manipulación humanoide, manipulación bimanual y control manual diestro. Documente el conjunto de sensores, la geometría del efector final, la taxonomía de agarre, la API de control, el procedimiento de calibración, los límites del espacio de trabajo, el modelo de colisión, el mecanismo de parada de seguridad y los datos de demostración disponibles para cada plataforma.

La prueba de aceptación de manipulación 3D de Optijara

El marco tiene siete puertas. La integridad del artefacto es lo primero, seguida de la reproducción fuera de línea, la conexión a tierra métrica 3D, la viabilidad del contacto, el mapeo de la encarnación, la revisión de la envolvente de seguridad y el despliegue supervisado limitado. Un modelo pasa sólo cuando cada puerta tiene evidencia. Las impresiones no cuentan.

Etapa 1: localización 2D versus conexión a tierra métrica 3D

El apuntamiento 2D pregunta si el modelo puede indicar un objetivo en el espacio de la imagen. La manipulación pregunta si el robot puede llegar al lugar correcto en el mundo real. Su prueba debe comparar cuadros delimitadores o puntos con objetivos métricos 3D, consistencia de profundidad, orientación de objetos, superficies accesibles y transformaciones entre cámara, mundo, base de robot y marcos de herramientas.Comience con un escenario fijo. Incluya objetos conocidos, objetos nuevos, superficies desordenadas, objetivos ocluidos y objetos transparentes o reflectantes si aparecen en el flujo de trabajo. Agregue también cambios de estado: abierto o cerrado, vertical o inclinado, vacío o lleno. Una respuesta 3D válida debe repetirse después de la recalibración y mantenerse bajo iluminación moderada o cambios de punto de vista.

Etapa 2: Puntuación del punto de contacto y de la orientación de agarre

La predicción de puntos de contacto sólo es útil si sobrevive a la física. Califique si el punto previsto se encuentra dentro de una región de contacto válida para la tarea, si el vector de aproximación evita los objetos cercanos, si la orientación de la pinza coincide con la geometría del objeto y si el contacto propuesto evita riesgos de deslizamiento, torsión o colisión que sus sensores pueden observar.

Etapa 3: Calibración y coherencia del marco de coordenadas

Muchos fallos de manipulación no son fallos del modelo. Son errores de marco, desviaciones de la marca de tiempo, errores de escala de profundidad, extrínsecos obsoletos o transformaciones de herramientas que ya no coinciden con el hardware. Audite los extrínsecos de la cámara, el marco base del robot, la transformación del efector final, la escala de profundidad, la alineación de la marca de tiempo, la calibración ojo-mano y la repetibilidad de la recalibración. Requiere que la salida del modelo se registre con el marco al que hace referencia. Un punto sin marco no es un plan de acción.

Etapa 4: desorden, oclusión y cambios de estado de objeto

Las demostraciones limpias son necesarias, pero no prueban mucho por sí solas. Agregue distractores, oclusiones parciales, cambios de estado del contenedor, empaques deformables, superficies reflectantes y movimiento de objetos entre la percepción y la ejecución. La prueba de aceptación debe registrar si las fallas provienen de la percepción, la conexión a tierra, la predicción del contacto, la planificación, el control o la recuperación.

Evaluación VLA entre realizaciones: del plan de tareas a la acción segura

Un VLA de realización cruzada debe probarse como cadena. La comprensión de las instrucciones conduce a la planificación de subtareas. La planificación conduce a la puesta a tierra del escenario. La conexión a tierra conduce a propuestas de acción. Las propuestas de acción se traducen en comandos específicos del robot. El robot ejecuta, observa el resultado y continúa o se recupera. Un eslabón débil en cualquier parte de esa cadena puede invalidar el despliegue.

Las tareas de largo horizonte deben variar la ubicación de los objetos, los distractores, la iluminación, los estados intermedios y la redacción de las instrucciones. La descomposición debe permanecer estable cuando cambia el escenario, pero no puede ser rígida. Si una taza se cae, el sistema no debe continuar ciegamente con el agarre original.

El mapeo de encarnaciones cruzadas es la parte más difícil de falsificar. Acciones abstractas como recoger, verter, empujar, limpiar, colocar o entregar deben corresponderse con el espacio de trabajo accesible de cada plataforma robótica, la geometría de agarre o mano, los límites de las articulaciones, los marcos de herramientas, el modelo de colisión y la envolvente de fuerza o velocidad. Las máscaras de encarnaciones específicas deben bloquear poses inalcanzables, orientaciones inseguras, zonas prohibidas, fuerza excesiva y acciones incompatibles con herramientas.La observabilidad es obligatoria. Mensaje de registro, imágenes, entradas de profundidad, punto de contacto previsto, marco de coordenadas objetivo, seguimiento de acción, decisiones de máscara, confianza o incertidumbre si se expone, rama de recuperación, anulación del operador y etiqueta de resultado final. Sin ese rastro, no se puede distinguir una debilidad del modelo de un problema de calibración o un error del controlador.

Plan de Medición y Reproducción de Benchmark

Los materiales de RynnBrain hacen referencia a la cognición incorporada, el razonamiento espacial, la localización, la conexión a tierra en 3D y la evaluación de robots reales. El conjunto de reproducción requerido debe incluir los scripts de evaluación oficiales de RynnBrain, cuando estén disponibles, y documentación de referencia relevante, como VSI-Bench, MMSI-Bench, RefSpatial-Bench y la página del conjunto de datos de RynnBrain-Bench. Trate cada punto de referencia como un instrumento de medición, no como un proxy de implementación. Un modelo puede funcionar bien en comprensión espacial y aun así fallar en su pinza, conjunto de objetos, presupuesto de latencia o envolvente de seguridad.

La reproducción debe incluir código PIN, punto de control, versión del conjunto de datos, hardware, pila de controladores, semillas aleatorias cuando corresponda, preprocesamiento de imágenes, plantillas de mensajes y scripts de evaluación. Si el documento informa un resultado de referencia, reprodúzcalo antes de usarlo en un memorando de adopción. Si la reproducción falla, registre el bloqueador: artefactos faltantes, falta de coincidencia del entorno, preprocesamiento no documentado, diferencia de hardware o error de implementación.

Primero simule y luego utilice pruebas físicas limitadas. Las pruebas con robots reales deben realizarse a baja velocidad, dentro de un espacio de trabajo delimitado, con acceso a parada de emergencia, funcionamiento supervisado y condiciones de aborto definidas. Los recursos de robótica de fabricación inteligente del NIST son útiles para el pensamiento de evaluación, pero no tratan una prueba de aceptación de investigación como una certificación de seguridad.

{
  "model": "RynnBrain 1.1",
  "acceptance_gates": ["artifact_integrity", "benchmark_reproduction", "metric_3d_grounding", "contact_viability", "embodiment_mapping", "safety_envelope", "supervised_trial"],
  "required_metrics": ["valid_3d_target_rate", "contact_point_validity", "grasp_orientation_validity", "intervention_rate", "recovery_success", "latency_distribution", "calibration_drift_sensitivity"],
  "deployment_blockers": ["unverified_license", "unreproduced_benchmark", "missing_frame_trace", "unsafe_action_mask_gap", "uncontained_failure"],
  "first_trial_scope": "single robot, bounded workspace, known objects plus controlled clutter, supervised low-speed execution"
}

Errores comunes, advertencias y dónde no implementar

Los equipos se equivocan de manera predecible. Consideran el apuntamiento 2D como prueba de que están preparados para la manipulación 3D. Se saltan las auditorías de calibración porque una demostración funcionó una vez. Confían en los puntos de referencia en papel sin reproducción. Ignoran las diferencias de encarnación. Sólo prueban escenas limpias. Omiten la recuperación de fallos. Miden el éxito de la tarea, pero pasan por alto la calidad del contacto, los cuasi accidentes, las intervenciones y los errores de encuadre.

Las advertencias operativas son importantes. La evaluación requiere tiempo de ingeniería. El comportamiento del modelo puede variar según el tamaño, la ruta de servicio, la calidad del sensor, el formato del mensaje y el controlador del robot. Las transmisiones de la cámara pueden contener información confidencial. La simulación puede ocultar la fricción, el cumplimiento, la latencia y los cambios en el estado del objeto. Desviaciones de calibración. El hardware se desgasta. La inferencia en red puede añadir inquietud. Algunos artefactos del modelo pueden exponer menos incertidumbre o detalles de seguimiento de lo que desean los operadores.

No implemente un modelo incorporado abierto en manipulaciones críticas para la seguridad sin supervisión, espacios públicos ilimitados, interacciones de alta fuerza, tareas que requieren un comportamiento de seguridad certificado, herramientas inestables o flujos de trabajo donde las fallas no se pueden contener. Evite implementaciones que capturen datos visuales confidenciales sin control o donde los operadores no puedan inspeccionar ni anular acciones.

El camino práctico es estrecho y valioso: verificar el lanzamiento, reproducir lo que pueda, ejecutar una prueba de aceptación de manipulación 3D contenida y definir criterios de rechazo antes del lanzamiento. Para los equipos que evalúan la IA incorporada abierta, Optijara puede ayudar a traducir lanzamientos como RynnBrain 1.1 en planes de prueba, puertas de prototipos, reproducción de puntos de referencia y hojas de ruta de automatización más seguras sin exagerar la preparación.