Transfer sim-to-real: trening robota w symulacji i luka symulacja-rzeczywistość

Robot uczy się biegać w kilka godzin — ale w symulatorze, gdzie upadek nic nie kosztuje, a jedna noc wystarcza na miliony prób. Kłopot zaczyna się w chwili, gdy tę samą politykę sterowania wgrywamy na fizyczną maszynę. To sedno problemu, który w robotyce potrafi zaważyć na całym projekcie: transfer sim-to-real.

Transfer sim-to-real to trening polityki sterowania robota w symulatorze fizyki — gdzie próby i błędy są tanie — a potem wgranie gotowej polityki na fizyczny sprzęt przy minimalnym douczaniu albo zupełnie bez niego. Główną przeszkodą jest luka symulacja-rzeczywistość (ang. reality gap): rozbieżność między tym, co model osiąga w symulacji, a tym, jak zachowuje się na prawdziwym robocie. Najskuteczniej zamyka się ją techniką domain randomization — celowym losowaniem setek parametrów symulacji na tyle szeroko, żeby rzeczywisty świat wyglądał dla modelu jak kolejny, niczym niewyróżniający się wariant symulacji.

Brzmi jak sztuczka i po części nią jest. Zanim jednak przejdziemy do mechaniki, uporządkujmy pojęcia — bo wokół sim-to-real narosło sporo szumu, a dopracowane nagrania z pokazów potrafią mylić bardziej niż niejeden błąd w kodzie symulatora. Ten tekst należy do klastra Podstawy fizycznej AI i traktuje temat jak briefing operacyjny, nie folder reklamowy — a jeśli potrzebujesz szerszego wprowadzenia do samego pojęcia fizycznej AI, zacznij od pillarowego materiału czym jest fizyczna AI.

Skąd bierze się luka symulacja-rzeczywistość?

Termin reality gap ukuli Jakobi, Husbands i Harvey w pracy „Noise and the Reality Gap: The Use of Simulation in Evolutionary Robotics“ (1995) — na długo przed obecną falą uczenia ze wzmocnieniem. Obserwacja jest prosta i boleśnie trwała: każda symulacja jest uproszczeniem, a robot działa w świecie, który się do tych uproszczeń nie stosuje.

Najwięcej problemów sprawia kontakt i tarcie. Modelowanie tego, co się dzieje, gdy stopa robota dotyka podłoża, gdy palce zaciskają się na przedmiocie albo gdy koło traci przyczepność, to jeden z najtrudniejszych fragmentów fizyki obliczeniowej. Do tego dochodzą rozbieżności w masie, momentach bezwładności i położeniu środka ciężkości, dynamika i opóźnienia napędów, szum czujników, luzy w przekładniach, odkształcalne materiały czy plączące się kable. Żadnego z tych efektów symulator nie odwzoruje idealnie.

Gorzej: uczenie ze wzmocnieniem wręcz te niedokładności tropi. Polityka optymalizowana wyłącznie pod wynik w symulacji chętnie nauczy się wykorzystywać każdy niefizyczny skrót, jaki podsuwa silnik — „odbije się“ od błędu numerycznego albo wygeneruje moment, którego prawdziwy serwomechanizm nigdy nie da. W symulacji wygląda to jak mistrzostwo. Na sprzęcie — jak upadek.

Na czym polega domain randomization w treningu robota w symulacji?

Punktem zwrotnym była praca Tobina i współpracowników z OpenAI oraz UC Berkeley „Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World“ (IROS 2017). Zespół pokazał, że sieć wytrenowaną wyłącznie na niefotorealistycznych, losowo teksturowanych obrazach z symulacji da się przenieść do zadania lokalizacji obiektów w prawdziwym świecie z dokładnością rzędu 1,5 cm — bez ani jednego prawdziwego zdjęcia w treningu.

Idea wywraca intuicję do góry nogami. Zamiast dążyć do maksymalnego realizmu symulacji, losujemy jej parametry — tekstury, oświetlenie, kolory, pozycję kamery, a osobno fizykę: masę, tarcie, tłumienie, opóźnienia, szum — na tyle szeroko, że prawdziwy świat staje się dla modelu statystycznie „jeszcze jednym wariantem symulacji“. Model nie uczy się jednej rzeczywistości; uczy się radzić sobie z całym rozkładem możliwych rzeczywistości.

