Podsumowanie etapu ACT: co 4 tygodnie trenowania robota naprawdę nas nauczyły

Przeprowadziliśmy ponad 100 fizycznych prób ewaluacyjnych, wytrenowaliśmy dwa modele od zera i odkryliśmy, że model z większą liczbą sensorów wypadł gorzej. Cztery tygodnie uczenia przez imitację z algorytmem ACT na ramieniu SO-101: co znaleźliśmy, co nas zaskoczyło i co robimy dalej.

TL;DR

Przez cztery tygodnie zbudowaliśmy kompletny pipeline uczenia przez imitację dla ramienia SO-101 z użyciem frameworka LeRobot i algorytmu ACT. Zebraliśmy 90 epizodów treningowych, wytrenowaliśmy warianty polityki RGB i RGBD, oceniliśmy je w 60 próbach fizycznych, a następnie przeprowadziliśmy pełny eksperyment sim-to-real w IsaacSim. Kluczowe wyniki: RGB pokonało RGBD (50% vs 43,3%), polityka z symulacji osiągnęła 80% w IsaacSim i tylko 50% na fizycznym robocie, a 10 demonstracji z rzeczywistości zamknęło połowę tej luki. Optymalna strategia, którą zidentyfikowaliśmy, to nie “najpierw symulacja” ani “tylko dane rzeczywiste”, lecz co-training na obu źródłach jednocześnie.

O czym był ten etap

W czerwcu 2026 ustawiliśmy dwa ramiona SO-101 w konfiguracji Leader-Follower i postawiliśmy proste pytanie: czy robot może nauczyć się podnosić piłkę i wkładać ją do pojemnika, obserwując wyłącznie, jak robi to człowiek?

Uczenie przez imitację (imitation learning, IL): metoda trenowania robotów, w której polityka uczy się na podstawie nagranych demonstracji człowieka, bez programowania trajektorii ani definiowania funkcji nagród. ACT (Action Chunking with Transformers): algorytm uczenia przez imitację, który przewiduje całe sekwencje przyszłych ruchów jednocześnie zamiast krok po kroku, eliminując kumulowanie się błędów predykcji typowe dla klasycznych modeli.

Zadanie benchmarkowe to Pick, Lift and Place (PLP): chwyć piłkę z jednej z sześciu pozycji startowych, unieś ją i umieść w pojemniku. Proste do opisania i wystarczająco wymagające, żeby pokazać każdą słabość pipeline’u.

Więcej o nazych początkach możesz przeczytać w artykule: Jak zbudowaliśmy stanowisko do uczenia przez imitację.

Tydzień 1: najpierw przyszła lekcja od sprzętu

Zanim zebraliśmy choć jeden użyteczny epizod treningowy, w połowie nagrywania padło serwo. LeRobot zinterpretował sygnał błędu sprzętowego jako naturalne zakończenie epizodu i przerwał sesję. Straciliśmy dane.

Rozwiązanie było proste z perspektywy czasu: przeprojektować pipeline tak, by każdy ukończony epizod był zapisywany i wysyłany na HuggingFace natychmiast po zakończeniu, zanim rozpocznie się kolejny. Zapis na poziomie sesji zakłada, że sesja dojdzie do końca. Sprzęt tego nie respektuje.

Nie tylko my: Sherry Chen odnotowała niemal identyczną awarię systemu podczas trenowania modelu ACT na tym samym sprzęcie SO-101 – obejmowała ona rozłączanie się kamery, problemy z kalibracją oraz zużycie silnika chwytaka wskutek nadmiernej siły użytej podczas teleoperacji. Gromadzenie danych w rzeczywistych warunkach jest znacznie bardziej skomplikowane i problematyczne, niż sugerują to jakiekolwiek poradniki.

Rozwiązanie było proste z perspektywy czasu: przeprojektować pipeline tak, by każdy ukończony epizod był zapisywany i wysyłany na HuggingFace natychmiast po zakończeniu, zanim rozpocznie się kolejny. Zapis na poziomie sesji zakłada, że sesja dojdzie do końca. Sprzęt tego nie respektuje.
Po wdrożeniu checkpointingu na poziomie epizodu zebraliśmy 90 epizodów treningowych w 6 strefach startowych, 15 na strefę, z celową wariacją ułożenia piłki wewnątrz każdej strefy. Jedno ograniczenie obowiązywało przez cały czas: środowisko pozostawało niezmienione – to samo oświetlenie, te same pozycje kamer, to samo tło. Modele uczenia przez imitację korelują dane wizualne z ruchami stawów, a zmiana środowiska między epizodami wprowadza szum, którego model nie jest w stanie oddzielić od sygnału.

