xBerry LeRobot Tydzień 4: sim-to-real – 80% w symulacji, 50% w realu i co naprawiło 10 demonstracji

W symulacji wytrenowana polityka osiągnęła 80%. Na fizycznym ramieniu SO-101 ta sama polityka osiągnęła 50%. Po dotrenowaniu na 10 rzeczywistych demonstracjach wskoczyliśmy na 65% w realu, ale w symulacji spadliśmy do 75%. Poprawa w jednym świecie ma swój koszt w drugim.

TL;DR

Tydzień 4 to nasz pierwszy pełny eksperyment z transferem sim-to-real z użyciem IsaacSim i IsaacLab w ekosystemie LeRobot. Polityka wytrenowana czysto na danych symulacyjnych osiągnęła 80% w symulacji i 50% na fizycznym robocie (30-punktowy reality gap). Dotrenowanie na 10 demonstracjach rzeczywistych podniosło wynik w realu do 65% przy jednoczesnym spadku do 75% w symulacji. Dane sugerują, że optymalna strategia to co-training na obu źródłach, a nie wybór jednego z nich.

Dlaczego w ogóle przechodzimy do symulacji

Co to jest Sim-to-real transfer (sim2real)? Jest to strategia treningowa, w której polityka robotyczna jest trenowana wewnątrz symulatora fizycznego, a następnie wdrażana na fizycznym sprzęcie, co redukuje koszty i ryzyko treningu bezpośrednio na robocie.

Co to jest Digital twin? Jest to wirtualna replika fizycznego robota i jego otoczenia, zamodelowana tak, żeby jak najwierniej odwzorować kinematykę, dynamikę i geometrię sensorów na tyle wiernie, żeby polityka wytrenowana w kopii wirtualnej miała szansę działać na fizycznym oryginale.

W Tygodniu 3 nasza najlepsza fizyczna polityka osiągnęła 50% w zadaniu Pick, Lift and Place przy wejściu RGB-only. Zbieranie kolejnych demonstracji fizycznych to oczywisty następny krok, ale też powolny i kosztowny: każdy epizod wymaga ręcznego resetowania stanowiska, istnieje zużycie mechaniczne ramienia i nie można równolegle zbierać epizodów. Symulacja eliminuje wszystkie trzy ograniczenia.

Jeśli chcesz dowiedzieć się więcej o naszych działań w tygodniu 3. – sprawdź xBerry LeRobot Tydzień 3: RGB vs RGBD – 60 prób, jeden zaskakujący wynik
 

Do zbudowania cyfrowego bliźniaka użyliśmy IsaacSim: symulatora fizycznego NVIDIA do robotyki, działającego wewnątrz IsaacLab: frameworka zbudowanego na IsaacSim, który integruje się z pipeline’em treningowym LeRobot. Zadanie pozostało niezmienione: Pick, Lift and Place z piłką i miską zamiast wcześniejszego układu obiekt-pudełko.

Pełny przepływ Tygodnia 4: zebranie datasetu w symulacji, trening polityki ACT, ewaluacja w symulacji, transfer polityki 1:1 na fizycznego robota, ewaluacja na sprzęcie, dotrenowanie na małej próbce demonstracji rzeczywistych, ponowna ewaluacja obu środowisk.

Uruchomienie środowiska symulacyjnego

IsaacSim wymaga precyzyjnego zestawu wersji CUDA, sterowników NVIDIA i bibliotek Omniverse. Zamiast instalować je bezpośrednio na hoście (co tworzy kruche, trudne do odtworzenia konfiguracje), uruchomiliśmy całe środowisko w kontenerze Dockera:

xhost +
docker run --name teleop -it --privileged --gpus all \
  -e "ACCEPT_EULA=Y" -e "PRIVACY_CONSENT=Y" \
  -e DISPLAY --rm --network=host \
  -v /dev:/dev \
  -v /run/udev:/run/udev:ro \
  -v $HOME/.Xauthority:/root/.Xauthority \
  -v ~/docker/isaac-sim/cache/kit:/isaac-sim/kit/cache:rw \
  -v ~/docker/isaac-sim/cache/ov:/root/.cache/ov:rw \
  -v ~/.cache/huggingface/lerobot/calibration:/root/.cache/huggingface/lerobot/calibration \
  -v ~/Sim-to-Real-SO-101-Workshop:/workspace/Sim-to-Real-SO-101-Workshop \
  teleop-docker:latest

