Teste de Aceitação da Rota de Política Xiaomi-Robotics-1: Levando Checkpoints VLA para uma Implantação Segura

Um checkpoint de robô pode parecer forte em um benchmark e ainda assim não estar pronto para uma célula de trabalho calibrada. O verdadeiro teste de aceitação da rota de política Xiaomi-Robotics-1 começa nos momentos incômodos: a câmera se desloca, um objeto cai fora da pose esperada, a reinicialização falha, a latência de inferência dispara, ou um operador precisa que o sistema pare antes que um pequeno erro se torne um incidente de segurança.

Essa é a lente certa para o Xiaomi-Robotics-1. O projeto oficial o descreve como um modelo fundamental de robótica visão-linguagem-ação treinado com mais de 100.000 horas de trajetórias UMI de manipulação no mundo real, seguido de pós-treinamento com mais de 10.000 horas de dados entre embodiments. O repositório, a página do projeto, o relatório no arXiv, a coleção no Hugging Face, o código de implantação e as pastas de avaliação de benchmark o tornam mais útil do que um lançamento apenas de demonstração. Eles também ampliam a superfície de avaliação.

A pergunta útil não é se esse checkpoint equivale a autonomia robótica. É se esse checkpoint pode se tornar uma rota candidata: um caminho de política delimitado que pode ser reproduzido, fixado, observado em shadow mode, lançado como canário, desativado e revertido. Um benchmark pergunta se um modelo consegue concluir tarefas sob uma configuração definida. Um teste de aceitação de rota pergunta se uma equipe consegue reproduzir o artefato, mapeá-lo para seu embodiment robótico, medir todo o loop percepção-política-ação e manter a autoridade humana intacta quando o comportamento fica estranho.

Esse ângulo difere do trabalho de robótica com vídeo na borda, em que a principal superfície de decisão é throughput de sensores, codecs e pipelines de vídeo no dispositivo. Para um contexto mais amplo sobre infraestrutura de robótica, veja o artigo relacionado da Optijara sobre JetPack 7.2.1 e robótica de vídeo na borda. O Xiaomi-Robotics-1 levanta uma pergunta separada: um checkpoint aberto de política VLA pode se tornar uma rota contida de política robótica após gates de calibração, temporização, segurança e recuperação? Para padrões adjacentes de avaliação de política robótica aberta, compare isto com o teste de aceitação de corpo inteiro e múltiplos embodiments do LingBot-VLA 2.0 da Optijara.

Por que o Xiaomi-Robotics-1 precisa de um gate de implantação, não de outro resumo de benchmark

O README oficial diz que o Xiaomi-Robotics-1 combina um VLM pré-treinado, Qwen3-VL, com um Diffusion-Transformer por meio de um design Mixture-of-Transformers. Ele relata mais de 100.000 horas de trajetórias UMI independentes de embodiment em mais de 1.700 cenários, depois pós-treinamento com dados entre embodiments, incluindo dados internos de robôs reais, dados filtrados de robôs open-source e dados UMI anotados manualmente. A coleção do Hugging Face lista checkpoints lançados, incluindo Xiaomi-Robotics-1-5B e checkpoints específicos de benchmark para RoboCasa, RoboCasa365 e VLABench.

Esses artefatos merecem atenção. Eles não são prova de implantação. O README relata pontuações de benchmark no RoboCasa, RoboCasa365, VLABench e RoboDojo, incluindo 57,4 por cento no RoboCasa365 em comparação com 46,6 por cento para a segunda melhor entrada na tabela. Trate esses números como alegações de benchmark relatadas pelo projeto até que uma equipe os reproduza com código fixado, pesos fixados, versões de simulador correspondentes e configurações de avaliação correspondentes.

O problema de implantação é mais confuso do que a conclusão de tarefas em um benchmark. Uma rota robótica precisa sobreviver a drift de calibração, frames obsoletos, oclusão parcial, deslocamentos de objetos, erros de reinicialização, limites de rede, bugs de adaptador de ação e intervenção humana. Se a política roda por meio de uma divisão cliente-servidor, como descrevem os guias de avaliação do RoboCasa e do VLABench, o teste de aceitação também precisa medir idas e voltas de socket, overhead de serialização, inferência do modelo, despacho de ação, resposta do atuador e jitter em loops repetidos. A mesma disciplina de prontidão se aplica também fora da robótica, como mostrado no teste de aceitação Cloudflare Agent Readiness AEO da Optijara.

O mapa de artefatos: o que as equipes devem fixar antes que qualquer robô se mova

Antes que um robô se mova, a equipe precisa de um mapa de artefatos que possa ser reconstruído depois. Fixe o commit do repositório público, a revisão exata do checkpoint no Hugging Face, hashes de arquivo para artefatos do modelo, a licença de código Apache-2.0, os termos do model card, o lockfile de dependências, a pilha CUDA e PyTorch, versões de transformers, versões de simulador, configs de benchmark, scripts de implantação e qualquer firmware de robô ou build de controlador usado em testes de hardware.

