xBerry LeRobot Tydzień 1: Zbieramy 90 epizodów treningowych do uczenia przez naśladowanie

Zbieranie danych treningowych do uczenia przez naśladowanie brzmi jak rozwiązany problem dopóki serwo nie padnie w połowie sesji, a nagranie nie zniknie. Oto jak zebraliśmy 90 epizodów demonstracji do modelu ACT na ramieniu SO-101: nasz setup, co się zepsuło i pipeline, który wszystko uratował.

TL;DR – Dane treningowe LeRobot: wyniki 1. tygodnia

W pierwszym tygodniu wewnętrznego projektu R&D zebraliśmy 90 epizodów treningowych dla zadania Pick, Lift and Place. Dane pochodziły z 4 kamer RGB i 2 map głębi, z 6 pozycji startowych po 15 epizodów każda. Awaria serwa i przerwy komunikacyjne wymusiły zbudowanie pipeline’u z automatycznym zapisem i uploadem na HuggingFace po każdym epizodzie. Okazało się wówczas, że jest to lepsze rozwiązanie, niż jakikolwiek zapis na poziomie sesji mógłby zapewnić.

Ile epizodów treningowych potrzebuje polityka uczenia przez naśladowanie?

Czym jest imitation learning? Jest to metoda treningu robota, w której model uczy się obserwując demonstracje kontrolowane przez człowieka zamiast być programowany jawnymi trajektoriami.

Liczba demonstracji potrzebnych do działającej polityki uczenia przez naśladowanie (imitation learning) zależy silnie od złożoności zadania. Dla zadania Pick, Lift and Place (PLP), w którym robot chwyta obiekt, unosi go i umieszcza w docelowym pojemniku – typowy zakres to 60–200 epizodów.

Dokładna liczba skaluje się z kilkoma niezależnymi czynnikami:

• Liczbą pozycji startowych – więcej stref przestrzennych oznacza więcej wariantów, na których model musi generalizować.
• Liczbą obiektów – każdy dodatkowy obiekt wprowadza nowe konfiguracje chwytu, wymagając k dodatkowych epizodów (gdzie k ≥ 15 w naszym setupie).
• Liczbą zmiennych czynników – pozycja pudełka, kolor obiektu, faktura powierzchni i podobne zmienne środowiskowe mnożą kombinatoryczną złożoność.

Czym skutkuje zbyt mała ilość epizodów? Proste. Polityka nie douczy się (underfitting) i nie generalizuje na niewidzianych pozycjach. Natomiast za dużo powtórzeń tej samej trajektorii sprawia, że polityka się przeucza (overfitting) i zapamiętuje ścieżkę zamiast rozumieć zadanie.

Dlaczego to ważne: Zdefiniowanie macierzy zmiennych przed nagrywaniem oszczędza godziny ponownego treningu. Błędne oszacowanie liczby epizodów jest kosztowne do naprawienia po zakończeniu kolekcji danych.

Nasz setup do zbierania danych treningowych LeRobot: 1 piłeczka, 6 stref, 90 epizodów

W 1. tygodniu celowo wybraliśmy ograniczony setup, aby ustawić czysty punkt startowy przed dodawaniem złożoności, składał się on z:

• 1 obiektu – jedna zielona piłeczka
• 1 pudełka – cel umieszczenia
• 6 pozycji startowych – 6 stref przestrzennych, z których piłeczka była ustawiana przed każdym epizodem

Nagraliśmy 15 epizodów z każdej pozycji startowej, co dało 90 epizodów łącznie w zbiorze treningowym.

W ramach każdej strefy startowej celowo zróżnicowaliśmy ułożenie piłeczki – rogi, środek, lewa krawędź, prawa krawędź i pozycje pośrednie. Ta wariacja wewnątrz strefy jest kluczowa: model trenowany wyłącznie na piłeczce ustawionej centralnie zawiedzie, gdy piłeczka trafi kilka centymetrów dalej. Model musi nauczyć się zadania, nie współrzędnych.

Kluczowe ograniczenie – spójność środowiska: Wszystkie 90 epizodów nagraliśmy w jednym, niezmiennym środowisku. Warunki oświetlenia, pozycje kamer, powierzchnia stołu i tło były stałe przez cały czas nagrywania. To nie preferencja – to twardy wymóg uczenia przez naśladowanie. Zmienność środowiska między epizodami wprowadza szum, którego model nie odróżni od sygnału.

