Teste de aceitação de simulação robótica Newton Physics 1.5: o manual RSRAT para prontidão de treino em lotes

Um simulador pode ganhar uma demonstração e ainda falhar na rota de treino. A cena renderizada não é o problema. O problema começa quando centenas de mundos robóticos estão a avançar, uma faixa termina cedo, uma reinicialização toca em estado que não deveria tocar, ou um caso extremo de contacto fica escondido dentro de uma curva de recompensa média.

Essa é a pergunta prática por trás do Newton Physics 1.5. A versão no GitHub identifica a v1.5.0 como uma versão de funcionalidades depois da v1.4.0, com notas sobre simulação escalável em lotes, fluxos de trabalho de controlo robótico, fiabilidade de contactos, fidelidade de importação de assets, mecânica de cabos e caminhos opcionais MuJoCo e Kamino. Boas notícias, mas não um sinal verde por si só. Uma versão pode adicionar funcionalidades úteis enquanto o robô, os assets, os controladores e a pilha de treino da própria equipa ainda precisam de qualificação.

Este artigo transforma a versão no Robot Simulation Route Acceptance Test da Optijara, ou RSRAT. Não é um benchmark oficial da NVIDIA ou do Newton. É um teste operacional de consultoria para decidir se o Newton 1.5 deve permanecer em uso de demonstração, passar para um canário limitado ou suportar treino robótico em lotes mais amplo. Para pensamento próximo sobre testes de aceitação, veja o guia da Optijara sobre aceitação da rota de política Xiaomi-Robotics-1, as lições de validação de edge em aceitação do pipeline de vídeo JetPack 7.2.1 e o padrão de evidência de pipeline de dados em aceitação do motor de dados multimodal Vane 0.1.0.

Por que o Newton Physics 1.5 precisa de evidência de rota

As notas de versão do Newton 1.5 mencionam controlo de articulações vetorizado experimental por meio de newton.controllers, fluxos de trabalho multi-mundo, reinicializações mascaradas do solver, gravidade dedicada de mundo global, modo de suspensão MuJoCo Warp opcional, geração hidroelástica determinística, geometria persistente, reinicialização seletiva, manifolds de caixas estáveis, auxiliares de cabos e correções para caminhos com muitos contactos. O repositório e a página de desenvolvimento da NVIDIA posicionam o Newton como um motor de física open-source para robótica e fluxos de trabalho de IA física. Warp, Isaac Lab e MuJoCo MJX adicionam o contexto envolvente para kernels em GPU, ambientes de aprendizagem por reforço em robótica e simulação MuJoCo orientada a JAX.

A pergunta de aceitação é mais estreita. A sua rota por essas funcionalidades produz evidência repetível para os seus robôs e cenas? Uma importação USD pode ter sucesso enquanto altera o comportamento de colisão. Uma rota MJCF pode preservar o ficheiro, mas deslocar pressupostos do controlador. Uma execução em lotes pode reportar throughput enquanto uma faixa com falha contamina a amostra de treino. Melhorias de contacto ainda precisam de verificações por repetição contra as cenas que realmente importam.

O tamanho do lote é uma métrica fraca de prontidão. O melhor sinal é se as piores faixas permanecem visíveis, isoladas e explicáveis. O RSRAT empurra as equipas para esse padrão. Ele pede bloqueios de versão, paridade de importador, isolamento de reinicialização, stress de contactos, repetição de controladores, limites de canário e propriedade de rollback. Esse mesmo hábito de rastreio de evidência aparece no teste de rastreio de evidência do Cloudflare Radar Researcher da Optijara, onde uma afirmação só é útil quando a rota pode ser reproduzida.

A rota RSRAT: cinco gates antes de escalar

Cada gate RSRAT devolve um estado de rota. Passar significa que a rota pode continuar. Observar significa que ela pode continuar apenas dentro de um canário nomeado com monitorização apertada. Falhar significa que a carga de trabalho permanece apenas em demonstração até que o defeito seja corrigido ou o âmbito seja reduzido.

Gate 1: Fixação de versão e ambiente

Comece por bloquear a página de versão do Newton, tag, commit, versões de dependências, driver de GPU, runtime, versão do Warp, camada de integração, hashes de cenas e definições do solver. A página da versão v1.5.0 fornece a identidade da versão e evidência de commit. Esse registo não é burocracia. É o que permite a um engenheiro reproduzir mais tarde um mau trace de contacto.

Gate 2: Paridade de importação de assets

Verifique se as rotas USD e MJCF preservam articulações, limites, massas, formas de colisão, sensores, atuadores e pressupostos do controlador. O Isaac Lab é um ponto de referência relevante para muitos fluxos de trabalho de robótica centrados em USD. O MuJoCo MJX é um ponto de referência relevante para rotas MJCF orientadas a JAX. Carregar o ficheiro não é aceitação. Corresponder aos pressupostos de física é aceitação.

Gate 3: Isolamento de mundos em lote

