Robotické SDK, ROS 2 a simulační prostředí

Robotická platforma roku 2026 — humanoidní, nebo čtyřnohá — přichází se třemi softwarovými vrstvami, které musíte vyřešit dřív, než se spustí první řádek Vašeho vlastního kódu. SDK výrobce, které mluví s klouby. ROS 2 wrapper, který mluví se vším ostatním. A simulátor, protože napálit Unitree G1 EDU za $43k do zdi je dost drahý způsob, jak odladit překlep.

Tyto tři vrstvy nejsou zaměnitelné. SDK je real-time a proprietární. ROS 2 je lingua franca, díky níž s Vaší platformou funguje i zbytek světové robotické kódové základny. Simulátor je místo, kde děláte práci, kterou na reálném robotu dělat nechcete — reinforcement learning, generování dat ve velkém, návrh scén, headless CI. Většina týmů do všech tří vrstev investuje méně, než by měla.

Tento článek prochází tím, co každá vrstva v roce 2026 skutečně nabízí, kde jsou hranice a které kombinace stojí za to postavit v rámci reálného rozpočtu robotické laboratoře. Referenční platformy jsou ty z R01 a R02. Referenční výpočetní základnou je řada Kentino AI (4× nebo 8× RTX 5090 či RTX Pro 6000 Blackwell, hostitel EPYC nebo Xeon).

Vrstva SDK — co výrobci skutečně dávají

Každý seriózní výrobce robotů dodává Software Development Kit. Název je stejný, obsah nikoli. Tady je, co je ve skutečnosti v balení.

Dva rozdíly jsou důležitější než všechny ostatní.

Otevřené vs. uzavřené. Unitree, Booster, EngineAI a DeepRobotics Vám dají přístup na úrovni kloubů. Momentové příkazy můžete posílat přímo aktuátorům na 500 Hz až 1 kHz. Přesně to potřebujete pro nasazení RL politik, vlastní výzkum chůze a cokoli dynamického. Boston Dynamics a ANYbotics drží řízení kloubů zavřené — dostanete vysokoúrovňová primitiva (dojdi sem, přelez tohle, manipuluj s tímhle), SDK je vystavuje jako RPC volání a práci s klouby odvádí vlastní kontrolér výrobce. Je to záměrné rozhodnutí. Uzavřený stack je spolehlivější a software pro autonomii je to, za co platíte $74k–$200k. Zároveň je to špatná volba, pokud Váš výzkum míří na nízkoúrovňové řízení.

Real-time, nebo ne. Unitree SDK2 používá Cyclone DDS přes vyhrazené síťové rozhraní a dává Vám na kloubové smyčce odezvu pod jednu milisekundu. Stack Boosteru je podobný. Spot SDK je gRPC přes HTTP/2 — dobré pro vyvolání chování, nepoužitelné pro uzavření řídicí smyčky na 1 kHz. Pokud Vaše práce potřebuje smyčku pod 2 ms, architektura rozhoduje víc než jazyk.

Poznámka k otázce Pythonu. Python bindingy nabízí každý výrobce. Ani v jednom případě to ale není jazyk, ve kterém běží řídicí smyčka. Vzorec je napříč oborem stejný: C++ pro real-time kontrolér, Python pro všechno nad ním. SDK výrobců to odrážejí: C++ bindingy vystavují víc, běží rychleji a jsou v nich napsané i vlastní ukázky výrobce. Python bindingy jsou plnohodnotné pro vysokoúrovňovou práci a pouhým obalem pro nízkoúrovňovou cestu. C++ volte, když píšete vnitřní řídicí smyčku, Python pro orchestraci, propojení percepce a integraci s inference serverem.

ROS 2 — proč na něj všichni nakonec přejdou

Nativní SDK Vás dostane na robota. ROS 2 Vás dostane do ekosystému.

Každá seriózní integrace nakonec mluví ROS 2, i když SDK výrobce stačí, a to ze tří důvodů:

1. Interoperabilita. Váš percepční stack, Váš SLAM, Vaše navigace, Váš plánovač manipulace, Váš teleop — všechno to má implementace v ROS 2 udržované stovkami přispěvatelů. Žádná z nich nemluví nativně formátem DDS topiců od Unitree. Obalte SDK jednou do ROS 2 zpráv a otevře se Vám celý ekosystém.
2. Flotily od více výrobců. Ve chvíli, kdy přidáte druhého robota od jiného výrobce, se přístup přes nativní SDK zhroutí. ROS 2 je jediná abstrakce, díky které mohou Spot, ANYmal a G1 sdílet stejný mapový server, stejný graf úloh a stejné rozhraní pro obsluhu.
3. Nábor lidí. ROS 2 lidé znají. Konvence pojmenování DDS topiců od Unitree neznají. Tým, který staví na ROS 2, může nabírat z celosvětového trhu. Tým, který staví na proprietárním stacku, nikoli.