Rozpoczęliśmy nagrywanie epizodów używając tej komendy ▼
 

lerobot-record \
--robot.type=so101_follower \
--robot.port=/dev/tty.usbmodem585A0076841 \
--robot.id=my_awesome_follower_arm \
--robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 1920, height: 1080, fps: 30}}" \
--teleop.type=so101_leader \
--teleop.port=/dev/tty.usbmodem58760431551 \
--teleop.id=my_awesome_leader_arm \
--display_data=true \
--dataset.repo_id=${HF_USER}/record-test \
--dataset.num_episodes=5 \
--dataset.single_task="Grab the black cube" \
--dataset.streaming_encoding=true \
# --dataset.vcodec=auto \
--dataset.encoder_threads=2

Chcesz wiedzieć więcej? Przeczytaj artykuł o Tygodniu 1 – Zbieranie 90 epizodów treningowych do uczenia przez naśladowanie.

Tydzień 2: dwa modele, jedno otwarte pytanie

Proces uczenia przeprowadzono na pojedynczym układzie GPU NVIDIA RTX PRO 4000 Blackwell, wykonując 50 000 kroków. Wytrenowano dwa warianty strategii ACT: wykorzystujący wyłącznie obraz RGB (2,5 godziny) oraz RGBD, uwzględniający dodatkowo mapy głębi z dwóch kamer Intel RealSense (5 godzin; czas ten wynikał z większej ilości danych przetwarzanych w ramach pojedynczej próbki). W obu przypadkach proces uczenia przebiegł pomyślnie, prowadząc do stabilnej zbieżności.

Przystępując do oceny, zakładaliśmy, że dane o głębi pozwolą modelowi lepiej postrzegać przestrzeń trójwymiarową i zwiększą precyzję chwytania. Było to uzasadnione założenie. Okazało się ono jednak błędne, a przynajmniej błędne w pewnych, nieprzewidzianych przez nas okolicznościach.

Zaczęliśmy trenować używając następującej komendy ▼

lerobot-record \
--robot.type=so100_follower \
--robot.port=/dev/ttyACM0 \
--robot.id=my_robot \
--robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
--display_data=true \
--dataset.repo_id=${HF_USER}/eval_act_your_dataset \
--dataset.num_episodes=10 \
--dataset.single_task="Your task description" \
--dataset.streaming_encoding=true \
--dataset.encoder_threads=2 \
# --dataset.vcodec=auto \
--policy.path=${HF_USER}/act_policy

Dowiedz się więcej na temat Tygodnia 2 – Trenowanie modele ACT – RGB i RGB+głębia.

Tydzień 3: pomiar głębi sprawdził się tam, gdzie czujniki miały widoczność, a zawiódł wszędzie indziej

Czym jest okluzja? Jest to sytuacja, w której obiekt znajduje się poza zasięgiem pewnego pola widzenia czujnika, co skutkuje zaszumionymi lub niepełnymi odczytami głębi. W pozycji nr 5 piłka zlewała się z tłem, zamiast zostać zarejestrowana jako wyraźna powierzchnia w mierzalnej odległości. Prawdopodobną drugą przyczyną był błąd kalibracji układu ręka-oko, sprawiający, że sygnał głębi wprowadza szum przestrzenny zamiast informacji przestrzennej. Model RGB nie jest narażony na ten rodzaj szumu, ponieważ w ogóle nie wykorzystuje danych o głębi.

Przeprowadziliśmy 60 prób oceny w warunkach rzeczywistych: po 30 dla każdego modelu, z uwzględnieniem 5 pozycji startowych. Główne wyniki: 50,0% dla modelu RGB oraz 43,3% dla RGBD. Jednak to szczegółowe zestawienie wyników w podziale na poszczególne pozycje dostarcza bardziej wartościowych informacji.

