Diagnóstico MicroDuck: controle, CUDA e ONNX

Se o controle de um MicroDuck físico oficial não responder, confira daemon ativo, fonte de entrada, conexão, estado de padd e mapeamento real. Leia os logs antes de refazer o pareamento ou alterar Bluetooth.

Comece no primeiro estágio de falha.

Use a tabela correspondente ao seu ambiente. Um problema de carregamento do navegador, uma dependência ausente do Python e uma incompatibilidade de formato ONNX acontecem em diferentes estágios. Mantenha o erro original antes de alterar as versões; caso contrário, você poderá perder a pista que identifica a camada com falha.

Problemas no simulador do navegador.

Sintomas do navegador e a próxima verificação
Sintoma	Experimente isso	O que gravar
Preso no carregamento	Abra o simulador direto. Experimente a visualização oficial de diagnóstico de inicialização ↗. Aguarde a conclusão da etapa do ativo ou da política.	Versão do navegador, última etapa de carregamento e qualquer erro de SISTEMA HALTED. Uma falha transitória de rede não é evidência de que sua GPU não possa treinar.
O robô ignora as setas	Entre ou retome a cena, clique nela para focar e segure uma seta. Experimente a página direta se o wrapper estiver capturando chaves.	Se a sobreposição de boas-vindas foi fechada, se a página rolou e se a leitura da velocidade mudou.
R senta em vez de rolar	Use o mapa de teclas do navegador atual. R agora controla sentar/ficar em pé no modo pés.	A URL do tutorial e a revisão do simulador. Não substitua atalhos do visualizador Python local.
Os chutes falham após mudar de modo	Retorne ao modo Pés. Chutes e golpes no chão são ações apenas com as pernas; o primeiro switch Rollers também possui carga extra.	Modo selecionado e se seus ativos foram carregados.

Essas verificações combinam nossa verificação de entrada/caminhada/redefinição da área de trabalho com o README do simulador : modos, carregamento e controles ↗ e Implementação do teclado do navegador ↗. Nenhum benchmark de navegador ou reivindicação de compatibilidade móvel está implícito.

Problemas de instalação e CUDA.

Sintomas de dependência e GPU
Sintoma	Próxima verificação
Versão Python rejeitada	Execute `uv run python --version` na cópia local do repositório. Esta revisão exige Python 3.12; siga as etapas de configuração da revisão fixada.
A GPU existe, mas CUDA é falso ou a contagem de GPU é 0	Execute o probe Python/CUDA no mesmo ambiente do treinamento. Registre a versão do PyTorch e a construção, sistema operacional e arquitetura do CUDA. No Linux ARM, inspecione a fonte de roda selecionada do projeto antes de alterar os drivers.
O download da dependência ARM expira	O início rápido oficial sugere um tempo limite HTTP UV mais longo para o primeiro download grande da roda CUDA. Experimente a configuração de um comando abaixo. Ele aborda apenas os tempos limite de download.
Jetson Thor: faltando biblioteca NVPL ou cuDSS	Leia a edição nº 38 com seu JetPack, driver e arquitetura exatos. Ele documenta um problema de pacote específico do Thor; uma receita do pacote GB10 não é automaticamente uma receita Jetson. O relatório ainda estava aberto para revisão.
Um comando de trem não relacionado é executado ou o trem está faltando	Use `uv run train` dentro do checkout sincronizado. O projeto possui intencionalmente este ponto de entrada; seu arquivo de dependência documenta uma colisão executável anterior. Sincronize novamente a revisão correspondente antes de alterar o PATH do sistema.
CUDA sem memória	Registre o erro de alocação, a memória da GPU e a contagem do ambiente. Feche apenas seus próprios trabalhos de GPU não utilizados e tente novamente a mesma tarefa com menos ambientes. Esta é uma redução diagnóstica, não uma cura garantida para todas as falhas de alocação.

Tente novamente um download de dependência expirado

UV_HTTP_TIMEOUT=600 uv sync --locked --python 3.12