Ma to swoją cenę. Za mało losowości — transfer się nie uda, bo rzeczywistość znajdzie się poza rozkładem danych treningowych. Za dużo — model nie nauczy się niczego, bo zadanie stanie się zbyt chaotyczne. OpenAI zaproponowało w 2019 r. Automatic Domain Randomization (ADR): zakresy losowania rozszerzają się automatycznie w trakcie treningu, zamiast ręcznego strojenia.

Ile czasu potrafi dzielić symulację od sprzętu, pokazał projekt Dactyl. Rozwiązywanie kostki Rubika jedną robotyczną dłonią udało się w symulacji już około połowy 2017 r., ale na fizycznego robota przeniesiono je dopiero w 2019 r. (OpenAI, „Solving Rubik’s Cube with a Robot Hand“, październik 2019). Kilkuletni odstęp między „działa w symulacji“ a „działa na sprzęcie“ to nie wyjątek — to reguła.

Jak wygląda dziś praktyka według przeglądów z lat 2025–2026 (m.in. arXiv:2510.20808 „The Reality Gap in Robotics“)? To raczej rysujący się konsensus niż twarde dane liczbowe, ale wzorzec jest powtarzalny:

Grupa parametrów	Przykłady	Jak się je losuje
Wizualne	tekstury, oświetlenie, kolory, pozycja kamery	agresywnie, w szerokim zakresie
Fizyczne	masa, tarcie, tłumienie, opóźnienia, szum czujników	ostrożnie, wokół wartości zmierzonych na sprzęcie

Klucz to identyfikacja systemu (system identification): zanim zaczniemy losować fizykę, mierzymy rzeczywiste parametry robota i losujemy wokół nich w wąskim zakresie. Na koniec dokładamy niewielki zbiór prawdziwych demonstracji do douczenia. Wygląd sceny można podkręcać do woli — fizykę trzymamy krótko.

Co naprawdę przenosi się z symulacji na sprzęt?

Najlepiej udokumentowany świeży przykład pochodzi z Robotic Systems Lab ETH w Zurychu. W pracy „ANYmal Parkour: Learning Agile Navigation for Quadrupedal Robots“ (Science Robotics, 2024) polityki lokomocji i percepcji wytrenowano w całości w symulacji, a następnie przeniesiono na fizycznego czworonoga ANYmal — co pozwoliło pokonywać przeszkody z prędkością dochodzącą do około 2 m/s. To konkretny, recenzowany wynik, a nie materiał promocyjny.

ETH ma na tym polu dłuższą historię — sim-to-real dla robotów kroczących ta grupa pokazywała już w 2019 r. (prace Hwangbo, Lee i in.) — choć dokładnych liczb z tamtych publikacji nie potwierdzam tu z pierwszej ręki i traktuję je jako tło.

I tu ważne zastrzeżenie w duchu briefingu: w obiegu krąży mnóstwo efektownych wskaźników skuteczności — dla chwytania obiektów, lokomocji na trudnym terenie i tak dalej. Część z nich pochodzi jednak z pojedynczych, wtórnych zestawień i nie daje się potwierdzić w pracy źródłowej. Dopóki tak jest, traktujemy je jako niepotwierdzone i po prostu nie cytujemy jako twardych danych. To nie ostrożność dla ostrożności — to jedyny sposób, żeby odróżnić rzeczywisty postęp od zręcznie sprzedanego pokazu.

Dlaczego dopracowane demo robota potrafi wprowadzać w błąd?

Bo między „robot to zrobił“ a „robot zrobił to sam, za pierwszym razem, bez człowieka na drążku“ leży przepaść — i to właśnie ona jest przemilczana w większości efektownych nagrań.

