xBerry LeRobot Tydzień 3: RGB vs RGBD – 60 prób, jeden zaskakujący wynik
Przeprowadziliśmy 60 fizycznych prób ewaluacyjnych, żeby sprawdzić, czy dodanie danych głębi do polityki ACT faktycznie poprawia wyniki. Na pozycji 5 model z głębią zdał egzamin raz na 5 prób. Model wyłącznie RGB zdał 4 razy na 5.
TL;DR
Porównaliśmy dwie polityki ACT na fizycznym ramieniu SO-101: jedną wytrenowaną na 4 kamerach RGB, drugą na tych samych kamerach plus 2 strumieniach głębi z RealSense. W 60 próbach rozłożonych na 6 pozycji startowych RGB osiągnęło 50,0%, RGBD 43,3%. Głębia pomogła znacząco w strefach, gdzie sensory miały bezpośredni widok na obiekt, i aktywnie zaszkodziła tam, gdzie głębokościomierze nie mogły niezawodnie odczytać pozycji piłki. Wniosek: dane głębi to poprawa warunkowa, a nie automatyczna.
Hipoteza, którą testowaliśmy
Co to jest RGBD? Jest to format wejściowy kamery łączący standardowe dane RGB z kanałem głębi z sensora takiego jak Intel RealSense, dający modelowi przestrzenną informację o odległości dla każdego piksela.
Po wytrenowaniu obu wariantów modelu w tygodniu 2 nadszedł czas weryfikacji: czy dodatkowe dane z sensorów naprawdę czyniły robota skuteczniejszym. Intuicja za RGBD jest przekonująca: strumień głębi daje modelowi poczucie przestrzeni trójwymiarowej zamiast płaskiego koloru, co powinno pomóc w ocenie odległości do chwytu i kąta podejścia. Nasze stanowisko korzystało z dwóch kamer Intel RealSense (D435 i D455), które obok standardowego obrazu kolorowego dostarczały mapy głębi ze wszystkich 4 kamer.
Pytanie było proste: czy bogatsze wejście przełoży się na lepszą politykę manipulacyjną?
Ewaluacja na fizycznym sprzęcie
Skoro oba modele były wytrenowane i zapisane w HuggingFace Hub, kolejnym krokiem była ewaluacja fizyczna na ramieniu SO-101. Użyliśmy eval_policy.py, skryptu ewaluacyjnego LeRobot, który ładuje wytrenowaną politykę, uruchamia ją bezpośrednio na robocie, rejestruje sukces lub porażkę dla każdego epizodu i zapisuje wyniki do datasetu.
eval_policy.py: skrypt LeRobot do uruchamiania wytrenowanej polityki na fizycznym robocie, rejestrowania wyników epizod po epizodzie i przesyłania ich do datasetu na HuggingFace Hub.
Przeprowadziliśmy dwie sesje ewaluacyjne: jedną dla modelu RGBD i jedną dla modelu wyłącznie RGB. Wariant RGBD ładuje wszystkie 6 strumieni kamer (4 kolorowe + 2 głębokościowe) wraz z pipeline’em filtrowania głębi (filtr decimation, disparatity, spatial, temporal i hole-filling). Wariant RGB-only używa flagi –rgb-only, która uruchamia kamery RealSense w trybie wyłącznie kolorowym, pomija inicjalizację pipeline’u głębi i skraca czas startu sesji.
Komenda ewaluacji RGBD:
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
Komenda ewaluacji RGB-only:
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
Flaga –resume, użyta tylko w sesji RGBD, pozwala skryptowi wykryć istniejący lokalny dataset i kontynuować od ostatnio zapisanego epizodu po przerwie.
Sukces definiowaliśmy jako chwycenie piłki i odłożenie jej do pojemnika w ciągu 30 sekund epizodu.
Każdą pozycję startową testowaliśmy 5 razy, co dało 30 prób na wariant modelu i 60 prób łącznie.
Sprawdź również: Jak trenowaliśmy modele RGB i RGB+głębia.
Wyniki: głębia wygrywa w jednych strefach, przegrywa dotkliwie w innych
Liczby zbiorcze sugerują, że RGB wygrało. Ale rozbicie na pozycje ujawnia znacznie ciekawszą historię.
| Pozycja startowa | RGB sukcesy | Skuteczność RGB | RGB-D sukcesy | Skuteczność RGB-D |
|---|---|---|---|---|
| Indeks 0 | 2/5 | 40% | 5/5 | 100% |
| Indeks 1 | 2/5 | 40% | 1/5 | 20% |
| Indeks 2 | 3/5 | 60% | 4/5 | 80% |
| Indeks 3 | 1/5 | 20% | 1/5 | 20% |
| Indeks 4 | 3/5 | 60% | 1/5 | 20% |
| Indeks 5 | 4/5 | 80% | 1/5 | 20% |
| Łącznie | 15/30 | 50.0% | 13/30 | 43.3% |
Pozycje 0 i 2 leżą bezpośrednio w optymalnym polu widzenia Kamery 2 (RealSense D435). Na tych pozycjach RGBD osiągnęło odpowiednio 100% i 80%, podczas gdy RGB: 40% i 60%. Gdy sensor głębi ma czysty, niezakłócony widok na obiekt, jego estymaty odległości są precyzyjne i model korzysta z nich efektywnie.
Pozycja 5 to krawędź stanowiska roboczego, daleko od Kamery 2 i pod niekorzystnym kątem względem Kamery 3. Tam RGBD osiągnęło 20%, a RGB 80%. Model z głębią zawodził cztery razy częściej.
Dlaczego głębia zawiodła na krawędzi stanowiska
Okluzja: stan, w którym obiekt wypada poza bezpośrednią linię widzenia sensora, zasłonięty przez inny element lub ustawiony pod kątem, przy którym wiązka sensora nie dociera do niego skutecznie.
Pozycja 5 umieszczała piłkę w strefie, gdzie kamery RealSense mają problem z niezawodnym odczytem. Na tej geometrii obraz głębi jest szumowy lub niekompletny: piłka zlewa się z tłem zamiast rejestrować jako wyraźna powierzchnia w mierzalnej odległości.
Drugim prawdopodobnym czynnikiem jest kalibracja ręka-oko. Kalibracja ręka-oko (hand-eye calibration): proces wyrównania układu współrzędnych kamery z układem końcówki robota (end-effector), tak aby “to, co kamera widzi na tych współrzędnych piksela” przekładało się poprawnie na “gdzie w przestrzeni 3D gripper powinien się przemieścić”. Błąd w tej kalibracji sprawia, że sygnał głębi wprowadza przestrzenny szum zamiast przestrzennej informacji. Model RGB-only nigdy nie napotyka tego szumu, bo w ogóle nie konsumuje danych głębi.
Dlaczego to ważne: Dodanie większej liczby sensorów do robota nie daje automatycznie lepszej polityki. Każdy sensor wnosi użyteczne dane wyłącznie w określonym oknie percepcyjnym wyznaczonym przez jego fizyczne umiejscowienie i jakość kalibracji. Poza tym oknem sensor może wprowadzać szum, z którym prostszy model nigdy by się nie spotkał.
Co to oznacza dla projektowania sensoryki?
Model RGB generalizował równomierniej po wszystkich pozycjach właśnie dlatego, że nie miał zlokalizowanego trybu awaryjnego. Kamera kolorowa pokrywa całe stanowisko z mniej więcej jednorodną jakością. Sensor głębi ma wzorzec pokrycia zależny od geometrii i każda strefa poza optymalnym zasięgiem staje się obciążeniem dla modelu wytrenowanego na ufaniu danym głębokościowym.
Dwa kierunki warte eksploracji: selektywne maskowanie głębi (dynamiczne wyłączanie wejścia głębokościowego dla epizodów, gdzie pozycja startowa wypada poza niezawodną strefę sensora, tak aby polityka wracała do zachowania RGB na krawędziach) oraz ukierunkowane zbieranie danych (rejestrowanie dodatkowych epizodów treningowych specyficznie z pozycji brzegowych i trening dedykowanej polityki na danych głębi z tych stref, zamiast stosować jeden model jednorodnie na całym stanowisku).
Co dalej?
Co to jest IsaacSim? Jest to symulator fizyczny NVIDIA do robotyki, który pozwala trenować polityki robotyczne w środowisku wirtualnym przed przeniesieniem ich na fizyczny sprzęt.
W przyszłym tygodniu przechodzimy do symulacji. Planujemy wytrenować politykę w IsaacSim, a następnie podjąć próbę transferu sim-to-real na fizyczne ramię SO-101. Otwartym pytaniem pozostaje, czy trening w symulacji pozwoli zamknąć lukę wydajności na pozycjach brzegowych, gdzie fizyczne pokrycie sensoryczne jest niedoskonałe, i jak duża część tego, czego robot nauczył się z fizycznych demonstracji, przetrwa przejście do wirtualnego środowiska treningowego.
FAQ
Czym jest eval_policy.py w LeRobot?
eval_policy.py to skrypt ewaluacyjny LeRobot, który uruchamia wytrenowaną politykę bezpośrednio na fizycznym robocie, rejestruje sukces lub porażkę w każdym epizodzie i zapisuje wyniki do datasetu na HuggingFace.
Dlaczego model RGBD wypadł gorzej niż RGB?
Model RGBD przewyższał RGB tylko na pozycjach, gdzie kamery RealSense miały bezpośredni widok na obiekt (pozycje 0 i 2). W strefach brzegowych, gdzie odczyty głębi były szumowe lub niekompletne, RGBD osiągał znacząco gorsze wyniki, co obniżyło jego ogólną skuteczność do 43,3% wobec 50,0% RGB.
Czym jest kalibracja ręka-oko w robotyce?
Kalibracja ręka-oko to proces dokładnego wyrównania układu współrzędnych kamery z układem końcówki robota, tak żeby robot mógł poprawnie tłumaczyć to, co widzi kamera, na fizyczne cele ruchu grippera.
Czym jest transfer sim-to-real?
Transfer sim-to-real to technika polegająca na trenowaniu polityki robotycznej w symulatorze fizycznym, a następnie wdrożeniu jej na fizycznym robocie, co ogranicza koszty i ryzyko treningu bezpośrednio na sprzęcie.
Czy dane głębi zawsze poprawiają polityki manipulacyjne robota?
Dane głębi poprawiają polityki manipulacyjne tylko w strefach stanowiska, gdzie sensor głębi ma niezawodną linię widzenia do obiektu. W strefach poza optymalną geometrią sensora dane głębi mogą wprowadzać szum obniżający skuteczność w porównaniu do prostszych modeli RGB-only.
Co robi flaga –rgb-only w eval_policy.py LeRobot?
Flaga –rgb-only w eval_policy.py LeRobot poleca skryptowi uruchomienie kamer RealSense wyłącznie w trybie kolorowym, pomijając pipeline głębi. Skraca to czas startu i ładuje tylko 4 strumienie RGB zgodne z wejściem użytym podczas treningu modelu RGB, zapewniając dokładne odwzorowanie warunków ewaluacji.
