SDK pre roboty, ROS 2 a simulačné prostredia

Robotická platforma roku 2026 — humanoidná alebo štvornohá — prichádza s troma softvérovými vrstvami, ktoré musíte vyriešiť skôr, než sa spustí čo i len riadok vášho vlastného kódu. SDK výrobcu, ktoré hovorí s kĺbmi. Wrapper pre ROS 2, ktorý hovorí so všetkým ostatným. A simulátor, ktorý použijete preto, lebo napáliť Unitree G1 EDU za $43k do steny je drahý spôsob, ako odladiť preklep.

Tieto tri vrstvy nie sú zameniteľné. SDK je real-time a proprietárne. ROS 2 je lingua franca, vďaka ktorej s vašou platformou funguje robotický kód zvyšku sveta. Simulátor je miesto, kde robíte prácu, ktorú na skutočnom robotovi robiť nechcete — posilňované učenie, veľkoobjemové generovanie dát, návrh scén, headless CI. Väčšina tímov do všetkých troch investuje menej, než by mala.

Tento článok prechádza tým, čo jednotlivé vrstvy v roku 2026 skutočne poskytujú, kde sú ich hranice a ktoré kombinácie sa oplatí postaviť v rámci reálneho rozpočtu robotického laboratória. Referenčnými platformami sú tie z R01 a R02. Referenčným výpočtovým výkonom je rad Kentino AI (4× alebo 8× RTX 5090 či RTX Pro 6000 Blackwell, hostiteľ EPYC alebo Xeon).

Vrstva SDK — čo vám výrobcovia skutočne dajú

Každý seriózny výrobca robotov dodáva Software Development Kit. Názov je rovnaký, obsah už nie. Toto je to, čo v balení naozaj nájdete.

Dve deliace čiary sú dôležitejšie než všetky ostatné.

Otvorené vs. uzavreté. Unitree, Booster, EngineAI a DeepRobotics vám dávajú prístup na úroveň kĺbov. Môžete posielať momentové príkazy priamo do aktuátorov s frekvenciou 500 Hz až 1 kHz. Presne to potrebujete na nasadenie RL politík, na vlastný výskum lokomócie a na čokoľvek dynamické. Boston Dynamics a ANYbotics držia riadenie kĺbov zavreté — dostanete vysokoúrovňové primitíva (choď sem, vylez tam, manipuluj s týmto), SDK ich sprístupňuje ako RPC volania a prácu v kĺboch odvedie vlastný regulátor výrobcu. Je to vedomá voľba. Uzavretý stack je spoľahlivejší a autonómny softvér je to, za čo platíte $74k–$200k. Zároveň je to nesprávny stack, ak sa váš výskum týka nízkoúrovňového riadenia.

Real-time vs. nie real-time. Unitree SDK2 používa Cyclone DDS cez vyhradené sieťové rozhranie a dáva vám odozvu v kĺbovej slučke pod jednou milisekundou. Stack od Boosteru je podobný. Spot SDK beží na gRPC cez HTTP/2 — v poriadku na vyvolanie správania, nepoužiteľné na uzavretie riadiacej slučky pri 1 kHz. Ak vaša práca potrebuje slučku pod 2 ms, architektúra je dôležitejšia než jazyk.

Poznámka k otázke Pythonu. Väzby pre Python ponúka každý výrobca. Ani jeden z nich v tomto jazyku neprevádzkuje riadiacu slučku. Vzorec je naprieč odvetvím rovnaký: C++ pre real-time regulátor, Python pre všetko nad ním. SDK výrobcov to odzrkadľujú: väzby pre C++ sprístupňujú viac, bežia rýchlejšie a sú napísané v nich aj vlastné príklady výrobcu. Väzby pre Python sú plnohodnotné pre vysokoúrovňovú prácu a sú obalom pre nízkoúrovňovú cestu. Zvoľte C++, keď píšete vnútornú riadiacu slučku, a Python na orchestráciu, prepojenie percepcie a integráciu s inferenčným serverom.

ROS 2 — prečo sa naň všetci zjednocujú