Na pozycjach 0 i 2, znajdujących się w optymalnym polu widzenia kamery RealSense D435, system RGBD uzyskał wyniki odpowiednio 100% i 80%. Na pozycji 5 – przy krawędzi obszaru roboczego i pod niekorzystnym kątem względem obu czujników głębi – system RGBD osiągnął wynik 20%, podczas gdy system RGB uzyskał 80%.

Dlaczego to ma znaczenie: Większa liczba czujników nie przekłada się automatycznie na lepszą strategię działania. Każdy czujnik dostarcza użytecznych danych jedynie w obrębie tzw. okna percepcji, wyznaczonego przez jego fizyczne umiejscowienie oraz jakość kalibracji. Poza tym zakresem czujnik może pogorszyć skuteczność systemu w porównaniu z prostszym modelem, który całkowicie go pomija.

Oceniliśmy RGBD, wykorzystując tą komendę ▼
 

python scripts/eval_policy.py \
  --policy-path=xBerry/lerobot_act_policy \
  --repo-id=xBerry/eval_lerobot_policy_rollout \
  --root=./datasets/eval_lerobot_policy_rollout \
  --task="Pick the object and place it in the container" \
  --fps=15 \
  --num-episodes=10 \
  --episode-time-s=30 \
  --reset-time-s=15 \
  --robot-port=/dev/ttyUSB0 \
  --robot-id=white_arm \
  --robot-calibration-dir=./local_calibration/robots/so_follower \
  --resume

Oraz oceniliśmy RGB-only używając tej komendy ▼
 

python scripts/eval_policy.py \
  --policy-path=xBerry/lerobot_act_rgb_policy \
  --rgb-only \
  --repo-id=xBerry/eval_lerobot_policy_rollout \
  --root=./datasets/eval_lerobot_policy_rollout \
  --task="Pick the object and place it in the container" \
  --fps=15 \
  --num-episodes=10 \
  --episode-time-s=30 \
  --reset-time-s=15 \
  --robot-port=/dev/ttyUSB0 \
  --robot-id=white_arm \
  --robot-calibration-dir=./local_calibration/robots/so_follower

Przeczytaj więcje o Tygodniu 3 – RGB vs RGBD – 60 prób, jeden zaskakujący wynik.

Tydzień 4: 80% w symulacji, 50% w rzeczywistości

Gromadzenie większej liczby fizycznych demonstracji to powolna i kosztowna droga do poprawy wydajności: każda próba wymaga ręcznego przywrócenia stanowiska pracy do stanu wyjściowego, wiąże się ze zużyciem mechanicznym ramienia, a poszczególnych prób nie można przeprowadzać równolegle. Symulacja eliminuje wszystkie trzy te ograniczenia.

Stworzyliśmy cyfrowego bliźniaka stanowiska SO-101 w środowisku IsaacSim (symulatorze fizyki dla robotyki firmy NVIDIA), odwzorowaliśmy scenę z dokładnością wizualną na poziomie 90% (różnica wizualna poniżej 10%) i zastosowaliśmy randomizację domenową. Jest to technika polegająca na losowaniu parametrów symulacji przy każdym jej restarcie – w tym oświetlenia, pozycji obiektów i ustawień kamery – w celu poszerzenia rozkładu danych treningowych tak, aby warunki rzeczywiste mieściły się w jego zakresie, a nie poza nim. Strategia wytrenowana wyłącznie na danych symulacyjnych osiągnęła wynik 80% w środowisku IsaacSim oraz 50% w przypadku robota rzeczywistego, co oznacza różnicę (tzw. *reality gap*) na poziomie 30 punktów procentowych.

Co to jest Fine-tuning (dotrenowanie)?Jest to proces dalszego trenowania modelu, który został już wcześniej wytrenowany, z wykorzystaniem niewielkiego, nowego zbioru danych, co pozwala mu dostosować się do nowych warunków bez utraty wcześniej zdobytej wiedzy.

Dostrajanie modelu w oparciu o zaledwie 10 rzeczywistych demonstracji podniosło skuteczność działania w świecie rzeczywistym do 65%, lecz obniżyło ją w środowisku symulacyjnym z 80% do 75%. Rzeczywiste dane przesunęły wagi modelu w stronę odmiennego rozkładu, poprawiając zdolność do generalizacji w świecie fizycznym kosztem mierzalnego spadku wydajności w idealnych warunkach symulacji. Wyniki te wskazują, że lepszą strategią jest wspólne trenowanie (co-training) na starannie dobranym zbiorze danych łączącym materiały z symulacji i świata rzeczywistego, zamiast traktowania tych dwóch etapów jako sekwencyjnych faz procesu.

