SDK dla robotów, ROS 2 i środowiska symulacyjne

Platforma robotyczna roku 2026 — humanoid albo czworonóg — przychodzi z trzema warstwami oprogramowania, z którymi trzeba sobie poradzić, zanim uruchomi się choć linijkę własnego kodu. SDK producenta, które rozmawia z przegubami. Nakładka ROS 2, która rozmawia z całą resztą. Oraz symulator, bo wpuszczenie Unitree G1 EDU za 43 tys. dolarów w ścianę to kosztowny sposób na debugowanie literówki.

Te trzy warstwy nie są wymienne. SDK działa w czasie rzeczywistym i jest zamknięte. ROS 2 to lingua franca, dzięki której reszta światowego kodu robotycznego współpracuje z daną platformą. Symulator to miejsce na pracę, której nie chce się wykonywać na prawdziwym robocie — uczenie przez wzmacnianie, generowanie danych na dużą skalę, projektowanie scen, bezgłowe CI. Większość zespołów inwestuje w te trzy obszary zbyt mało.

Ten artykuł pokazuje, co każda z warstw naprawdę daje w 2026 roku, gdzie przebiegają granice i które kombinacje warto postawić w ramach realnego budżetu laboratorium robotycznego. Platformami referencyjnymi są te z R01 i R02. Referencyjną mocą obliczeniową jest linia Kentino AI (4× lub 8× RTX 5090 albo RTX Pro 6000 Blackwell, host EPYC lub Xeon).

Warstwa SDK — co naprawdę dostarczają producenci

Każdy liczący się producent robotów dostarcza Software Development Kit. Nazwa jest ta sama, zawartość już nie. Oto, co naprawdę znajduje się w pudełku.

Dwa podziały mają większe znaczenie niż wszystkie pozostałe.

Otwarte kontra zamknięte. Unitree, Booster, EngineAI i DeepRobotics dają dostęp na poziomie przegubów. Komendy momentu obrotowego można wysyłać prosto do siłowników z częstotliwością od 500 Hz do 1 kHz. Dokładnie tego wymaga wdrażanie polityk RL, własne badania nad lokomocją i wszystko, co dynamiczne. Boston Dynamics i ANYbotics trzymają sterowanie przegubami zamknięte — udostępniają prymitywy wysokopoziomowe (idź tutaj, wejdź na to, chwyć tamto), SDK wystawia je jako wywołania RPC, a pracę na przegubach wykonuje kontroler producenta. To świadomy wybór. Zamknięty stos jest bardziej niezawodny, a oprogramowanie autonomii to właśnie to, za co płaci się od 74 tys. do 200 tys. dolarów. To jednocześnie niewłaściwy stos, jeśli badania dotyczą sterowania niskopoziomowego.

Czas rzeczywisty albo nie. Unitree SDK2 wykorzystuje Cyclone DDS na dedykowanym interfejsie sieciowym i zapewnia podmilisekundowy czas obiegu w pętli przegubów. Stos Boostera działa podobnie. Spot SDK to gRPC po HTTP/2 — w sam raz do zlecania zachowań, bezużyteczne do zamykania pętli sterowania przy 1 kHz. Jeśli praca wymaga pętli poniżej 2 ms, architektura znaczy więcej niż język.

Słowo o Pythonie. Każdy producent oferuje wiązania Pythona. W żadnym z nich nie działa jednak sama pętla sterowania. Wzorzec w całej branży jest identyczny: C++ do kontrolera czasu rzeczywistego, Python do wszystkiego powyżej. SDK producentów to odzwierciedlają: wiązania C++ udostępniają więcej, działają szybciej i to w nich napisane są firmowe przykłady. Wiązania Pythona są pełnoprawne w pracy wysokopoziomowej, a w ścieżce niskopoziomowej stanowią jedynie nakładkę. C++ wybiera się do pisania wewnętrznej pętli sterowania, a Python do orkiestracji, spinania percepcji i integracji z serwerem inferencyjnym.

ROS 2 — dlaczego wszyscy się do niego sprowadzają

Natywne SDK daje dostęp do robota. ROS 2 daje dostęp do ekosystemu.

