microduck_rl 2b25a48. Nenhuma exportação de ponto de verificação, execução de GPU ou implantação física foi realizada por este site. Os comandos abaixo operam em seu próprio ponto de verificação e gravam arquivos locais.Saiba o que cada arquivo representa.
| Artefato | Objetivo |
|---|---|
| Ponto de verificação de treinamento (.pt) | Estado de treinamento salvo usado pelo exportador correspondente. Mantenha a tarefa e a configuração do treinamento com ele. |
| Modelo exportado (.onnx) | Gráfico de inferência. O caminho oficial de exportação inclui a normalização da observação aprendida durante o treinamento. |
| Pacote de políticas | Um modelo, manifesto e README descrevendo como o tempo de execução deve usá-lo. A aprovação nas verificações de pacotes não estabelece a qualidade da caminhada ou a segurança do hardware. |
Uma política recebe uma observação —o estado esperado do robô e os valores de comando—e retorna ações. O atual contrato compartilhado possui 61 valores de observação e 14 ações. Sua ordem e significado são tão importantes quanto sua contagem. Início rápido do MicroDuck RL e registro de tarefas ↗.
Exporte o ponto de verificação com sua tarefa correspondente.
Use o ambiente configurado na sua execução de treinamento. Substitua o caminho do ponto de verificação de exemplo pelo arquivo real que você salvou. O seguinte ID de tarefa é para o exemplo de caminhada; use a tarefa que produziu seu ponto de verificação. Mantenha um first-walk.onnx existente em outro lugar se precisar preservá-lo.
uv run scripts/export.py Mjlab-Velocity-Flat-MicroDuck \
--checkpoint-file /absolute/path/to/model_3000.pt \
--num-envs 1 \
--onnx-file first-walk.onnxEste é o exportador do projeto, não um comando de conversão genérico. Constrói o ambiente de treinamento e exporta o ator junto com seu normalizador. Ver movimento plausível em play não verifica se um modelo convertido manualmente contém esse normalizador. Verifique a mensagem de conclusão do exportador e o arquivo de saída real. Exportador oficial ONNX e normalização de observação ↗.
Ensaie o arquivo exportado com o layout correto.
uv run scripts/infer_policy.py \
--walking first-walk.onnx \
--new-cmd-obsO visualizador imprime a forma de entrada do modelo ambulante. A bandeira acima seleciona o layout do comando atual. As políticas legadas de 51 entradas precisam ser desativadas. Não preencha um modelo arbitrário para fazer com que as dimensões correspondam: isso não repara diferentes significados de observação, ordenação conjunta, tempo ou escala de ação. O script local usa inferência CPU ONNX, mas ainda precisa de suas dependências Python, ativos de modelo e um visualizador funcional. Sinalizadores de reprodução local e controles de teclado ↗.
| Ação | Simulador de navegador | Infer_policy.py local |
|---|---|---|
| Sentar / ficar de pé | R no modo pés | Y com a política de sentar/levantar correspondente carregada |
| Chute esquerdo/direito | Q/E no modo pés | K/L com políticas de kick carregadas |
| Rolo para frente | R é atribuído para sentar/levantar | R somente quando uma política roulade é fornecida |
As ações opcionais precisam de seus arquivos de modelo correspondentes. O comando somente caminhar acima não carrega as políticas de sentar, chutar ou rolar. Para o mapeamento atual do navegador, use o guia do simulador.
Inspecione um pacote antes de compartilhá-lo.
O editor tem um modo de teste que prepara um pacote local. Substitua YOUR_USERNAME pelo namespace Hugging Face pretendido. Este exemplo descreve uma política de caminhada perpétua; não use essa semântica para um truque não relacionado.
uv run publish --onnx first-walk.onnx \
--repo YOUR_USERNAME/microduck-first-walk \
--kind perpetual --slot walk --dry-runO editor verifica a forma esperada, executa uma verificação básica de saída e valida o manifesto antes da preparação policy.onnx, manifest.json e README.md. A simulação é interrompida antes do upload do Hub. Ele recria sua pasta de teste local publish-first-walk/, portanto, mantenha as notas manuais fora dessa pasta. Embalagem de políticas, validação e implementação de teste ↗.
A saída de um modelo finito e não constante é apenas uma verificação básica de validade. Antes de qualquer tentativa de hardware, documente o que aconteceu na simulação ao iniciar, parar, virar e recuperar. Mantenha a documentação de tempo de execução do robô e sua configuração exata ao lado dessas observações.
Mantenha a procedência anexada ao resultado.
Repositório original e revisão completa:
ID da tarefa e configuração de treinamento:
Arquivo de checkpoint ou URL da execução:
Comando de exportação exato:
Nome do ONNX e SHA-256:
Dimensões de entrada/saída e formato dos comandos:
Comando de execução e modelo do robô:
Escala das ações e frequência de controle:
Comportamento observado em simulação:
Falhas conhecidas e casos não testados:
Validação física, se houver:
Autor original, fonte e referências de licença:Para uma política personalizada, registre sua origem e permissões separadamente de malhas de robôs, músicas ou outros ativos agrupados. Um resultado da simulação deve permanecer rotulado como simulação quando você o compartilha.
Continue com seu resultado.
O que você gostaria de entender a seguir?
Mantenha a fonte, seu ambiente e suas observações juntos.
Fontes e data de revisão
Fontes verificadas em 8 de setembro de 2026 · Fonte revisada