Stav distribucí ROS 2, květen 2026:

Upřímné shrnutí. Produkční nasazení dnes stále běží na Humble. Humble je LTS, na kterou míří výrobci — Unitree unitree_ros2, stack Boosteru, komunitní spot_ros2, grid_map od ANYbotics — všechny mají stabilní větve pro Humble. Nové projekty by měly začínat na Jazzy: má před sebou další tři roky LTS a migrační nástroje jsou vyzrálé. Lyrical Luth je příliš čerstvá — dejte jí čas do konce roku 2026, než na ní postavíte produkční systém.

Pokud projekt startujete v květnu 2026, jděte do Jazzy. Pokud rozšiřujete projekt založený v roce 2023, zůstaňte na Humble, dokud Vás k migraci nedonutí nákup dalšího robota. Iron a Kilted přeskočte úplně; vydání bez LTS jsou pro ty, kdo chtějí těsně sledovat upgrady Gazebo Harmonic a akceptovat daň za údržbu.

Rozdělení řídicí smyčky

Tohle je architektonické rozhodnutí, které většinu týmů zaskočí.

Rozdělení řídicí smyčky: dole real-time vrstva SDK v C++, nahoře orchestrace v ROS 2 a Pythonu, propojené na 10–50 Hz stavovými zprávami přes DDS.

Řídicí smyčka zůstává na robotu v C++. Vysokoúrovňová vrstva běží v ROS 2 nodech, buď na aplikačním procesoru robota (Jetson Orin AGX), nebo — u náročnější práce — na odděleném inference serveru (viz I01). Obě vrstvy spolu komunikují na 10–50 Hz přes DDS. Nesdílejí jeden proces.

Toto rozdělení není volitelné. Python ROS 2 node nedokáže uzavřít kloubovou smyčku na 1 kHz — znemožní to už samotný garbage collector. Pokoušet se o to je nejčastější chyba prvního roku práce s humanoidy. SDK výrobce existuje přesně proto, abyste nemuseli.

Kdy simulátor potřebujete (a kdy ne)

Simulátor je povinný pro čtyři druhy práce:

• Reinforcement learning. Politiku chůze nenatrénujete od nuly na reálném robotu. Robot by se rozbil, člověk u tréninku by dal výpověď a náklady by byly absurdní. RL se dělá v simulaci — miliony epizod, tisíce prostředí paralelně.
• Generování dat ve velkém. Syntetická data pro doladění VLM, porozumění scéně, úchopy při manipulaci. Nejpokročilejší týmy (R09) vygenerují přes noc statisíce anotovaných scén.
• Headless CI. Chcete, aby každý git push ověřil, že robot pořád chodí. Na reálném hardwaru je to nepraktické. Noční běh v simulaci, který protáhne stack chůze a percepce, praktický je.
• Návrh prostředí. Rozvržení skladu, výrobní buňky, laboratoře — vědět, jestli se v nich robot dokáže pohybovat, ještě než je postavíte.

Simulátor nepotřebujete pro:

• Rané prototypování. Pokud píšete demo „ať robot zamává“, je simulátor jen režie navíc. Použijte reálného robota.
• Jednoduchou manipulaci. Zvednout krabici, otevřít zásuvku. Propast mezi simulací a realitou je u těchto úloh často větší než čas, který byste strávili prací na reálném robotu.
• Vývoj teleoperace. Celý smysl teleopu je člověk ve smyčce. Simulace tu nepomůže.
• Jednorázová chování. Cokoli, co spustíte dvakrát a pak zahodíte.

Chyba, kterou týmy dělají, je brát simulátor jako výchozí volbu. Není. Je to nástroj pro ty čtyři případy výše plus pro zřejmý bezpečnostní důvod „nechci rozbít reálného robota“.

Přehled simulátorů pro rok 2026

Pro robotiku kráčejících strojů jsou v roce 2026 podstatné čtyři simulátory. Nejsou si rovné a volba mezi nimi je názorová.