Są trzy powody, dla których każda poważna integracja ostatecznie mówi w ROS 2, nawet gdy SDK producenta w zupełności wystarcza:

1. Interoperacyjność. Stos percepcji, SLAM, nawigacja, planer manipulacji, teleoperacja — wszystkie mają implementacje w ROS 2 utrzymywane przez setki współtwórców. Żadna z nich nie mówi natywnie w formacie topiców DDS Unitree. Wystarczy raz opakować SDK w komunikaty ROS 2, a otwiera się cały ekosystem.
2. Floty wielu producentów. W dniu dołączenia drugiego robota od innego producenta podejście oparte na natywnym SDK się rozpada. ROS 2 to jedyna abstrakcja, która pozwala, by Spot, ANYmal i G1 korzystały z tego samego serwera map, tego samego grafu zadań i tego samego interfejsu człowiek–maszyna.
3. Rekrutacja. Ludzie znają ROS 2. Nie znają konwencji nazewnictwa topiców DDS Unitree. Zespół budujący na ROS 2 może rekrutować z globalnej puli. Zespół budujący na zamkniętym stosie — nie.

Stan dystrybucji ROS 2, maj 2026:

Uczciwa ocena. Wdrożenia produkcyjne nadal działają dziś na Humble. To właśnie w Humble celują producenci — unitree_ros2 od Unitree, stos Boostera, społecznościowy spot_ros2 oraz grid_map od ANYbotics mają stabilne gałęzie dla Humble. Nowe projekty powinny startować na Jazzy: ma jeszcze trzy lata wsparcia LTS, a narzędzia migracyjne są dojrzałe. Lyrical Luth jest zbyt świeże, by na nie stawiać — przed uruchomieniem na nim systemu produkcyjnego warto poczekać do końca 2026 roku.

Przy projekcie startującym w maju 2026 wyborem jest Jazzy. Przy rozbudowie projektu rozpoczętego w 2023 roku warto zostać przy Humble do czasu, aż kolejny zakup robota wymusi migrację. Iron i Kilted należy pominąć w całości; wydania bez LTS są dla tych, którzy chcą na bieżąco śledzić aktualizacje Gazebo Harmonic i godzą się na koszt utrzymania.

Podział pętli sterowania

To decyzja architektoniczna, która zaskakuje większość zespołów.

Podział pętli sterowania: na dole warstwa SDK w C++ działająca w czasie rzeczywistym, u góry orkiestracja w Pythonie w ROS 2, połączone komunikatami stanu DDS z częstotliwością 10–50 Hz.

Pętla sterowania zostaje na robocie, w C++. Warstwa wysokopoziomowa działa w węzłach ROS 2 — albo na procesorze aplikacyjnym robota (Jetson Orin AGX), albo, przy cięższych zadaniach, na zewnętrznym serwerze inferencyjnym (zob. I01). Obie warstwy komunikują się z częstotliwością 10–50 Hz po DDS. Nie dzielą jednego procesu.

Ten podział nie jest opcjonalny. Węzeł ROS 2 w Pythonie nie zamknie pętli przegubów przy 1 kHz — uniemożliwia to już sam odśmiecacz pamięci. Próby tego dokonania to najczęstszy błąd pierwszego roku pracy z humanoidami. SDK producenta istnieje właśnie po to, by nie było takiej potrzeby.

Kiedy symulator jest potrzebny (a kiedy nie)

Symulator jest niezbędny przy czterech rodzajach pracy:

• Uczenie przez wzmacnianie. Polityki lokomocji nie da się wytrenować od zera na prawdziwym robocie. Robot by się zepsuł, trener by odszedł, a koszt byłby absurdalny. RL dzieje się w symulacji — miliony epizodów, tysiące środowisk równolegle.
• Generowanie danych na dużą skalę. Dane syntetyczne do fine-tuningu modeli VLM, rozumienia scen i chwytów manipulacyjnych. Najbardziej zaawansowane zespoły (R09) generują w ciągu nocy setki tysięcy oznaczonych scen.
• Bezgłowe CI. Każdy push do gita powinien potwierdzać, że robot nadal chodzi. Na sprzęcie jest to niepraktyczne. Nocny przebieg symulacji sprawdzający stos lokomocji i percepcji — już tak.
• Projektowanie środowiska. Rozplanowanie magazynu, gniazda produkcyjnego czy laboratorium — wiedza o tym, czy robot się w nim poruszy, zanim zostanie zbudowane.

