Sim2Real

O que “Sim2Real” significa

Sim2Real (“da simulação para a realidade (simulation-to-reality)”) refere-se a técnicas para treinar e validar sistemas de percepção e controle de robôs em simulação, e então transferi-los para robôs no mundo real com perda mínima de desempenho. O desafio central é a lacuna de realidade (reality gap): simuladores são imperfeitos, então uma política (policy) ou modelo (model) que funciona na simulação pode falhar no mundo físico.

O Sim2Real importa porque a coleta de dados em robôs reais (real-robot data collection) frequentemente é:

  • Cara (tempo de hardware, supervisão humana)
  • Lenta (redefinir cenas, executar tentativas)
  • Arriscada (danos a robôs e ambientes)
  • Difícil de escalar (o paralelismo é limitado)

Em contraste, a simulação oferece:

  • Execuções (rollouts) rápidas e paralelas para Aprendizado por Reforço (Reinforcement Learning)
  • Rótulos automáticos para tarefas de percepção (segmentação (segmentation), profundidade (depth), pose (pose))
  • Experimentos repetíveis e ablações controladas (ablations)
  • Exploração segura de cenários raros ou perigosos

Duas das famílias de abordagens mais usadas são:

  1. Randomização de domínio (domain randomization): tornar a simulação diversa o suficiente para que a realidade pareça “apenas mais uma amostra randomizada”.
  2. Métodos de transferência (transfer methods): adaptar explicitamente modelos/políticas da simulação para o domínio real (ajuste fino (fine-tuning), identificação de sistema (system identification), adaptação de domínio (domain adaptation), aprendizado residual (residual learning), etc.).

Este artigo foca em randomização de domínio e transferência da simulação para robôs reais, com fundamentos teóricos e orientação prática.

A lacuna de realidade: por que Sim2Real é difícil

Uma política de robô interage com o mundo por meio de dinâmica, sensoriamento e computação. Simuladores aproximam os três, mas sistemas reais diferem de muitas maneiras:

Incompatibilidade de dinâmica

  • Massa/inércia incorretas, atrito, amortecimento
  • Erros de modelagem de contato (stick–slip, complacência, impactos)
  • Dinâmica dos atuadores (limites de torque, constantes do motor)
  • Folga (backlash) em juntas, stiction, alongamento de cabos, flexão estrutural
  • Efeitos aerodinâmicos para drones

Incompatibilidade de percepção

  • Iluminação, exposição, desfoque de movimento
  • Distorção de lente, rolling shutter
  • Padrões de ruído do sensor e dados ausentes (falhas em profundidade, perdas em LiDAR)
  • Diferenças de textura e material

Incompatibilidade de sistema/pilha

  • Latência (latency) e variação temporal (jitter) em loops de controle
  • Erros de estimação de estado (state estimation) (viés, deriva)
  • Diferenças entre pipelines de observação simulados e reais
  • Paradas de segurança e saturações não modeladas

Muitas falhas ocorrem em interfaces: pipelines de percepção → planejamento → controle se comportam de forma diferente quando qualquer incerteza a montante muda (veja Percepção → Planejamento → Controle (Perception → Planning → Control)).

Uma visão formal útil: robustez sobre uma família de simuladores

Uma formalização comum modela a tarefa como um Processo de Decisão de Markov (Markov Decision Process, MDP) com parâmetros (\theta) descrevendo o ambiente e o robô:

  • Dinâmica: (s_{t+1} \sim p_\theta(s_{t+1}\mid s_t, a_t))
  • Observações: (o_t \sim g_\theta(o_t\mid s_t))
  • Recompensa: (r_t = r_\theta(s_t, a_t))

No treinamento padrão em simulação, você escolhe um (\theta=\theta_{\text{sim}}). Na realidade, o parâmetro verdadeiro é (\theta_{\text{real}}\neq \theta_{\text{sim}}).

A randomização de domínio em vez disso treina em uma distribuição (p(\theta)) para que a política aprendida (\pi(a\mid o)) funcione em muitos mundos plausíveis:

[ \max_\pi \ \mathbb{E}_{\theta \sim p(\theta)} \left[ J(\pi; \theta) \right] ]

Isso é intimamente relacionado a controle robusto (robust control) e robustez distribucional (distributional robustness): você está tentando produzir políticas que sejam insensíveis à incerteza de parâmetros (veja também Controle (Control)).

Randomização de Domínio (DR)

Ideia central

