Uso de DROID, BridgeData V2 y Open X en un SO-100

Hay un conjunto de datos público de un millón de trayectorias en un bucket de Google Cloud y un SO-100 en el escritorio que costó de 110 a 150 EUR en piezas. ¿Por qué el primero no puede enseñar al segundo? En parte sí puede, pero casi ninguna de la transferencia ocurre donde la gente espera, y la parte que parece más fácil no funciona en absoluto.

Lo que sigue: qué hay dentro de DROID, BridgeData V2 y Open X-Embodiment, dónde cada uno choca con un brazo de 5 GDL de bajo costo, y qué hacer en su lugar. Cada número a continuación proviene del artículo, la tarjeta del conjunto de datos o el archivo fuente al que pertenece.

Lo que realmente contienen los tres conjuntos de datos

DROID

El más estandarizado de los tres. Un equipo en todas partes: un Franka Panda con una pinza Robotiq 2F-85, dos cámaras estéreo ZED 2 ajustables y una ZED Mini de muñeca, teleoperado con controladores Meta Quest 2, grabado a través de Polymetis a 15 Hz tanto en el espacio de articulación como en el de efector final. Las etiquetas de idioma llegaron más tarde a través de tasq.ai, hasta tres por episodio.

• 76k trayectorias, 350 horas, 564 escenas, 84 tareas, 50 recolectores en tres continentes.
• El resultado principal es el co-entrenamiento, no el entrenamiento independiente: los lotes mezclados 50/50 con demostraciones en el dominio superan al siguiente mejor método en un 22 por ciento de éxito absoluto en la distribución, y un 17 por ciento fuera de ella.
• IPEC-COMMUNITY/droid_lerobot: 92,233 episodios, 27,044,326 fotogramas, franka, 15 fps, codebase_version v2.0, tres transmisiones AV1 a 180x320, 392 GB.
• Una muestra de depuración de 2 GB y 100 episodios se encuentra en gs://gresearch/robotics/droid_100. Empiece por ahí.

BridgeData V2

Lo más parecido a una configuración de aficionado: un brazo WidowX 250 de 6 GDL, 60,096 trayectorias en 24 entornos y 13 habilidades a 5 Hz. Nótese la composición: 50,365 demostraciones teleoperadas por expertos más 9,731 de una política de recogida y colocación (pick-and-place) aleatoria y programada, por lo que aproximadamente el 16 por ciento no es una demostración humana, lo cual es importante para aprendizaje por imitación la calidad. La descarga habitual, IPEC-COMMUNITY/bridge_orig_lerobot, informa de 53,192 episodios y 1,893,026 fotogramas a 5 fps, robot_type widowx: menos que los 60,096 del artículo, así que lea el recuento de meta/info.json en lugar de citar cualquiera de los dos.

Open X-Embodiment

No es un conjunto de datos en el mismo sentido: 60 conjuntos de datos de robots existentes de 34 laboratorios agrupados en una colección RLDS que cubre 22 implementaciones y más de un millón de trayectorias. BridgeData V2 se encuentra dentro como bridge_orig; la porción google_robot, fractal20220817_data, se convierte en 87.212 episodios a 3 fps.

La agrupación conlleva una advertencia que el artículo establece explícitamente. Para los experimentos RT-X, los autores convierten cada fuente en una acción de efector final de 7 GDL, pero no alinean los sistemas de coordenadas entre los conjuntos de datos, y permiten que los valores de acción sean posiciones o velocidades absolutas o relativas, según el esquema de control original de cada robot. Su conclusión: el mismo vector de acción puede inducir movimientos muy diferentes para distintos robots.

El desajuste, en cuatro partes

La falta de coincidencia de encarnación (embodiment mismatch) suele tratarse como un problema vago. Son cuatro, fallan de manera diferente, y dos no se pueden solucionar con scripts.

1. Grados de libertad

Un SO-100 tiene cinco articulaciones en el brazo más una pinza. Contado como motores, es un brazo de 6 GDL, y el artículo de SmolVLA lo llama así; contado como mecanismo de posicionamiento es de 5 GDL, y LeRobot lo llama así en su docstring de cinemática inversa, que describe la cinemática inversa de orientación suave en el SO-101 de 5 GDL donde la muñeca sigue la orientación solo parcialmente. Un Franka tiene siete articulaciones de posicionamiento. Esa brecha decide qué poses existen: un brazo de 5 GDL generalmente no puede alcanzar una posición y orientación arbitrarias a la vez, por lo que el solucionador devuelve lo más cercano que puede, un movimiento diferente al demostrado. Antecedentes: .