Symulator nie jest potrzebny do:

• Wczesnego prototypowania. Przy demie w stylu „niech robot pomacha” symulator to zbędny narzut. Lepiej użyć prawdziwego robota.
• Prostej manipulacji. Podniesienie pudełka, otwarcie szuflady. Różnica między symulacją a rzeczywistością jest w tych zadaniach często kosztowniejsza niż czas poświęcony na wykonanie ich na prawdziwym robocie.
• Prac nad teleoperacją. Cały sens teleoperacji polega na obecności człowieka w pętli. Symulacja tu nie pomaga.
• Zachowań jednorazowych. Wszystkiego, co uruchomi się dwa razy i wyrzuci.

Błędem zespołów jest traktowanie symulatora jako ustawienia domyślnego. Nim nie jest. To narzędzie do czterech powyższych przypadków plus oczywistego względu bezpieczeństwa: „nie chcę rozbić prawdziwego robota”.

Przegląd symulatorów na 2026 rok

W robotyce kroczącej w 2026 roku liczą się cztery symulatory. Nie są równoważne, a wybór między nimi jest kwestią przekonań.

Liczby w kolumnie środowisk równoległych są praktyczne, nie teoretyczne. Zależą od złożoności modelu. Ramię Franka osiąga wyższe wartości równoległości niż humanoid o 41 stopniach swobody z precyzyjnymi dłońmi.

Isaac Sim i Isaac Lab — zakład NVIDII

Isaac Sim to fotorealistyczny, akcelerowany przez GPU symulator zbudowany na stosie Omniverse. Isaac Lab to framework uczenia robotów osadzony na nim. Razem stanowią odpowiedź NVIDII na każde pytanie o symulację w robotyce.

Mocne strony:

• Renderowanie fotorealistyczne. Oświetlenie śledzone promieniami, wierne materiały, modele rzeczywistych kamer. Jeśli stos percepcji musi nauczyć się, jak świat naprawdę wygląda, to jedyny symulator, który dostarcza tego na dużą skalę.
• Fizyka akcelerowana przez GPU. Środowiska równoległe rezydują w pamięci GPU. Pojedyncza RTX 5090 obsługuje tysiące instancji humanoida przy setkach kroków fizyki na sekundę.
• Isaac Lab. Przejrzysty framework RL z wbudowanym wsparciem dla RSL RL, RL-Games, SKRL i Stable Baselines3. Ponad 16 gotowych modeli robotów obejmuje G1, H1, Spot, ANYmal, Franka oraz rosnącą listę nowości.
• Integracja z GR00T. To tutaj żyje stos modeli fundamentowych NVIDII dla humanoidów. Do trenowania polityki typu vision-language-action i wdrażania jej na wielu platformach to właściwa ścieżka.

Słabe strony:

• Uciążliwa konfiguracja Omniverse. Środowisko Omniverse jest narzucające, ciężkie i nieprzyjazne domyślnej instalacji Ubuntu. Przed pierwszą uruchomioną symulacją trzeba liczyć się z dniem walki z launcherem, serwerem Nucleus i pamięcią podręczną zasobów.
• Zależność od GPU. Isaac Sim nie działa na CPU. Nie działa też dobrze na pojedynczej 4090. Konfiguracja referencyjna to minimum 5090, najlepiej Pro 6000 Blackwell, oraz host EPYC dostarczający dane.
• Narzucone wybory. Formatem zasobów jest USD. Fizyką jest PhysX. Renderowaniem jest RTX. Kto chce innego silnika fizyki, trafił do niewłaściwego symulatora.

