Integração Humanoide LeRobot SONIC: Tokens de Movimento Não São Juntas Motoras

O que a integração humanoide do LeRobot realmente acrescenta

A integração humanoide LeRobot SONIC é interessante porque não pede a uma política de tarefa que conduza diretamente cada motor de um Unitree G1. Esse é o instinto certo. Uma política humanoide pode prever uma representação compacta de movimento, enquanto um controlador local trata do movimento de corpo inteiro e fornece alvos de juntas para rastreamento de baixo nível. Esta separação não estabelece equilíbrio seguro numa configuração não testada.

Para o checkpoint de colocação de lata, a política de tarefa prevê 64 valores de tokens de movimento mais dois campos de pinça. Esses 64 valores não são 64 comandos de juntas. São coordenadas latentes. Um decodificador a bordo combina esse token com histórico recente do estado do robô e depois produz alvos de juntas para o ciclo de controlo proporcional-derivativo do robô.

Essa divisão é o ponto central. Também é onde uma integração descuidada pode correr mal.

Uma nota de integração útil, não um benchmark novo

O artigo de integração humanoide LeRobot de 25 de setembro explica como teleoperação, aprendizagem de políticas e controlo do Unitree G1 se encaixam. O checkpoint e o conjunto de dados de colocação da lata já eram artefactos de agosto, portanto o anúncio não deve ser lido como uma nova versão de modelo com pesos novos. A parte útil é o diagrama de ligação, especialmente a forma como expõe a fronteira entre a saída da política e o controlo de movimento a bordo.

A primeira pergunta prática é a compatibilidade

O lançamento descreve um fluxo de trabalho. A documentação do controlador descreve a implantação. O checkpoint descreve uma política treinada. Ler os três em conjunto levanta uma pergunta simples: o runtime fornece as observações que o checkpoint foi treinado para usar?

Essa pergunta ainda não está resolvida. A política da lata espera 31 valores de estado. O controlador SONIC documentado expõe 64 valores de eco de token. Dimensões de ação partilhadas não resolvem a questão.

Isto é separado da transferência de armazenamento abordada na nossa análise da integração LeRobot LanceDB. Um conjunto de dados legível e um checkpoint carregável são úteis, mas não provam que um runtime de robô ao vivo esteja a alimentar a mesma representação de estado que a política aprendeu.

Porque a política de tarefa não é o controlador de equilíbrio

O token não é uma lista de motores

O lançamento descreve uma representação latente SONIC de 64 dimensões. O checkpoint da lata acrescenta dois campos de pinça. Essas coordenadas codificam intenção de movimento. Não são posições de juntas, alvos de torque ou uma lista direta de comandos de atuadores.

A documentação do G1 descreve o SonicWholeBodyController a decodificar um token mais propriocepção recente numa ação residual. Esse residual é escalado e somado a ângulos padrão em pé, produzindo alvos para 29 juntas. O controlo PD do robô rastreia então esses alvos.

O decodificador carrega pesos ONNX e constantes de implantação a partir de lerobot/sonic_decoder. A implementação fixada lê ganhos PD, ângulos padrão, escala de ação e um token neutro dos metadados ONNX. Também separa a ordem de juntas do IsaacLab da ordem de implantação do MuJoCo. Esses mapeamentos não são mera escrituração. Fazem parte do contrato de movimento.

Para uma visão mais ampla das hipóteses de hardware e controlador, a nossa análise de controlo de morfologia BRIDGE é um contexto útil. Ela não prova que BRIDGE e SONIC partilhem uma interface.

A inferência remota não deve ser dona do ciclo local

Para implantação física, a documentação descreve um policy_server no lado da GPU, um robot_client a bordo que executa o controlador SONIC no Jetson do G1, e a ponte run_g1_server. Blocos de tokens passam pela rede. O controlador a bordo foi concebido para executar o seu ciclo documentado de 50 Hz usando propriocepção local; a conformidade real com prazos deve ser medida.

Este diagrama é um mapa conceitual de interface, não uma implantação verificada. O processador de observação fica propositalmente não resolvido. O ciclo de feedback local não deve precisar de um novo resultado de inferência na GPU a cada tick do controlador. O buffer pode reduzir a dependência da latência remota, mas não prova equilíbrio seguro ou comportamento útil depois de perda de rede.

Posicionamento assíncrono e RTC guiado são controlos diferentes

A implantação assíncrona decide onde a inferência é executada e como os blocos de ações chegam ao robô. O agrupamento em tempo real guiado, ou RTC, trata da previsão através das fronteiras de blocos de ação. O cartão do checkpoint da lata recomenda RTC guiado, ao mesmo tempo que diz que este checkpoint não foi treinado para RTC treinado ou piR2.

