Usando DROID, BridgeData V2 e Open X em um SO-100

Existe um conjunto de dados público de um milhão de trajetórias em um bucket do Google Cloud e um na mesa que custou 110 a 150 EUR em peças. Por que o primeiro não pode ensinar o segundo? Em parte pode, mas quase nenhuma da transferência acontece onde as pessoas esperam, e a parte que parece mais fácil não funciona de forma alguma.

O que se segue: o que está dentro de , e , onde cada um colide com um braço 5-DoF de baixo custo, e o que fazer em vez disso. Cada número abaixo veio do artigo, cartão do conjunto de dados ou arquivo fonte ao qual pertence.

O que os três conjuntos de dados realmente contêm

DROID

O mais padronizado dos três. Um único equipamento em todos os lugares: um Franka Panda com uma garra Robotiq 2F-85, duas câmeras estéreo ZED 2 ajustáveis e uma ZED Mini de pulso, teleoperado com controladores Meta Quest 2, gravado via Polymetis a 15 Hz tanto no espaço articular quanto no efetor final espaço. Rótulos de linguagem vieram depois via tasq.ai, até três por episódio.

• 76k trajetórias, 350 horas, 564 cenas, 84 tarefas, 50 coletores em três continentes.
• O resultado principal é o co-treinamento, não o treinamento autônomo: lotes misturados 50/50 com demonstrações no domínio superam o próximo melhor método em 22 por cento de sucesso absoluto na distribuição, 17 por cento fora dela.
• IPEC-COMMUNITY/droid_lerobot: 92.233 episódios, 27.044.326 quadros, franka, 15 fps, codebase_version v2.0, três fluxos AV1 a 180x320, 392 GB.
• Uma amostra de depuração de 2 GB e 100 episódios está em gs://gresearch/robotics/droid_100. Comece por lá.

BridgeData V2

O mais próximo de uma configuração de hobby: um braço WidowX 250 de 6 GDL, 60.096 trajetórias em 24 ambientes e 13 habilidades a 5 Hz. Observe a composição: 50.365 demonstrações teleoperadas por especialistas mais 9.731 de uma política de pegar e colocar (pick-and-place) roteirizada e aleatória, portanto, cerca de 16 por cento não é demonstração humana, o que é importante para a aprendizagem por imitação qualidade. O download usual, IPEC-COMMUNITY/bridge_orig_lerobot, relata 53.192 episódios e 1.893.026 quadros a 5 fps, robot_type widowx: menos do que os 60.096 do artigo, então leia a contagem de meta/info.json em vez de citar qualquer um.

Open X-Embodiment

Não é um conjunto de dados no mesmo sentido: 60 conjuntos de dados de robôs existentes de 34 laboratórios agrupados em uma coleção RLDS cobrindo 22 implementações e mais de um milhão de trajetórias. BridgeData V2 está contido nela como bridge_orig; a fatia google_robot, fractal20220817_data, converte-se em 87.212 episódios a 3 fps.

O agrupamento apresenta uma ressalva que o artigo declara abertamente. Para os experimentos RT-X, os autores convertem cada fonte em uma ação de efetuador final de 7-DoF, mas não alinham os sistemas de coordenadas entre os conjuntos de dados e permitem que os valores de ação sejam posições ou velocidades absolutas ou relativas, de acordo com o esquema de controle original de cada robô. A conclusão deles: o mesmo vetor de ação pode induzir movimentos muito diferentes para robôs diferentes.

A incompatibilidade, em quatro partes

A incompatibilidade de incorporação é geralmente tratada como um problema vago. São quatro, falham de maneiras diferentes, e duas não são corrigíveis por script.

1. Graus de liberdade

Um SO-100 tem cinco articulações de braço mais uma garra. Contado como motores, é um braço de 6-DoF, e o artigo SmolVLA o chama assim; contado como um mecanismo de posicionamento, é de 5-DoF, e LeRobot o chama assim em sua docstring de cinemática inversa, que descreve IK de orientação suave no SO-101 de 5-DOF onde o pulso rastreia a orientação apenas parcialmente. Um Franka tem sete articulações de posicionamento. Essa lacuna decide quais poses existem: um braço de 5-DoF geralmente não consegue alcançar uma posição e orientação arbitrárias ao mesmo tempo, então o resolvedor retorna o mais próximo que pode, um movimento diferente do demonstrado. Contexto: graus de liberdade.

# 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

Portanto, um checkpoint DROID pronto não é um atalho. A Physical Intelligence distribui pi05_droid em gs://openpi-assets/checkpoints/pi05_droid, e o mesmo README que elogia sua abrangência adverte que esses checkpoints especializados podem não se generalizar para sua configuração. Seu estado são oito números de junta Franka e suas chaves de imagem são exterior_image_1_left e wrist_image_left. Nenhuma flag transforma isso em um comando SO-100 de seis motores.

2. O que o vetor de ação realmente diz

Mais profundo que a dimensionalidade. Nas conversões LeRobot, todos os três indicam para onde a garra deve ir, no espaço cartesiano. Um SO-100 indica para onde seis servos devem ir. A conversão requer um modelo cinemático e um resolvedor, não um redimensionamento.

LeRobot realmente fornece a peça que falta: o seguidor SO possui um processador de cinemática com as etapas InverseKinematicsEEToJoints e ForwardKinematicsJointsToEE. Suas chaves são ee.x, ee.y, ee.z mais um vetor de rotação ee.wx, ee.wy, ee.wz e ee.gripper_pos, então até mesmo a codificação de orientação difere do roll-pitch-yaw nos arquivos. A etapa IK leva um orientation_weight, padrão 0.01, cuja docstring diz para definir 0.0 para IK somente de posição em braços subatuados. Você pode construir a ponte, mas a metade de orientação de cada ação emprestada permanece aproximada.

