Wkraczamy w fazę RL: najpierw pomiary, potem symulacja

30-punktowa luka między symulacją a rzeczywistością, którą odkryliśmy w fazie ACT, miała konkretną przyczynę: symulacja opierała się na założeniach, nie na pomiarach. Tydzień 1 fazy uczenia przez wzmocnienie nie zaczął się od trenowania. Zaczął się od taśmy mierniczej, loggera telemetrii i sześciu serwomechanizmów, które trzeba było zrozumieć, zanim dało się je modelować.

TL;DR

Fazę uczenia przez wzmocnienie w projekcie xBerry Robotic Arm rozpoczęliśmy od przebudowania symulacji od zera – tym razem z mierzonymi parametrami zamiast domyślnych. W IsaacLab zaimportowaliśmy pełną scenę (ramię SO-101, czarna miska, żółta piłka, biały stół), skalibrowano dwie kamery na podstawie fizycznych pomiarów FOV i odległości, a na 6 serwomechanizmach STS3215 przeprowadzono identyfikację systemów w celu wyznaczenia tarcia, limitów momentu, sztywności i tłumienia. Rezultat: symulacja zgodna z fizycznym setupem w ok. 90%. Środowisko jest gotowe do treningu RL.

Od imitacji do wzmocnienia: inny rodzaj uczenia

W fazie ACT nauczyliśmy ramię SO-101 podnosić piłkę, pokazując mu 90 demonstracji ludzkich. Robot uczył się kopiować to, co widział. Uczenie przez wzmocnienie (RL) działa inaczej: zamiast demonstracji agent otrzymuje sygnał nagrody za każdą podjętą akcję i odkrywa skuteczne zachowanie metodą prób i błędów. Nie ma trajektorii do naśladowania – jest tylko definicja zadania, przestrzeń obserwacji i funkcja nagrody.

Praktyczna konsekwencja jest taka, że RL wymaga znacznie więcej czasu symulacji. Tam gdzie ACT potrzebował 90 nagrań z rzeczywistości, RL potrzebuje setek tysięcy symulowanych epizodów, by osiągnąć zbieżność. Symulacja odbiegająca od fizycznego robota o 30 punktów procentowych – jak nasza w fazie ACT – wygenerowałaby politykę, która natychmiast zawodzi na sprzęcie. Poprawna symulacja to nie krok wstępny. To jest praca właściwa.

Budowanie sceny w IsaacLab

IsaacLab – framework open-source NVIDIA do trenowania agentów uczenia maszynowego w symulacji, zbudowany na bazie IsaacSim. Dostarcza ustrukturyzowane środowiska do zadań manipulacji, lokomocji i sterowania, ze wsparciem dla symulacji fizycznej i randomizacji domeny.

Zaimportowaliśmy pełną scenę Pick, Lift and Place do IsaacLab: białe ramię SO-101, czarna miska, żółta piłka i biały stół – wszystko jako assety USD. Walidacja fizyki potwierdziła poprawne interakcje robot-piłka-miska: piłka toczy się, odbija i zatrzymuje realistycznie. Setup kamer odzwierciedla fizyczne laboratorium dokładnie: kamera OVER zawieszona ok. 134 cm nad przestrzenią roboczą i kamera EGO zamontowana blisko chwytaka w odległości 28 cm.

Obie kamery skonfigurowano z pomiarów fizycznych, nie z domyślnych wartości symulatora:

# OVER camera 
CameraCfg(width=640, height=480, horizontal_fov=30.9) 
# EGO camera 
CameraCfg(width=1920, height=1080, horizontal_fov=67.3)

Kamera EGO – zamontowana na ramieniu – daje modelowi widok z pierwszej osoby na chwytak zbliżający się do celu. Szerokie pole widzenia 67,3° rejestruje relację ręka-obiekt z bliskiej odległości, co jest kluczową ramką dla decyzji o chwycie.

Identyfikacja systemów: mierzyć zamiast zakładać

Identyfikacja systemów (SysID) – proces pomiaru dynamicznych właściwości systemu fizycznego i wykorzystania tych pomiarów do konfiguracji modelu. W symulacji robotycznej oznacza to wyznaczanie rzeczywistych parametrów serwomechanizmów – tarcia, limitów momentu, sztywności pozycyjnej, tłumienia prędkościowego i bezpośrednie kodowanie ich w silniku fizyki zamiast używania domyślnych ustawień producenta.

Tu tkwiło źródło luki sim-to-real w fazie ACT. Setup w IsaacSim używał przybliżonych parametrów serw. Fizyczny robot zachowywał się inaczej w każdym przegubie, bo rzeczywiste serwomechanizmy mają unikalne profile tarcia, przełożenia i limity prądu, które ujawnia tylko telemetria.

Przeprowadziliśmy logowanie telemetrii na wszystkich 5 aktywnych serwach SO-101 (model STS3215) przez 50-sekundową sekwencję ruchów, rejestrując pozycję, prędkość i obciążenie w każdej chwili czasowej. Wynikające z tego krzywe ujawniły indywidualny profil tarcia każdego przegubu, punkt nasycenia prędkości i rozkład obciążenia — danych, których nie da się odczytać z żadnej karty katalogowej.

Te pomiary trafiły bezpośrednio do konfiguracji SO101_CFG w IsaacLab. Każdy przegub ma teraz wartości sztywności (Kp) i tłumienia (Kd) wyznaczone z telemetrii, a nie założone:

SO101_CFG = ArticulationCfg(
 actuators={
 # Gear 1/191 — 34.4 N·m
 "rotation": ImplicitActuatorCfg(
 joint_names_expr=["Rotation"],
 effort_limit_sim=30,
 stiffness=55,
 damping=0.7,
  ),
 # Gear 1/345 — 62.1 N·m (highest torque joint)
 "pitch": ImplicitActuatorCfg(
 joint_names_expr=["Pitch"],
 effort_limit_sim=30,
 stiffness=30,
 damping=0.8,
  ),
 # Gear 1/191 — 34.4 N·m
 "elbow": ImplicitActuatorCfg(
 joint_names_expr=["Elbow"],
 effort_limit_sim=30,
 stiffness=25,
 damping=0.7,
  ),
 # Gear 1/147 — 26.5 N·m
 "wrist_pitch": ImplicitActuatorCfg(
 joint_names_expr=["Wrist_Pitch"],
 effort_limit_sim=30,
 stiffness=12,
 damping=0.5,
  ),
 # Gear 1/147 — 26.5 N·m
 "wrist_roll": ImplicitActuatorCfg(
 joint_names_expr=["Wrist_Roll"],
 effort_limit_sim=30,
 stiffness=7,
 damping=0.5,
  ),
 # Gear 1/147 — 26.5 N·m
 "gripper": ImplicitActuatorCfg(
 joint_names_expr=["Jaw"],
 effort_limit_sim=30,
 stiffness=4,
 damping=0.3,
  ),
  },
)

Model aktuatora używa regulatora PD – sterowania proporcjonalno-różniczkującego — do generowania momentu obrotowego dla każdego przegubu. Wyjściowy moment τ wyraża się równaniem:

τ = Kp × (q_cel − q) + Kd × (q̇_cel − q̇)

gdzie Kp (sztywność) napędza przegub w kierunku docelowej pozycji, a Kd (tłumienie) tłumi oscylacje wywołane przez wysokie wartości Kp. Każdy przegub SO-101 ma inne przełożenie i profil obciążenia, więc pary Kp/Kd były strojone indywidualnie na podstawie danych telemetrycznych. Największą sztywność (Kp = 55) ma przegub Rotation; chwytak używa najniższej (Kp = 4), by nie uszkadzać chwytanych obiektów.

Dlaczego to ważne: Symulacja z mierzonymi parametrami serw wygeneruje politykę, która lepiej przenosi się na hardware. Luka sim-to-real to przede wszystkim problem dynamiki, nie wizualizacji. Najpierw popraw fizykę – potem martw się o piksele.

Co dalej: definicja zadania RL

Środowisko jest zbudowane i zwalidowane — ok. 90% zgodności wizualnej z fizycznym setupem. Tydzień 2 skupi się na zdefiniowaniu trzech kluczowych komponentów zadania RL: przestrzeni akcji (jakie komendy stawów może wydawać agent), przestrzeni obserwacji (co agent widzi — klatki kamer, pozycje przegubów, stan chwytaka) i funkcji nagrody (jak agent uczy się, że umieszczenie piłki w misce to cel). Te trzy decyzje projektowe zdecydują o wszystkim, co dotyczy jakości polityki wyłaniającej się z treningu.

FAQ

Czym jest uczenie przez wzmocnienie i czym różni się od uczenia przez imitację?

Uczenie przez wzmocnienie (RL) to paradygmat treningowy, w którym agent uczy się optymalnej polityki poprzez interakcję ze środowiskiem metodą prób i błędów, otrzymując sygnał nagrody za każdą podjętą akcję. W przeciwieństwie do uczenia przez imitację, które wymaga demonstracji ludzkich, RL odkrywa skuteczne zachowanie samodzielnie, co pozwala znajdować strategie, których żadna demonstracja by nie obejmowała.

Czym jest IsaacLab?

IsaacLab to framework open-source NVIDIA do uczenia robotów w symulacji, zbudowany na IsaacSim. Dostarcza ustrukturyzowane środowiska, narzędzia do randomizacji domeny i fizykalnie dokładną symulację, zaprojektowaną do trenowania polityk RL i IL transferowalnych na fizyczny sprzęt.

Czym jest identyfikacja systemów w robotyce?

Identyfikacja systemów (SysID) to proces pomiaru dynamicznych właściwości systemu fizycznego – tarcia, limitów momentu, przełożeń, bezwładności i wykorzystania tych pomiarów do konfiguracji modelu symulacji. Dokładna SysID redukuje lukę sim-to-real poprzez zapewnienie, że fizyka symulacji odpowiada zachowaniu rzeczywistego sprzętu.

Czym jest regulator PD w sterowaniu serwomechanizmami?

Regulator proporcjonalno-różniczkujący (PD) generuje moment przegubu jako τ = Kp × (q_cel − q) + Kd × (q̇_cel − q̇). Człon sztywności Kp napędza przegub w kierunku pozycji docelowej; człon tłumienia Kd tłumi oscylacje, które mogą wywoływać wysokie wartości Kp. Każdy przegub SO-101 ma indywidualnie dostrojone wartości Kp i Kd oparte na fizycznych pomiarach telemetrycznych.

Dlaczego FOV kamery ma znaczenie dla transferu sim-to-real?

Kamera skonfigurowana z niepoprawnym FOV generuje obrazy z innym zniekształceniem perspektywicznym niż kamera fizyczna, co powoduje, że polityka podczas treningu otrzymuje obserwacje, które nie odpowiadają warunkom wdrożenia. Fizyczny pomiar FOV i odległości dla każdej kamery eliminuje to źródło błędu sim-to-real przed rozpoczęciem treningu.

Co będzie w Tygodniu 2? Tydzień 2 zdefiniuje trzy komponenty środowiska zadania RL: przestrzeń akcji, przestrzeń obserwacji i funkcję nagrody. Te decyzje projektowe determinują jakość i transferowalność wynikowej polityki.