Uruchomiliśmy całe środowisko w kontenerze Dockera, używając tego polecenia ▼
 

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

Jeśli chcesz wiedzieć więcej, sprawdź jak nam poszło w Tygodniu 4 – sim-to-real – 80% w symulacji, 50% w realu i co naprawiło 10 demonstracji.

Moment, którego nikt się nie spodziewał: chwila, gdy piłka się wymknęła.

Jakie jest rozwiązanie sprzeczne z intuicją? Podczas gromadzenia danych celowo uwzględnia się przypadki niepowodzenia. Należy popchnąć piłkę, pozwolić jej się oddalić, upuścić ją poza zasięg ramienia robota, a następnie skierować go z powrotem do pozycji wyjściowej. Takie epizody odzyskiwania sprawności uczą model, że ucieczka piłki to rozpoznawalny stan, który wymaga właściwej reakcji: powrotu do punktu wyjścia i ponownej próby. Robot potrafiący poradzić sobie z nieudaną próbą chwytu jest znacznie bardziej niezawodny niż taki, który wykonuje chaotyczne, nieskuteczne ruchy.

Jeden z wniosków zawartych w końcowym raporcie z ewaluacji zasługuje na osobne omówienie: awaria typu Out-of-Distribution (OOD).

Czym jest Out-of-Distribution (OOD)? Jest to sytuacja, w której model podczas ewaluacji napotyka stan nieobecny w danych treningowych. W uczeniu przez naśladownictwo dane spoza rozkładu (OOD) prowadzą do załamania działania strategii – zamiast łagodnego pogorszenia jakości pracy obserwujemy chaotyczne i nieprzewidywalne ruchy elementów układu.

Nagrywaliśmy wyłącznie udane demonstracje: piłka była zawsze podnoszona i odkładana poprawnie. Gdy podczas ewaluacji piłka wyśliznęła się z chwytaka, model nie miał wyuczonej odpowiedzi na ten stan. Ramię się wywijało. Uderzało w stół. Ruchy były całkowicie losowe.

Dlaczego to ważne: Polityka uczenia przez imitację jest tak odporna, jak rozkład danych, na którym ją wytrenowano. Każdy stan, który nigdy nie pojawił się w treningu, wywoła całkowite załamanie. Epizody z błędami i odzyskiwaniem kontroli to nie opcja – to podstawowy wymóg każdego deployowalnego systemu physical AI.

Co zrobilibyśmy inaczej

Patrząc wstecz na cztery tygodnie, wyróżniają się trzy lekcje.

Dobór obserwacji jest ważniejszy niż ich liczba.

Potwierdziliśmy to dwukrotnie: RGBD pogorszyło wyniki na pozycjach brzegowych, a zmniejszenie liczby kamer w setupie symulacyjnym poprawiło transfer sim2real (robot przestał trenować na obserwacjach, których nie miał podczas fizycznego wdrożenia). Właściwe sensory, poprawnie skalibrowane i umieszczone, wygrywają z bogatszym, ale bardziej zaszumionym zestawem.

Randomizacja domeny powinna obejmować właściwości mechaniczne, nie tylko wizualne.

W Tygodniu 4 randomizowaliśmy oświetlenie i pozycje obiektów. Czego brakowało: tarcie serw, bezwładność przegubów, opór materiałów. Te dynamiczne różnice między symulacją a sprzętem kumulują się przez całą trajektorię. Szersza randomizacja (obejmująca właściwości fizyczne) dałaby lepszy transfer bez dodatkowych danych rzeczywistych.

Identyfikacja systemu powinna poprzedzać randomizację domeny.

Dokładna dokumentacja każdego parametru fizycznego robota przed konfiguracją symulatora — zakresy przegubów, krzywe momentu serw, parametry wewnętrzne kamer – redukuje bazowy gap sim2real jeszcze przed włączeniem randomizacji. Dobrze scharakteryzowana symulacja z szeroką randomizacją jest silniejsza niż każde z tych podejść osobno.