Em vez de construir um simulador perfeitamente preciso, você cria deliberadamente muitos simuladores imperfeitos. Se a distribuição de simulação randomizada cobrir a realidade, então implantar no robô real passa a ser “dentro da distribuição”.

Na prática, a DR é aplicada a:

  • Randomização de domínio visual (texturas, iluminação, propriedades da câmera)
  • Randomização de dinâmica (massas, atrito, força de atuadores)
  • Randomização de ambiente (formas de objetos, posições, desordem/“clutter”)
  • Randomização de sensor/latência (ruído, atraso, perda)

Randomização de domínio visual

Parâmetros comuns para randomizar:

  • Direção/intensidade/temperatura de cor da luz
  • Texturas de superfície, cores, rugosidade/metálico
  • Imagens de fundo (domos HDRI, fotos aleatórias)
  • Intrínsecos/extrínsecos da câmera (FOV, pequenos desvios de pose)
  • Modelos de ruído (gaussiano, Poisson, sal-e-pimenta)
  • Aproximações de desfoque de movimento e rolling shutter
  • Oclusores e objetos distratores

Isso é especialmente eficaz para modelos de estimação de pose (pose estimation), detecção de preensão (grasp detection) e segmentação que precisam sobreviver a mudanças de aparência no mundo real.

Exemplo prático: treinar um estimador de pose de preensão em renders sintéticos onde a cada episódio se randomiza:

  • textura da mesa, textura do objeto, iluminação, exposição da câmera
  • malha do objeto amostrada de uma biblioteca com escalas aleatórias
  • objetos de desordem adicionados com materiais aleatórios

O modelo aprende a focar em geometria e pistas robustas, em vez de texturas específicas.

Randomização de dinâmica

Parâmetros típicos:

  • Massas dos elos, inércias, deslocamentos do CoM
  • Atrito de junta (Coulomb/viscoso), amortecimento
  • Coeficientes de atrito de contato, restituição
  • Multiplicadores de força do motor, limites de torque
  • Latência de controle e retenção de ação (“zero-order hold”)
  • Perturbações externas (empurrões, vento)
  • Complacência do solo (para locomoção)

Exemplo prático: políticas de locomoção de quadrúpedes treinadas com randomização de:

  • atrito de 0,4–1,2
  • força do motor ±20%
  • latência 0–30 ms
  • pequenas perturbações no heightfield do terreno

Isso ajuda as políticas a lidar com pisos desconhecidos, queda de tensão da bateria e jitter de temporização.

Quanta randomização é suficiente?

Um modo de falha comum é a sub-randomização (under-randomization): a realidade fica fora do intervalo randomizado. Outro é a super-randomização (over-randomization): o treinamento fica difícil demais e as políticas tornam-se excessivamente conservadoras.

Uma estratégia prática é:

  1. Começar com intervalos amplos, porém plausíveis.
  2. Avaliar cedo no robô real com restrições de segurança (veja Segurança em Robótica (Robotics Safety)).
  3. Encolher/deslocar intervalos com base na incompatibilidade observada (por exemplo, estimativas de atrito).
  4. Adicionar randomizações para casos de falha (por exemplo, picos de latência).

Randomização de domínio por currículo

Em vez de randomizar tudo desde o início, você pode usar um currículo:

  • Começar perto de um simulador nominal (aprendizado mais fácil).
  • Ampliar gradualmente os intervalos de randomização conforme o desempenho melhora.

Isso frequentemente estabiliza o treinamento de RL e reduz o “colapso de política (policy collapse)” sob randomização inicial excessivamente severa.

Código de exemplo: randomizando dinâmica em um loop no estilo Gym (Gym-like)

import numpy as np

class DynamicsRandomizer:
    def __init__(self):
        # Example ranges (tune to your robot/system)
        self.friction_range = (0.5, 1.1)
        self.mass_scale_range = (0.8, 1.2)
        self.motor_strength_range = (0.85, 1.15)
        self.latency_steps_range = (0, 3)  # discrete control steps of delay

    def sample(self):
        return {
            "mu": np.random.uniform(*self.friction_range),
            "mass_scale": np.random.uniform(*self.mass_scale_range),
            "motor_strength": np.random.uniform(*self.motor_strength_range),
            "latency_steps": np.random.randint(self.latency_steps_range[0],
                                              self.latency_steps_range[1] + 1),
        }

def reset_env(env, randomizer):
    params = randomizer.sample()
    env.set_contact_friction(params["mu"])
    env.scale_link_masses(params["mass_scale"])
    env.set_motor_strength(params["motor_strength"])
    env.set_action_latency(params["latency_steps"])
    obs = env.reset()
    return obs, params