# src/lerobot/robots/so_follower/so_follower.py
motors = {
    "shoulder_pan":  Motor(1, "sts3215", norm_mode_body),
    "shoulder_lift": Motor(2, "sts3215", norm_mode_body),
    "elbow_flex":    Motor(3, "sts3215", norm_mode_body),
    "wrist_flex":    Motor(4, "sts3215", norm_mode_body),
    "wrist_roll":    Motor(5, "sts3215", norm_mode_body),
    "gripper":       Motor(6, "sts3215", MotorNormMode.RANGE_0_100),
}
# action keys are "<motor>.pos"; send_action sync_writes them to
# "Goal_Position"  ->  a 6-D ABSOLUTE JOINT POSITION command


# openpi/src/openpi/policies/droid_policy.py
def make_droid_example() -> dict:
    return {
        "observation/exterior_image_1_left": np.random.randint(256, size=(224, 224, 3), dtype=np.uint8),
        "observation/wrist_image_left":      np.random.randint(256, size=(224, 224, 3), dtype=np.uint8),
        "observation/joint_position":        np.random.rand(7),   # seven Franka joints
        "observation/gripper_position":      np.random.rand(1),
        "prompt": "do something",
    }
# state = concat(joint_position, gripper_pos)  ->  8-D

Así que un punto de control DROID prefabricado no es un atajo. Physical Intelligence distribuye pi05_droid en gs://openpi-assets/checkpoints/pi05_droid, y el mismo README que elogia su amplitud advierte que estos puntos de control expertos pueden no generalizarse a tu configuración. Su estado son ocho números de articulación de Franka y sus claves de imagen son exterior_image_1_left y wrist_image_left. Ninguna bandera convierte eso en un comando SO-100 de seis motores.

2. Lo que realmente dice el vector de acción

Más allá de la dimensionalidad. En las conversiones de LeRobot, los tres indican dónde debe ir el efector final, en el espacio cartesiano. Un SO-100 indica dónde deben ir seis servomotores. La conversión requiere un modelo cinemático y un solucionador, no una remodelación.

LeRobot sí incluye la pieza que falta: el seguidor SO tiene un procesador de cinemática con pasos InverseKinematicsEEToJoints y ForwardKinematicsJointsToEE. Sus claves son ee.x, ee.y, ee.z más un vector de rotación ee.wx, ee.wy, ee.wz y ee.gripper_pos, por lo que incluso la codificación de orientación difiere del roll-pitch-yaw en los archivos. El paso IK toma un orientation_weight, por defecto 0.01, cuya docstring indica establecer 0.0 para IK solo de posición en brazos subactuados. Se puede construir el puente, pero la mitad de orientación de cada acción prestada permanece aproximada.

3. Frecuencia de control

DROID es de 15 Hz, BridgeData V2 de 5 Hz, el segmento google_robot de 3 fps; los autores de pi0 describen la parte de código abierto de su mezcla como control de baja frecuencia entre 2 y 10 Hz. DatasetRecordConfig de LeRobot por defecto tiene fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. Una entrenada con datos de 5 Hz aprendió que una acción cubre 200 ms. Si se reproduce a 30 Hz, el brazo se arrastra; si se remuestrea ingenuamente, se difumina el fotograma donde el gripper se cierra. También interactúa mal con : un fragmento de 100 pasos es de 20 segundos a 5 Hz, 3.3 a 30 Hz.

4. Cámaras

BridgeData V2 aleatorizó dos poses de cámara cada 50 trayectorias, y su página de proyecto señala que la mayoría de los datos solo contienen la vista fija de todos modos. DROID utilizó soportes ajustables ZED 2 más una ZED Mini en la muñeca. Tienes dos cámaras web USB posicionadas a ojo. La pose de la cámara no es una variable molesta para un ; es gran parte de lo que el codificador visual se basó, y nada en el formato de archivo indica que las poses difieran.

¿Qué sucede cuando intentas fusionar los datos de todos modos?

El plan obvio es concatenar: unos pocos miles de episodios DROID más tus 50. LeRobot se niega, y la negativa nombra las tres cosas que difieren.

1. 1
   Descarga la muestra de 100 episodios, no los 1.7 TB completos

   2 GB son suficientes para ver la estructura.

   bash

   pip install gsutil tensorflow tensorflow-datasets
   gsutil -m cp -r gs://gresearch/robotics/droid_100 ~/tensorflow_datasets/

2. 2
   Convierte RLDS al formato LeRobot

   openx2lerobot envuelve las transformaciones estándar de OXE y anota el tipo de robot y la frecuencia de control. El README lo incluye en convert.sh.

   bash

   git clone https://github.com/Tavish9/any4lerobot.git
   cd any4lerobot/openx2lerobot
   
   python openx_rlds.py \
       --raw-dir ~/tensorflow_datasets/droid_100/1.0.0 \
       --local-dir ~/lerobot_droid100 \
       --repo-id you/droid100_lerobot \
       --use-videos

