Capítulo 01 Básico
O que é Physical AI e por que agora
Modelos de linguagem resolveram boa parte do trabalho de escritório. O mundo físico é a fronteira seguinte — e é uma fronteira que não perdoa erro.
1.1 Definição de trabalho
Physical AI é o termo que se consolidou (popularizado por Jensen Huang, CEO da NVIDIA, em suas keynotes de 2024–2025) para sistemas de inteligência artificial que percebem o mundo físico através de sensores e agem sobre ele através de atuadores — robôs manipuladores, humanoides, veículos autônomos, drones, braços industriais. A diferença central em relação à IA de software: o ciclo de feedback passa pela física real, não por uma API.
1.2 Por que "agora" e não há dez anos
Três coisas mudaram ao mesmo tempo. Modelos de visão-linguagem (VLMs) ficaram bons o suficiente para servir de "cérebro" que entende cena e instrução em linguagem natural. Simulação físico-realista (módulo 4) ficou rápida e barata o suficiente para gerar milhões de horas de experiência sintética. E hardware de robótica — atuadores, baterias, sensores — ficou mais barato e mais capaz, tornando humanoides de propósito geral um projeto comercialmente plausível e não só um artigo acadêmico.
Não é robótica clássica (um braço industrial seguindo uma trajetória pré-programada, sem aprendizado) e não é ficção científica de robô doméstico universal já disponível na loja. É, hoje, majoritariamente pesquisa aplicada e pilotos em produção estreita — com uma lacuna real entre demonstração em vídeo e sistema autônomo confiável em produção (módulo 11 detalha essa lacuna caso a caso).
1.3 A tabela que separa os dois mundos
| Dimensão | IA de software (texto/imagem) | Physical AI |
|---|---|---|
| Ambiente | Digital, determinístico, reversível | Físico, ruidoso, muitas vezes irreversível |
| Dado de treino | Escala de internet (texto, imagem) | Escasso, caro de coletar (módulo 6) |
| Custo de erro | Resposta ruim, regenerar | Objeto quebrado, pessoa ferida, hardware danificado |
| Latência aceitável | Segundos | Milissegundos, em malha de controle (módulo 2) |
| Avaliação | Benchmarks offline | Precisa rodar no mundo real em algum ponto |
"Por que Physical AI é considerada mais difícil que LLMs?" é a pergunta de abertura mais comum em entrevistas da área. A resposta que impressiona não é "porque robôs são complicados" — é a tabela acima: dado escasso, custo de erro físico, e a exigência de rodar em tempo real fora de um datacenter controlado.
Diga se cada sistema é Physical AI, robótica clássica, ou nenhum dos dois: (a) braço industrial soldando sempre no mesmo ponto, programado manualmente; (b) robô aspirador que usa visão para mapear e evitar móveis desconhecidos; (c) chatbot que responde perguntas sobre manutenção de robôs; (d) braço que aprendeu, por demonstração humana, a arrumar objetos variados numa caixa.
Ver gabarito
(a) Robótica clássica — trajetória fixa, sem percepção adaptativa. (b) Physical AI — percepção (visão), decisão (mapeamento/planejamento) e ação adaptadas ao ambiente. (c) Nenhum dos dois — é IA de software sobre texto, mesmo que o assunto seja robôs. (d) Physical AI — aprendeu uma política a partir de dados, generaliza para objetos novos.
Capítulo 02 Básico · Interativo
Anatomia de um agente físico: percepção, cognição, ação
Todo agente físico roda o mesmo ciclo, do robô aspirador ao humanoide de laboratório. O que muda é a sofisticação de cada etapa — não a existência delas.
2.1 O ciclo sense-think-act
Role o bloco abaixo: o painel escuro fica fixo e destaca a etapa que cada cartão descreve. O ciclo nunca para — ele roda de novo a cada novo instante de decisão, muitas vezes a dezenas ou centenas de vezes por segundo.
Percepção: o gargalo é ruído, não falta de dado
Câmeras RGB e de profundidade, LiDAR, IMU (aceleração/rotação), sensores de força/torque nas juntas e propriocepção (onde estão as próprias articulações). O problema raramente é "falta sensor" — é lidar com ruído, oclusão e iluminação variável em tempo real.
Modelo de mundo: comprimir sem perder o que importa
Pode ser um mapa 3D explícito (SLAM), ou uma representação latente aprendida (embeddings de um modelo de visão). Sistemas modernos de Physical AI tendem a aprender essa representação end-to-end em vez de construí-la à mão.
Decisão: de regras a redes neurais
Robótica clássica usava máquinas de estado e controladores explícitos. Physical AI moderna usa políticas aprendidas — redes neurais (frequentemente modelos VLA, capítulo 3) que mapeiam percepção + objetivo diretamente para ação.
Atuação: o relógio que nunca perdoa
Um braço robótico manipulando um objeto frágil pode precisar decidir a cada 10–50 milissegundos. Um humanoide caminhando, ainda mais rápido para a malha de equilíbrio. Esse orçamento de latência é o motivo de muitas arquiteturas separarem uma política "lenta e inteligente" de um controlador "rápido e simples" — tema do capítulo 8.
2.2 Quatro peças, em cartões
Sensores
A fonte de verdade do mundo — e a fonte de todo ruído que o resto do sistema precisa tolerar.
Modelo de mundo
A ponte entre dado bruto e decisão — explícito (mapas) ou aprendido (embeddings).
Política
A função que decide a ação — o alvo principal do aprendizado em Physical AI moderna.
Atuadores
Motores, garras, pernas — a interface final e o ponto onde erro de software se torna dano físico.
Um sistema que decide perfeitamente mas tarde demais falha da mesma forma que um que decide errado. Muitas arquiteturas de Physical AI de produção sacrificam alguma sofisticação de percepção para garantir um orçamento de latência previsível — é uma troca deliberada, não um atalho por pressa.
Um robô de armazém pega a caixa errada. Liste três hipóteses, uma para cada etapa (percepção, modelo de mundo, política), sobre onde a falha pode ter começado.
Ver exemplo resolvido
Percepção: a câmera confundiu duas caixas parecidas sob iluminação ruim. Modelo de mundo: a posição da caixa certa estava desatualizada por um atraso no mapa. Política: a política identificou a caixa certa mas escolheu a ação de agarrar errada por generalização ruim para aquele formato de caixa. Diagnosticar exige logs de cada etapa separadamente — nunca assumir que "o robô errou" localiza o problema.
Um humanoide precisa reagir a um tropeço em até 30ms para não cair. Se a percepção leva 8ms, o modelo de mundo 5ms e a política 12ms, quanto resta para a atuação, e isso é confortável?
Ver gabarito
30 − 8 − 5 − 12 = 5ms para a atuação física responder. É uma margem apertadíssima — na prática, sistemas de equilíbrio usam um controlador de baixo nível dedicado e muito mais rápido que a política de alto nível, exatamente para não depender desse orçamento total (capítulo 8).
Capítulo 03 Intermediário
Modelos de visão-linguagem-ação (VLA)
A ideia que unificou o campo: pegue um modelo de visão-linguagem já treinado em escala de internet, e ensine-o a produzir ações em vez de só texto.
3.1 A ideia central
Um modelo de visão-linguagem (VLM) já sabe associar imagem a texto — "isto é uma xícara vermelha sobre uma mesa". Um modelo visão-linguagem-ação (VLA) estende isso: em vez de responder em texto, o modelo produz uma sequência de ações de controle (posições de junta, velocidades, comandos de garra) que, executadas, cumprem uma instrução como "pegue a xícara vermelha e coloque na pia". A aposta central é que o conhecimento de mundo do VLM (o que é uma xícara, como objetos se comportam, o que significa "colocar na pia") generaliza para tarefas físicas melhor do que treinar uma política do zero só com dados de robô.
3.2 O panorama de modelos
| Modelo | Origem | Ideia distintiva |
|---|---|---|
| RT-1 / RT-2 | Google DeepMind | Ações discretizadas em "tokens", tratadas como se fossem palavras de um vocabulário |
| OpenVLA | Comunidade aberta (Stanford, Berkeley, outros) | Modelo aberto e replicável, treinado sobre datasets públicos (módulo 6) |
| π0 (pi-zero) | Physical Intelligence | Ações contínuas via "flow matching", visando generalização entre tipos de robô |
| Octo | Comunidade aberta | Modelo generalista treinado em múltiplos robôs e tarefas simultaneamente |
3.3 Ações discretas vs. contínuas
Duas famílias de representação de ação disputam o campo:
- Discretização (tokens): cada dimensão de movimento é dividida em faixas (por exemplo, 256 níveis de posição), tratada como um "vocabulário" que o modelo prevê como faria com palavras. Vantagem: reaproveita toda a infraestrutura de modelos de linguagem. Desvantagem: perde precisão fina de movimento.
- Ação contínua direta: o modelo produz valores reais (não discretizados), frequentemente via cabeças de regressão ou técnicas de difusão/flow matching. Vantagem: movimento mais suave e preciso. Desvantagem: arquitetura mais especializada, menos reuso direto de LLMs prontos.
"Por que usar um VLM pré-treinado em vez de treinar do zero com dados de robô?" testa se você entende a economia do campo: dados de robô são escassos e caros (módulo 6); dados de imagem-texto são abundantes. Herdar conhecimento de mundo de um VLM é uma forma de contornar a escassez — não uma escolha arbitrária de arquitetura.
Para cada tarefa, discreta ou contínua parece mais adequada: (a) empurrar um botão grande; (b) costurar um ponto cirúrgico; (c) empilhar caixas num palete.
Ver gabarito
(a) Discreta é suficiente — tolerância de posição alta. (b) Contínua é praticamente obrigatória — a precisão de milímetros e a suavidade do movimento importam diretamente para o resultado. (c) Depende da tolerância do palete; discreta costuma bastar, com contínua ajudando no alinhamento fino final.
Capítulo 04 Intermediário
Simulação: treinar antes de tocar o mundo real
Treinar uma política direto no robô físico é lento, caro e arriscado. A simulação existe para adiar esse custo — não para eliminá-lo.
4.1 Por que simular
- Velocidade: um simulador pode rodar mais rápido que o tempo real e em paralelo, gerando em horas o equivalente a anos de experiência de um robô físico.
- Custo: hardware de robô é caro e se desgasta; instâncias de simulação em nuvem escalam horizontalmente por uma fração do custo.
- Segurança: uma política aleatória no início do treinamento pode danificar um robô real ou o ambiente; em simulação, o pior caso é reiniciar.
4.2 O ecossistema de simuladores
| Simulador | Mantido por | Ponto forte |
|---|---|---|
| NVIDIA Isaac Sim / Isaac Lab | NVIDIA | Física via Omniverse/PhysX, renderização foto-realista, paralelismo em GPU |
| MuJoCo | Google DeepMind (código aberto desde 2022) | Física de contato rápida e precisa, padrão de pesquisa em RL para robótica |
| Genesis | Comunidade acadêmica/open source | Simulação de altíssima velocidade voltada a treinar políticas em escala |
| Gazebo | Open Robotics | Integração nativa com ROS, forte em robótica móvel/industrial clássica |
| Unity (com ML-Agents) | Unity Technologies | Motor de jogos geral, útil para prototipagem visual e treinamento de RL — ver a apostila de Unity WebGL para o motor em si |
Simuladores custam engenharia: montar a cena, calibrar a física, e — o mais caro de todos — garantir que o simulado se pareça o suficiente com o real para o que foi aprendido lá funcionar aqui. Essa lacuna tem nome e é o assunto inteiro do próximo capítulo.
Você quer treinar uma política de manipulação com milhares de variações de objeto em paralelo, priorizando velocidade de treino sobre realismo visual. Qual família de simulador da tabela é mais indicada, e por quê?
Ver exemplo resolvido
MuJoCo ou Genesis — ambos priorizam velocidade de física de contato e paralelismo sobre fidelidade fotográfica, o que é exatamente o que treino de política em larga escala precisa. Isaac Sim ganharia se o objetivo fosse também treinar percepção visual robusta com renderização realista.
Capítulo 05 Aplicado
O gap sim-to-real e como fechá-lo
Uma política perfeita em simulação pode falhar completamente no robô real. Esse gap tem causas conhecidas e mitigações testadas.
5.1 De onde vem o gap
| Fonte do gap | O que acontece | Mitigação principal |
|---|---|---|
| Visual | Texturas, iluminação e materiais simulados não batem com o real | Domain randomization visual; renderização foto-realista |
| Dinâmica | Atrito, massa, elasticidade dos objetos simulados diferem do real | Domain randomization física; identificação de sistema (system identification) |
| Latência e ruído de sensor | Sensores reais atrasam e erram de formas que o simulador não modela por padrão | Injetar ruído e atraso sintéticos no treino |
| Dinâmica de contato | Contato físico (fricção, deformação) é notoriamente difícil de simular com fidelidade | Simuladores especializados em contato; calibração empírica |
5.2 Domain randomization: a técnica mais usada
Em vez de tentar simular o mundo real com perfeição (impossível), domain randomization varia deliberadamente cor, textura, iluminação, massa, atrito e posições dentro de uma faixa ampla durante o treino. A política aprende a ser robusta a essa variação — e o mundo real passa a ser só "mais uma variação dentro da faixa já vista", em vez de um domínio completamente novo.
5.3 Digital twins e identificação de sistema
Uma abordagem complementar é medir parâmetros físicos reais do robô específico (massa exata de cada elo, atrito de cada junta, folga mecânica) e calibrar o simulador para reproduzi-los com precisão — um digital twin. Isso reduz o gap para aquele robô específico, ao custo de ter que recalibrar para cada unidade de hardware ou após desgaste.
"Descreva domain randomization e dê um exemplo de parâmetro que você randomizaria" é pergunta padrão para engenharia de ML em robótica. Uma resposta forte cita pelo menos um parâmetro visual (textura/iluminação) e um físico (massa/atrito), e explica que o objetivo é robustez, não realismo perfeito.
Uma política de agarrar objetos funciona perfeitamente em simulação mas falha 60% das vezes no robô real, sempre deixando o objeto cair pouco depois de tocá-lo. Qual fonte de gap da tabela 5.1 é a suspeita número 1, e que experimento você faria para confirmar?
Ver gabarito
Suspeita 1: dinâmica de contato/atrito — o objeto escorrega porque o atrito real é diferente do simulado. Experimento: medir o coeficiente de atrito real dos objetos e da garra, recalibrar o simulador com esses valores, e re-treinar ou fazer fine-tuning só com essa correção antes de suspeitar de outras causas.
Você está treinando um robô para navegar num corredor de escritório. Liste três parâmetros que randomizaria e por quê.
Ver exemplo resolvido
(1) Iluminação (janelas, luzes artificiais variam por prédio); (2) textura/cor do piso (carpete, cerâmica, madeira); (3) posição e tipo de obstáculos (móveis, pessoas, caixas) — cobrindo tanto a variação visual quanto a variação de layout que o robô vai encontrar em prédios diferentes do treino.
Capítulo 06 Aplicado
Dados: teleoperação, demonstrações humanas e datasets
Não existe "internet de dados de robô". Cada trajetória física útil foi coletada, uma a uma, com custo real.
6.1 O problema da escassez
Um LLM treina em trilhões de tokens de texto já existente na internet. Não existe equivalente para "um braço robótico agarrando dez mil objetos diferentes com sucesso" — esse dado precisa ser gerado ativamente, geralmente com um humano no processo. Essa escassez é a razão estrutural pela qual VLA (módulo 3) tenta herdar conhecimento de modelos treinados em dados abundantes (imagem-texto) em vez de aprender tudo do zero com dados de robô.
6.2 Formas de coletar demonstração
| Método | Como funciona | Trade-off |
|---|---|---|
| Teleoperação | Humano controla o robô remotamente (joystick, luva háptica, exoesqueleto) enquanto os dados de trajetória são gravados | Alta qualidade, mas lento e caro por demonstração |
| Ensino cinestésico | Humano move fisicamente o braço do robô pela tarefa, gravando as posições | Intuitivo, mas não escala para robôs muito maiores/menores que humanos |
| Captura de movimento humano | Grava humanos realizando a tarefa com as próprias mãos, depois retarget para o robô | Escalável, mas exige mapear anatomia humana para a do robô |
| Aprendizado a partir de vídeo | Extrai informação de ação a partir de vídeos existentes (YouTube, egocêntricos) sem robô físico | Dado abundante, mas a ação real precisa ser inferida indiretamente |
6.3 Os datasets que o campo compartilha
- Open X-Embodiment: esforço colaborativo entre dezenas de laboratórios, agregando dados de mais de vinte tipos de robô diferentes — a base de treino de OpenVLA e Octo (módulo 3).
- RoboNet: dataset multi-robô anterior, focado em manipulação, um dos primeiros esforços de agregação em larga escala.
- DROID: dataset distribuído coletado por teleoperação em múltiplas instituições, com foco em diversidade de cenas domésticas e de escritório.
- Ego4D e vídeos egocêntricos: não são dados de robô, mas alimentam a linha de "aprender ação a partir de vídeo humano".
Times de Physical AI contratam especificamente para "engenharia de dados de robótica" — um papel que não existe em ML de texto/imagem na mesma forma: projetar rigs de teleoperação, garantir qualidade e diversidade das demonstrações, e construir pipelines de anotação são competências próprias e bem remuneradas neste mercado ainda com poucos especialistas.
Você precisa de mil demonstrações de "dobrar uma toalha" para um braço robótico bimanual. Teleoperação, ensino cinestésico ou vídeo humano? Justifique considerando custo e qualidade.
Ver gabarito
Teleoperação é a escolha mais comum para tarefas bimanuais complexas: o operador humano controla ambos os braços com feedback visual, produzindo demonstrações de alta qualidade que capturam a coordenação entre as duas mãos — algo que ensino cinestésico (um braço por vez, sem coordenação natural) e vídeo humano (retarget de anatomia diferente) dificultam.
Capítulo 07 Aplicado
Aprendizado por reforço aplicado a robôs
RL promete robôs que melhoram com a própria experiência. Na prática física, cada trial custa tempo, energia e desgaste — e isso muda tudo.
7.1 Por que RL em robôs físicos é brutalmente caro
Algoritmos de RL clássicos (usados com sucesso em jogos) frequentemente precisam de milhões de trials para convergir. Um robô físico não pode rodar milhões de trials — cada um consome tempo real, desgasta motores e pode acabar em uma queda ou colisão. Por isso a maioria do RL de robótica moderna roda majoritariamente em simulação (módulo 4), com o robô real usado só para fine-tuning final e validação.
7.2 Alternativas e complementos ao RL puro
| Abordagem | Ideia | Quando preferir |
|---|---|---|
| Imitation learning | Aprender diretamente das demonstrações (módulo 6), sem exploração por tentativa e erro | Quando há demonstrações de qualidade suficientes |
| RL offline | Aprender uma política a partir de um dataset fixo de experiência já coletada, sem interagir mais com o ambiente durante o treino | Quando coletar mais dados é caro mas já existe um dataset razoável |
| RL online em simulação + fine-tuning real | Explorar livremente em simulação, refinar com poucas iterações reais | Quando o gap sim-to-real (módulo 5) já foi bem mitigado |
7.3 Reward hacking físico: quando o robô "trapaceia" com o corpo
Reward hacking em RL de software produz um resultado bobo (um agente de jogo que trava o placar em vez de jogar). Em Physical AI, uma política mal especificada pode "trapacear" batendo o braço numa posição fixa que engana o sensor de sucesso, ou explorando um bug do motor de física em simulação — e depois falhar (ou danificar hardware) ao ser levada para o robô real. Projetar a função de recompensa com cuidado, e validar em simulação antes de qualquer contato com hardware real, não é opcional.
Uma política de RL treinada para "manter o objeto o mais alto possível" aprende a jogar o objeto para cima repetidamente em vez de erguê-lo e sustentá-lo. Isso é um bug do robô ou da recompensa? Como você corrigiria a especificação?
Ver gabarito
É reward hacking — a recompensa media só a altura instantânea, sem penalizar velocidade/impacto ou recompensar sustentação ao longo do tempo. Correção: recompensar altura sustentada (média numa janela de tempo) e penalizar velocidade excessiva de impacto — alinhando a métrica com o comportamento realmente desejado.
Capítulo 08 Avançado
Controle clássico encontra aprendizado
A arquitetura que domina sistemas em produção não escolhe entre controle clássico e aprendizado — combina os dois em camadas.
8.1 Duas tradições, dois pontos fortes
| Dimensão | Controle clássico (PID, MPC) | Política aprendida |
|---|---|---|
| Garantias | Prováveis matematicamente (estabilidade, limites) | Estatísticas, sem garantia formal geral |
| Generalização | Exige modelo explícito do sistema | Generaliza para situações não modeladas explicitamente |
| Velocidade | Roda em microssegundos, determinístico | Depende do tamanho do modelo e do hardware de inferência |
| Onde brilha | Malhas de segurança e equilíbrio de baixo nível | Percepção, planejamento de alto nível, tarefas variáveis |
8.2 A arquitetura hierárquica padrão
Sistemas de produção tipicamente separam uma política de alto nível (aprendida, mais lenta, decide "o quê" fazer) de um controlador de baixo nível (clássico, muito mais rápido, decide "como" executar com segurança e estabilidade). Um humanoide, por exemplo, pode ter uma política aprendida decidindo "caminhe até a mesa e pegue a xícara" enquanto um controlador de equilíbrio clássico, rodando numa frequência muito mais alta, garante que o robô não caia a cada passo — independente do que a política de alto nível decidiu.
8.3 A camada de segurança (safety shield)
Uma prática cada vez mais padrão é inserir uma camada de segurança entre a política aprendida e os atuadores: um verificador clássico (baseado em regras ou modelo físico) que intercepta e corrige ou bloqueia ações que violariam limites conhecidos (velocidade máxima de junta, zona de exclusão, força máxima) — mesmo que a política aprendida, por erro de generalização, tenha produzido essa ação.
"Você confiaria uma política de rede neural para controlar diretamente os atuadores sem nenhuma camada de segurança clássica?" é pergunta de julgamento de senioridade. A resposta esperada reconhece que a resposta correta quase sempre é não — arquiteturas híbridas com camada de segurança são o padrão da indústria, não uma escolha conservadora incomum.
Para um braço robótico que corta vegetais seguindo instrução em linguagem natural ("corte a cenoura em rodelas"), esboce que parte seria política aprendida e que parte seria controlador clássico.
Ver exemplo resolvido
Política aprendida (VLA, alto nível): interpreta a instrução, identifica a cenoura, decide a sequência de cortes e trajetórias aproximadas. Controlador clássico (baixo nível): executa cada movimento de corte com força e velocidade controladas dentro de limites seguros, e uma camada de segurança bloqueia qualquer trajetória que aproxime a lâmina de dedos detectados por visão, independente do que a política decidiu.
Capítulo 09 Avançado
Humanoides e manipulação: o estado da arte
2026 tem mais humanoides andando em vídeo do que em qualquer outro momento da história — e o desafio real nunca foi andar. É a mão.
9.1 O panorama de plataformas humanoides
| Plataforma | Empresa | Status observável (2026) |
|---|---|---|
| Figure 02 / 03 | Figure AI | Pilotos em ambiente industrial e parcerias anunciadas; foco em manipulação e VLA próprio |
| Optimus | Tesla | Demonstrações internas e roadmap de produção declarado; uso interno em fábrica citado, deploy externo amplo ainda não confirmado independentemente |
| Atlas (versão elétrica) | Boston Dynamics | Foco em pesquisa de manipulação dinâmica e mobilidade, sem produto comercial amplo |
| Digit | Agility Robotics | Pilotos comerciais em logística (manuseio de totes/caixas em armazém) |
| H1 / G1 e outros | Unitree | Plataformas de custo mais baixo, fortes em pesquisa acadêmica e prototipagem |
9.2 Por que manipulação é mais difícil que locomoção
Caminhar é um problema de equilíbrio dinâmico bem estudado desde os anos 1980. Manipular é um problema de contato de alta dimensão com objetos desconhecidos: uma mão humana tem mais de vinte graus de liberdade, o atrito e a deformação de cada objeto são diferentes, e a tarefa muda a cada novo objeto. É por isso que "andar bem" chegou décadas antes de "manipular bem qualquer objeto novo" — e por que a manipulação generalista continua sendo o principal gargalo de pesquisa do campo.
9.3 Destreza e manipulação bimanual
- Preensão de objetos novos (grasping): decidir onde e como agarrar um objeto nunca visto, sem depender de uma biblioteca fixa de formatos conhecidos.
- Sensação tátil: sensores de pele artificial e sensores de força na ponta dos dedos ainda são muito mais grosseiros que a sensibilidade tátil humana, limitando ajustes finos de preensão.
- Coordenação bimanual: tarefas como dobrar roupa ou montar peças exigem coordenar dois braços com objetivos que se afetam mutuamente em tempo real — muito mais difícil de treinar do que um braço isolado.
Um vídeo de humanoide fazendo uma tarefa doméstica pode ser: (a) totalmente autônomo, (b) parcialmente teleoperado com edição de vídeo favorável, ou (c) uma demonstração roteirizada de melhor caso, sem repetibilidade divulgada. As três coisas parecem idênticas em quinze segundos de vídeo. Antes de tratar qualquer demonstração como evidência de capacidade de produção, procure: taxa de sucesso divulgada, número de tentativas, e se foi autônomo ou teleoperado — informação que empresas sérias costumam divulgar quando o resultado é genuinamente forte.
Uma empresa divulga um vídeo de 20 segundos de um humanoide dobrando uma camisa perfeitamente. Que três perguntas você faria antes de considerar isso evidência de capacidade real de produto?
Ver gabarito
(1) Foi autônomo ou teleoperado? (2) Qual a taxa de sucesso em múltiplas tentativas, com camisas diferentes, não só a melhor gravação? (3) Isso rodou em condições controladas de laboratório ou num ambiente real e variável? Sem essas respostas, o vídeo é evidência de potencial, não de produto pronto.
Capítulo 10 Muito avançado
Segurança, robustez e falhas físicas
Um bug de software é um ticket no backlog. Um bug de Physical AI pode ser uma pessoa no hospital. A engenharia de segurança não é opcional aqui.
10.1 Normas que já existem para isso
| Norma | Escopo |
|---|---|
| ISO 10218 (partes 1 e 2) | Requisitos de segurança para robôs industriais e sua integração |
| ISO/TS 15066 | Requisitos específicos para robôs colaborativos (cobots) operando perto de humanos |
| ISO 13482 | Segurança para robôs de cuidado pessoal (assistência, mobilidade) |
Essas normas antecedem a onda atual de Physical AI baseada em aprendizado, mas seus princípios — parada de emergência acessível, limites de força/velocidade, zonas de exclusão — continuam sendo a base sobre a qual sistemas modernos precisam ser construídos, independentemente de quão "inteligente" seja a política que os controla.
10.2 Falhas específicas de sistemas físicos aprendidos
- Oclusão de sensor: um objeto ou a própria estrutura do robô bloqueia a visão no momento crítico, e a política decide com informação incompleta sem saber que está incompleta.
- Desgaste de atuador: um motor gasto se comporta diferente do modelo (simulado ou aprendido) usado no treino — um tipo de "drift" que não existe em software puro.
- Robustez adversarial de percepção: padrões visuais específicos (adesivos, texturas) podem confundir sistemas de visão de forma imperceptível para humanos — uma preocupação de segurança real para veículos autônomos e robôs em ambientes públicos.
- Comportamento humano inesperado: pessoas perto de robôs não seguem scripts; uma criança correndo, um objeto caindo fora do previsto — a política precisa degradar com segurança, não só performar bem no caso esperado.
Um sistema seguro não é o que nunca encontra uma situação imprevista — é o que, ao encontrar uma, para com segurança em vez de continuar agindo com confiança injustificada. Projetar para "eu não sei o que fazer aqui, vou parar" é tão importante quanto projetar para "eu sei o que fazer aqui".
Um robô de entrega autônomo detecta uma situação fora de qualquer padrão visto em treino (por exemplo, uma obra não sinalizada bloqueando a calçada). Que comportamento de fallback você especificaria?
Ver gabarito
Parar em local seguro, reduzir velocidade a zero, acionar sinalização visível (luz/som) informando incerteza, e — se disponível — solicitar intervenção remota humana (teleoperação de resgate) em vez de tentar improvisar uma rota não validada. O princípio geral: diante de alta incerteza, o custo de parar é quase sempre menor que o custo de agir errado.
Capítulo 11 Muito avançado
Onde já funciona e onde ainda é promessa
O filtro mais útil para julgar qualquer anúncio do campo: implantado em produção com métricas públicas, ou ainda piloto/demonstração?
11.1 Quatro casos, lidos com o mesmo filtro
Robótica de armazém
Logística · já funciona em escalaRobôs móveis autônomos (AMRs) transportando estantes e itens dentro de centros de distribuição — como os sistemas usados pela Amazon (linhagem Kiva/Proteus) e concorrentes — operam em produção, 24/7, há anos, com métricas de produtividade públicas e melhoria contínua divulgada. Manipulação fina (retirar um item específico de uma prateleira bagunçada) ainda é mais limitada que transporte, mas o transporte autônomo em si é uma categoria madura.
Robótica agrícola
Agro · funciona em nichos definidosColheita autônoma de frutas específicas, robôs de capina seletiva e tratores com piloto autônomo guiado por GPS/visão já operam comercialmente em fazendas — mas cada sistema costuma ser especializado numa cultura e num tipo de terreno. Generalizar de "colhe morango" para "colhe qualquer fruta em qualquer plantação" continua sendo pesquisa, não produto.
Entrega autônoma de última milha
Delivery · misto, dependente de regulaçãoRobôs de entrega em calçada e veículos autônomos de entrega operam em pilotos em várias cidades, mas enfrentam barreiras regulatórias, casos extremos de calçada/trânsito não resolvidos, e frequentemente ainda dependem de supervisão remota humana para casos fora do previsto — uma forma de teleoperação de segurança, não autonomia plena.
Humanoide generalista doméstico/fábrica
Manipulação geral · majoritariamente promessaUm humanoide capaz de realizar qualquer tarefa doméstica ou de linha de fábrica variável, com a mesma confiabilidade e sem supervisão, ainda não está implantado em produção ampla e independentemente verificada em 2026 — apesar de demonstrações impressionantes (capítulo 9). O que existe são pilotos estreitos, em tarefas específicas, dentro de empresas ou parcerias controladas.
Para qualquer anúncio de Physical AI, pergunte: ambiente estruturado ou não-estruturado? tarefa estreita ou geral? métricas públicas de produção ou vídeo de demonstração? Quanto mais estruturado e estreito, mais provável que já seja produção real. Quanto mais geral e impressionante o vídeo, maior a chance de ser, ainda, promessa de roadmap.
Capítulo 12 Prática
Pipeline completo e plano de 30 dias
Juntando todos os capítulos num roteiro só, do problema definido ao piloto em produção — e um plano realista para começar a explorar o campo em um mês.
12.1 O pipeline, de ponta a ponta
Passo 2 Escolher simulador e montar a cena (capítulo 4)
Passo 3 Coletar ou reaproveitar demonstrações (capítulo 6)
Passo 4 Treinar política — imitation learning, RL ou VLA fine-tuned (capítulos 3 e 7)
Passo 5 Aplicar domain randomization e medir robustez em simulação (capítulo 5)
Passo 6 Adicionar camada de segurança e controlador de baixo nível (capítulo 8)
Passo 7 Transferir para hardware real com fine-tuning limitado (capítulo 5)
Passo 8 Piloto controlado, com métricas de taxa de sucesso e casos de falha documentados (capítulo 10 e 11)
Passo 9 Expandir escopo só depois de dados reais de produção — não antes
12.2 Plano de 30 dias para explorar o campo
| Semana | Foco |
|---|---|
| 1 | Fundamentos (capítulos 1–2) + instalar um simulador (MuJoCo ou Isaac Sim) e rodar um exemplo pronto |
| 2 | Treinar uma política simples de imitation learning num ambiente simulado padrão (por exemplo, um braço de dois graus de liberdade) |
| 3 | Baixar uma amostra do Open X-Embodiment, explorar um checkpoint de OpenVLA e testar em simulação |
| 4 | Escolher um projeto de portfólio abaixo e documentar taxa de sucesso, falhas e o que faria diferente |
12.3 Projetos de portfólio
- Política de manipulação simulada, do zero ao vídeo: imitation learning num ambiente MuJoCo/Isaac Lab, com domain randomization e um relatório da taxa de sucesso.
- Fine-tuning de um VLA aberto: partir de um checkpoint OpenVLA/Octo e adaptar para uma tarefa nova, documentando dados usados e resultado.
- Estudo comparativo de simuladores: a mesma tarefa em dois simuladores da tabela 4.2, comparando velocidade de treino e qualidade da política resultante.
- Auditoria de segurança de um sistema hipotético: aplicar ISO 10218/15066 a um caso de uso escolhido, listando riscos e mitigações concretas.
- Análise crítica de demonstrações públicas: escolher três vídeos de humanoides divulgados e aplicar o filtro do capítulo 11 e 9, documentando o que cada um realmente evidencia.
12.4 Fontes para continuar
- Papers de referência: RT-2 (Google DeepMind), OpenVLA e π0 (Physical Intelligence) — os artigos originais, disponíveis publicamente, com detalhes de arquitetura e dados.
- Datasets e código aberto: Open X-Embodiment, repositórios oficiais de OpenVLA e Octo.
- Simuladores: documentação oficial de NVIDIA Isaac Lab e MuJoCo, ambos com tutoriais gratuitos.
- Normas de segurança: ISO 10218 e ISO/TS 15066, para quem for além do protótipo.
Quatro ideias sustentam Physical AI: (1) o custo de erro é físico e às vezes irreversível — isso muda cada decisão de arquitetura em relação à IA de software; (2) dado de robô é escasso por natureza, e boa parte do campo existe para contornar essa escassez (VLA herdando de VLMs, simulação, domain randomization); (3) a arquitetura que vence em produção é híbrida — aprendizado para flexibilidade, controle clássico para garantias de segurança; (4) o filtro do capítulo 11 — estruturado/estreito/com métricas públicas versus geral/impressionante/só demonstração — é a ferramenta mais útil para separar o que já está mudando o mundo do que ainda é promessa de roadmap.