Em simuladores reais (MuJoCo, Isaac Sim, PyBullet), a API exata difere, mas o padrão é o mesmo: amostrar parâmetros no reset (ou ocasionalmente no meio do episódio) e configurar o simulador.

Abordagens de transferência além da randomização de domínio

A randomização de domínio busca tornar as políticas robustas o suficiente para transferir diretamente (“zero-shot”). Quando isso não é suficiente, você tipicamente adiciona adaptação explícita.

Identificação de sistema (SysID) e calibração

A identificação de sistema (system identification, SysID) tenta estimar parâmetros do simulador (\theta) para que trajetórias simuladas correspondam a trajetórias reais.

  • Coletar trajetórias reais (estados, ações, contatos se disponíveis).
  • Otimizar parâmetros do simulador para minimizar a incompatibilidade.
  • Re-treinar ou reavaliar políticas no simulador calibrado.

A SysID funciona bem quando:

  • A classe do modelo é adequada (o simulador consegue representar o sistema real).
  • Você tem boas medições (torques de junta, eventos de contato).

Ela tem dificuldade com:

  • Complacência não modelada, contatos complexos, objetos deformáveis (deformable objects).
  • Observabilidade parcial (partial observability) ou estimação de estado ruim.

Na prática, muitas equipes usam um híbrido (hybrid):

  • Calibrar o simulador de forma grosseira (massas, inércias, constantes do motor).
  • Usar randomização de domínio para as incertezas restantes.

Ajuste fino em dados reais (“Sim + Real”)

Você treina em simulação e então continua treinando com dados do robô real.

Para percepção:

  • Pré-treinar com rótulos sintéticos e fazer ajuste fino com um conjunto real menor e rotulado.

Para controle:

  • Usar aprendizado por reforço offline (offline RL) ou atualizações seguras na própria política (on-policy) com restrições (constraints).
  • Manter um controlador de contingência (fallback controller) robusto (por exemplo, um estabilizador baseado em modelo (model-based stabilizer)).

Isso é comum em manipulação (Manipulação (Manipulation)), onde a incompatibilidade de contato é severa.

Aprendizado residual (política do sim + correção aprendida)

Você decompõe o controle em:

  • Um controlador/política nominal da simulação, (u_{\text{sim}})
  • Um residual aprendido (u_{\text{res}}) treinado com dados reais

[ u = u_{\text{sim}}(o) + u_{\text{res}}(o) ]

Isso pode ser mais seguro do que ajuste fino ponta a ponta porque:

  • A linha de base continua funcional.
  • Residuais podem ser limitados ou regularizados.

Abordagens residuais são frequentemente combinadas com controladores clássicos (veja Controle).

Adaptação de domínio para percepção

Se você treina modelos de visão em imagens sintéticas, pode reduzir a lacuna da simulação para o real com:

  • Adaptação no nível de características (feature-level adaptation) (alinhamento adversarial)
  • Tradução imagem-para-imagem (image-to-image translation) (por exemplo, fazer imagens sintéticas parecerem reais)
  • Randomização de estilo (style randomization) (uma variante de DR)
  • Usar representações baseadas em geometria (profundidade, normais) que transferem melhor

Uma receita robusta comum:

  • Treinar no sintético com forte randomização visual
  • Fazer ajuste fino usando um pequeno conjunto de imagens reais
  • Avaliar sob mudanças reais de iluminação e configurações de câmera

Informação privilegiada e treinamento assimétrico

Em simulação, você pode ter acesso ao estado completo (posições, velocidades, forças de contato) mesmo quando o robô real só tem observações parciais.

Uma técnica poderosa é o ator-crítico assimétrico (asymmetric actor-critic):

  • O crítico (critic) usa estado privilegiado na simulação para melhorar o aprendizado.
  • O ator (actor) usa apenas observações disponíveis no real.

Na implantação, o ator transfere porque nunca dependeu de entradas privilegiadas.

Padrões práticos de aplicação

1) Sim2Real para preensão e manipulação

Objetivo: pick-and-place, bin picking, inserção.

Escolhas comuns de sim: MuJoCo, Isaac Sim, Bullet, modelos de contato personalizados.

O que funciona:

  • DR visual para texturas de objetos e iluminação
  • DR de dinâmica para atrito e massa do objeto
  • Treinamento com geometrias de objetos diversas (bibliotecas de formas)
  • Adicionar ruído de sensor e perturbações de calibração da câmera