Execute essa atribuição de uma linha em um shell POSIX, como bash ou zsh. As restrições subjacentes e a colisão executável estão documentadas em Python, versões fixadas das dependências e fontes de pacotes ARM ↗ ; A descoberta de GPU é descrita por PyTorch: verificando a disponibilidade de CUDA ↗. Relatório Jetson Thor nº 38 (relatório da comunidade, aberto para revisão) ↗ é um relatório de usuário, não uma correção testada por este site.

Problemas de exportação e reprodução.

Sintomas de política e verificações correspondentes
Sintoma	Próxima verificação
ONNX espera 61 entradas, mas recebe um layout mais antigo	Para o contrato de apólice atual revisado, use `--new-cmd-obs` no visualizador local. Deixe-o desativado para políticas legadas de 51 entradas. Confirme o formato de entrada real antes de escolher.
Um arquivo.pt não será carregado como ONNX	Use o exportador oficial de pontos de controle. Os tipos de arquivo têm finalidades diferentes; renomear um ponto de verificação não o converte.
o jogo parece plausível, mas o replay exportado se comporta mal	Verifique se o exportador oficial incluiu a normalização da observação. Em seguida, compare tarefa, ponto de verificação, modelo do robô, escala de ação e layout de comando. Esta é uma ordem de investigação, não um diagnóstico da sua política específica.
Um trabalho remoto continua após Ctrl-C	Abra o URL do trabalho salvo, inspecione seu status e cancele explicitamente, se apropriado. A interrupção do fluxo de logs não interrompe a tarefa.

Inspecione Sinalizadores de reprodução local e controles de teclado ↗ e Exportador oficial ONNX e normalização de observação ↗ para o layout e comportamento de normalização. O comportamento do log da nuvem está documentado em Guia de envio de trabalhos em nuvem MicroDuck ↗ ; o cancelamento é abordado em Hugging Face: gerenciamento e cancelamento de trabalhos ↗.

Em um robô oficial, separe um problema do teclado Bluetooth de uma alteração na fonte de controle.

Esta seção é um caminho de diagnóstico revisado na fonte para o daemon oficial 0.17.2, lançado em 13 de outubro; o site o revisou em 14 de outubro e não emparelhou um bloco nem operou um robô. Não descreve uma réplica ou o simulador do navegador. A página oficial de emparelhamento Bluetooth e o script de histórico já existiam antes de 0.17.2. versão 0.17.2 ↗ emparelhamento e guia de link ↗.

Salve a linha de base somente leitura abaixo antes de tentar uma nova ligação, reinicialização de serviço ou configuração do controlador. configure --list lista substituições, portanto, nenhuma linha netpad.enabled geralmente significa o padrão false, não uma consulta com falha. As duas linhas de saída de systemctl são ordenadas padd e então netpadd. Esta é uma verificação de seleção de origem, não outro tutorial de configuração de UDP; o guia de lançamento 0.17.2 explica o novo tempo UDP. comandos oficiais ↗ seleção de fonte ↗.

Linha de base do bloco somente leitura no robô

robotctl version
robotctl configure --list
systemctl is-active padd netpadd
robotctl pad status
robotctl pad bindings
robotctl logs padd -n 100
robotctl logs bluetooth -n 100