O Newton 1.5 destaca reinicializações mascaradas do solver, gravidade dedicada de mundo global e trabalho de reinicialização seletiva. O RSRAT pede às equipas que provem isolamento com hashes de estado, sementes aleatórias, buffers de contacto, traces de recompensa e verificações do integrador do controlador enquanto uma faixa reinicializa e as suas vizinhas continuam a avançar.

Gate 4: Estabilidade de contactos e controladores

Cenas ricas em contacto são onde demonstrações polidas podem começar a mostrar fraqueza. Repita casos de preensão, deslizamento, empilhamento, impacto e hidroelásticos que correspondam à tarefa pretendida. Para controladores, repita execuções nominais e arranques perturbados, depois inspecione saturação de atuadores, desvio do integrador e recuperação de estados maus.

Gate 5: Controlo de rollout e regressão

Uma atualização de simulador precisa de um responsável pela rota, âmbito de canário, caminho de fallback e gatilho de rollback. Isso é especialmente verdadeiro para equipas que usam simulação dentro de um pipeline de treino, onde um defeito silencioso do simulador pode consumir tempo de computação antes que alguém veja o pressuposto errado.

Gate 1: Fixar o Newton 1.5 e definir reprodutibilidade

Crie um manifesto antes dos testes de desempenho. Registe a versão, tag e commit do Newton, o URL de origem do Newton, versão do Warp, ambiente Python, detalhes de CUDA e driver de GPU, sistema operativo alvo, camada de integração, hashes de cenas, definições do solver, configuração do controlador, política de sementes aleatórias e versão do executor de testes. Se a rota tocar no Isaac Lab, registe a versão do Isaac Lab e as definições de tarefas. Se tocar em MuJoCo ou MJX, registe a origem XML ou MJCF e as definições MJX.

Mantenha os rótulos visíveis. A versão Newton 1.5 rotula o controlo de articulações vetorizado como experimental e a suspensão MuJoCo Warp como opcional. Esses rótulos devem acompanhar a funcionalidade até à decisão de rota. Funcionalidades experimentais podem ser avaliadas, mas não devem tornar-se discretamente infraestrutura obrigatória. Caminhos de cabos, deformáveis, hidroelásticos e outros com muitos contactos precisam da mesma disciplina porque são sensíveis a definições do solver, geometria e desenho de tarefas.

Defina reprodutibilidade antes de velocidade. Uma execução mais rápida que não pode ser repetida é evidência fraca. Sinais úteis incluem assinaturas de repetição com semente fixa, checksums de episódios, contagens de eventos de contacto, checksums de estado de reinicialização, tempo de passo na cauda, taxa de NaN ou explosão e desvio de regressão contra um corpus conhecido. Estas métricas não provam transferência de simulação para real. Provam se a rota de simulação é controlada internamente o suficiente para suportar experiências de treino.

Gate 2: Testar a fidelidade de importação USD e MJCF

As verificações de importador devem ser rigorosas e um pouco monótonas. A falha de importação mais cara é muitas vezes pequena: um eixo de articulação que mudou, uma propriedade de massa que mudou, uma aproximação de colisão que altera o deslizamento ou um mapeamento de atuador que dá à política a observação errada.

Execute verificações sim-para-sim antes do treino. Use cenas pequenas, sementes fixas e controladores de referência. Compare envelopes de trajetória, não apenas a recompensa final. Se uma carga de trabalho usa USD por meio do Isaac Lab e outra usa MJCF por meio do MuJoCo ou MJX, trate-as como rotas separadas com manifestos separados. Não deixe que um resultado limpo num caminho lave o risco no outro.

Gate 3: Provar o isolamento de reinicialização seletiva

O teste central do RSRAT é o isolamento de reinicialização seletiva. Crie um lote com vários mundos: uma faixa desenhada para terminar cedo, uma com stress de contacto, uma cena de base tranquila e uma família de assets diferente. Reinicialize uma faixa enquanto as outras continuam. Depois compare hashes de estado antes e depois da reinicialização, sementes aleatórias, buffers de contacto, traces de recompensa, buffers de controlador e flags de terminação.

Uma aprovação não exige que todos os valores de ponto flutuante coincidam em todos os dispositivos. Exige evidência de que os critérios de aceitação da rota são estáveis o suficiente para a carga de trabalho. A faixa de reinicialização não deve alterar recompensas, buffers de contacto ou integradores de controlador vizinhos. Uma faixa com falha não deve desaparecer dentro de métricas ao nível do lote. A aleatorização deve permanecer dentro de limites declarados, para que uma definição global como a gravidade não altere pressupostos para mundos vizinhos, a menos que esse seja o experimento.

Teste em níveis. Comece com um lote pequeno onde os defeitos sejam fáceis de inspecionar. Avance para um lote misto com cenas e famílias de robôs diferentes. Depois execute um lote de stress que aproxime o formato de treino pretendido. Acompanhe tendência de throughput, margem de memória da GPU, tempo de passo na cauda, falhas de isolamento de reinicialização e reprodutibilidade de episódios. O throughput médio sozinho não basta porque a rota de treino costuma falhar na cauda.