O que é difícil:

  • Contato e atrito são notoriamente difíceis de simular com precisão.
  • Objetos deformáveis e garras de sucção adicionam complexidade.
  • Garras reais têm complacência e folga que não estão presentes no sim.

Estratégia de transferência frequentemente usada:

2) Sim2Real para locomoção de quadrúpedes

Objetivo: caminhar/correr de forma robusta em diferentes superfícies.

O que funciona:

  • DR de dinâmica (atrito, força do motor, latência)
  • Randomização de terreno (heightfields, inclinações)
  • Empurrões externos
  • Treinamento com estado privilegiado (treinamento assimétrico)

O que é difícil:

  • Contato pé–solo e complacência com precisão
  • Desgaste do hardware e efeitos de temperatura
  • Deriva na estimação de estado (viés do IMU)

Muitas implantações bem-sucedidas usam:

  • Uma política aprendida para ação de alto nível
  • Estabilização clássica / filtros de segurança por baixo (veja Segurança em Robótica)

3) Sim2Real para navegação móvel

Objetivo: desvio de obstáculos, planejamento local, exploração.

A simulação é ótima para:

Desafios de transferência:

  • Artefatos de sensor (multipercurso de LiDAR, brilho na câmera)
  • Mudança de domínio em desordem e comportamento humano
  • Patinagem de rodas, terreno irregular e imprecisões no mapa (veja Localização e Mapeamento Simultâneos (SLAM))

Abordagem frequentemente usada:

  • Treinar uma política local em sim com DR de sensor + ruído
  • Integrá-la a uma pilha de navegação clássica (planejamento global, mapeamento)
  • Validar de ponta a ponta com logs realistas de replay de sensores

4) Sim2Real para drones e robôs aéreos

Principais randomizações:

  • Rajadas de vento e modelos de turbulência
  • Atraso e perda de sensor
  • Mudanças na distribuição de massa com carga útil
  • Eficiência da hélice e queda de tensão da bateria

Segurança é primordial: use cercamento geográfico (geofencing), chaves de emergência (kill-switches) e implantações em etapas (staged rollouts).

Engenharia de um pipeline de Sim2Real

Etapa 1: Defina o que transfere (e o que não transfere)

Nem tudo deveria ser aprendido ponta a ponta. Muitos sistemas têm melhor desempenho ao combinar:

  • Percepção aprendida
  • Estimação de estado clássica
  • Planejamento + controladores (baseados em modelo)
  • Políticas locais aprendidas para comportamentos difíceis de modelar (contatos, desvio reativo)

Isso espelha a visão de pilha de robótica (robotics stack) em Percepção → Planejamento → Controle.

Etapa 2: Escolha fidelidade do simulador vs. velocidade

Alta fidelidade ajuda, mas velocidade e paralelismo frequentemente importam mais para aprender.

  • Rápido + randomizado pode superar lento + “preciso” se a lacuna restante for coberta estatisticamente.
  • Para tarefas ricas em contato (contact-rich), a fidelidade se torna mais importante.

Etapa 3: Implemente randomização como um componente de primeira classe

Trate a randomização como parte da definição do ambiente:

  • Amostragem de parâmetros
  • Logging e reprodutibilidade (controle de seed)
  • Ferramentas de depuração (renderização, inspeção de estado)

Uma prática útil é registrar os parâmetros amostrados para cada episódio, para que você possa correlacionar falhas com condições específicas.

Etapa 4: Adicione sensores realistas e restrições de computação

Inclua:

  • Limites de frequência do loop de controle
  • Atrasos nas observações
  • Quantização e saturações
  • Perda ou frames ausentes
  • Ruído do estimador de estado (ou executar o mesmo estimador no sim)

Ignorar latência é uma causa clássica de “funciona no sim, oscila no real”.

Etapa 5: Valide a transferência de forma incremental

Antes de autonomia total:

  • Comece com limites de ação conservadores
  • Use superfícies macias / estruturas de segurança
  • Teste com um supervisor e “deadman switch”
  • Execute tentativas de horizonte curto com resets frequentes

Isso está intimamente relacionado a práticas de implantação discutidas em Segurança em Robótica.

Modos de falha e como tratá-los

Incompatibilidade rica em contato

Sintomas:

  • Preensão escorrega no real, mas não no sim
  • Inserção emperra ou quica