Realia obliczeniowe. Serwer Kentino AI z 4× RTX 5090 bez trudu prowadzi trening humanoida w Isaac Lab — 4,000–8,000 środowisk równoległych, pełny fotorealizm przy renderowaniu 30–60 FPS, zbieżność polityki w zadaniu lokomocji w 6–24 godziny. Przy 8× 5090 skaluje się szerzej albo prowadzi kilka eksperymentów równolegle. Pro 6000 Blackwell to właściwy wybór, gdy wiążącym ograniczeniem jest pamięć (duże partie danych, obszerniejsze biblioteki zasobów humanoidów).

MuJoCo i MJX — odpowiedź stawiająca na fizykę

MuJoCo to symulator fizyki od DeepMind. MJX to przepisana wersja XLA / JAX, która uruchamia MuJoCo na GPU z pełnym przetwarzaniem wsadowym. MJWarp to nowsze wspólne przedsięwzięcie NVIDII i Google, w którym MuJoCo napisano w Warp — skaluje się lepiej w scenach bogatych w kontakty.

Mocne strony:

• Szybkość. Czysta fizyka ciał sztywnych z bogatymi kontaktami, napisana od podstaw pod GPU. Na pojedynczej RTX 5090 MJX obsługuje tysiące środowisk humanoidalnych z liczbą kroków fizyki na sekundę, której Isaac Sim nie dorównuje przy tej samej złożoności sceny.
• Determinizm. To samo ziarno, ta sama trajektoria. Odtwarzalne RL to zaleta.
• Wsparcie DeepMind. Każda ważna publikacja robotyczna DeepMind z ostatnich pięciu lat korzysta z MuJoCo. Biblioteki modeli (MuJoCo Menagerie) obejmują G1, H1, Spot, ANYmal, ramię Franka i Shadow Hand.
• Prostota. Bez Omniverse, bez USD, bez Nucleusa. Instalacja przez pip i start.

Słabe strony:

• Renderowanie. Renderer MuJoCo pochodzi z epoki OpenGL. Wystarcza do wizualizacji, nie nadaje się do fotorealistycznego generowania danych.
• Ekosystem zasobów. Mniejszy niż w Isaacu. Import URDF działa, ale dopracowanie jest słabsze.
• Modele czujników. Modele kamery, głębi i LiDAR-u są podstawowe. Jeśli polityka zależy od realistycznego szumu czujników, trzeba te modele zbudować samodzielnie.

Realia obliczeniowe. Pojedyncza RTX 5090 obsługuje 4,000–16,000 równoległych środowisk humanoidalnych MJX, zależnie od złożoności kontaktów. Serwer Kentino AI z 4× 5090 potrafi prowadzić ponad 50,000 środowisk humanoidalnych równolegle na potrzeby RL lokomocji. To właśnie ta arytmetyka sprawia, że DeepMind i większość laboratoriów akademickich używa MuJoCo w wewnętrznej pętli treningu polityk.

Gazebo Harmonic — natywny dla ROS 2

Gazebo to otwartoźródłowy symulator, który od dwóch dekad jest domyślnym wyborem dla ROS. Gazebo Harmonic to bieżące wydanie LTS i bezproblemowo łączy się z ROS 2 Humble oraz Jazzy.

Mocne strony:

• Integracja z ROS 2. Pierwszorzędna. Dzięki mostowi ros_gz węzły ROS 2 działają w symulacji bez żadnych zmian.
• Otwartość i brak opłat. Bez licencji, bez Omniverse, bez zależności od NVIDII. Działa na CPU, na kartach AMD, na czymkolwiek.
• Właściwy do testów integracyjnych. Gdy celem jest „sprawdzenie, czy stos nawigacji i planer nadal działają po refaktoryzacji”, Gazebo jest trafnym wyborem.

Słabe strony:

• Powolność. Jednowątkowa fizyka, domyślnie renderowanie programowe. Środowiska równoległe oznaczają uruchamianie wielu procesów Gazebo. W Gazebo nie trenuje się polityk RL, tylko je wstępnie sprawdza.
• Brak przyjaźni wobec GPU. Brak wsadowego przetwarzania na GPU. Dodanie akceleracji renderowania pomaga, ale nie zmienia fundamentalnej skalowalności.
• Większa różnica sim-to-real. Model kontaktu jest mniej rygorystyczny niż w MuJoCo, a modele czujników mniej realistyczne niż w Isaacu.

