16. Inferência real, avaliação e iteração de dados
Capítulo 16 do curso para iniciantes em SO-ARM Physical AI — como a inferência funciona no SO-ARM real, rode sua política ACT treinada com lerobot-record e lerobot-rollout, avalie por taxa de sucesso, analise falhas e itere os dados.
A inferência move o braço real com torque total e sem humano no ciclo. Limpe o espaço num raio de 1 metro, afaste as mãos e mantenha a mão pronta para cortar a energia.
16.1 Fluxo de dados da inferência
16.1 Fluxo de dados da inferência
Lembre do Capítulo 9: a inferência é a imagem espelhada da coleta. Ciclo por quadro:
- Ler as duas câmeras → Observação;
- Ler as 6 juntas do seguidor → Estado;
- Normalizar com as estatísticas salvas no dataset;
- A política prevê um bloco de ações (k × 6);
- Executar nos servos os primeiros passos do bloco;
- Consumida a parte executada, reobservar e reprever.
O braço líder agora fica de fora — o modelo substituiu o humano como decisor. Todo o resto (câmeras, barramento serial, limites de segurança) é idêntico à gravação, e é por isso que as chaves de câmera e o --robot.id precisam bater exatamente com a sessão de gravação.
16.2 Pré-processamento e desnormalização
16.2 Pré-processamento e desnormalização
Seu dataset guardou estatísticas por feature (média/desvio) em meta/stats (Capítulo 13). Na inferência:
- Entrada: imagens e estados são normalizados com as estatísticas de treino antes de entrar na rede;
- Saída: as ações normalizadas da rede são desnormalizadas de volta a valores reais de junta antes de irem aos servos.
É por isso que o comando de avaliação deve usar as mesmas chaves de câmera (front, side) da gravação — chave trocada significa estatística faltando, e aparece isto:
mean is infinity. You should either initialize with stats as an argument or use a pretrained model
16.3 Iniciar a inferência no robô real
16.3 Iniciar a inferência no robô real
Método A: lerobot-record com política (recomendado para começar)
A ferramenta record aceita um checkpoint de política. Ela grava um dataset de avaliação enquanto a política comanda o braço — 10 episódios de avaliação:
lerobot-record \
--robot.type=so101_follower \
--robot.port=/dev/ttyACM0 \
--robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30, fourcc: "MJPG"}, side: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30, fourcc: "MJPG"}}" \
--robot.id=my_awesome_follower_arm \
--display_data=false \
--dataset.repo_id=seeedstudio123/eval_test123 \
--dataset.single_task="Put the object from Point A into Point B" \
--policy.path=outputs/train/act_so101_test/checkpoints/last/pretrained_model
Notas:
--policy.pathé o checkpoint do Capítulo 15. Se o subiu ao Hub, serve um repo id (ex.:${HF_USER}/act_so101_test).- O
dataset.repo_idde avaliação costuma começar comeval_— vídeos e dados ficam separados, ex.:seeedstudio123/eval_test123. - Se aparecer
File exists: '.../eval_xxxx', apague a pasta de avaliação antiga e rode de novo. - As chaves de câmera (
front,side) devem coincidir exatamente com as da gravação do dataset (ver 16.2).
Método B: lerobot-rollout em tempo real
Execução ao vivo sem gravar (suportado por políticas como SmolVLA / ACT):
lerobot-rollout \
--strategy.type=base \
--policy.path=${HF_USER}/act_policy \
--robot.type=so101_follower \
--robot.port=/dev/ttyACM0 \
--robot.cameras="{ front: {type: opencv, index_or_path: 8, width: 640, height: 480, fps: 30, fourcc: "MJPG"}}" \
--display_data=true \
--task="Your task description" \
--duration=60
16.4 Execução do bloco de ações
16.4 Execução do bloco de ações
A distinção bloco/horizonte do Capítulo 14 fica visível aqui:
- O modelo prevê k=100 ações por passada;
- Só a primeira parcela roda em malha aberta antes de reobservar;
- A sobreposição entre o fim do bloco velho e o começo do novo é suavizada (ensemble temporal), então o movimento parece contínuo, não aos trancos.
Se o braço se move em "arrancadas" — uma pausa forte a cada meio segundo — o problema é o horizonte efetivo ou a velocidade de inferência: confira a GPU, o fps das câmeras e considere a inferência assíncrona (a política num processo servidor à parte; a ideia, no capítulo de implantação da Fase 4).
16.5 Segurança: limites, velocidade e parada de emergência
16.5 Segurança: limites, velocidade e parada de emergência
- Os limites de junta da calibração restringem toda ação enviada.
- Mantenha a mão no interruptor nas primeiras rodadas de cada checkpoint novo; cortar a energia é a parada mais rápida (os servos afrouxam).
- ESC numa sessão de avaliação
lerobot-recordencerra o episódio de forma limpa. - Nunca deixe o braço rodar sem supervisão perto de pessoas, cabos ou da borda da mesa.
16.6 Avaliação: taxa de sucesso e tempo de conclusão
16.6 Avaliação: taxa de sucesso e tempo de conclusão
Use os critérios do Capítulo 11 — objetivamente determináveis, não "parece ok":
- Defina sucesso: "o objeto termina dentro da área marcada de B".
- Varie os inícios: coloque o objeto nos 5 pontos marcados e repita cada ponto N vezes.
- Conte: sucessos / total = taxa. Registre também o tempo médio — uma política que demora ou tenta de novo e de novo também está te dizendo algo.
Tabela de resultados sugerida por checkpoint:
| Ponto inicial | Execuções | Sucessos | Taxa |
|---|---|---|---|
| Centro | 4 | 4 | 100% |
| Topo | 4 | 3 | 75% |
| Esquerda | 4 | 2 | 50% |
| ... |
16.7 Teste de generalização
16.7 Teste de generalização
Aprovado o teste dentro da distribuição, sonde as fronteiras deliberadamente (uma mudança por vez):
- Mova o objeto levemente para fora da área marcada;
- Troque o objeto (outro tamanho, mesma categoria);
- Mude a luz (dia vs. abajur noturno).
Espere degradação suave dentro da distribuição e falha dura fora — o princípio de distribuição do Capítulo 8 aparecendo no hardware. Cada falha de generalização que você quiser consertar se responde com dados cobrindo aquela situação, não com mais passos de treino.
16.8 Análise dos tipos de falha
16.8 Análise dos tipos de falha
Classifique cada episódio falho num de quatro baldes — o balde dita a correção:
| Tipo de falha | Parece | Correção |
|---|---|---|
| Falha de percepção | Agarra 3 cm à esquerda do objeto | Dados sem cobertura daquela posição/luz → colete lá |
| Falha de estratégia | Sempre aproxima pelo lado errado | Demonstrações inconsistentes → regrave com uma estratégia |
| Falha de execução | Aproximação certa, objeto escorrega | Força/velocidade de agarre inconsistentes nos dados; confira a calibração da garras |
| Falha de sistema | Braço engasga, pausa, câmera trava | Não é o modelo: fps, banda USB, calibração, temperatura de servo |
16.9 Iteração de dados: coleta guiada por falhas
16.9 Iteração de dados: coleta guiada por falhas
O ciclo que encerra a via principal da Fase 3:
- Avalie (16.6) e classifique as falhas (16.8);
- Para cada balde de falha de percepção/estratégia, grave 10–20 episódios novos cobrindo exatamente aquela situação (fluxo do Capítulo 12);
- Limpe e mescle no dataset com as ferramentas do Capítulo 13;
- Retreine (Capítulo 15) — retomado ou do zero;
- Reavalie. Repita até a taxa satisfazer sua definição de "pronto".
Esse ciclo guiado por falhas — e não nenhuma rodada de treino — é a rotina diária dos projetos reais de aprendizado robótico.