Não colapse essas ideias numa única afirmação. Amostragem do conjunto de dados a 50 fps, um bloco de 50 ações, cadência de publicação e um controlador de 50 Hz são quantidades separadas. Números iguais podem ser uma pista. Não são prova de que os relógios correspondam num sistema ao vivo.

O Mapa da Interface Token-para-Movimento

Comece pela semântica, depois verifique as formas

A configuração do checkpoint declara observation.state com forma [31] e action com forma [66]. O esquema do conjunto de dados nomeia os campos de estado: 29 posições de juntas, depois valores das pinças esquerda e direita. Os seus campos de ação são motion_token_0 até motion_token_63, seguidos pelas pinças.

A Parte 5 da documentação G1 atual em main diz, em vez disso, que o SonicWholeBodyController devolve um estado de observação de eco de token de 64 dimensões. O observation_state() da implementação fixada confirma que expõe o último token decodificado, não o vetor medido de juntas e pinças do checkpoint.

Essa é a principal lacuna de integração. A compatibilidade direta não está estabelecida. Uma equipe precisa resolver o processador de observação, o mapeamento de estado físico, a normalização e a revisão de código antes de ligar estes artefactos. Preencher um vetor de juntas ou fatiar um vetor latente apenas faz o tensor passar numa verificação de forma. Não faz com que os valores signifiquem a mesma coisa.

A tabela do cartão do modelo também rotula a ação como "64 joints + 2 grippers." Isso entra em conflito com os campos de configuração nomeados, o esquema do conjunto de dados e a explicação do lançamento. Para esta interface, os artefactos tipados têm mais peso do que a redação da tabela.

Matriz de compatibilidade para todo o caminho de movimento

O Mapa da Interface Token-para-Movimento abaixo é uma síntese editorial dos artefactos inspecionados. Não é um padrão e não é uma receita de implantação testada pela Optijara. A sua função é tornar visível a evidência em falta antes que alguém escolha um runtime.

O cartão do checkpoint regista o código LeRobot 8bf6056d1. O código-fonte do controlador inspecionado aqui está fixado em e595b7902714ba51f91e47523f66f89c5181b649. A documentação atual em main exige uma instalação a partir do código-fonte e distingue a versão estável v0.6.1. Os seus exemplos SONIC usam nepyope/sonic_walk, não o checkpoint da lata. Trate-os como referências relacionadas, não como instruções intercambiáveis.

{
  "contract": {
    "checkpoint_state": "29 posições de juntas mais 2 pinças",
    "checkpoint_action": "64 coordenadas SONIC mais 2 pinças",
    "documented_controller_state": "eco de token de 64 valores"
  },
  "proposedchecks": ["Resolver processador de observação", "Verificar nomes e normalização", "Fixar revisões de runtime compatíveis"],
  "limitations": ["Compatibilidade direta não resolvida", "Nenhum teste de inferência, simulação ou hardware executado para este artigo"]
}

O que o checkpoint da lata mostra, e o que não mostra

Leia a tarefa, as câmaras e o tempo como um contrato

O cartão do conjunto de dados can_clean_final descreve 105 episódios e 212.290 frames a 50 fps. Os três fluxos de câmara de 480 por 640 são ego_view, left_wrist e right_wrist. A única tarefa é Bring the can to the white table. Esses detalhes definem o contrato de entrada do checkpoint. Não estabelecem desempenho noutra sala, com outra montagem de câmara ou sob uma instrução de tarefa diferente.

O conjunto de dados documenta action[t] como o comando que produz observation.state[t+1]. Preserve essa relação ao construir exemplos de replay. Estado com o mesmo índice não deve tornar-se silenciosamente o resultado atribuído à ação.

O cartão também relata que observation.state[29] e action[64], os campos da pinça esquerda, são sempre zero. Em termos práticos, as gravações foram feitas com uma mão. Dois campos de saída de pinça não fornecem evidência de habilidade bimanual.

A normalização precisa do mesmo cuidado. A configuração especifica normalização por quantis para estado e ação. O cartão do conjunto de dados diz que os limites de quantis da pinça esquerda foram definidos manualmente para evitar divisão por zero. Uma migração de processador tem de preservar esse tratamento em vez de ler comportamento útil da mão esquerda numa faixa numérica válida.

Perda não é uma afirmação de sucesso na tarefa