Najgłośniejszy przykład to Tesla Optimus. Bloomberg opisał (październik 2024), że podczas pokazu Cybercab/Optimus w Burbank część robotów była zdalnie sterowana przez ludzi (teleoperacja joystickiem — o tym, jak ta sama technika służy legalnie do zbierania danych treningowych, piszemy w materiale o teleoperacji i zbieraniu danych robotów), choć oprawa wydarzenia sugerowała większą autonomię; przedstawiciel Tesli Milan Kovac przyznał później, że roboty były „do pewnego stopnia wspomagane przez człowieka“. W grudniu 2025 r. nagranie z Miami pokazało Optimusa, który przewraca się, wykonując ruch dłonią przypominający zdejmowanie gogli VR do teleoperacji — co ponownie rozpaliło dyskusję, ile w tych pokazach jest autonomii, a ile zdalnego sterowania (Forbes, Electrek, przełom 2025/2026). Musk twierdził, że niektóre sekwencje (np. układ sztuk walki) były sterowane przez AI, a „nikt nimi nie kierował“ — to jednak deklaracja firmy, nie fakt zweryfikowany niezależnie. Według wtórnych doniesień prasy branżowej styczniowa telekonferencja wynikowa Tesli w 2026 r. miała potwierdzić, że żadna jednostka Optimusa nie wykonywała wtedy „użytecznej“ pracy w fabryce — to informacja z jednego źródła, w dodatku szybko tracąca aktualność, więc traktujmy ją jako niepewną.

Druga strona medalu: nie każde efektowne wideo to oszustwo. Wielokrotnie sprawdzano (m.in. Snopes), że głośne w sieci nagrania Boston Dynamics — salta Atlasa, taniec — pokazują prawdziwe, fizyczne roboty, a nie animację. Ale nawet uczciwe demo bywa mylące co do dojrzałości technologii: gotowa, minutowa etiuda promocyjna to efekt ogromnej selekcji i montażu z wielu podejść oraz miesięcy pracy zespołów inżynierskich. (Krążąca liczba „5–6 zespołów pracujących miesiącami na jedną minutę materiału“ pochodzi z pojedynczego, wtórnego źródła — traktuję ją jako orientacyjną, nie potwierdzoną.)

Wniosek operacyjny jest jeden: dopracowane wideo może łączyć wyselekcjonowane ujęcia, zaaranżowaną scenę, wyreżyserowaną sekwencję i nieujawnioną teleoperację. Uczciwym testem dojrzałości nie jest pokaz na scenie, lecz to, co polityka wytrenowana w symulacji robi sama, bez nadzoru, przy pierwszym zetknięciu z rzeczywistym środowiskiem.

Czym są cyfrowe bliźniaki i gdzie w tym wszystkim jest symulacja?

Cyfrowy bliźniak (digital twin) to wierny, zsynchronizowany model wirtualny fizycznego obiektu, robota albo całej linii produkcyjnej. W robotyce jest to środowisko, w którym trenuje się i testuje polityki, zanim trafią na sprzęt — i w którym można równolegle uruchomić tysiące kopii robota. Temu zagadnieniu poświęciliśmy osobny, szerszy materiał o symulacji robotów i cyfrowych bliźniakach.

Przegląd narzędzi (stan na 2026 r.; numery wersji warto sprawdzać na bieżąco):

• NVIDIA Isaac Sim / Isaac Lab — symulator z akceleracją GPU, zbudowany na Omniverse i OpenUSD. Isaac Sim 5.0 i Isaac Lab 2.2 stały się ogólnie dostępne około SIGGRAPH 2025 (sierpień 2025). NVIDIA deklaruje pracę z prędkością rzędu 1000× czasu rzeczywistego i tysiącami równoległych instancji robota — to liczba producenta, nie niezależny pomiar.
• MuJoCo — silnik fizyki stworzony przez Emo Todorova, przejęty przez Google DeepMind w 2021 r. i udostępniony na licencji Apache 2.0 rok później, w 2022 r. Ceniony za szybką i dokładną fizykę kontaktu; nie ma wbudowanego renderingu fotorealistycznego.
• Newton — otwarty silnik fizyki z akceleracją GPU, współtworzony przez Google DeepMind, Disney Research i NVIDIA, oparty na NVIDIA Warp i OpenUSD, pod skrzydłami Linux Foundation; projektowany tak, by współpracować z MuJoCo Playground i Isaac Lab (wg NVIDIA, 2025). Projekt młody i szybko się zmienia.