Natívne SDK vás dostane na robota. ROS 2 vás dostane do ekosystému.

Každá serióznejšia integrácia skončí pri ROS 2 aj vtedy, keď SDK výrobcu stačí, a to z troch dôvodov:

1. Interoperabilita. Váš percepčný stack, váš SLAM, vaša navigácia, váš plánovač manipulácie, váš teleop — všetko to má implementácie v ROS 2, ktoré udržiavajú stovky prispievateľov. Ani jedna z nich natívne nehovorí formátom tém Unitree DDS. Obaľte SDK raz do správ ROS 2 a otvorí sa vám celý ekosystém.
2. Flotily od viacerých výrobcov. V deň, keď pridáte druhého robota od iného výrobcu, sa prístup cez natívne SDK zrúti. ROS 2 je jediná abstrakcia, vďaka ktorej môžu Spot, ANYmal a G1 zdieľať rovnaký mapový server, rovnaký graf úloh a rovnaké rozhranie človek – stroj.
3. Nábor. Ľudia poznajú ROS 2. Nepoznajú konvencie pomenúvania tém v Unitree DDS. Tím, ktorý stavia na ROS 2, môže naberať z globálneho trhu. Tím, ktorý stavia na proprietárnom stacku, nie.

Stav distribúcií ROS 2, máj 2026:

Úprimné zhrnutie. Produkčné nasadenia dnes stále bežia na Humble. Humble je LTS, na ktoré cielia výrobcovia — Unitree unitree_ros2, stack Boosteru, komunitný spot_ros2, ako aj grid_map od ANYbotics — všetky majú stabilné vetvy pre Humble. Jazzy je miesto, kde by mali začínať nové buildy: má pred sebou ďalšie tri roky života LTS a migračné nástroje sú vyzreté. Lyrical Luth je príliš nové na záväzok — dajte mu čas do konca roka 2026, než naň postavíte produkčný systém.

Ak začínate projekt v máji 2026, choďte do Jazzy. Ak rozširujete projekt začatý v roku 2023, zostaňte na Humble, kým vás k migrácii nedotlačí nákup ďalšieho robota. Iron a Kilted úplne preskočte; vydania mimo LTS sú pre tých, čo chcú zblízka sledovať upgrady Gazebo Harmonic a akceptujú daň za údržbu.

Rozdelenie riadiacej slučky

Toto je architektonické rozhodnutie, ktoré väčšinu tímov zaskočí.

Rozdelenie riadiacej slučky: dole real-time vrstva SDK v C++, hore orchestrácia v Pythone nad ROS 2, prepojené stavovými správami cez DDS pri 10 – 50 Hz.

Riadiaca slučka zostáva na robotovi v C++. Vysokoúrovňová vrstva beží v uzloch ROS 2, buď na aplikačnom procesore robota (Jetson Orin AGX), alebo — pri náročnejšej práci — na externom inferenčnom serveri (pozri I01). Obe vrstvy spolu hovoria pri 10 – 50 Hz cez DDS. Nezdieľajú jeden proces.

Toto rozdelenie nie je voliteľné. Uzol ROS 2 v Pythone nedokáže uzavrieť kĺbovú slučku pri 1 kHz — znemožní to už samotný garbage collector. Pokus o to je najčastejšia chyba v prvom roku práce s humanoidmi. SDK výrobcu existuje práve preto, aby ste to nemuseli riešiť.

Kedy simulátor potrebujete (a kedy nie)

Simulátor je povinný pri štyroch druhoch práce:

• Posilňované učenie. Politiku lokomócie nemôžete natrénovať od nuly na skutočnom robotovi. Robot by sa rozbil, tréner by dal výpoveď a náklady by boli obscénne. RL prebieha v simulácii — milióny epizód, tisíce prostredí paralelne.
• Veľkoobjemové generovanie dát. Syntetické dáta na doladenie VLM, porozumenie scéne, úchopy pri manipulácii. Tímy na špici (R09) vygenerujú cez noc stovky tisíc anotovaných scén.
• Headless CI. Chcete, aby každý git push overil, že robot stále chodí. Robiť to na hardvéri je nepraktické. Nočný beh v simulácii, ktorý preverí lokomočný a percepčný stack, praktický je.
• Návrh prostredia. Rozvrhnutie skladu, výrobnej bunky, laboratória — poznanie, či v ňom robot dokáže navigovať, ešte predtým, než ho postavíte.