O conjunto de dados foi revisto e as falhas foram removidas. O cartão do checkpoint relata perda final de treino de 0,025, explicitamente sem uma divisão de validação. Isso é metadado de treino útil. Não é sucesso autónomo na tarefa e não é evidência de generalização.

A leitura justa é mais estreita: estes artefactos documentam uma configuração de treino e expõem restrições que uma avaliação compatível deve respeitar. Afirmações de capacidade precisam de evidência em ciclo fechado separada. Reserve explicitamente recursos para verificar hipóteses de interface e avaliar comportamento, em vez de tratar a disponibilidade dos artefactos como prova de compatibilidade.

Um manual de adoção primeiro em simulação para a pilha de movimento G1

Estágio 1: reconcilie o contrato offline

Todas as verificações abaixo são propostas. A Optijara não executou inferência, simulação, treino ou testes físicos de robô para este artigo.

Comece pela inspeção dos artefactos. Fixe revisões. Compare nomes e unidades de estado. Confirme a ordem das juntas. Rastreie ambas as pinças separadamente. Compare identidades de câmaras e pré-processamento com o checkpoint, não apenas dimensões de imagem. Inspecione normalização de estado/ação e constantes do decodificador. Trate o mapeamento de observação 31-versus-64 não resolvido como uma condição de paragem.

Este também é o lugar para verificar alinhamento temporal. Um pipeline de replay que fornece os campos certos a partir do timestep errado não reproduziu a interface de treino. Registe as decisões do processador para que outro engenheiro consiga distinguir transformações deliberadas de coerção acidental.

Estágio 2: separe o tempo da política do tempo do controlador

Depois de ferramentas e mapeamentos compatíveis estarem resolvidos, execute replay offline ou simulação da interpretação de token-para-alvo antes de julgar o comportamento de tarefa aprendido. A documentação fornece exemplos de simulação, mas isso não mostra que um simulador inalterado reproduz exatamente esta pilha da política da lata.

Defina limites de aceitação para a configuração pretendida antes de testar. Este artigo não fornece padrões universais de segurança. Registe a cadência de publicação e o consumo da fila juntamente com a latência de inferência; uma média decente pode esconder interrupções. Para uma discussão complementar sobre evidência comportamental, veja o nosso mapa de avaliação de robótica vídeo-para-tarefa.

Estágio 3: decida se a preparação de hardware é justificada

Adote agora a inspeção de interface. Migre processadores apenas depois de os seus significados estarem definidos. Não transplante um comando do cartão do checkpoint para código de hardware atual em main apenas porque ambos mencionam Unitree G1.

Antes de qualquer teste físico, exija procedimentos de segurança do fabricante, uma área de teste controlada e uma paragem de emergência funcional. Reveja explicitamente o comportamento de fila obsoleta e perda de rede. Este artigo não estabelece um watchdog padrão nem recomenda um teste rápido síncrono em hardware.

Erros comuns e limitações a manter visíveis

Erros que fazem a interface parecer mais segura do que é

• Tratar coordenadas latentes como juntas motoras ignora o papel do decodificador. Rastreie a decodificação de tokens e a conversão de ordem de juntas.
• Corresponder dimensões de ação enquanto se ignora o significado da observação deixa a entrada da política não resolvida. Verifique ambos os lados do contrato.
• Chamar 50 Hz de velocidade da política confunde controlo local com rendimento de inferência. Meça-os separadamente.
• Inferir habilidade bimanual a partir de dois campos de saída ignora a pinça esquerda inativa registada.
• Tratar RTC guiado como implantação assíncrona segura confunde previsão de blocos com posicionamento de runtime e tratamento de falhas.

Licenciamento, segurança e compromissos operacionais

A listagem de ficheiros do decodificador SONIC inspecionada expõe artefactos do decodificador, mas nenhum cartão de modelo ou ficheiro de licença visível. Essa ausência não é uma conclusão legal. Reveja separadamente os termos do modelo base, decodificador, software de controlador, conjunto de dados e hardware; uma licença de biblioteca ou de conjunto de dados não concede permissão para todos os componentes.

Deriva de ramo main e processadores da época do checkpoint complicam a reprodutibilidade. Posicionamento de câmaras, convenções de propriocepção e diferenças de execução em GPU também precisam de revisão. Se observações de câmara saírem do robô para inferência remota, avalie controlos de acesso e privacidade para o ambiente operacional.

Reserve recursos para integração e avaliação sem assumir prontidão para produção. A decisão imediata é se uma equipe consegue estabelecer um contrato consistente de observação-para-token-para-movimento, com hipóteses não resolvidas visíveis antes de começar a preparação de hardware.