Mitigações:

  • Randomizar atrito, restituição, complacência
  • Usar feedback tátil se disponível
  • Treinar políticas para serem complacentes e corretivas (re-preensão, tentativas de novo)
  • Usar ajuste fino no real ou aprendizado residual

Overfitting a artefatos do simulador

Sintomas:

  • A política explora dinâmicas irreais (por exemplo, truques de quique)
  • O modelo de visão depende de pistas sintéticas (bordas perfeitas, profundidade sem ruído)

Mitigações:

  • Aumentar a diversidade de DR
  • Adicionar artefatos de sensor (desfoque, distorção, profundidade ausente)
  • Usar adaptação de domínio ou ajuste fino no real

Diferenças ocultas em sistemas de coordenadas e calibração

Sintomas:

  • Offsets consistentes em pontos de preensão
  • Deriva de navegação no real, mas não no sim

Mitigações:

  • Randomizar levemente os extrínsecos da câmera
  • Validar o pipeline de calibração separadamente
  • Usar alvos de calibração e testes unitários (unit tests) para transformações (transforms)

Incompatibilidade de latência e temporização

Sintomas:

  • Oscilações, instabilidade, reações atrasadas

Mitigações:

  • Randomizar latência e retenção de ação
  • Igualar frequência real de controle e filtragem
  • Usar controladores com margens de robustez (veja Controle)

Como Sim2Real é avaliado

Métricas comuns de avaliação dependem da tarefa:

  • Taxa de sucesso (sucesso de preensão, objetivo de navegação alcançado)
  • Robustez sob perturbações (recuperação de empurrões, mudanças de iluminação)
  • Generalização para novos objetos/ambientes
  • Métricas de segurança (colisões, quedas, violações de limite de junta)
  • Queda de desempenho sim-para-real (degradação relativa)

Uma prática recomendada é avaliar em um conjunto de condições do mundo real:

  • múltiplos pisos/superfícies
  • diferentes horários do dia (iluminação)
  • cargas úteis variadas ou conjuntos de objetos
  • diferentes níveis de bateria / temperaturas

Boas práticas e “regras de bolso”

  • Prefira velocidade randomizada a fidelidade frágil: se você consegue treinar 100× mais experiência com DR, frequentemente você ganha.
  • Randomize os parâmetros que mais importam:
    • atrito, latência, força do motor para controle
    • iluminação, texturas, intrínsecos da câmera para visão
  • Adicione ruído e atrasos cedo; adaptá-los depois pode quebrar o comportamento aprendido.
  • Use informação privilegiada no sim para aprender mais rápido, mas garanta que a política implantada use apenas observações reais.
  • Mantenha comportamentos de contingência e restrições de segurança nas primeiras implantações reais.
  • Registre tudo (seeds aleatórias, parâmetros amostrados, telemetria do robô real) para postmortems.

Relação com outros tópicos de robótica

  • Sim2Real fica na interseção entre aprendizado e pilhas clássicas de robótica: modelos precisam sobreviver ao pipeline completo do sensoriamento à atuação (Percepção → Planejamento → Controle).
  • Muitos sistemas de controle Sim2Real combinam políticas aprendidas com estabilização clássica por realimentação e limites (Controle).
  • Sim2Real é especialmente desafiador em tarefas ricas em contato como preensão e inserção (Manipulação).
  • Demonstrações podem reduzir a lacuna sim-para-real quando a exploração por RL é insegura ou modelos de contato são imprecisos demais (Aprendizado por Imitação).
  • A implantação no mundo real exige medidas explícitas de segurança e testes em etapas (Segurança em Robótica).
  • A transferência em navegação frequentemente interage com erros de mapeamento e localização (Localização e Mapeamento Simultâneos (SLAM)) e suposições de planejamento (Planejamento de Movimento).

Resumo

Sim2Real é a prática de transferir aprendizado de robôs da simulação para hardware físico apesar da lacuna de realidade. A randomização de domínio trata isso treinando sobre uma distribuição de mundos simulados, de modo que a realidade se torne “apenas outra variante”. Quando a DR sozinha é insuficiente, equipes usam técnicas de transferência como identificação de sistema, ajuste fino em dados reais, aprendizado residual e adaptação de domínio — frequentemente em sistemas híbridos que combinam aprendizado com componentes clássicos de robótica.

Os resultados mais confiáveis de Sim2Real vêm de tratar aleatoriedade, imperfeições de sensoriamento, latência e segurança como restrições de projeto de primeira classe — não como reflexão tardia — e de validar incrementalmente com testes cuidadosos no mundo real.