Conteúdo detalhado
🏗️ Hierarquia de controle: simbólico × reativo
A robótica clássica sempre separou planejamento (alto nível, abstrato, lento) de controle (baixo nível, contínuo, rápido). As arquiteturas híbridas modernas reencarnam essa hierarquia com componentes aprendidos: um modelo de raciocínio no topo, uma política reativa na base. O motivo é fundamental — as escalas de tempo são incompatíveis.
💡 O conflito de escalas de tempo
Raciocinar "como guardar a louça" leva segundos de inferência num VLM grande. Controlar um dedo exige decisões a cada ~5 ms. Forçar uma rede só a fazer ambos resulta em algo lento demais para a malha ou burro demais para a tarefa. A hierarquia desacopla as frequências.
Hierarquia
Planejar vs controlar.
Planejamento simbólico
Abstrato, discreto.
Política reativa
Contínua, rápida.
Desacoplamento
Frequências separadas.
🐢🐇 System 1 / System 2 (Helix, GR00T)
A instância de ponta da hierarquia é o dual-system, emprestando a metáfora de Kahneman. O System 2 (VLM lento) raciocina e emite um vetor latente de intenção; o System 1 (política rápida) condiciona-se nesse latente para gerar ação de alta frequência. Helix e GR00T convergiram para esse desenho — e ele roda assíncrono: o S1 não espera o S2 a cada passo.
# Inferência assíncrona dual-system
latent = None
loop_S2 (~8 Hz): latent = VLM(image, instruction) # raciocínio
loop_S1 (~200 Hz): action = policy(obs, latent) # controle
robot.step(action)
# S1 reusa o último latent enquanto S2 ainda pensa📊 Por que o latente, e não texto?
- Banda larga — um vetor contínuo carrega mais nuance que uma string de skill discreta.
- Diferenciável — permite treinar S1 e S2 de forma acoplada quando desejado.
- Rápido — não há parsing de linguagem na malha de controle.
Dual-system
S2 pensa, S1 age.
Latent conditioning
S1 condicionado em z.
Async inference
Loops independentes.
Kahneman
Pensar lento × rápido.
📋 LLM como planejador: SayCan, Code-as-Policies
Antes do latente contínuo, a primeira onda de híbridos usou o LLM como planejador simbólico. SayCan (Google, 2022) combinou a probabilidade do LLM ("say") com a viabilidade de cada skill ("can") para escolher o próximo passo. Code-as-Policies foi além: o LLM escreve código que chama APIs de percepção e controle, ganhando loops, condicionais e composição.
# Code-as-Policies — LLM gera o plano como programa
# instrução: "empilhe os blocos por cor"
for color in detect_colors():
blocks = get_objects(color=color)
base = blocks[0]
for b in blocks[1:]:
pick(b); place_on(base); base = b
# loops + lógica que uma lista plana de skills não expressa💡 SayCan em uma frase
score(skill) = P_LLM(skill é útil para a tarefa) × P_affordance(robô consegue executar agora). O "say" sozinho sonha planos impossíveis; o "can" os ancora na realidade física.
SayCan
Say × can.
Code-as-Policies
LLM escreve código.
Task decomposition
Quebrar em subtarefas.
Prompting
Sem treinar nova política.
🎯 Affordances e grounding
Um plano só vale se for executável. Affordance é a estimativa de quão viável é uma ação no estado atual; grounding é a ligação entre a linguagem do planejador e as habilidades reais do robô. Sem isso, o LLM produz planos eloquentes e impossíveis — pedir para "pegar o copo" quando não há copo à vista.
✓ Fazer
- ✓Usar uma value function ou detector como filtro de viabilidade.
- ✓Grounding em percepção: só ofertar skills cujos objetos existem na cena.
- ✓Restringir o vocabulário de skills ao que o executor domina.
✗ Evitar
- ✗Confiar no LLM puro para julgar viabilidade física.
- ✗Planos abertos sem ancorar nos objetos/estado reais.
- ✗Skills no plano que o executor nunca foi treinado a fazer.
Affordance
Viabilidade da ação.
Grounding
Linguagem → skill real.
Value function
Filtro de viabilidade.
Viabilidade
O "can" do SayCan.
🔁 Memória e feedback: replanejar com falha
Execução cega quebra no primeiro imprevisto. Sistemas robustos fecham o loop: detectam falha, atualizam a memória e replanejam. Técnicas como inner monologue realimentam observações textuais ("o copo escorregou") ao planejador, que ajusta o plano. Robustez vem de recuperação, não de execução perfeita.
Detectar
Sucesso/falha por percepção (objeto na mão? superfície limpa?) ou success detector aprendido.
Realimentar (inner monologue)
Converter o resultado em feedback que o planejador consome no próximo passo.
Replanejar
Reescrever a fila de skills com base no novo estado, em vez de seguir o plano original morto.
⚡ Dica prática
Não replaneje a cada quadro (caro e instável). Replaneje em eventos: fim de skill, falha detectada ou mudança grande de cena. O resto do tempo, deixe a política reativa absorver pequenas perturbações sozinha.
Closed-loop
Loop fechado com feedback.
Inner monologue
Feedback textual ao planner.
Replanning
Reescrever o plano.
Memória
Estado acumulado da tarefa.
⏳ Horizonte longo: composição de skills
O gargalo atual da robótica generalista é o horizonte longo: tarefas de minutos que encadeiam dezenas de skills. Mesmo com 95% de sucesso por skill, 20 skills em série dão ~36% de sucesso total — o erro composto que vimos na Trilha 1 reaparece em escala de tarefa. A híbrida ataca isso com replanejamento e recuperação, mas a robustez de ponta a ponta ainda é fronteira aberta.
📊 A matemática do erro composto em tarefas
- 0.9520 ≈ 36% — sucesso de tarefa com 20 skills a 95% cada, sem recuperação.
- 0.9920 ≈ 82% — por que cada ponto de success rate por skill importa enormemente.
- Recuperação muda a conta: replanejar transforma falha em retry, não em fim da tarefa.
💡 Por que a híbrida é a aposta certa aqui
Um VLA monolítico tende a acumular drift em horizonte longo. A hierarquia reinjeta estrutura: o planejador mantém o objetivo global enquanto o executor cuida do local, e o closed-loop corrige desvios antes que se componham.
Long-horizon
Tarefas de minutos.
Skill composition
Encadear habilidades.
Erro composto
Falhas se multiplicam.
Drift
Desvio acumulado.
✅ Resumo do módulo
Próximo módulo
3.4 — Aplicações: Manufatura, Logística, Saúde, Agro. Onde essas arquiteturas viram valor de mercado.