Integración humanoide LeRobot SONIC: los tokens de movimiento no son articulaciones motoras

Lo que realmente agrega la integración humanoide de LeRobot

La integración humanoide LeRobot SONIC es interesante porque no pide a una política de tareas que controle directamente cada motor de un Unitree G1. Ese es el instinto correcto. Una política humanoide puede predecir una representación compacta del movimiento, mientras un controlador local maneja el movimiento de cuerpo completo y proporciona objetivos articulares para el seguimiento de bajo nivel. Esta separación no establece un equilibrio seguro en una configuración no probada.

Para el checkpoint de colocación de latas, la política de tareas predice 64 valores de token de movimiento más dos campos de pinza. Esos 64 valores no son 64 comandos articulares. Son coordenadas latentes. Un decodificador integrado combina ese token con el historial reciente del estado del robot y luego produce objetivos articulares para el bucle de control proporcional derivativo del robot.

Esa separación es el punto central. También es donde una integración descuidada puede fallar.

Una nota de integración útil, no un benchmark nuevo

El artículo de integración humanoide de LeRobot del 25 de septiembre explica cómo encajan la teleoperación, el aprendizaje de políticas y el control del Unitree G1. El checkpoint y el conjunto de datos de colocación de latas ya eran artefactos de agosto, por lo que el anuncio no debe leerse como una nueva publicación de modelo con pesos nuevos. La parte útil es el diagrama de cableado, especialmente la forma en que expone el límite entre la salida de la política y el control de movimiento integrado.

La primera pregunta práctica es la compatibilidad

La publicación describe un flujo de trabajo. La documentación del controlador describe el despliegue. El checkpoint describe una política entrenada. Leer los tres juntos plantea una pregunta simple: ¿el runtime proporciona las observaciones que el checkpoint fue entrenado para usar?

Esa pregunta sigue sin resolverse. La política de latas espera 31 valores de estado. El controlador SONIC documentado expone 64 valores de eco de token. Las dimensiones de acción compartidas no resuelven el asunto.

Esto es distinto de la transferencia de almacenamiento cubierta en nuestro análisis de integración LeRobot LanceDB. Un conjunto de datos legible y un checkpoint cargable son útiles, pero no demuestran que un runtime de robot en vivo esté alimentando la misma representación de estado que la política aprendió.

Por qué la política de tareas no es el controlador de equilibrio

El token no es una lista de motores

La publicación describe una representación latente SONIC de 64 dimensiones. El checkpoint de latas agrega dos campos de pinza. Esas coordenadas codifican la intención de movimiento. No son posiciones articulares, objetivos de torque ni una lista directa de comandos de actuadores.

La documentación del G1 describe SonicWholeBodyController decodificando un token más propiocepción reciente en una acción residual. Ese residual se escala y se suma a ángulos de pie predeterminados, lo que produce objetivos para 29 articulaciones. El control PD del robot luego sigue esos objetivos.

El decodificador carga pesos ONNX y constantes de despliegue desde lerobot/sonic_decoder. La implementación fijada lee ganancias PD, ángulos predeterminados, escala de acción y un token neutro desde los metadatos ONNX. También separa el orden de articulaciones de IsaacLab del orden de despliegue de MuJoCo. Esos mapeos no son contabilidad. Son parte del contrato de movimiento.

Para una visión más amplia de las suposiciones de hardware y controlador, nuestro análisis de morfología y control de BRIDGE es contexto útil. No demuestra que BRIDGE y SONIC compartan una interfaz.

La inferencia remota no debe poseer el bucle local

Para el despliegue físico, la documentación describe un policy_server del lado de la GPU, un robot_client integrado que ejecuta el controlador SONIC en el Jetson del G1 y el puente run_g1_server. Los fragmentos de tokens se mueven por la red. El controlador integrado está diseñado para ejecutar su bucle documentado de 50 Hz usando propiocepción local; el cumplimiento real de los plazos debe medirse.

Este diagrama es un mapa conceptual de interfaz, no un despliegue verificado. El procesador de observaciones se deja sin resolver a propósito. El ciclo de retroalimentación local no debería necesitar un nuevo resultado de inferencia de GPU en cada tick del controlador. El almacenamiento en búfer puede reducir la dependencia de la latencia remota, pero no demuestra equilibrio seguro ni comportamiento útil después de una pérdida de red.

La colocación asíncrona y el RTC guiado son mandos distintos

El despliegue asíncrono decide dónde se ejecuta la inferencia y cómo llegan los fragmentos de acción al robot. El chunking guiado en tiempo real, o RTC, aborda la predicción a través de los límites de los fragmentos de acción. La tarjeta del checkpoint de latas recomienda RTC guiado, mientras también dice que este checkpoint no fue entrenado para RTC entrenado ni piR2.