Simulátor nepotrebujete na:

• Rané prototypovanie. Ak píšete demo „nech robot zamáva“, simulátor je réžia navyše. Použite skutočného robota.
• Jednoduchá manipulácia. Zdvihnúť škatuľu, otvoriť zásuvku. Medzera medzi simuláciou a realitou je pri týchto úlohách často väčšia než čas, ktorý by ste strávili prácou na skutočnom robotovi.
• Vývoj teleoperácie. Celý zmysel teleoperácie je človek v slučke. Simulácia tu nepomôže.
• Jednorazové správanie. Čokoľvek, čo spustíte dvakrát a potom zahodíte.

Chyba, ktorú tímy robia, je, že simulátor berú ako východiskový stav. Nie je. Je to nástroj pre štyri prípady vyššie plus zjavný bezpečnostný dôvod „nechcem rozbiť skutočného robota“.

Ponuka simulátorov v roku 2026

Pre robotiku s nohami sú v roku 2026 podstatné štyri simulátory. Nie sú rovnocenné a voľba medzi nimi je názorová.

Čísla v stĺpci s paralelnými prostrediami sú praktické, nie teoretické. Závisia od zložitosti modelu. Rameno Franka beží pri vyššom počte paralelných inštancií než humanoid so 41 stupňami voľnosti a obratnými rukami.

Isaac Sim a Isaac Lab — stávka NVIDIE

Isaac Sim je fotorealistický simulátor s akceleráciou na GPU, postavený na stacku Omniverse. Isaac Lab je framework pre učenie robotov, ktorý sedí nad ním. Spolu sú odpoveďou NVIDIE na každú otázku o simulácii v robotike.

V čom je dobrý:

• Fotorealistické vykresľovanie. Osvetlenie s trasovaním lúčov, verné materiály, modely reálnych kamier. Ak sa váš percepčný stack musí naučiť, ako svet naozaj vyzerá, toto je jediný simulátor, ktorý to dodá vo veľkom.
• Fyzika akcelerovaná na GPU. Paralelné prostredia žijú v pamäti GPU. Jediná RTX 5090 uženie tisíce inštancií humanoida pri stovkách fyzikálnych krokov za sekundu.
• Isaac Lab. Čistý RL framework so zabudovanou podporou pre RSL RL, RL-Games, SKRL a Stable Baselines3. Viac než 16 predpripravených modelov robotov zahŕňa G1, H1, Spot, ANYmal, Franka a rastúci zoznam nováčikov.
• Integrácia GR00T. Tu žije stack základových modelov pre humanoidy od NVIDIE. Ak chcete trénovať politiku typu vízia – jazyk – akcia a nasadzovať ju naprieč platformami, toto je vaša cesta.

V čom je slabý:

• Bolesť s nastavením Omniverse. Runtime Omniverse je názorový, ťažký a nekamaráti sa s predvolenou inštaláciou Ubuntu. Počítajte s dňom bojov s launcherom, serverom Nucleus a cache assetov, než vám prvá simulácia nabehne.
• Viazanosť na GPU. Isaac Sim na CPU nebeží. Na jedinej 4090 nebeží dobre. Referenčná zostava je minimálne 5090, lepšie Pro 6000 Blackwell a hostiteľ EPYC, ktorý ju nakŕmi dátami.
• Názorový. Formáty assetov sú USD. Fyzika je PhysX. Vykresľovanie je RTX. Ak chcete iný fyzikálny engine, ste v nesprávnom simulátore.