Osobny wątek to dane syntetyczne i modele świata. NVIDIA Cosmos (zapowiedziane w marcu 2025) to rodzina „modeli świata“ (world foundation models) generujących sterowalne wideo treningowe z map segmentacji, danych o głębi, lidaru, pozy czy trajektorii. Producent podaje skalę treningu rzędu 20 milionów godzin prawdziwego wideo — to liczba deklarowana, nie zweryfikowana niezależnie. W czerwcu 2026 r. (GTC Taipei, 1 czerwca) NVIDIA zapowiedziała Cosmos 3 — nową architekturę typu mixture-of-transformers, opisywaną jako model omnimodalny; szczegóły są świeże i na razie niezweryfikowane poza komunikatem producenta. Z kolei „GR00T Blueprint“ ma kompresować szacunkowo 6500 godzin zbierania danych z teleoperacji przez ludzi do około 11 godzin obliczeń (również deklaracja producenta, z jednego źródła).

Symulacja zasila też modele fundamentalne dla robotów. Rodzinę NVIDIA Isaac GR00T otwiera model GR00T N1 pokazany na GTC w marcu 2025 r.; kolejne iteracje (N1.5 i nowsze) miały przewyższać poprzednika w testach w symulacji oraz na rzeczywistym robocie Fourier GR-1. Numery wersji powyżej N1.5 traktuję jako niepewne przy granicy wiedzy ze stycznia 2026 r. — warto sprawdzić bieżącą wersję. Szerzej modele typu wizja-język-działanie (VLA) — jak RT-2 (Google DeepMind, 2023), otwarty OpenVLA (2024) czy π0 startupu Physical Intelligence (2024) — pokazują kierunek: sterowanie robotem uczone na połączeniu danych z internetu, demonstracji i właśnie symulacji.

Na koniec pieniądze — i tu ostrożnie, bo szacunki rynkowe rozjeżdżają się zależnie od definicji. Nie należy ich uśredniać; każdą liczbę przypisuję do źródła:

• Wąsko zdefiniowany rynek „Physical AI Simulation and Digital Twin for Robotics“ wyceniono na 3,8 mld USD w 2025 r. z prognozą ~34,6 mld USD do 2034 r. przy ~28,5% CAGR (Marketintelo — jeden dostawca badań).
• Szeroki rynek cyfrowych bliźniaków (znacznie większy zakres): ~21,14 mld USD w 2025 r. i ~149,81 mld USD do 2030 r. wg MarketsandMarkets; ~35,8 mld USD w 2025 r. i ~328,5 mld USD do 2033 r. wg Fortune Business Insights.
• Po stronie venture capital wtórne doniesienia mówią o ponad 2,2 mld USD zainwestowanych w 2025 r. w startupy budujące modele fundamentalne dla robotów — liczba warta odnotowania jako pojedyncze, przybliżone źródło.

Różnica między ~21 a ~36 mld USD w tym samym 2025 r. to nie błąd — to różne definicje rynku. Dobra ilustracja, dlaczego w tej branży warto pytać „co dokładnie policzono“.

Briefing operacyjny — co z tego wynika dla wdrożeń?

• Sim-to-real działa, ale nie jest magią. Dla lokomocji i manipulacji istnieją recenzowane wyniki (jak ANYmal Parkour, 2024). Luka symulacja-rzeczywistość nigdy nie znika do zera — da się ją zmniejszyć, nie zlikwidować.
• Fizykę losuj ostrożnie, warstwę wizualną agresywnie. Zmierz rzeczywiste parametry (identyfikacja systemu), losuj wokół nich, dołóż garść prawdziwych demonstracji do douczenia.
• Zakładaj kilkuletni odstęp między „działa w symulacji“ a „działa na sprzęcie“ — Dactyl pokonał go między 2017 a 2019 r.
• Demo ze sceny to nie dowód. Pytaj o teleoperację, liczbę podejść i o to, czy robot działał sam. Uczciwy test to pierwsze zetknięcie z rzeczywistym środowiskiem bez nadzoru.
• Weryfikuj liczby producentów i wersje. „1000× czasu rzeczywistego“, „6500 → 11 godzin“, numery wersji GR00T czy Cosmos to często deklaracje jednego źródła — datuj je i sprawdzaj na bieżąco.

Definicje kluczowych pojęć zebraliśmy w słowniku, a pozostałe elementy układanki — od czujników po bezpieczeństwo wdrożeń — rozbieramy w klastrze Podstawy fizycznej AI.