Sim-to-Real
Jak działa
Typowy potok sim-to-real: (1) budowa symulatora fizyki i renderowania odwzorowującego robota i zadanie; (2) trening polityki w symulacji, zwykle uczeniem przez wzmacnianie na wielu równoległych instancjach; (3) domknięcie luki rzeczywistości jedną lub kilkoma metodami: randomizacją domeny (losowanie tekstur, mas, tarcia, opóźnień), adaptacją domeny (dostrojenie reprezentacji do danych rzeczywistych), identyfikacją systemu (kalibracja parametrów symulatora do pomiarów z realnego robota); (4) wdrożenie i ewaluacja na fizycznym robocie; (5) opcjonalne dostrojenie na małej ilości danych rzeczywistych. Wariant automatycznej randomizacji domeny (ADR) stopniowo zwiększa trudność, gdy polityka radzi sobie coraz lepiej.
Rozwiązany problem
Trenowanie robotów bezpośrednio na fizycznym sprzęcie jest wolne, kosztowne i ryzykowne (zużycie, awarie, bezpieczeństwo). Symulacja rozwiązuje to, dając nieograniczone dane, ale polityki wyuczone w symulacji zwykle zawodzą na prawdziwym robocie z powodu luki rzeczywistości. Sim-to-Real zamyka tę lukę, umożliwiając przeniesienie umiejętności z symulacji na sprzęt.
Komponenty
Losowe zmienianie parametrów symulacji (tekstury, oświetlenie, masy, tarcie, opóźnienia), by rzeczywistość jawiła się jako kolejny wariant treningowy.
Dostrajanie reprezentacji lub polityki tak, by rozkład cech z symulacji zbliżył się do rozkładu z danych rzeczywistych.
Kalibracja parametrów symulatora (dynamika, tarcie, opóźnienia) do pomiarów z realnego robota, by symulacja lepiej odwzorowała sprzęt.
Silnik fizyki i renderowania (często masowo równoległy na GPU) generujący dane treningowe odwzorowujące robota i zadanie.
Implementacja
Nieodwzorowana fizyka, opóźnienia i szumy czujników sprawiają, że polityka świetna w symulacji zawodzi na sprzęcie.
Zbyt szeroka randomizacja daje polityki nadmiernie zachowawcze i nieoptymalne w rzeczywistości.
Ewolucja
Sadeghi i Levine pokazują lot bez kolizji wyuczony wyłącznie na losowo renderowanych obrazach z symulacji, bez ani jednego prawdziwego zdjęcia treningowego.
Tobin i in. formalizują randomizację domeny, umożliwiając transfer sieci trenowanych wyłącznie na danych syntetycznych na rzeczywisty sprzęt.
OpenAI trenuje w symulacji z randomizacją domeny politykę manipulacji obiektem, przenosząc ją na fizyczną dłoń robotyczną Shadow Hand.
OpenAI rozwiązuje kostkę Rubika jedną robotyczną dłonią, wykorzystując automatyczną randomizację domeny (ADR) rosnącej trudności.
Przegląd Zhao, Peña Queralta i Westerlunda porządkuje główne podejścia: randomizację i adaptację domeny, uczenie przez naśladowanie, meta-uczenie i destylację wiedzy.
NVIDIA Isaac Gym i prace nad lokomocją (np. czworonóg ANYmal) pokazują trening tysięcy równoległych środowisk na GPU i transfer polityk chodu na prawdziwe roboty w minuty.
Hiperparametry (konfigurowalne osie)
Rozpiętość i rozkład losowanych parametrów (tekstury, oświetlenie, masy, tarcie, opóźnienia). Zbyt wąskie zakresy nie domykają luki rzeczywistości, zbyt szerokie dają polityki nadmiernie zachowawcze.
Ile instancji symulacji działa jednocześnie na GPU. Bezpośrednio wpływa na przepustowość danych i tempo treningu.
Kompromis między dokładnością fizyki/renderowania a liczbą kroków na sekundę. Wyższa wierność zwęża lukę rzeczywistości kosztem szybkości.
Tempo, w jakim rozszerzane są zakresy randomizacji w miarę poprawy polityki. Kluczowe w podejściu OpenAI (kostka Rubika).
Ilość danych z fizycznego robota użytych do opcjonalnego dostrojenia polityki po transferze. Często minimalna lub zerowa (zero-shot).
Wąskie gardło obliczeniowe
Wąskim gardłem jest tempo generowania danych przez symulator — kroki fizyki i (opcjonalnie) renderowanie. Wierność fizyki, liczba równoległych środowisk oraz rozdzielczość renderowania wprost ograniczają, jak szybko powstają dane treningowe do uczenia przez wzmacnianie.
Równoległość
Największa przewaga sim-to-real: symulatory na GPU (np. NVIDIA Isaac Gym / Isaac Lab) uruchamiają tysiące równoległych środowisk jednocześnie, co daje ogromną przepustowość danych i skraca trening polityk z dni do minut. Faza wdrożenia (inference) na fizycznym robocie jest natomiast sekwencyjna — polityka działa w czasie rzeczywistym w pętli sterowania.
Wymagania sprzętowe
Masowo równoległa symulacja fizyki oraz trening polityk uczeniem przez wzmacnianie (np. Isaac Gym / Isaac Lab) wykonują się na GPU; tysiące środowisk naraz to domena kart graficznych.