Čísla ve sloupci paralelních prostředí jsou praktická, ne teoretická. Závisejí na složitosti modelu. Rameno Franka běží ve vyšších počtech paralelních instancí než humanoid se 41 stupni volnosti a obratnýma rukama.

Isaac Sim a Isaac Lab — sázka NVIDIA

Isaac Sim je fotorealistický simulátor akcelerovaný na GPU, postavený na stacku Omniverse. Isaac Lab je framework pro učení robotů, který na něm stojí. Dohromady jsou odpovědí NVIDIA na každou otázku kolem robotické simulace.

V čem je dobrý:

• Fotorealistický rendering. Ray tracing osvětlení, věrné materiály, modely reálných kamer. Pokud se Váš percepční stack potřebuje naučit, jak svět skutečně vypadá, je to jediný simulátor, který to zvládne ve velkém.
• Fyzika akcelerovaná na GPU. Paralelní prostředí žijí v paměti GPU. Jediná RTX 5090 utáhne tisíce instancí humanoidů při stovkách fyzikálních kroků za sekundu.
• Isaac Lab. Čistý RL framework s vestavěnou podporou RSL RL, RL-Games, SKRL a Stable Baselines3. Mezi 16+ předpřipravenými modely robotů najdete G1, H1, Spot, ANYmal, Franku a další přibývající novinky.
• Integrace s GR00T. Bydlí tu stack humanoidních foundation modelů od NVIDIA. Pokud chcete natrénovat vision-language-action politiku a nasadit ji napříč platformami, vede cesta tudy.

V čem je slabý:

• Bolestivé zprovoznění Omniverse. Běhové prostředí Omniverse je názorové, těžké a k výchozí instalaci Ubuntu nepřívětivé. Počítejte s dnem bojů s launcherem, serverem Nucleus a cache assetů, než proběhne první simulace.
• Závislost na GPU. Isaac Sim na CPU neběží. Na jediné 4090 neběží dobře. Referenční sestava je 5090 jako minimum, lépe Pro 6000 Blackwell, a k tomu hostitel s EPYC, který data stihne dodávat.
• Názorový. Formát assetů je USD. Fyzika je PhysX. Rendering je RTX. Pokud chcete jiný fyzikální engine, jste ve špatném simulátoru.

Realita výpočetního výkonu. Server Kentino AI se 4× RTX 5090 utáhne trénink humanoidů v Isaac Lab bez potíží — 4,000–8,000 paralelních prostředí, plný fotorealismus při 30–60 FPS renderu, konvergence politiky pro chůzi za 6–24 hodin. S 8× 5090 škálujete do šířky nebo běžíte více experimentů naráz. Pro 6000 Blackwell je správná volba tam, kde je limitem paměť (velké batch size, rozsáhlejší knihovny humanoidních assetů).

MuJoCo a MJX — odpověď, která staví na fyzice

MuJoCo je fyzikální simulátor od DeepMind. MJX je přepis do XLA / JAX, který MuJoCo rozbíhá na GPU s plným dávkováním. MJWarp je novější společné úsilí NVIDIA a Google, které píše MuJoCo ve Warpu a lépe škáluje pro kontaktně bohaté scény.

V čem je dobrý:

• Rychlost. Čistá fyzika tuhých těles s bohatými kontakty, psaná od základu pro GPU. Na jediné RTX 5090 rozbíhá MJX tisíce humanoidních prostředí s počtem fyzikálních kroků za sekundu, na který Isaac Sim při stejné složitosti scény nedosáhne.
• Determinismus. Stejné semínko, stejná trajektorie. Reprodukovatelné RL je přednost.
• Podpora DeepMind. Každý zásadní robotický článek DeepMind za posledních pět let používá MuJoCo. Knihovny modelů (MuJoCo Menagerie) obsahují G1, H1, Spot, ANYmal, rameno Franka i Shadow Hand.
• Jednodušší. Žádný Omniverse, žádné USD, žádný Nucleus. Pip install a běží.

V čem je slabý:

• Vizuální rendering. Renderer MuJoCo je z éry OpenGL. Na vizualizaci stačí, na fotorealistické generování dat je nepoužitelný.
• Ekosystém assetů. Menší než u Isaacu. Import URDF funguje, ale výsledek není tak vyladěný.
• Modely senzorů. Modely kamery, hloubky a LiDARu jsou základní. Pokud Vaše politika závisí na realistickém šumu senzorů, budete si tyto modely stavět sami.

