Architektura ROS 2, NVIDIA Isaac Lab i transfer Sim-to-Real w robotach humanoidalnych

Dwuwarstwowa architektura sterowania współczesnego humanoida

Nowoczesne roboty humanoidalne (takie jak Unitree G1 EDU, H1-2, Booster T1 czy Fourier GR-2) rozdzielają architekturę obliczeniową na dwie odseparowane warstwy: niskopoziomowy kontroler czasu rzeczywistego (Low-Level Real-Time Control) oraz wysokopoziomowy komputer percepcji i planowania (High-Level AI Compute).

Warstwa niskopoziomowa komunikuje się po magistrali CAN-FD lub EtherCAT z częstością 500–1000 Hz, wymuszając zadane momenty (Torque), pozycje kątowe ($q_{des}$) i współczynniki sztywności ($K_p, K_d$) na poszczególnych aktuatorach. Warstwa wysokopoziomowa — oparta najczęściej na module NVIDIA Jetson Orin NX/AGX (100–275 TOPS) — przetwarza chmurę punktów z LiDAR-u 3D, obraz z kamer głębi oraz uruchamia modele VLA (Vision-Language-Action) przez middleware ROS 2 Humble/Jazzy (CycloneDDS).

Potok Sim-to-Real: dlaczego trenujemy w NVIDIA Isaac Lab i weryfikujemy w MuJoCo?

Bezpośrednie trenowanie algorytmów uczenia ze wzmocnieniem (Reinforcement Learning) na fizycznym robocie doprowadziłoby do jego zniszczenia w ciągu kilku minut. Standardowy potok inżynierski obejmuje trzy etapy:

• Etap 1 — Masowy trening równoległy w NVIDIA Isaac Lab (Omniverse): symulacja 4096 wirtualnych instancji robota jednocześnie na karcie GPU z zastosowaniem Domain Randomization (losowe zmiany współczynnika tarcia posadzki, masy ładunku ±15% oraz opóźnień komunikacyjnych).
• Etap 2 — Walidacja krzyżowa Sim-to-Sim w silniku MuJoCo: wyeksportowana sieć ONNX/TorchScript jest testowana w drugim, niezależnym silniku fizycznym MuJoCo w celu wykrycia artefaktów specyficznych dla symulatora.
• Etap 3 — Wdrożenie na fizycznej jednostce w uprzęży asekuracyjnej: uruchomienie węzła inferencyjnego C++/Python komunikującego się po DDS ze stopniowym zwiększaniem wzmocnienia $K_p$.

Na co zwrócić uwagę przy wyborze wersji robota pod projekty badawcze?

Uczelnie i działy R&D muszą pamiętać, że podstawowe wersje demonstracyjne (np. Unitree G1 Standard / Basic) mają zablokowany dostęp do niskopoziomowego API stawów i nie posiadają dodatkowej płyty obliczeniowej Jetson Orin. Do prac z ROS 2 i własnymi politykami RL konieczny jest wybór wariantów deweloperskich (EDU / Ultimate / Developer Edition).

Jak zorganizować repozytorium, żeby sim-to-real nie był loterią

Różnica między projektem, który przechodzi z symulacji na sprzęt w miesiąc, a tym, który utyka na kwartał, najczęściej nie leży w modelu uczenia, a w organizacji kodu. Trzy warstwy powinny być rozdzielone: opis robota i sceny (URDF, parametry fizyczne), polityka sterowania oraz interfejs sprzętowy. Jeśli parametry fizyczne są zaszyte w skrypcie treningowym, każda zmiana modelu oznacza powtórzenie eksperymentu od zera.

Druga praktyka to wersjonowanie polityki razem z konfiguracją sprzętu. Unitree G1 EDU (24 stopnie swobody, 286 500 PLN, dostępny) ma inne przełożenia i bezwładności w zależności od konfiguracji dłoni; polityka wytrenowana na jednej wersji potrafi nie działać na drugiej, mimo identycznej liczby stawów. Zapis, na jakiej konfiguracji powstał model, jest tańszy niż tydzień debugowania.

Kiedy symulacja kłamie: różnice, których nie da się wytrenować

Symulacja nie odwzorowuje trzech rzeczy, które psują wdrożenia: luzu w przekładniach, opóźnienia komunikacji i zachowania czujników przy złym oświetleniu. Model wytrenowany na idealnych danych potrafi zachowywać się poprawnie w Isaac Lab i gubić kroki na hali, gdzie LiDAR widzi odbicia od regałów, a kamera pracuje pod słońce.

Praktyczna metoda to trening z randomizacją i walidacja na sprzęcie po każdej iteracji, nie na końcu projektu. Po każdym etapie warto zapisać trzy liczby: skuteczność w symulacji, skuteczność na sprzęcie i różnicę między nimi. Jeśli różnica rośnie, problem jest w modelu rzeczywistości — nie w polityce, którą właśnie trenujesz.

Bezpieczeństwo stacku: co dzieje się, gdy sterownik traci łączność

Architektura ROS 2 opiera się na komunikacji sieciowej, a to znaczy, że awaria sieci jest normalnym scenariuszem, nie wyjątkiem. Sterownik musi mieć zdefiniowane zachowanie przy utracie łączności: zatrzymanie ruchu w bezpiecznej pozycji, wyłączenie napędów po określonym czasie i komunikat do operatora. Bez tego robot albo zastyga w ruchu, albo wykonuje ostatnie zlecenie w nieskończoność.

Warto też rozdzielić magistrale: sterowanie bezpieczeństwem (e-stop, czujniki stref) nie może biegać po tej samej sieci co logowanie i telemetria. W praktyce oznacza to osobny kontroler bezpieczeństwa, który nie zna ROS-a i nie potrzebuje go do zatrzymania maszyny — i to jest wymóg, który trzeba wpisać w specyfikację, zanim wybierzesz platformę.