Kluczowe flagi: –gpus all daje kontenerowi pełny dostęp do GPU niezbędny do renderowania fizyki, –network=host współdzieli sieć hosta, żeby kontener mógł komunikować się z podłączonym przez USB robotem, -v /dev:/dev montuje fizyczne urządzenia hosta do kontenera, a wolumen huggingface/lerobot/calibration gwarantuje, że dane kalibracyjne robota przetrwają restart kontenera.

Przed zebraniem demonstracji skalibrowano oba ramiona i przeprowadzono testy ruchów: fizyczne ramię leader sterowało followerem wewnątrz symulacji, a poprawność odwzorowania pozycji przegubów weryfikowaliśmy przed nagraniem jakichkolwiek epizodów.

Dopasowanie sceny i randomizacja domeny

Żeby sim2real miało szansę zadziałać, symulacja musi wyglądać wystarczająco podobnie do rzeczywistości. Przyjęliśmy cel: różnica wizualna poniżej 10%, mierzona porównaniem klatek z kamer fizycznych i renderowanych w symulacji. Wymagało to dopasowania łańcucha przegubów i zakresów ruchu SO-101, geometrii i właściwości materiałowych piłki i miski oraz pozycji, kątów i pola widzenia wszystkich kamer.

Co to jest Randomizacja domeny? Jest to technika, która losuje parametry symulacji przy każdym resecie epizodu (pozycja obiektów, oświetlenie, kąt kamery), sztucznie rozszerzając rozkład danych treningowych tak, żeby rzeczywiste warunki mieściły się w jego obrębie zamiast poza nim.

Dopasowanie wizualne to jednak nie wszystko. Polityka trenowana na jednej, stałej scenie uczy się bardzo wąskiego rozkładu danych.

Oświetlenie losowaliśmy przy każdym resecie funkcją próbkującą losową ekspozycję, temperaturę barwową i teksturę HDRI ze zbioru map środowiskowych:

def randomize_sky_light(env, env_ids, exposure_range, temperature_range, textures_root, asset_cfg=None):
    exposure = math_utils.sample_uniform(*exposure_range, (1,), device="cpu").item()
    temperature = math_utils.sample_uniform(*temperature_range, (1,), device="cpu").item()
    textures = glob.glob(os.path.join(textures_root, "*.exr"))
    texture = textures[torch.randint(0, len(textures), (1,)).item()]
    prim.GetAttribute("inputs:exposure").Set(exposure)
    prim.GetAttribute("inputs:colorTemperature").Set(temperature)
    prim.GetAttribute("inputs:texture:file").Set(Sdf.AssetPath(texture))

Pozycje piłki i miski losowano analogicznie, z małym prawdopodobieństwem umieszczenia piłki już w misce (symulując częściowo wykonane zadanie).

Wyniki: 30-punktowy gap i jak 10 demonstracji zamknęło połowę z niego

Z dopasowaną sceną i randomizacją domeny wytrenowaliśmy politykę ACT na danych symulacyjnych i oceniliśmy ją w obu środowiskach.

Etap 1: polityka trenowana wyłącznie na danych symulacyjnych

Reality gap: różnica w skuteczności między symulacją a fizycznym sprzętem, wynikająca z tego, że symulacja nigdy nie odwzorowuje w 100% tarcia, zmienności oświetlenia i szumu sensorycznego rzeczywistego świata. Mimo starannego dopasowania sceny polityka napotkała na fizycznym robocie rozkład danych wystarczająco różny od treningowego, żeby spaść o 30 punktów procentowych.

Etap 2: dotrenowanie na 10 demonstracjach rzeczywistych

Co to jest Fine-tuning (dotrenowanie)? Jest to kontynuacja treningu już wytrenowanego modelu na małym nowym zbiorze danych, pozwalająca na adaptację do nowych warunków bez utraty wiedzy z oryginalnych danych.

Dodanie zaledwie 10 rzeczywistych epizodów podniosło skuteczność fizyczną o 15 punktów procentowych. Jednocześnie zredukowało skuteczność w symulacji o 5 punktów. Najbardziej prawdopodobne wytłumaczenie: rzeczywiste dane przyciągnęły wagi modelu w stronę innego rozkładu (inne oświetlenie, inna dynamika chwytu), poprawiając generalizację do świata fizycznego kosztem precyzji w idealnych warunkach symulacyjnych.