O código do servidor de implantação carrega um AutoModel com trust_remote_code, flash attention, bfloat16, CUDA e retorna tensores de ação serializados por pickle. O README de avaliação do RoboCasa especifica RoboCasa v0.2, Python 3.10, transformers 4.57.1 e uma divisão cliente-servidor em dois ambientes conda. O README de avaliação do VLABench especifica seu próprio ambiente, versões fixadas de MuJoCo e dm_control e uma forma de ação bruta de [10, 60], com as primeiras 7 dimensões executáveis para delta de posição, delta de rotação Euler e controle de garra.

O contrato de entrada/saída precisa de seu próprio inventário. Registre nomes de câmeras, resolução de imagem, pré-processamento, formato de instrução, campos de propriocepção se usados, task_id ou chave do robô, forma do tensor de ação, escala de ação, semântica da garra, frequência de ação, comportamento de batching, protocolo de endpoint e a camada de adaptador específica do robô. Se um campo continua implícito, a equipe não está avaliando uma rota. Está apostando. Para equipes que formalizam gates mais amplos de lançamento de modelos, o teste de aceitação de implantação do Motif 3 da Optijara oferece um paralelo útil para separar alegações de modelo de evidência de rota.

O framework R-PATH da Optijara para aceitação de rotas de políticas robóticas

R-PATH é um framework prático de aceitação para passar de um checkpoint de pesquisa a uma rota contida de política robótica. Ele significa Reproduzir, Fixar, Alinhar, Testar e Manter.

R: Reproduza a rota publicada

Comece em simulação, não no hardware. Reproduza o caminho documentado do RoboCasa, RoboCasa365 ou VLABench que corresponde ao checkpoint que você pretende inspecionar. A documentação de avaliação do Xiaomi-Robotics-1 usa uma configuração cliente-servidor em que o servidor carrega o modelo e serve ações por um socket, enquanto o cliente executa o simulador, monta entradas com AutoProcessor e decodifica ações. Esse limite é onde muitos problemas de implantação aparecem.

P: Fixe a política e a plataforma

Depois que uma execução de linha de base existir, congele tudo que é mutável. Fixe código, checkpoint, dependências, comportamento do processador, assets do simulador, definições de tarefa, scripts de lançamento, variáveis de ambiente e configuração de hardware. Adicione checksums para arquivos de modelo e arquivos de adaptador de rota. Armazene comandos de lançamento ao lado dos metadados de execução.

A: Alinhe câmeras, ações e embodiment

O pré-treinamento independente de embodiment é promissor porque pode aprender padrões amplos de manipulação antes do alinhamento específico do robô. Ele não remove a necessidade de mapeamento específico do robô. Alinhe intrínsecos e extrínsecos de câmera, convenções de frame, iluminação, crop de imagem, escala de objeto, limites do espaço de trabalho, pose de base, cinemática do braço, escala de ação, semântica de abrir e fechar a garra, posições de reinicialização e definições de tarefa.

T: Teste temporização de loop fechado e recuperação

Meça o loop completo, não apenas a inferência do modelo. O loop inclui captura de câmera, pré-processamento, transferência de rede se usada, inferência do modelo, serialização de ação, conversão do adaptador de ação, despacho do controlador, resposta do atuador, atualização da observação e avaliação do gate de segurança. Registre distribuições de latência e jitter, não apenas médias. Depois teste oclusões, frames atrasados, observações obsoletas, instruções ambíguas, objetos deslocados, pegadas falhas, caminhos bloqueados, falhas de reinicialização e eventos de parada de emergência.

H: Mantenha autoridade humana e reversão

Nenhuma rota VLA deve superar o mecanismo de parada. Autoridade humana de parada, limites físicos do espaço de trabalho, fallback de parada segura, fallback para controlador de linha de base, shadow mode, modo canário e regras de reversão precisam existir antes da expansão.

Matriz de decisão de rota: quando o Xiaomi-Robotics-1 está pronto, não está pronto ou está pronto apenas para sandbox

Esta matriz é intencionalmente conservadora. Uma aprovação em benchmark pode justificar avaliação contínua. Ela não deve autorizar atuação em uma célula de trabalho de produção por si só. O Xiaomi-Robotics-1 pode ser o candidato certo para avaliação ampla de manipulação, mas um controlador com script mais estreito, uma política de imitation learning, um fluxo assistido por teleoperação ou uma stack robótica específica de fornecedor pode ser melhor para uma tarefa restrita com requisitos rígidos de repetibilidade. Isso é engenharia comum: use o modelo onde a adaptabilidade importa e use controle mais simples onde a repetibilidade importa mais.

Checklist de implementação: do checkpoint à rota robótica calibrada

Comece com previsões shadow, em que a política observa mas não atua. Compare as ações propostas com envelopes seguros esperados. Depois avance para tarefas canário contidas com supervisão humana, limites físicos e um fallback de linha de base. Se um canário falhar por calibração, latência, reinicialização ou comportamento fora da distribuição, reverta a rota em vez de editar o ambiente até a falha desaparecer.