Realia obliczeniowe. Gazebo działa na tym, co akurat jest pod ręką. Serwer Kentino AI to dla niego przesada. Laptop w zupełności wystarczy. Kompromis polega na tym, że przy jakimkolwiek nietrywialnym obciążeniu RL Gazebo przestaje wystarczać w ciągu kilku dni.

Genesis — akademicki pretendent o wysokiej przepustowości

Genesis to symulator tworzony przez wiele instytucji, który pojawił się pod koniec 2024 roku ze śmiałymi deklaracjami wydajności i od tego czasu większość z nich potwierdził. Swój wkład wniosły CMU, Stanford, MIT CSAIL, NVIDIA i Tsinghua.

Mocne strony:

• Przepustowość. Genesis osiąga ponad 40 milionów FPS na pojedynczej RTX 4090 przy zadaniu kinematyki odwrotnej dla ramienia Franka. Dla humanoidów wynik jest niższy, ale nadal liczony w milionach. Architektura od początku powstała wokół masowo równoległej symulacji.
• Multifizyka. Ciała sztywne, ciecze, ciała miękkie, materiały sypkie, MPM. Jeśli zadanie obejmuje coś innego niż kontakt ciał sztywnych (manipulacja obiektami odkształcalnymi, przelewanie cieczy, interakcja z materiałem sypkim), Genesis jest jedynym symulatorem z tej listy, który obsługuje to natywnie.
• Generatywne narzędzia scen. Genesis dostarcza generowanie scen sterowane promptem. Opis środowiska w tekście zamienia się w gotową scenę.

Słabe strony:

• Młodszy ekosystem. Mniej gotowych modeli, mniej poradników, mniejsza społeczność niż przy MuJoCo czy Isaacu.
• Mniej sprawdzony w transferze sim-to-real. Fizyka jest szybka; czy przenosi się na sprzęt równie dobrze jak w MuJoCo, społeczność dopiero ustala.
• Luki w dokumentacji. Typowe dla szybko ewoluujących projektów badawczych.

Gdzie pasuje w 2026 roku. Genesis to trafny wybór przy akademickim RL, gdy zależy nam na maksymalnej przepustowości środowisk i jesteśmy gotowi napisać więcej własnego kodu spajającego. Do produkcyjnego potoku sim-to-real bezpieczniejszym wyborem pozostaje dziś MuJoCo albo Isaac. Warto obserwować rozwój sytuacji.

Realia sim-to-real, edycja 2026

Praktyczny stan transferu sim-to-real, maj 2026:

• Randomizacja domeny jest obowiązkowa. Nie da się trenować na jednym zestawie parametrów fizycznych i liczyć na transfer. Masa, tarcie, opóźnienia silników, szum czujników, latencja — wszystko to podlega podczas treningu losowaniu z zadanego zakresu.
• Opóźnienie akcji znaczy więcej, niż się przyznaje. Siłowniki prawdziwego robota mają 5–25 ms opóźnienia od komendy do momentu obrotowego. Symulacja bez tego opóźnienia daje polityki, które na sprzęcie oscylują. Opóźnienie trzeba wbudować w symulację od pierwszego dnia.
• Szum czujników trzeba wstrzyknąć. Dryf IMU, szum kamery, przerwy w odczytach czujnika głębi. Publikacje z 2026 roku, które działają, uwzględniają to wszystko w treningu.
• Trening w wielu symulatorach to najnowsza granica. PolySim i podobne frameworki trenują równocześnie w MuJoCo, Isaacu, a czasem i Gazebo. Wczesne wyniki są dobre. Koszt obliczeniowy to 2–3× trening w jednym symulatorze.
• Ruch humanoida pod dużym obciążeniem wciąż sprawia trudność. Przenoszenie ładunku, odzyskiwanie równowagi po popchnięciu z ładunkiem w rękach — na platformach z R01 wyniki nadal spadają o 50–80% przy przejściu z symulacji do rzeczywistości.

Należy założyć, że dwie trzecie wydajności w świecie rzeczywistym pochodzić będzie z symulacji. Ostatnia trzecia część to dostrajanie na sprzęcie, identyfikacja systemu i uparte debugowanie.