Dlaczego to ważne: Sim2real nie jest transferem jednostronnym. Model musi znaleźć kompromis między dwoma rozkładami danych. Dotrenowanie na danych rzeczywistych zamyka część reality gap, ale poprawa w jednym świecie ma wymierny koszt w drugim. Optymalna strategia to co-training: starannie zbalansowana mieszanka danych symulacyjnych i rzeczywistych w jednym przebiegu treningowym, a nie sekwencyjne “najpierw symulacja, potem przełączenie”.

Narzędzia do zamykania reality gap

Randomizacja domeny redukuje gap przez poszerzenie rozkładu treningowego, ale istnieją dedykowane metody bezpośredniego jego pomiaru i korekty.

SAGE estymuje i koryguje rozjazd parametrów dynamicznych (tarcie przegubów, bezwładność) między modelem symulacyjnym a fizycznym zachowaniem robota.

GapONet trenuje osobną sieć modelującą sam gap: różnicę między tym, co przewiduje symulacja, a tym, co faktycznie robi robot, pozwalając na korektę polityki bez pełnego retrenowania.

Cosmos generuje dodatkowe warianty syntetycznych danych na bazie zebranych epizodów, zwiększając różnorodność treningową bez konieczności zbierania nowych fizycznych demonstracji.

Co dalej

W przyszłym tygodniu modyfikujemy scenę symulacyjną, żeby lepiej dopasować ją do rzeczywistości, oraz przechodzimy z uczenia przez imitację na uczenie przez wzmocnienie (reinforcement learning, RL). Porównanie obu podejść w kontekście sim2real to jedno z otwartych pytań w manipulacji robotycznej: RL może eksplorować strategie, które nigdy nie pojawiły się w ludzkich demonstracjach, ale wymaga też staranniejszego projektowania funkcji nagrody i jest trudniejszy do stabilizacji na granicy sim-to-real.

FAQ

Czym jest transfer sim-to-real w robotyce?

Transfer sim-to-real to technika trenowania polityki robotycznej w symulatorze fizycznym i wdrażania jej na fizycznym robocie, redukująca koszty zbierania danych i zużycie sprzętu. Wyzwaniem jest to, że symulacja nigdy nie odwzorowuje w pełni rzeczywistości, tworząc lukę w skuteczności zwaną reality gap.

Czym jest reality gap w uczeniu robotów?

Reality gap to różnica w skuteczności między polityką ewaluowaną w symulacji a tą samą polityką działającą na fizycznym robocie. Wynika z różnic w tarciu, oświetleniu, szumie sensorycznym i dynamice obiektów, których symulacja nie jest w stanie w pełni odwzorować.
 

Czym jest randomizacja domeny?

Randomizacja domeny to technika treningowa, która losuje parametry symulacji (oświetlenie, pozycje obiektów, kąty kamer) przy każdym resecie epizodu, żeby polityka uczyła się szerokiego rozkładu warunków zamiast wąskiej, stałej sceny, zwiększając szansę na generalizację do rzeczywistości.

Co to jest IsaacSim?

IsaacSim to symulator fizyczny NVIDIA do robotyki, używany do tworzenia wiernych środowisk wirtualnych do treningu i testowania polityk robotycznych. IsaacLab to framework zbudowany na IsaacSim integrujący się z pipeline’ami uczenia robotów, takimi jak LeRobot.

Ile demonstracji rzeczywistych potrzeba do fine-tuningu po sim-to-real?

W naszym eksperymencie 10 rzeczywistych demonstracji dodanych do polityki wytrenowanej na symulacji podniosło skuteczność fizyczną o 15 punktów procentowych (z 50% do 65%), pokazując, że nawet bardzo mały zbiór danych rzeczywistych potrafi częściowo zamknąć reality gap bez konieczności zbierania setek fizycznych epizodów.

Czym jest co-training w sim-to-real?

Co-training to strategia mieszająca dane symulacyjne i rzeczywiste w jednym przebiegu treningowym zamiast trenować sekwencyjnie najpierw na symulacji, a potem dotrenowywać na realu. Celem jest polityka generalizująca do obu rozkładów jednocześnie, redukująca kompromis skutecznościowy obserwowany przy optymalizacji tylko pod jeden świat.