Realita výpočtového výkonu. Server Kentino AI so 4× RTX 5090 zvláda tréning humanoidov v Isaac Lab s rezervou — 4 000 až 8 000 paralelných prostredí, plný fotorealizmus pri 30 – 60 FPS vykresľovania a konvergencia politiky na lokomočnej úlohe za 6 – 24 hodín. S 8× 5090 škálujete do šírky alebo beháte viac experimentov naraz. Pro 6000 Blackwell je správna voľba vtedy, keď je limitom pamäť (veľké dávky, rozsiahlejšie knižnice humanoidných assetov).

MuJoCo a MJX — odpoveď postavená na fyzike

MuJoCo je fyzikálny simulátor od DeepMindu. MJX je prepis do XLA / JAX, ktorý beží s MuJoCo na GPU s plným dávkovaním. MJWarp je novší spoločný projekt NVIDIE a Googlu, ktorý píše MuJoCo vo Warpe a lepšie škáluje pri scénach bohatých na kontakt.

V čom je dobrý:

• Rýchlosť. Čistá fyzika tuhých telies s bohatým kontaktom, písaná od základu pre GPU. Na jedinej RTX 5090 uženie MJX tisíce humanoidných prostredí pri počte fyzikálnych krokov za sekundu, ktorému Isaac Sim pri rovnakej zložitosti scény nekonkuruje.
• Determinizmus. Rovnaký seed, rovnaká trajektória. Reprodukovateľné RL je prednosť.
• Zázemie DeepMindu. Každá väčšia robotická práca DeepMindu za posledných päť rokov používa MuJoCo. Knižnice modelov (MuJoCo Menagerie) obsahujú G1, H1, Spot, ANYmal, rameno Franka aj Shadow Hand.
• Jednoduchšie. Žiadny Omniverse, žiadne USD, žiadny Nucleus. Pip install a beží.

V čom je slabý:

• Vizuálne vykresľovanie. Renderer MuJoCo je z éry OpenGL. Na vizualizáciu postačuje, na fotoreálne generovanie dát je nepoužiteľný.
• Ekosystém assetov. Menší než pri Isaacu. Import URDF funguje, ale vycibrenosť je nižšia.
• Modely senzorov. Modely kamery, hĺbky a LiDARu sú základné. Ak vaša politika závisí od realistického šumu senzorov, budete si tie modely stavať sami.

Realita výpočtového výkonu. Jediná RTX 5090 uženie 4 000 až 16 000 paralelných humanoidných prostredí MJX podľa zložitosti kontaktov. Server Kentino AI so 4× 5090 zvládne na RL lokomócie viac než 50 000 paralelných humanoidných prostredí. Toto je matematika, pre ktorú má DeepMind a väčšina akademických laboratórií vo vnútornej slučke tréningu politík práve MuJoCo.

Gazebo Harmonic — natívny pre ROS 2

Gazebo je open source simulátor, ktorý je už dve desaťročia predvolenou voľbou pre ROS. Gazebo Harmonic je aktuálne LTS a čisto sa dopĺňa s ROS 2 Humble a Jazzy.

V čom je dobrý:

• Integrácia s ROS 2. Prvotriedna. Most ros_gz znamená, že vaše uzly ROS 2 fungujú v simulácii bez akýchkoľvek zmien.
• Otvorené a bezplatné. Žiadna licencia, žiadny Omniverse, žiadna závislosť na NVIDII. Beží na CPU, na GPU od AMD, na čomkoľvek.
• Správna voľba na integračné testy. Keď je vaším cieľom „overiť, že navigačný stack a plánovač po refaktoringu stále fungujú“, Gazebo je správna voľba.

V čom je slabý:

• Pomalé. Jednovláknová fyzika, predvolene softvérové vykresľovanie. Paralelné prostredia znamenajú spúšťanie viacerých procesov Gazeba. RL politiky v Gazebe netrénujete, len ich odskúšate.
• Nepriateľské k GPU. Žiadne dávkovanie na GPU. Pridanie akcelerácie vykresľovania pomôže, ale na základnom škálovaní to nič nezmení.
• Horšia medzera medzi simuláciou a realitou. Kontaktný model je menej prísny než v MuJoCo a modely senzorov sú menej realistické než v Isacu.