Sintomas oficiais do robô e a próxima evidência a ser lida
O que você vê	O que isso pode significar	Próxima etapa
`padd` inativo; `netpadd` ativo	UDP é a fonte selecionada, portanto, um pad Bluetooth não pode ser acionado durante essa configuração.	Confira a configuração que força a fonte de entrada e consulte o guia atual de troca de fonte; não emparelhe novamente um controle Bluetooth para corrigir uma escolha deliberada de UDP.
`padd` ativo; nenhum pad conectado	O driver está em execução, mas não há entrada Bluetooth no momento. Um pad mostrado como emparelhado, mas NÃO confiável pode funcionar agora, mas não consegue reconectar após uma reinicialização.	Grave registros `pad status` e `padd` / `bluetooth`. Se a falha identificada for confiança, siga as etapas originais de emparelhamento específicas do controlador; não apague todos os títulos primeiro.
Almofada conectada; `padd` inativo	A ligação de rádio e o driver podem falhar separadamente. Um ícone conectado por si só não prova que o robô recebe o controle.	Compare os estados de serviço e o diário `padd`. Se nenhuma das fontes for iniciada, relate o primeiro erro de serviço antes de alterar as configurações.
Pad conectado e driver ativo; um botão não faz nada	Uma ligação ou modo pode explicar isso. Desde 0.16.2, X/Y/LB/RB não tem ação padrão; 0.17.2 também pode substituir eixos, ganhos e limites.	Leia `pad bindings`, `configure --list` e o modo atual. Uma lista de substituição vazia não imprime todos os padrões efetivos.
Pad conectado e driver ativo; a entrada parece congelar durante a condução	Uma parada de rádio é diferente de uma desconexão. `padd` pode reenviar o último valor do stick em 50 Hz, portanto, uma nova intenção downstream não é prova de novos relatórios de pad.	Verifique primeiro o diário `padd`. O painel oficial `robotctl monitor` `p` mostra lacunas brutas no relatório evdev, mas interpretá-lo enquanto move os manípulos requer um teste de hardware controlado e suportado.

O guia de emparelhamento original ↗ distingue um controlador conectado de um driver ativo, e seu exemplo do Pro Controller mostra por que a conexão manual antes do par pode não deixar nenhum dispositivo de entrada. Não altere o BlueZ Privacy por suposição: o documento oficial registra diferentes motivos de falha que exigem configurações diferentes. Seu script de histórico ↗ lê padd existentes e registros de diário do kernel sem um live pad; um tempo limite de supervisão 0x08 aponta para alcance ou interferência, enquanto 0x13/0x16 indica que o pad foi desligado. A falta de histórico não prova ser um link confiável, e uma plataforma de descanso não envia relatórios. Nunca chame um teste de stick ao vivo como somente leitura apenas porque o comando monitor lê apenas dados.

Ao compartilhar uma pergunta, inclua a versão do daemon, os estados de origem em ordem, as duas linhas pad status, as ligações reais dos botões e um pequeno trecho de registro com carimbo de data e hora. Remova endereços de controladores, IPs locais, números de série e detalhes de contas. Indique se a observação veio de um robô físico oficial; uma simulação de navegador não pode testar seu rádio Bluetooth. A parada 0.17.2 UDP stale_ms e a perda de sessão timeout_ms aplicam-se a netpadd, não a este diagnóstico de pad Bluetooth. Máquina de estado UDP ↗ Tratamento de stop e perdas ↗.

Envie um relatório sobre o qual alguém possa agir.

Substitua os campos abaixo pelo que você observou. Inclua um trecho de erro curto e relevante; remova tokens e caminhos pessoais antes de compartilhar. “O que funcionou por último” costuma ser mais útil do que apenas uma captura de tela da exceção final.

Modelo de relatório de solução de problemas

Objetivo:
Etapa com falha (navegador / instalação / CUDA / treinamento / exportação / execução):
URL da página ou repositório e commit completo:
Sistema operacional e arquitetura:
Versões de navegador OU Python / uv / PyTorch / CUDA:
GPU e driver, se relevante:
ID da tarefa / fonte da política / dimensões de entrada:
Comando ou sequência de ações exatos:
Comportamento esperado:
Comportamento real:
Primeiro erro (trecho curto sem segredos):
Última etapa bem-sucedida:
Uma mudança testada e seu resultado:

Inicie uma discussão relacionada →. Para uma suspeita de bug upstream, inclua a mesma reprodução mínima no canal de suporte disponível do projeto original.

Continue com seu resultado.

Repita as verificações de ambiente → Verifique o caminho de exportação e reprodução →

CONTINUE A CONVERSA

O que você gostaria de entender a seguir?

Mantenha a fonte, seu ambiente e suas observações juntos.

Iniciar uma discussão relacionada → Leia discussões relacionadas →

Fontes e data de revisão

Fontes verificadas em 14 de outubro de 2026 · Fonte revisada