No fusiones esas ideas en una sola afirmación. El muestreo del conjunto de datos a 50 fps, un fragmento de 50 acciones, la cadencia de publicación y un controlador de 50 Hz son cantidades separadas. Los números coincidentes pueden ser una pista. No son prueba de que los relojes coincidan en un sistema en vivo.

El mapa de interfaz de token a movimiento

Empieza con la semántica, luego comprueba las formas

La configuración del checkpoint declara observation.state con forma [31] y action con forma [66]. El esquema del conjunto de datos nombra los campos de estado: 29 posiciones articulares, luego valores de pinza izquierda y derecha. Sus campos de acción son motion_token_0 hasta motion_token_63, seguidos por las pinzas.

La parte 5 de la documentación principal actual del G1, en cambio, dice que SonicWholeBodyController devuelve un estado de observación de eco de token de 64 dimensiones. La función observation_state() de la implementación fijada confirma que expone el último token decodificado, no el vector medido de articulaciones y pinzas del checkpoint.

Esa es la brecha principal de integración. La compatibilidad directa no está establecida. Un equipo necesita resolver el procesador de observaciones, el mapeo de estado físico, la normalización y la revisión de código antes de conectar estos artefactos. Rellenar un vector articular o recortar un vector latente solo hace que el tensor pase una comprobación de forma. No hace que los valores signifiquen lo mismo.

La tabla de la tarjeta del modelo también etiqueta la acción como "64 articulaciones + 2 pinzas". Eso entra en conflicto con los campos de configuración nombrados, el esquema del conjunto de datos y la explicación de la publicación. Para esta interfaz, los artefactos tipados pesan más que la redacción de la tabla.

Matriz de compatibilidad para la ruta completa de movimiento

El mapa de interfaz de token a movimiento siguiente es una síntesis editorial de los artefactos inspeccionados. No es un estándar y no es una receta de despliegue probada por Optijara. Su trabajo es hacer visible la evidencia faltante antes de que alguien elija un runtime.

La tarjeta del checkpoint registra el código de LeRobot 8bf6056d1. La fuente del controlador inspeccionada aquí está fijada a e595b7902714ba51f91e47523f66f89c5181b649. La documentación principal actual requiere una instalación desde fuente y distingue la versión estable v0.6.1. Sus ejemplos de SONIC usan nepyope/sonic_walk, no el checkpoint de latas. Trátalos como referencias relacionadas, no como instrucciones intercambiables.

{
  "contract": {
    "checkpoint_state": "29 joint positions plus 2 grippers",
    "checkpoint_action": "64 SONIC coordinates plus 2 grippers",
    "documented_controller_state": "64-value token echo"
  },
  "proposedchecks": ["Resolve observation processor", "Verify names and normalization", "Pin compatible runtime revisions"],
  "limitations": ["Drop-in compatibility unresolved", "No inference, simulation or hardware tests performed for this article"]
}

Lo que muestra el checkpoint de latas y lo que no

Lee la tarea, las cámaras y la temporización como un contrato

La tarjeta del conjunto de datos can_clean_final describe 105 episodios y 212.290 fotogramas a 50 fps. Los tres flujos de cámara de 480 por 640 son ego_view, left_wrist y right_wrist. La única tarea es Bring the can to the white table. Esos detalles definen el contrato de entrada del checkpoint. No establecen rendimiento en otra sala, con otro montaje de cámara o bajo una instrucción de tarea diferente.

El conjunto de datos documenta action[t] como el comando que produce observation.state[t+1]. Conserva esa relación al construir ejemplos de reproducción. El estado con el mismo índice no debe convertirse silenciosamente en el resultado atribuido a la acción.

La tarjeta también informa que observation.state[29] y action[64], los campos de la pinza izquierda, siempre son cero. En términos prácticos, las grabaciones fueron de una sola mano. Dos campos de salida de pinza no proporcionan evidencia de habilidad bimanual.

La normalización necesita el mismo cuidado. La configuración especifica normalización por cuantiles para estado y acción. La tarjeta del conjunto de datos dice que los límites de cuantiles de la pinza izquierda se fijaron manualmente para evitar división por cero. Una migración del procesador tiene que preservar ese manejo en lugar de interpretar un rango numérico válido como comportamiento útil de la mano izquierda.

La pérdida no es una afirmación de éxito en la tarea

El conjunto de datos fue revisado y se eliminaron fallos. La tarjeta del checkpoint informa una pérdida final de entrenamiento de 0,025, explícitamente sin una partición de reserva. Es metadato útil de entrenamiento. No es éxito autónomo en la tarea y no es evidencia de generalización.