Protokół nagrywania: 30-sekundowe epizody, 4 kamery, 2 mapy głębi

Jak uruchomić nagrywanie epizodów:

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

Każda demonstracja przebiegała zgodnie ze stałym protokołem:

• Czas epizodu: ~30 sekund — wystarczająco długo, by wykonać pełną sekwencję Pick, Lift and Place w kontrolowanym tempie.
• Czas resetu: 10 sekund między epizodami na przywrócenie środowiska – przeniesienie piłeczki z punktu końcowego do kolejnej pozycji startowej.
• Dane wizualne: 4 kamery RGB rejestrujące jednocześnie synchroniczne strumienie wideo kolorowego.
• Dane głębi: 2 mapy głębi z kamer Intel RealSense, rejestrujące informacje przestrzenne 3D obok klatek kolorowych.

Ramię SO-101 działa w konfiguracji Leader–Follower: operator fizycznie steruje ramieniem lider ręcznie, a ramię follower odzwierciedla każdy ruch stawów w czasie rzeczywistym.

 

W tym czasie Framework LeRobot – biblioteka open-source od Hugging Face, zarządzająca synchronizacją wielu kamer, strukturyzacją zbiorów danych i treningiem polityk – rejestruje wszystkie strumienie kamer i dane pozycji stawów synchronicznie, tworząc wielomodalny zbiór gotowy do treningu.

 

Tak przygotowany setup działał, aż do pierwszej awarii sprzętu.

Co się zepsuło: 2 problemy sprzętowe przerywające nagrywanie

Napotkaliśmy 2 odrębne problemy podczas sesji nagrywania.

Problem 1 – Błąd serwa na efektorze. Silnik serwo sterujący chwytakiem (end effector – końcowy staw mający kontakt z obiektami) na ramieniu SO-101 zgłosił sygnał błędu do sterownika podczas aktywnego nagrywania. LeRobot zinterpretował ten błąd jako naturalny sygnał zakończenia epizodu i automatycznie przerwał nagrywanie. Sesja zakończyła się w połowie epizodu bez ostrzeżenia.

Problem 2 – Przerwy komunikacyjne. Sporadyczne opóźnienia w warstwie komunikacji między sterownikiem ramienia a stacją roboczą nagrywającą powodowały, że LeRobot podobnie przerywał sesję – traktując opóźnienie jako sytuację błędną.

Jak to naprawiliśmy: pipeline z zapisem i uploadem na HuggingFace po każdym epizodzie

Zamiast traktować całą sesję nagrywania jako jedną monolityczną operację, przeprojektowaliśmy pipeline tak, by zapisywał każdy ukończony epizod indywidualnie – w momencie jego zakończenia, zanim rozpocznie się kolejny. Każdy zapisany epizod jest od razu wysyłany na HuggingFace – platformę uczenia maszynowego hostującą nasz zbiór danych – natychmiast po zamknięciu 30-sekundowego okna nagrywania.

Jak wznowić nagrywanie lub dograć kolejne epizody:

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
--resume=true # wznowienie nagrywania

Ta architektura rozwiązała oba problemy jednocześnie:

• Błąd serwera lub przerwa komunikacyjna po epizodzie N pozostawia epizody 1 do N-1 w pełni nienaruszone na HuggingFace. Żadne dane nie są tracone.
• Nagrywanie można wznowić po każdej przerwie bez restrukturyzacji zbioru danych.
• Dogranie kolejnych epizodów – jeśli 90 okaże się niewystarczające do zbieżności treningu – wymaga jedynie kontynuowania istniejącego zbioru w tym samym repozytorium HuggingFace.

Dodatkowo uszkodzone serwo zostało wymienione na nowe. Ze względu na to, że SO-101 to robot modularny to każdy staw używa standardowego modułu serwa, który można wymontować i zastąpić w kilka minut bez demontażu reszty ramienia. Wymiana nie wymagała ponownej kalibracji całego systemu, a nagrywanie zostało szybko wznowione.

 
Dlaczego to ważne: Budowanie pipeline’ów z checkpointingiem na poziomie epizodu i backupem w chmurze od pierwszego dnia to nie przerost formy tylko minimalny standard niezawodności dla systemów physical AI. Sprzęt zawiedzie. Pipeline musi być na to obojętny.