Realita výpočetního výkonu. Jediná RTX 5090 utáhne 4,000–16,000 paralelních humanoidních prostředí MJX podle složitosti kontaktů. Server Kentino AI se 4× 5090 zvládne pro RL chůze přes 50,000 humanoidních prostředí paralelně. Právě tahle matematika drží DeepMind i většinu akademických laboratoří u MuJoCo pro vnitřní smyčku tréninku politik.

Gazebo Harmonic — nativní ROS 2

Gazebo je open-source simulátor, který je už dvě desetiletí výchozí volbou pro ROS. Gazebo Harmonic je aktuální LTS a čistě se páruje s ROS 2 Humble a Jazzy.

V čem je dobrý:

• Integrace s ROS 2. Prvotřídní. Most ros_gz znamená, že Vaše ROS 2 nody fungují v simulaci beze změn.
• Otevřený a zdarma. Žádná licence, žádný Omniverse, žádná závislost na NVIDIA. Běží na CPU, na GPU od AMD, na čemkoli.
• Správná volba pro integrační testy. Když je cílem „ověřit, že navigační stack a plánovač po refaktoringu pořád fungují“, je Gazebo správná volba.

V čem je slabý:

• Pomalý. Jednovláknová fyzika, ve výchozím stavu softwarový rendering. Paralelní prostředí znamenají spouštět více procesů Gazeba. RL politiky v Gazebu netrénujete; jen je zběžně proklepnete.
• Nepřátelský ke GPU. Žádné dávkování na GPU. Akcelerace renderingu pomůže, ale základní škálování nezmění.
• Horší propast mezi simulací a realitou. Kontaktní model je méně přísný než u MuJoCo, modely senzorů méně realistické než u Isaacu.

Realita výpočetního výkonu. Gazebo běží na čemkoli, co máte. Server Kentino AI je na něj overkill. Stačí notebook. Daň za to je, že u jakékoli netriviální RL úlohy Gazebu během pár dní odrostete.

Genesis — akademický vyzyvatel s vysokou propustností

Genesis je simulátor z dílny více institucí, který přišel na konci roku 2024 se smělými výkonnostními tvrzeními a většinu z nich od té doby doložil. Přispěly na něj CMU, Stanford, MIT CSAIL, NVIDIA i Tsinghua.

V čem je dobrý:

• Propustnost. Genesis překonává 40 milionů FPS na jediné RTX 4090 u úlohy inverzní kinematiky ramene Franka. U humanoidů je číslo nižší, stále ale v milionech. Architektura je od začátku postavená na masivně paralelní simulaci.
• Multifyzika. Tuhá tělesa, kapaliny, měkká tělesa, granuláty, MPM. Pokud Vaše úloha zahrnuje něco jiného než kontakt tuhých těles (manipulace s deformovatelnými objekty, přelévání kapalin, práce se sypkými materiály), je Genesis jediný simulátor v tomto seznamu, který to zvládá nativně.
• Nástroje pro generování scén. Genesis přichází s generováním scén řízeným promptem. Popíšete prostředí textem a dostanete scénu.

V čem je slabý:

• Mladší ekosystém. Méně hotových modelů, méně návodů, menší komunita než u MuJoCo nebo Isaacu.
• Méně prověřený v přenosu do reality. Fyzika je rychlá; jestli se přenáší na hardware stejně dobře jako u MuJoCo, komunita teprve zjišťuje.
• Mezery v dokumentaci. Běžné u rychle se vyvíjejících výzkumných projektů.

Kam patří v roce 2026. Genesis je správná volba pro RL akademického střihu, kde chcete maximální propustnost prostředí a jste ochotni napsat si víc vlastního lepidla. Pro produkční sim-to-real pipeline je dnes bezpečnější volbou MuJoCo nebo Isaac. Sledujte ho.

Realita sim-to-real, edice 2026

Praktický stav sim-to-real, květen 2026:

• Domain randomization je povinná. Nemůžete trénovat na jediné sadě fyzikálních parametrů a čekat přenos. Hmotnost, tření, zpoždění motorů, šum senzorů, latence — to vše se během tréninku náhodně rozptyluje v určitém rozsahu.
• Na zpoždění akce záleží víc, než si lidé připouštějí. Aktuátory reálného robota mají od příkazu k momentu zpoždění 5–25 ms. Simulace běžící bez tohoto zpoždění produkuje politiky, které na hardwaru oscilují. Zpoždění zaneste do simulace hned od prvního dne.
• Šum senzorů je nutné přidat. Drift IMU, šum kamery, výpadky hloubkového senzoru. Články z roku 2026, které fungují, mají tohle všechno v tréninku.
• Trénink přes více simulátorů je nejpokročilejší směr. PolySim a podobné frameworky trénují současně napříč MuJoCo + Isaac a někdy i Gazebem. První výsledky jsou dobré. Výpočetní náklady jsou 2–3× vyšší než u tréninku v jediném simulátoru.
• Pohyb humanoida se zátěží je pořád těžký. Nesení nákladu, vyrovnání se se strčením při nesení předmětu — tohle se mezi simulací a realitou stále propadá o 50–80 % na platformách z R01.

Počítejte s tím, že dvě třetiny reálného výkonu přijdou ze simulace. A s tím, že poslední třetina bude doladění na hardwaru, identifikace systému a tvrdohlavé ladění chyb.

Konkrétní recept: G1 + ROS 2 Humble + Isaac Lab na serveru Kentino AI

Hardware:
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 DOF)
  - Kentino AI 256 Turin Dual / 4× RTX 5090 / 1× RTX Pro 6000 Blackwell
    (Pro 6000 pro simulaci, 5090 pro dávkový trénink politik)
  - Wi-Fi 6E AP, přímá viditelnost na pracovní prostor
  - 10 GbE switch, drátový spoj z Kentino AI do AP

Software na serveru Kentino AI:
  - Ubuntu 22.04, CUDA 13, Docker
  - Isaac Sim 5.x + Isaac Lab (běhové prostředí Omniverse, lokální Nucleus)
  - ROS 2 Humble (nebo Jazzy, pokud začínáte dnes na zelené louce)
  - PyTorch 2.x, JAX, RSL RL
  - vLLM obsluhující VLM pro vysokoúrovňovou percepci (viz I02)
  - MuJoCo + MJX jako druhý simulátor, pro křížovou validaci

Software na G1:
  - Unitree SDK2 (řídicí smyčka kloubů v C++)
  - unitree_ros2 (Humble) na Jetsonu
  - Vlastní ROS 2 nody: command_router, perception_relay
  - gRPC klient k vLLM na serveru Kentino AI

Postup:
  1. Natrénujte politiku chůze nebo celotělového pohybu v Isaac Lab na
     Pro 6000 (4,000+ paralelních instancí G1, RSL RL).
  2. Ověřte politiku v MJX (dávkově na 4× 5090) s různými
     semínky pro domain randomization.
  3. Nasaďte politiku přes TorchScript na Jetson v G1, obalenou
     v ROS 2 nodu, který volá řídicí smyčka Unitree SDK2.
  4. Vysokoúrovňové příkazy ROS 2 tečou z grafu úloh laboratoře
     přes command_router do politiky.
  5. Náročná percepce (VLM) žije na serveru Kentino AI, dostupná přes
     Wi-Fi 6E + gRPC.

Celková doba zprovoznění je pro tým s předchozí zkušeností s ROS 2 dva až tři týdny. Pro tým, který se ROS 2 učí od nuly, dva až tři měsíce. Podle toho plánujte. Výpočetní část na serveru Kentino AI je ta snazší.

Upřímný pohled

Tři názory, bez obalu:

1. ROS 2 je správná vrstva abstrakce. Nativní SDK jsou nutná, ale nestačí. Stavějte na ROS 2 wrapperu a SDK výrobce berte jako službu, kterou wrapper konzumuje. Odchod k proprietárnímu řešení Vám nic nepřinese a připraví Vás o zbytek ekosystému.
2. Isaac Sim je budoucnost, ale přítomnost je pro většinu týmů MuJoCo + ROS 2. Pokud děláte RL na chůzi a obratnou manipulaci, je MuJoCo / MJX levnější, rychlejší a snáze nasaditelná volba. Pokud děláte fotorealistickou percepci, generování dat ve velkém nebo doladění foundation modelů typu VLA, je Isaac jediná možnost. Většina laboratoří potřebuje obojí a server Kentino AI má rezervu na obojí naráz.
3. Nejpokročilejší laboratoře používají všechny čtyři. Isaac na rendering a pipeline foundation modelů. MuJoCo na vnitřní smyčku RL. Gazebo na integrační testy ROS 2. Genesis na multifyziku. Předstírat, že si vystačíte s jedním, je cesta, jak si po roce přepisovat celý stack.

---

Toto je součást Kentino Wiki, referenční série o AI výpočetním výkonu, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.