3. 3
   Lee meta/info.json antes que nada

   Este archivo decide si el resto de tu día funciona.

   bash

   python -c "import json;d=json.load(open('meta/info.json'));\
   print(d['codebase_version'], d['robot_type'], d['fps']);\
   print(d['features']['action']['shape'], d['features']['observation.state']['shape'])"

4. 4
   Intenta la fusión y lee el error

   merge carga cada conjunto de datos, luego validate_all_metadata verifica los fps, robot_type y las características contra el primero de la lista, generando un error en la primera discrepancia.

   bash

   lerobot-edit-dataset \
       --new_repo_id you/mixed \
       --operation.type merge \
       --operation.repo_ids "['you/droid100_lerobot', 'you/my_so100_task']"
   
   # ValueError: Same fps is expected, but got fps=30 instead of 15.

Los valores de referencia provienen del conjunto de datos que listaste primero, por lo que el mensaje se queja de tus 30 fps en lugar de los 15 de DROID. Corrige los fps y te encontrarás con la verificación de robot_type; corrige eso y te encontrarás con la verificación de características, 7 contra 6 para la acción. Ningún ordenamiento funciona, y la misma protección se ejecuta en el momento de la grabación a través de sanity_check_dataset_robot_compatibility.

¿Qué se transfiere realmente?

Pesos, no episodios. Cada política generalista moderna absorbió parte de esto en el preentrenamiento, y cuando desde un lo heredas ya reconciliado por personas con la capacidad de cómputo para hacerlo correctamente. El artículo de pi0 es sincero sobre la proporción: el 9.1 por ciento de su mezcla de preentrenamiento, contada en pasos de tiempo, son datos de código abierto que incluyen OXE, Bridge v2 y DROID. Esa cifra es de pi0; la mezcla de cada proveedor difiere.

Esta es la razón por la que SmolVLA se comporta de manera diferente en un brazo de bajo costo. Su artículo selecciona 481 conjuntos de datos de la comunidad de Hugging Face, filtrados por tipo de encarnación, recuento de episodios, calidad de los datos y cobertura de fotogramas: 22.9K episodios, 10.6M fotogramas, evaluados en brazos reales SO-100 y SO-101. Pequeño y emparejado supera a grande y desemparejado. Compare en ACT contra SmolVLA.

Tres caminos que vale la pena tomar

Ruta A: ajuste fino desde un punto de control que ya absorbió los datos

La mayoría de la gente debería tomar este camino. Nunca toque DROID ni Open X-Embodiment: elija una política cuyo preentrenamiento ya haya absorbido datos de encarnación cruzada, grabe sus propios episodios, realice un ajuste fino.

ACT es el caso límite honesto: sin modelo base, por lo que ninguno de los datos públicos lo alcanza. No es automáticamente una desventaja, ya que a 20 ms por paso de acción es el único de los cinco que puede cerrar un bucle rápido, como la página de ACT se detalla. Elija por tarea usando los cinco comparados, GR00T N1.7 contra Pi0.5, y los 332 resultados de referencia en 85 modelos en la arena.

Ruta B: usar DROID como dispositivo de prueba

La muestra de 100 episodios es la mejor de 2 GB que descargará este mes, y no para entrenamiento. Es un conjunto de datos que sabe que es correcto. Ejecute su convertidor, cargador y un trabajo corto de GPU en él; cualquier cosa que falle es un error de infraestructura encontrado mientras era barato. NVIDIA hace lo mismo a escala: la tarjeta GR00T N1.7 enumera cuatro variantes post-entrenadas, para Bridge y Fractal en SimplerEnv, DROID y LIBERO.

Ruta C: graba tus propios datos, deliberadamente

Treinta a cincuenta suena poco al lado de 76,000 hasta que recuerdas que los tuyos son los únicos con tu brazo, tus cámaras y tu mesa. Con los valores predeterminados de LeRobot, 50 episodios equivalen a 100 minutos de tiempo real. Consulta , y .

Dos formas de pasar de datos públicos a una política funcional

Lo que cuesta cada ruta

La asimetría es el punto clave: la ruta que toma prestados más datos es la más cara y la menos probable de mover tu brazo. Menos de dos horas de tu propia teleoperación superan un terabyte de una Franka ajena. ¿Aún no tienes un brazo? /live transmite un SO-100 físico sin necesidad de registrarse. Luego entrena tu primera política, y SmolVLA en SO-100 para la guía específica.