Kluczowy wniosek: checkpointing na poziomie epizodu to nie opcja

Najbardziej przenośna lekcja z 1. tygodnia nie dotyczy konkretnie ramion robotycznych, a tego, że systemy physical AI wymagają checkpointingu na poziomie epizodu z backupem w chmurze od pierwszego dnia.

Zapis na poziomie sesji zakłada, że sesja dojdzie do końca. Sprzęt tego założenia nie respektuje. Każdy pipeline, który może stracić godzinę nagrań przez jedno zerwane połączenie, nie jest pipeline’em, to zakład.

Co dalej: trening modelu ACT na 90 epizodach

Co to jest ACT? Jest to algorytm metody uczenia przez naśladowanie opartej na architekturze Transformer, która przewiduje całe sekwencje przyszłych akcji jednocześnie zamiast krok po kroku.

Mając 90 epizodów przesłanych na HuggingFace, 2. tydzień skupia się na treningu modelu. Kolejny krok to napisanie pipeline’u treningowego do nauczenia ramienia SO-101 autonomicznego wykonywania zadania Pick, Lift and Place z użyciem algorytmu ACT (Action Chunking with Transformers). To podejście redukuje kumulowanie się błędów predykcji typowe dla metod krokowych w długich sekwencjach manipulacyjnych.

Jeśli jesteś zainteresowany naszym wewnętrznym projektem robotycznym i sam chciałbyś zacząć takie przedsięwzięcie – nie zwlekaj i skontaktuj się z nami już dziś!
 
 

FAQ

Co to jest uczenie przez naśladowanie w robotyce?

Uczenie przez naśladowanie (imitation learning) to metoda treningu robota, w której polityka – model sterujący robotem – uczy się obserwując demonstracje kontrolowane przez człowieka, zamiast być programowana jawnymi trajektoriami lub uczeniem ze wzmocnieniem opartym na nagrodach.

Ile epizodów treningowych potrzebuje zadanie Pick, Lift and Place?

Zadanie Pick, Lift and Place wymaga typowo od 60 do 200 epizodów demonstracji, zależnie od liczby pozycji startowych, zaangażowanych obiektów i innych zmiennych czynników w setupie. Każdy nowy czynnik zmienności wymaga nagrania k dodatkowych epizodów demonstracji.

Co to jest algorytm ACT używany w LeRobot?

ACT (Action Chunking with Transformers) to algorytm uczenia przez naśladowanie, który używa architektury Transformer do jednoczesnego przewidywania całych sekwencji przyszłych akcji robota zamiast jednej akcji na raz, redukując kumulowanie się błędów predykcji typowe dla metod krokowych w długich sekwencjach manipulacyjnych.

Co to jest ramię SO-101?

SO-101 to modularny manipulator robotyczny z 6 stopniami swobody (6 DoF), zaprojektowany do badań nad uczeniem przez naśladowanie. SO-101 działa w konfiguracji Leader–Follower, gdzie operator fizycznie steruje jednym ramieniem, a drugie odzwierciedla ruchy stawów w czasie rzeczywistym podczas nagrywania danych treningowych.

Dlaczego wszystkie epizody treningowe muszą być nagrywane w tym samym środowisku?

Modele uczenia przez naśladowanie uczą się ze statystycznej korelacji między danymi wizualnymi a akcjami stawów robota. Jeśli środowisko zmienia się między epizodami – inne oświetlenie, kąty kamer lub elementy tła – model nie może niezawodnie zmapować tego, co widzi, na właściwe akcje, co wprowadza szum degradujący jakość polityki.

Co to jest LeRobot i jak obsługuje zbieranie danych?

LeRobot to framework open-source do badań nad robotiką rozwijany przez Hugging Face, zarządzający synchronizowanym nagrywaniem wielu kamer, strukturyzacją zbiorów danych, treningiem polityk neuronowych i ewaluacją modeli. Podczas nagrywania LeRobot monitoruje sygnały stanu sprzętu i przerwie sesję przy wykryciu błędu — co sprawia, że odporna architektura pipeline’u jest niezbędna.

Jeśli chcesz być na bieżąćo z naszymi postępami w projekcie LeRobot, śledź nas na naszym Linkedinie – xBerry R&D House.