3. Taxa de controle

DROID é 15 Hz, BridgeData V2 5 Hz, o segmento google_robot 3 fps; os autores de pi0 descrevem a parte de código aberto de sua mistura como controle de baixa frequência entre 2 e 10 Hz. O DatasetRecordConfig do LeRobot padroniza para fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. Uma treinada com dados de 5 Hz aprendeu que uma ação cobre 200 ms. Reproduza-a a 30 Hz e o braço rasteja; reamostre ingenuamente e você borra o quadro onde o gripper fecha. Também interage mal com : um agrupamento de 100 passos é 20 segundos a 5 Hz, 3.3 a 30 Hz.

4. Câmeras

BridgeData V2 randomizou duas poses de câmera a cada 50 trajetórias, e sua página de projeto observa que a maior parte dos dados carrega apenas a visão fixa de qualquer forma. DROID usou suportes ajustáveis ZED 2 mais um ZED Mini de pulso. Você tem duas webcams USB posicionadas a olho. A pose da câmera não é uma variável incômoda para um ; é muito do que o codificador visual se baseou, e nada no formato do arquivo indica que as poses diferem.

O que acontece quando você tenta mesclar os dados de qualquer forma

O plano óbvio é concatenar: alguns milhares de episódios DROID mais os seus 50. LeRobot recusa, e a recusa nomeia as três coisas que diferem.

1. 1
   Baixe a amostra de 100 episódios, não o total de 1.7 TB

   2 GB é suficiente para ver a estrutura.

   bash

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

2. 2
   Converta RLDS para o formato LeRobot

   openx2lerobot encapsula as transformações padrão OXE e anota o tipo de robô e a frequência de controle. O README coloca isso em 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
   Leia meta/info.json antes de qualquer outra coisa

   Este arquivo decide se o resto do seu dia 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
   Tente a fusão e leia o erro

   merge carrega cada conjunto de dados, então validate_all_metadata verifica fps, robot_type e features contra o primeiro da lista, levantando um erro no primeiro desencontro.

   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.

Os valores de referência vêm de qualquer conjunto de dados que você listou primeiro, e é por isso que a mensagem reclama dos seus 30 fps em vez dos 15 do DROID. Corrija o fps e você encontrará a verificação de robot_type; corrija isso e você encontrará a verificação de features, 7 contra 6 para a ação. Nenhuma ordenação passa, e a mesma proteção é executada no momento da gravação via sanity_check_dataset_robot_compatibility.

Então, o que realmente é transferido?

Pesos, não episódios. Toda política generalista moderna absorveu parte disso no pré-treinamento, e quando você de um lançado, você o herda já reconciliado por pessoas com o poder de computação para fazê-lo corretamente. O artigo de pi0 é franco sobre a proporção: 9,1 por cento de sua mistura de pré-treinamento, contada em passos de tempo, são dados de código aberto, incluindo OXE, Bridge v2 e DROID. Esse número é de pi0; a mistura de cada fornecedor difere.

É por isso que SmolVLA se comporta de forma diferente em um braço de baixo custo. Seu artigo seleciona 481 conjuntos de dados da comunidade do Hugging Face, filtrados por tipo de incorporação, contagem de episódios, qualidade dos dados e cobertura de quadros: 22.9K episódios, 10.6M quadros, avaliados em braços reais SO-100 e SO-101. Pequeno e correspondente supera grande e incompatível. Compare em ACT contra SmolVLA.

Três caminhos que valem a pena seguir

Caminho A: ajuste fino a partir de um checkpoint que já absorveu os dados

A maioria das pessoas deve seguir este. Você nunca toca em DROID ou Open X-Embodiment: escolha uma política cujo pré-treinamento já absorveu dados de incorporação cruzada, grave seus próprios episódios, faça o ajuste fino.

ACT é o caso limite honesto: sem modelo base, então nenhum dos dados públicos o alcança. Não é automaticamente uma desvantagem, já que a 20 ms por passo de ação é o único dos cinco que pode fechar um ciclo rápido, como a página do ACT, estabelece. Escolha por tarefa usando todos os cinco comparados, GR00T N1.7 contra Pi0.5, e os 332 resultados de benchmark em 85 modelos na arena.

Caminho B: usar DROID como um dispositivo de teste

A amostra de 100 episódios é os melhores 2 GB que você baixará este mês, e não para treinamento. É um conjunto de dados que você sabe que está correto. Execute seu conversor, carregador e um trabalho curto de GPU nele; qualquer coisa que falhe é um bug de infraestrutura encontrado enquanto era barato. A NVIDIA faz o mesmo em escala: a placa GR00T N1.7 lista quatro variantes pós-treinadas, para Bridge e Fractal em SimplerEnv, DROID e LIBERO.

Caminho C: grave os seus próprios, deliberadamente

Trinta a cinquenta parece pouco perto de 76.000 até você se lembrar que os seus são os únicos com o seu braço, suas câmeras e sua mesa. Nos padrões do LeRobot, 50 episódios equivalem a 100 minutos de tempo real. Veja , e .

Duas maneiras de passar de dados públicos para uma política funcional

Quanto custa cada caminho

The asymmetry is the point: the path that borrows the most data is the most expensive and least likely to move your arm. Under two hours of your own teleoperation beats a terabyte of somebody else's Franka. No arm yet? /live streams a physical SO-100 with no signup. Then train your first policy, and SmolVLA on SO-100 for the specific guide.