O que as equipes erram ao avaliar políticas robóticas VLA abertas

O primeiro erro é confundir cobertura de benchmark com cobertura operacional. RoboCasa, RoboCasa365 e VLABench são valiosos porque fornecem ambientes estruturados para avaliação. A página do projeto RoboCasa365 o descreve como abrangendo 365 tarefas e mais de 2.500 ambientes de cozinha, com mais de 600 horas de dados de demonstração humana e mais de 1.600 horas de demonstrações geradas sinteticamente. Nenhum benchmark pode provar que uma célula de trabalho alvo, distribuição de objetos, configuração de iluminação, rotina de reinicialização e limite de segurança estão cobertos.

O segundo erro é pular o mapeamento de embodiment. Treinamento independente de embodiment ou entre embodiments pode ajudar o modelo a aprender padrões transferíveis de manipulação. Ele não garante que sua pose de câmera, garra, escala de ação, frame de coordenadas ou temporização do controlador correspondam às premissas da política.

O terceiro erro é medir sucesso enquanto se ignora a recuperação. Uma rota que conclui uma tarefa em condições limpas, mas se comporta mal depois de uma pegada falha, não está pronta para expansão. Comportamento de recuperação, tratamento de quase acidentes, detecção fora da distribuição, parada segura e política de reinicialização muitas vezes importam mais do que clipes isolados de sucesso.

O quarto erro é tratar latência como média. Uma rota de política pode ter uma média aceitável e ainda falhar por causa de jitter, observações obsoletas ou atrasos intermitentes do servidor. Observe as caudas, não apenas o centro da distribuição.

Plano de medição: evidência a coletar antes da aprovação da rota

Um pacote de aprovação de rota deve responder a uma pergunta incômoda: outra equipe poderia inspecionar a mesma execução e entender exatamente o que aconteceu? Capture commit de origem, hash do checkpoint, config, ambiente, embodiment do robô, ID de calibração de câmera, tarefa, seed se aplicável, instrução, stack de runtime, horário de início e fim, operador e modo da rota. Depois capture resultado da tarefa, motivo de intervenção, quase acidente, colisão, gatilho fora da distribuição, resultado de reinicialização, ativação de fallback, evento de reversão, distribuição de latência, jitter, observações descartadas, observações obsoletas e modo de falha observado.

Custo por hora-tarefa aceita é útil se tratado como uma métrica interna, não como uma promessa universal. Ele pode combinar tempo de hardware, supervisão do operador, overhead de reinicialização, custo de computação, manutenção, execuções rejeitadas e tempo de tarefa bem-sucedida aceita. O objetivo é comparar rotas sem esconder o trabalho de reinicialização e o custo de supervisão.

{
  "route_status": "shadow",
  "policy": "Xiaomi-Robotics-1 candidate route",
  "required_pins": ["repo_commit", "checkpoint_hash", "dependency_lock", "calibration_id"],
  "accepted_tasks": ["team_defined_after_canary"],
  "excluded_tasks": ["uncalibrated_or_high_risk_tasks"],
  "safety_gates": ["independent_human_stop", "workspace_limit", "fallback", "rollback"],
  "rollback_condition": "timing, recovery, OOD, collision, or reset behavior outside acceptance band",
  "unresolved_caveats": ["sim_to_real_gap", "benchmark_leakage", "calibration_drift", "model_weight_terms"]
}

Ressalvas, limites e o próximo passo prático

Vale a pena avaliar o Xiaomi-Robotics-1 porque ele entrega código público, caminhos de implantação, links de checkpoints, guias de benchmark, uma página de projeto e um relatório técnico. Isso torna possível uma reprodução séria. Não remove as partes difíceis da implantação robótica.

As principais ressalvas são custo de implementação, lacunas entre simulador e mundo real, vazamento de benchmark ou sobreposição de dataset, variância de modelo e provedor, privacidade dos dados de câmera, drift de calibração, termos de assets de terceiros, limites de certificação de segurança e trade-offs operacionais. Não implante se os artefatos não puderem ser fixados, a avaliação não puder ser reproduzida, os embodiments suportados não corresponderem ao robô, a temporização for instável, a parada de segurança não for independente, a recuperação for ruim, a política de reinicialização for pouco clara ou a reversão depender de heroísmo manual.

O próximo passo prático é tratar o Xiaomi-Robotics-1 como uma rota candidata por trás do R-PATH, não como uma implantação automática. Reproduza primeiro, fixe os artefatos, alinhe o embodiment, teste temporização e recuperação de loop fechado e mantenha a autoridade humana visível por meio de controles de canário e reversão. Se sua equipe está avaliando políticas robóticas ou outras rotas de automação de IA, a Optijara pode ajudar a desenhar gates de aceitação, telemetria, rigs de avaliação e planos de rollout que conectam artefatos de pesquisa a evidência operacional.