Konkretny przepis: G1 + ROS 2 Humble + Isaac Lab na serwerze Kentino AI

Sprzęt:
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 DOF)
  - Kentino AI 256 Turin Dual / 4× RTX 5090 / 1× RTX Pro 6000 Blackwell
    (Pro 6000 do symulacji, karty 5090 do wsadowego treningu polityk)
  - punkt dostępowy Wi-Fi 6E, w zasięgu wzroku obszaru roboczego
  - przełącznik 10 GbE, połączenie kablowe z Kentino AI do AP

Oprogramowanie na serwerze Kentino AI:
  - Ubuntu 22.04, CUDA 13, Docker
  - Isaac Sim 5.x + Isaac Lab (środowisko Omniverse, lokalny Nucleus)
  - ROS 2 Humble (albo Jazzy, przy starcie od zera dzisiaj)
  - PyTorch 2.x, JAX, RSL RL
  - vLLM serwujący model VLM do percepcji wysokopoziomowej (zob. I02)
  - MuJoCo + MJX jako drugi symulator, do walidacji krzyżowej

Oprogramowanie na G1:
  - Unitree SDK2 (pętla sterowania przegubami w C++)
  - unitree_ros2 (Humble) na Jetsonie
  - własne węzły ROS 2: command_router, perception_relay
  - klient gRPC do vLLM na serwerze Kentino AI

Przebieg pracy:
  1. Trening polityki lokomocji lub całego ciała w Isaac Lab na
     Pro 6000 (ponad 4,000 równoległych instancji G1, RSL RL).
  2. Walidacja polityki w MJX (wsadowo na 4× 5090) z różnymi
     ziarnami randomizacji domeny.
  3. Wdrożenie polityki przez TorchScript na Jetsona w G1, opakowane
     w węzeł ROS 2 wywoływany przez pętlę sterowania Unitree SDK2.
  4. Wysokopoziomowe komendy ROS 2 płyną z grafu zadań laboratorium
     przez command_router do polityki.
  5. Ciężka percepcja (VLM) działa na serwerze Kentino AI, dostępna przez
     Wi-Fi 6E + gRPC.

Całkowity czas uruchomienia dla zespołu z wcześniejszym doświadczeniem w ROS 2 to dwa do trzech tygodni. Dla zespołu uczącego się ROS 2 od zera — dwa do trzech miesięcy. Warto to uwzględnić w planach. Strona obliczeniowa, czyli serwer Kentino AI, jest łatwiejszą częścią.

Uczciwa ocena

Trzy opinie, wprost:

1. ROS 2 to właściwa warstwa abstrakcji. Natywne SDK są konieczne, ale niewystarczające. Warto budować na nakładce ROS 2 i traktować SDK producenta jako usługę, z której ta nakładka korzysta. Pójście w rozwiązanie zamknięte nic nie daje, a kosztuje resztę ekosystemu.
2. Isaac Sim to przyszłość, ale teraźniejszością dla większości zespołów jest MuJoCo + ROS 2. Przy pracy nad RL w lokomocji i precyzyjnej manipulacji MuJoCo / MJX jest tańszym, szybszym i łatwiejszym we wdrożeniu wyborem. Przy fotorealistycznej percepcji, generowaniu danych na dużą skalę lub dostrajaniu modeli fundamentowych typu VLA jedynym wyborem jest Isaac. Większość laboratoriów potrzebuje obu, a serwer Kentino AI ma zapas, by obsłużyć jedno i drugie.
3. Najbardziej zaawansowane laboratoria używają wszystkich czterech. Isaac do renderowania i potoku modeli fundamentowych. MuJoCo do wewnętrznej pętli RL. Gazebo do testów integracyjnych ROS 2. Genesis do zadań multifizycznych. Udawanie, że wystarczy jeden, kończy się przepisywaniem całego stosu po roku.

---

To część Kentino Wiki — serii referencyjnej o mocy obliczeniowej dla AI, robotyce i systemach, które je łączą. Uwagi i sprostowania prosimy kierować na info@kentino.com.