Co dalej: uczenie przez wzmocnienie

Czym jest uczenie przez wzmocnienie (reinforcement learning RL)? Jest to paradygmat, w którym agent uczy się optymalnej polityki przez interakcję ze środowiskiem metodą prób i błędów, maksymalizując skumulowaną nagrodę bez potrzeby oznakowanych danych demonstracyjnych.

Kolejny etap projektu przechodzi od uczenia przez imitację do uczenia przez wzmocnienie (reinforcement learning, RL).

Gdzie ACT jest ograniczony tym, co pokazał człowiek, RL może eksplorować strategie, które nigdy nie pojawiły się w żadnym nagraniu. Koszt to projektowanie funkcji nagrody: precyzyjne określenie, co znaczy “dobrze” w fizycznym zadaniu manipulacyjnym, wymaga starannej inżynierii. Porównamy algorytmy off-policy (SAC, TD3) i on-policy (PPO) na tym samym zadaniu Pick, Lift and Place w kontekście sim2real: która rodzina algorytmów lepiej transferuje się z IsaacSim na fizyczne ramię SO-101?

Zbadamy też Cosmos3 od NVIDIA do augmentacji datasetu: generowania fotorealistycznych wariantów wideo na podstawie outputów symulatora, redukując domain gap bez konieczności zbierania dodatkowych danych z rzeczywistości.

FAQ

Czym jest ACT (Action Chunking with Transformers)? ACT to algorytm uczenia przez imitację, który używa architektury Transformer do jednoczesnego przewidywania całych sekwencji przyszłych pozycji stawów robota zamiast jednej akcji na krok. Takie podejście redukuje kumulowanie się błędów predykcji w długich sekwencjach manipulacyjnych.

Dlaczego RGB wypadło lepiej niż RGBD w ewaluacji SO-101? Model RGBD przewyższał RGB tylko na pozycjach, gdzie kamery RealSense miały bezpośredni widok na piłkę (pozycje 0 i 2, osiągając 100% i 80%). Na pozycjach brzegowych z okluzją lub niekorzystną geometrią sensora dane głębi wprowadzały szum, z którym model RGB nigdy się nie spotkał, obniżając ogólny wynik RGBD do 43,3% wobec 50,0% RGB.

Czym jest reality gap w transferze sim-to-real? Reality gap to różnica w skuteczności między polityką ewaluowaną w symulacji a tą samą polityką działającą na fizycznym robocie. W naszym eksperymencie gap wyniósł 30 punktów procentowych: 80% w IsaacSim i 50% na fizycznym SO-101, wynikając z różnic w tarciu, oświetleniu i szumie sensorycznym, których symulacja nie może w pełni odwzorować.

Ile demonstracji rzeczywistych potrzeba, by częściowo zamknąć reality gap? W naszym eksperymencie 10 demonstracji rzeczywistych dodanych do polityki wytrenowanej na symulacji podniosło skuteczność fizyczną o 15 punktów procentowych (z 50% do 65%), kosztem 5 punktów w symulacji (z 80% do 75%). Strategia co-trainingu mieszająca dane symulacyjne i rzeczywiste od początku powinna dać lepsze wyniki niż sekwencyjny fine-tuning.

Czym jest błąd Out-of-Distribution w uczeniu przez imitację? Błąd Out-of-Distribution (OOD) pojawia się, gdy robot napotyka podczas ewaluacji stan, który nigdy nie wystąpił w danych treningowych. W uczeniu przez imitację wejście OOD powoduje całkowite załamanie polityki: model nie ma wyuczonej odpowiedzi i generuje chaotyczne, nieprzewidywalne ruchy. Nagrywanie celowych błędów i epizodów odzyskiwania kontroli podczas zbierania danych to standardowe zabezpieczenie.

Czym jest randomizacja domeny w uczeniu robotów? Randomizacja domeny to technika treningowa, która losuje parametry symulacji przy każdym resecie epizodu, w tym oświetlenie, pozycje obiektów i kąty kamer, tak żeby polityka uczyła się obsługiwać szeroki zakres warunków zamiast jednej stałej sceny. Polityka wytrenowana z randomizacją domeny ma większą szansę transferu na fizyczny sprzęt, bo rzeczywista zmienność mieści się w jej rozkładzie treningowym.