Realita výpočtového výkonu. Gazebo beží na čomkoľvek, čo máte. Server Kentino AI je naň zbytočný, postačí notebook. Kompenzáciou je, že pri akejkoľvek netriviálnej RL záťaži Gazebo prerastiete v priebehu dní.

Genesis — akademický vyzývateľ s vysokou priepustnosťou

Genesis je simulátor viacerých inštitúcií, ktorý prišiel koncom roka 2024 so smelými výkonnostnými tvrdeniami a odvtedy väčšinu z nich potvrdil. Prispeli naň CMU, Stanford, MIT CSAIL, NVIDIA aj Tsinghua.

V čom je dobrý:

• Priepustnosť. Genesis dosahuje na jedinej RTX 4090 vyše 40 miliónov FPS pri úlohe inverznej kinematiky s ramenom Franka. Pri humanoidoch je číslo nižšie, stále však v miliónoch. Architektúra je od začiatku stavaná okolo masívne paralelnej simulácie.
• Multifyzika. Tuhé telesá, tekutiny, mäkké telesá, granuláty, MPM. Ak vaša úloha zahŕňa niečo iné než kontakt tuhých telies (manipulácia s deformovateľnými objektmi, prelievanie tekutín, práca s granulátmi), Genesis je jediný simulátor z tohto zoznamu, ktorý to zvláda natívne.
• Generatívne nástroje na tvorbu scén. Genesis prichádza s generovaním scén riadeným promptom. Prostredie opíšete textom a dostanete scénu.

V čom je slabý:

• Mladší ekosystém. Menej predpripravených modelov, menej návodov a menšia komunita než pri MuJoCo či Isacu.
• Menej overené pre prenos zo simulácie do reality. Fyzika je rýchla; či sa prenáša na hardvér rovnako dobre ako pri MuJoCo, komunita ešte len preveruje.
• Medzery v dokumentácii. Bežné pri rýchlo sa vyvíjajúcich výskumných projektoch.

Kam zapadá v roku 2026. Genesis je správna voľba pre RL akademického strihu, kde chcete maximálnu priepustnosť prostredí a ste ochotní si viac lepidla napísať sami. Pre dnešný produkčný pipeline prenosu do reality je bezpečnejšia voľba MuJoCo alebo Isaac. Sledujte, ako sa to vyvinie.

Realita prenosu zo simulácie do reality, vydanie 2026

Praktický stav prenosu zo simulácie do reality, máj 2026:

• Doménová randomizácia je povinná. Nemôžete trénovať na jedinej sade fyzikálnych parametrov a čakať, že sa to prenesie. Hmotnosť, trenie, oneskorenia motorov, šum senzorov, latencia — to všetko sa počas tréningu randomizuje v rámci rozsahu.
• Oneskorenie akcie je dôležitejšie, než ľudia priznávajú. Aktuátory skutočného robota majú od príkazu po moment oneskorenie 5 – 25 ms. Simulácia, ktorá beží bez tohto oneskorenia, vytvára politiky, ktoré na hardvéri oscilujú. Zapečte oneskorenie do simulácie hneď od prvého dňa.
• Šum senzorov treba vstreknúť. Drift IMU, šum kamery, výpadky hĺbkového senzora. Práce z roku 2026, ktoré fungujú, majú toto všetko zahrnuté v tréningu.
• Tréning naprieč viacerými simulátormi je absolútna špička. PolySim a podobné frameworky trénujú súčasne naprieč MuJoCo + Isaac a niekedy aj Gazebom. Prvé výsledky sú dobré. Výpočtové náklady sú 2 – 3× vyššie než pri tréningu v jedinom simulátore.
• Pohyb ťažko zaťaženého humanoida je stále náročný. Nesenie bremena, zotavenie sa zo sotenia pri nesení nákladu — tieto úlohy sa pri prechode zo simulácie do reality stále zhoršujú o 50 – 80 % na platformách z R01.