Gate 4: Submeter contactos, controladores e comportamento de suspensão ou ativação a stress

As notas de versão do Newton 1.5 apontam para melhor tratamento de contactos, incluindo geração hidroelástica determinística, geometria persistente, reinicialização seletiva, manifolds de caixas estáveis, acoplamento de proxy VBD de superfície completa e correções de capacidade em caminhos relevantes. Trate essas notas como razões para escrever testes mais afiados.

Repita cenários ricos em contacto que representem a rota: garras a fechar sobre objetos, caixas a empilhar e deslizar, impactos, interações com cabos ou deformáveis quando aplicável, e cenas hidroelásticas se a carga de trabalho as usar. Compare distribuições de contagem de contactos, cenas anómalas, sintomas de penetração ou deslizamento e recuperação após perturbação. Alguma variação numérica é normal. Explosões repetidas, desvio inexplicado, NaNs ou regressões específicas da rota não são.

Os testes de controlador devem incluir sementes nominais, arranques perturbados e condições de latência de cauda. Observe saturação de atuadores, desvio do integrador, recuperação instável e traces de recompensa que parecem bons apenas porque uma faixa com falha foi diluída pela média. Se a rota usa controlo de articulações vetorizado experimental, mantenha esse rótulo na decisão de rota. Se usa suspensão MuJoCo Warp opcional, teste o comportamento de ativação em cenas onde árvores articuladas inativas se tornam ativas após contacto.

A matriz de decisão RSRAT

A matriz de decisão transforma evidência numa rota. Ela é conservadora por desenho porque a aceitação do simulador é mais barata do que treinar com dados contaminados.

Apenas demonstração é adequado para exploração e visualização. Uma rota de canário ajusta-se a evidência que é em grande parte forte, mas ainda tem um risco nomeado num conjunto limitado de cenas ou família de robôs. Treino em lotes expandido precisa de gates aprovados, evidência armazenada legível por máquina e gatilhos de rollback que a equipa realmente usará.

O desenho do canário deve incluir um pequeno corpus de regressão, um formato de lote limitado, um simulador de fallback conhecido ou caminho de versão anterior, limiares específicos da rota e um responsável. Faça rollback quando a paridade de importador quebrar assets críticos, reinicializações seletivas vazarem estado, o comportamento de contacto se tornar instável, a repetição do controlador divergir ou as métricas do canário falharem os critérios acordados.

Checklist de implementação e plano de medição

Use esta checklist antes de ampliar uma rota Newton 1.5.

{
  "framework": "RSRAT",
  "simulatorVersion": "Newton Physics v1.5.0",
  "sourceUrls": ["https://github.com/newton-physics/newton/releases", "https://github.com/newton-physics/newton"],
  "importRoutes": ["USD", "MJCF"],
  "batchSizes": ["small", "mixed", "stress"],
  "resetIsolationStatus": "pass-watch-fail",
  "contactRepeatabilityStatus": "pass-watch-fail",
  "canaryDecision": "demo-only | limited-canary | expanded-training",
  "rollbackPlan": "owner, trigger, fallback route"
}

A medição deve cobrir margem de memória da GPU, tendência de throughput, tempo de passo na cauda, falhas de isolamento de reinicialização, anomalias de contacto, taxa de NaN ou explosão, reprodutibilidade de episódios e desvio de regressão. Equipas que precisam de uma bancada de testes independente podem adaptar o RSRAT internamente ou pedir à Optijara que o transforme num fluxo de trabalho medido de qualificação de simulador ligado à sua pilha de treino e automação.

O que as equipas erram

Erro 1: Tratar sucesso de importador como paridade física

Uma cena que carrega não é necessariamente uma cena que preserva pressupostos de controlo. Corrija isto com tabelas de paridade de importador, cenas de referência e repetição de controlador antes do treino começar.

Erro 2: Diluir pela média falhas de passo na cauda e reinicialização

Médias de lote podem esconder a faixa com falha. Acompanhe tempo de passo na cauda, falhas de isolamento de reinicialização, anomalias de contacto e reprodutibilidade ao nível do episódio. Se uma faixa explodir, a rota deve tornar isso visível.

Erro 3: Expandir lotes antes de existir rollback

Um canário sem rollback é apenas uma experiência maior. Defina o simulador de fallback ou rota Newton anterior, o responsável, as condições de paragem e a evidência necessária para retomar.

Erro 4: Exagerar evidência de simulação para real

A aceitação do simulador pode reduzir riscos internos conhecidos. Ela não prova transferência física. A transferência para o mundo real exige validação física, evidência específica da tarefa, revisão de segurança e limites cuidadosos sobre o que o resultado da simulação significa. O RSRAT é útil porque torna a rota do simulador mais auditável antes de as equipas gastarem computação de treino em evidência fraca.