La lectura justa es más estrecha: estos artefactos documentan una configuración de entrenamiento y exponen restricciones que una evaluación compatible debe respetar. Las afirmaciones de capacidad necesitan evidencia separada de bucle cerrado. Presupuesta explícitamente la comprobación de suposiciones de interfaz y la evaluación del comportamiento, en lugar de tratar la disponibilidad de artefactos como prueba de compatibilidad.

Un plan de adopción con simulación primero para la pila de movimiento del G1

Etapa 1: conciliar el contrato offline

Todas las comprobaciones siguientes son propuestas. Optijara no ha ejecutado inferencia, simulación, entrenamiento ni pruebas físicas con robots para este artículo.

Empieza con la inspección de artefactos. Fija revisiones. Compara nombres de estado y unidades. Confirma el orden articular. Rastrea ambas pinzas por separado. Compara identidades de cámaras y preprocesamiento con el checkpoint, no solo dimensiones de imagen. Inspecciona la normalización de estado y acción y las constantes del decodificador. Trata el mapeo de observación de 31 frente a 64 sin resolver como una condición de parada.

Este también es el lugar para comprobar la alineación temporal. Una canalización de reproducción que suministra los campos correctos desde el timestep equivocado no ha reproducido la interfaz de entrenamiento. Registra las decisiones del procesador para que otro ingeniero pueda distinguir transformaciones deliberadas de coerción accidental.

Etapa 2: separar la temporización de la política de la temporización del controlador

Después de resolver herramientas y mapeos compatibles, ejecuta reproducción offline o simulación de la interpretación de token a objetivo antes de juzgar el comportamiento de tarea aprendido. La documentación proporciona ejemplos de simulación, pero eso no muestra que un simulador sin cambios reproduzca esta pila exacta de política de latas.

Define umbrales de aceptación para la configuración prevista antes de probar. Este artículo no proporciona valores predeterminados universales de seguridad. Registra la cadencia de publicación y el consumo de cola junto con la latencia de inferencia; un promedio decente puede ocultar interrupciones. Para una discusión complementaria de la evidencia conductual, consulta nuestro mapa de evaluación robótica de video a tarea.

Etapa 3: decidir si la preparación de hardware está justificada

Adopta ahora la inspección de interfaz. Migra procesadores solo después de que sus significados estén resueltos. No trasplantes un comando de tarjeta de checkpoint al código de hardware principal actual solo porque ambos mencionan Unitree G1.

Antes de cualquier prueba física, exige procedimientos de seguridad del fabricante, un área de prueba controlada y una parada de emergencia funcional. Revisa explícitamente el comportamiento de cola obsoleta y pérdida de red. Este artículo no establece un watchdog predeterminado ni recomienda una prueba de humo síncrona en hardware.

Errores comunes y limitaciones que conviene mantener visibles

Errores que hacen que la interfaz parezca más segura de lo que es

• Tratar coordenadas latentes como articulaciones motoras omite el papel del decodificador. Rastrea la decodificación de tokens y la conversión de orden articular.
• Coincidir dimensiones de acción mientras se ignora el significado de observación deja sin resolver la entrada de la política. Comprueba ambos lados del contrato.
• Llamar 50 Hz a la velocidad de la política confunde el control local con el rendimiento de inferencia. Mídelos por separado.
• Inferir habilidad bimanual de dos campos de salida ignora la pinza izquierda registrada como inactiva.
• Tratar RTC guiado como despliegue asíncrono seguro confunde la predicción de fragmentos con la colocación del runtime y el manejo de fallos.

Licencias, seguridad y compromisos operativos

El listado de archivos del decodificador SONIC inspeccionado expone artefactos del decodificador, pero no muestra una tarjeta de modelo ni un archivo de licencia visibles. Esa ausencia no es una conclusión legal. Revisa por separado los términos del modelo base, decodificador, software del controlador, conjunto de datos y hardware; una licencia de biblioteca o conjunto de datos no concede permiso para todos los componentes.

La deriva de la rama principal y los procesadores de la época del checkpoint complican la reproducibilidad. La colocación de cámaras, las convenciones de propiocepción y las diferencias de ejecución en GPU también necesitan revisión. Si las observaciones de cámara salen del robot para inferencia remota, evalúa controles de acceso y privacidad para el entorno operativo.

Presupuesta trabajo de integración y evaluación sin asumir preparación para producción. La decisión inmediata es si un equipo puede establecer un contrato consistente de observación a token a movimiento, con las suposiciones sin resolver visibles antes de que empiece la preparación de hardware.