Počítajte s tým, že dve tretiny vášho reálneho výkonu prídu zo simulácie. Počítajte s tým, že posledná tretina bude doladenie na hardvéri, systémová identifikácia a tvrdohlavé ladenie chýb.

Konkrétny recept: G1 + ROS 2 Humble + Isaac Lab na serveri Kentino AI

Hardvér:
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 DOF)
  - Kentino AI 256 Turin Dual / 4× RTX 5090 / 1× RTX Pro 6000 Blackwell
    (Pro 6000 na simuláciu, 5090 na dávkový tréning politík)
  - AP s Wi-Fi 6E, priama viditeľnosť na pracovnú plochu
  - 10 GbE switch, drôtový spoj z Kentino AI do AP

Softvér na serveri Kentino AI:
  - Ubuntu 22.04, CUDA 13, Docker
  - Isaac Sim 5.x + Isaac Lab (runtime Omniverse, lokálny Nucleus)
  - ROS 2 Humble (alebo Jazzy, ak začínate od nuly dnes)
  - PyTorch 2.x, JAX, RSL RL
  - vLLM obsluhujúci VLM pre vysokoúrovňovú percepciu (pozri I02)
  - MuJoCo + MJX ako druhá simulácia, na krížovú validáciu

Softvér na G1:
  - Unitree SDK2 (riadiaca slučka kĺbov v C++)
  - unitree_ros2 (Humble) na Jetsone
  - Vlastné uzly ROS 2: command_router, perception_relay
  - Klient gRPC k vLLM na serveri Kentino AI

Pracovný postup:
  1. Natrénujte lokomočnú alebo celotelovú politiku v Isaac Lab na
     Pro 6000 (4 000+ paralelných inštancií G1, RSL RL).
  2. Overte politiku v MJX (dávkovo na 4× 5090) s odlišnými
     seedmi doménovej randomizácie.
  3. Nasaďte politiku cez TorchScript na Jetson v G1, zabalenú
     do uzla ROS 2, ktorý volá riadiaca slučka Unitree SDK2.
  4. Vysokoúrovňové príkazy ROS 2 tečú z grafu úloh laboratória
     cez command_router do politiky.
  5. Ťažká percepcia (VLM) žije na serveri Kentino AI, dostupná cez
     Wi-Fi 6E + gRPC.

Celkový čas rozbehu pre tím s predchádzajúcou skúsenosťou s ROS 2 sú dva až tri týždne. Pre tím, ktorý sa ROS 2 učí od nuly, sú to dva až tri mesiace. Plánujte podľa toho. Výpočtová stránka servera Kentino AI je tá jednoduchšia časť.

Úprimný pohľad

Tri názory, bez okolkov:

1. ROS 2 je správna abstrakčná vrstva. Natívne SDK sú nevyhnutné, ale nestačia. Stavajte na wrapperi pre ROS 2 a SDK výrobcu berte ako službu, ktorú tento wrapper spotrebúva. Odchod do proprietárneho riešenia vám nič neprinesie a pripraví vás o zvyšok ekosystému.
2. Isaac Sim je budúcnosť, ale prítomnosťou je pre väčšinu tímov MuJoCo + ROS 2. Ak je vašou prácou RL na lokomócii a obratnej manipulácii, MuJoCo / MJX je lacnejšia, rýchlejšia a jednoduchšie nasaditeľná voľba. Ak je vašou prácou fotorealistická percepcia, veľkoobjemové generovanie dát alebo dolaďovanie základových modelov typu VLA, Isaac je jediná možnosť. Väčšina laboratórií potrebuje oboje a server Kentino AI má rezervu na to, aby zvládol oboje.
3. Laboratóriá na špici používajú všetky štyri. Isaac na vykresľovanie a pipeline základových modelov. MuJoCo na vnútornú slučku RL. Gazebo na integračné testy ROS 2. Genesis na multifyzikálnu prácu. Predstava, že si vystačíte s jedným, je presne to, prečo tímy po roku prepisujú celý svoj stack.

---

Toto je súčasť Kentino Wiki, referenčnej série o AI výpočtoch, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy uvítame na info@kentino.com.