SDK pro roboty, ROS 2 a simulační prostředí

Robotická platforma pro rok 2026 – ať už humanoidní nebo čtyřnohý – se dodává se třemi softwarovými příběhy, se kterými se musíte vypořádat, než se spustí jakýkoli váš vlastní kód. SDK výrobce, které komunikuje s klouby. Wrapper ROS 2, který komunikuje se vším ostatním. A simulátor, který používáte, protože narazit na zeď s Unitree G1 EDU za 43 tisíc dolarů je drahý způsob, jak odladit překlep.

Tyto tři vrstvy nejsou zaměnitelné. SDK funguje v reálném čase a je proprietární. ROS 2 je lingua franca, která umožňuje, aby zbytek robotického kódu z celého světa fungoval na vaší platformě. Simulátor je místo, kde děláte práci, kterou na skutečném robotovi dělat nechcete – posilovací učení, generování dat ve velkém měřítku, návrh scén, bezhlavou CI. Většina týmů na všechny tři vrstvy vynakládá méně prostředků.

Tento článek se zabývá tím, co každá vrstva skutečně nabízí v roce 2026, kde jsou jejich hranice a jaké kombinace se vyplatí splnit s reálným rozpočtem robotické laboratoře. Referenční platformy jsou ty, které jsou uvedeny v R01 a R02Referenčním výpočetním systémem je řada K-AI (4× nebo 8× RTX 5090 nebo RTX Pro 6000 Blackwell, EPYC nebo Xeon host).

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

Každý důvěryhodný prodejce robotů dodává sadu pro vývoj softwaru. Název je stejný, obsah nikoli. Zde je to, co je ve skutečnosti v krabici.

Dvě rozdělení jsou důležitější než zbytek.

Otevřený vs. uzavřený. Unitree, Booster, EngineAI a DeepRobotics vám poskytují přístup na úrovni kloubů. Můžete vydávat příkazy k regulaci točivého momentu o frekvenci 500 Hz až 1 kHz přímo do aktuátorů. To je přesně to, co potřebujete pro nasazení politik RL, výzkum vlastní lokomotivy a cokoli dynamického. Boston Dynamics a ANYbotics udržují řízení kloubů uzavřené – získáte primitiva na vysoké úrovni (jít sem, vylézt tam, manipulovat s tím), SDK je zpřístupní jako volání RPC a práci na kloubu vykoná vlastní řídicí jednotka společnosti. To je záměrná volba. Uzavřený stack je spolehlivější a software pro autonomii je to, za co platíte 74 000–200 000 dolarů. Je to také špatný stack, pokud je váš výzkum v nízkoúrovňovém řízení.

V reálném čase vs. ne. Unitree SDK2 používá Cyclone DDS přes vyhrazené síťové rozhraní a poskytuje submilisekundový zpáteční cyklus v rámci společné smyčky. Boosterův stack je podobný. Spot SDK je gRPC přes HTTP/2 – v pořádku pro ovládání chování, ale nepoužitelný pro uzavření řídicí smyčky na 1 kHz. Pokud vaše práce vyžaduje smyčku pod 2 ms, je architektura důležitější než jazyk.

Poznámka k otázce Pythonu. Každý dodavatel nabízí vazby Pythonu. Žádný z nich není jazykem, ve kterém běží řídicí smyčka. Vzorec v celém odvětví je stejný: C++ pro řídicí jednotku reálného času, Python pro vše nad ní. Sady SDK od dodavatelů to odrážejí: vazby C++ zpřístupňují více, běží rychleji a jsou v nich napsány vlastní příklady od dodavatele. Vazby Pythonu jsou prvotřídní pro práci na vysoké úrovni a zároveň obalují nízkoúrovňovou cestu. Při psaní vnitřní řídicí smyčky zvolte C++ a Python pro orchestraci, propojení vnímání a integraci s inferenčním serverem.

ROS 2 – proč se na něj všichni normalizují

Nativní SDK vás dostane k robotovi. ROS 2 vás dostane do ekosystému.

Existují tři důvody, proč každá seriózní integrace nakonec používá ROS 2, i když je SDK výrobce dostačující:

1. Interoperabilita. Váš percepční stack, váš SLAM, vaše navigace, váš plánovač manipulace, váš teleop – to vše má implementace ROS 2, které spravují stovky přispěvatelů. Žádný z nich nativně neumí formát tématu Unitree DDS. Stačí SDK jednou zabalit do zpráv ROS 2 a celý ekosystém se otevře.
2. Vozové parky od více dodavatelů. V den, kdy přidáte druhého robota od jiného dodavatele, se přístup s nativním SDK zhroutí. ROS 2 je jediná abstrakce, která umožňuje robotům Spot, ANYmal a G1 sdílet stejný mapový server, stejný graf úloh a stejné rozhraní člověk-stroj.
3. Najímání. Lidé znají ROS 2. Neznají však konvence pojmenování témat Unitree DDS. Tým, který staví na ROS 2, si může najmout zaměstnance z globálního poolu. Tým, který staví na proprietárním stacku, to nedokáže.

Stav distribuce ROS 2, květen 2026:

Upřímné čtení. Produkční nasazení dnes stále běží na platformě Humble. Humble je LTS, na kterou se dodavatelé zaměřují — Unitree unitree_ros2, Boosterův stack, komunita spot_ros2a grid_map od ANYbotics mají všechny stabilní větve Humble. Jazzy je místo, kde by měly nové sestavení začít: má ještě tři roky LTS života a migrační nástroje jsou zralé. Lyrical Luth je příliš nový na to, abychom se k němu zavázali – dejte mu čas do konce roku 2026, než na něm postavíte produkční systém.

Pokud zahajujete projekt v květnu 2026, zvolte Jazzy. Pokud prodlužujete projekt zahájený v roce 2023, zůstaňte u Humble, dokud další nákup robota nevynutí migraci. Iron a Kilted zcela vynechejte; verze bez LTS jsou určeny pro ty, kteří chtějí pečlivě sledovat upgrady Gazebo Harmonic a akceptovat daň z údržby.

Rozdělení regulační smyčky

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

Rozdělení řídicí smyčky: dole vrstva C++ SDK v reálném čase, nahoře orchestrace ROS 2 Python, propojeno s frekvencí 10–50 Hz prostřednictvím stavových zpráv DDS.

Řídicí smyčka zůstává na robotu v C++. Vrstva vyšší úrovně běží v uzlech ROS 2, buď na aplikačním procesoru robota (Jetson Orin AGX), nebo v případě náročnějších úloh na externím inferenčním serveru (viz I01). Obě vrstvy komunikují na frekvenci 10–50 Hz přes DDS. Nesdílejí žádný proces.

Toto rozdělení není volitelné. Uzel Pythonu ROS 2 nedokáže uzavřít společnou smyčku 1 kHz – samotný garbage collector to znemožňuje. Pokus o to je nejčastější chybou v prvním roce práce s humanoidy. SDK dodavatele existuje právě proto, abyste to nemuseli dělat.

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

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

• Posilovací učení. Nemůžete natrénovat lokomoční zásady od nuly na skutečném robotovi. Robot by se porouchal, trenér by přestal fungovat a náklady by byly obscénní. RL se v simulátoru odehrává – miliony epizod, tisíce prostředí paralelně.
• Generování dat ve velkém měřítku. Syntetická data pro doladění VLM, pochopení scény, uchopení manipulace. Špičkové týmy (R09) vygenerují přes noc stovky tisíc označených scén.
• Bezhlavá CI. Chcete, aby se při každém spuštění gitu ověřilo, že robot stále chodí. Dělat to na hardwaru je nepraktické. Noční simulační běh, který procvičuje lokomoci a vnímání, ano.
• Design prostředí. Navrhování skladu, tovární buňky, laboratoře – před stavbou je důležité vědět, zda se v ní robot dokáže orientovat.

Simulátor nepotřebujete pro:

• Rané prototypování. Pokud píšete demo s názvem „Robot mává“, simulátor je nad hlavou. Použijte skutečného robota.
• Jednoduchá manipulace. Zvednutí krabice, otevření zásuvky. Rozdíl mezi simulací a realitou u těchto úkolů je často větší než čas, který byste jim strávili u skutečného robota.
• Vývoj Teleopu. Celý smysl teleopu je člověk ve smyčce. Simulace nepomáhá.
• Jednorázové chování. Cokoli, co dvakrát spustíš a zahodíš.

Chyba, které se týmy dopouštějí, je, že simulátor považují za výchozí. Není to tak. Je to nástroj pro čtyři výše uvedené případy a navíc zjevný bezpečnostní argument „nechci havarovat skutečného robota“.

Sestava simulátorů pro rok 2026

Pro robotiku s nohou v roce 2026 budou důležité čtyři simulátory. Nejsou si rovnocenné a jejich výběr je subjektivní.

Čísla ve sloupci paralelních prostředí jsou praktická, nikoli teoretická. Závisí na složitosti modelu. Frankovo ​​rameno běží s vyšším počtem paralelních prostředí 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ý GPU, postavený na platformě Omniverse. Isaac Lab je framework pro učení robotů, který na něm stojí. Společně představují odpověď společnosti NVIDIA na každou otázku týkající se simulace robotů.

Co dělá dobře:

• Fotorealistické vykreslování. Osvětlení s paprskovým sledováním, přesné materiály, modely kamer z reálného světa. Pokud se vaše percepční platforma potřebuje naučit, jak svět skutečně vypadá, je to jediný simulátor, který to dokáže ve velkém měřítku.
• Fyzika akcelerovaná GPU. Paralelní prostředí se nacházejí v paměti GPU. Jedna RTX 5090 spouští tisíce humanoidních instancí rychlostí stovek fyzikálních kroků za sekundu.
• Isaacova laboratoř. Čistý RL framework s vestavěnou podporou pro RSL RL, RL-Games, SKRL a Stable Baselines3. Mezi více než 16 předpřipravenými modely robotů patří G1, H1, Spot, ANYmal, Franka a rostoucí seznam nováčků.
• Integrace GR00T. Zde se nachází základní model humanoidů od NVIDIA. Pokud chcete trénovat politiku vidění-jazyka-akce a nasadit ji napříč platformami, je tohle ta správná cesta.

Co to dělá špatně:

• Bolest s nastavením Omniverse. Runtime Omniverse je svéhlavý, těžkopádný a není přátelský k výchozí instalaci Ubuntu. Před spuštěním první simulace očekávejte den boje se spouštěčem, serverem Nucleus a mezipamětí zdrojů.
• Vázané na GPU. Isaac Sim neběží na CPU. Neběží dobře na jednom čipu 4090. Referenční nastavení je minimálně 5090, preferován Pro 6000 Blackwell a hostitel EPYC pro přenos dat.
• Umíněný. Formáty datových zdrojů jsou USD. Fyzika je PhysX. Renderování je RTX. Pokud chcete jiný fyzikální engine, jste ve špatném simulátoru.

Vypočítat realitu. Server K-AI s 4× RTX 5090 pohodlně zvládne trénink humanoidů z Isaac Lab – 4 000–8 000 paralelních prostředí, plně fotorealistický render s 30–60 FPS, konvergence politik pro úlohu lokomoce za 6–24 hodin. S 8× 5090 můžete škálovat širší prostor nebo spustit více experimentů paralelně. Pro 6000 Blackwell je tou správnou volbou, když je paměť omezením (velké dávky, větší knihovny humanoidních dat).

MuJoCo a MJX – odpověď založená na fyzice

MuJoCo je fyzikální simulátor od DeepMind. MJX je přepis XLA/JAX, který spouští MuJoCo na GPU s plným dávkovým zpracováním. MJWarp je novější společný projekt společností NVIDIA a Google, který píše MuJoCo ve Warpu a lépe se škáluje pro scény s vysokým počtem kontaktů.

Co dělá dobře:

• Rychlost. Čistá fyzika tuhých těles bohatá na kontakty, napsaná pro GPU od základů. Na jediné grafické kartě RTX 5090 spouští MJX tisíce humanoidních prostředí rychlostí fyzikálních kroků za sekundu, které Isaac Sim nedokáže dosáhnout se stejnou složitostí scény.
• Determinismus. Stejné semeno, stejná trajektorie. Reprodukovatelná RL je funkcí.
• Podpora DeepMind. Všechny významné články o robotice publikované v časopise DeepMind za posledních pět let používají MuJoCo. Mezi modelové knihovny (MuJoCo Menagerie) patří G1, H1, Spot, ANYmal, Frankova ruka a Shadow Hand.
• Jednodušší. Žádný Omniverse, žádný USD, žádný Nucleus. Instalace Pipu, spuštění.

Co to dělá špatně:

• Vizuální vykreslování. Renderer v MuJoCo je z éry OpenGL. Pro vizualizaci dostačující, pro fotorealistické generování dat nepoužitelný.
• Ekosystém aktiv. Menší než Isaac. Dovoz z URDF funguje, ale leštění je horší.
• Modely senzorů. Modely kamery, hloubky a LiDAR jsou základní. Pokud vaše zásady závisí na realistickém šumu senzorů, budete si tyto modely vytvářet sami.

Vypočítat realitu. Jedna RTX 5090 zvládne paralelně spustit 4 000–16 000 humanoidních prostředí MJX v závislosti na složitosti kontaktu. Server 4× 5090 K-AI dokáže paralelně spustit více než 50 000 humanoidních prostředí pro lokomoční RL. Toto je matematika, kterou používá DeepMind a většina akademických laboratoří na MuJoCo pro vnitřní smyčku školení politik.

Gazebo Harmonic – původní model ROS 2

Gazebo je open-source simulátor, který je již dvě desetiletí výchozím prvkem pro ROS. Gazebo Harmonic je aktuální LTS a skvěle se hodí k ROS 2 Humble a Jazzy.

Co dělá dobře:

• Integrace ROS2. Prvotřídní. ros_gz Bridge znamená, že vaše uzly ROS 2 fungují v simulaci beze změn.
• Otevřené a zdarma. Žádná licence, žádný Omniverse, žádná závislost na NVIDIA. Běží na CPU, na GPU AMD, na čemkoli.
• Právo na integrační testování. Pokud je vaším cílem „ověřit, zda navigační stack a plánovač fungují i ​​po refaktorování“, je Gazebo tou správnou volbou.

Co to dělá špatně:

• Pomalý. Jednovláknová fyzika, standardně softwarové vykreslování. Paralelní prostředí znamenají spouštění více procesů Gazebo. V Gazebo se netrénují RL zásady, ale provádí se jejich dymové testování.
• Není kompatibilní s GPU. Žádné dávkování pomocí GPU. Přidání akcelerace renderování pomáhá, ale nemění základní škálování.
• Rozdíl mezi simulací a skutečností je horší. Kontaktní model je méně rigorózní než MuJoCo, senzorové modely jsou méně realistické než Isaac.

Vypočítat realitu. Gazebo běží na čemkoli, co máte. Server K-AI je na to zbytečný. Notebook je v pořádku. Nevýhodou je, že pro jakoukoli netriviální pracovní zátěž v reálném čase Gazebo během několika dní přerostete.

Genesis – akademický kandidát na vysokou propustnost

Genesis je multiinstitucionální simulátor, který přišel koncem roku 2024 s výraznými výkonnostními nároky a od té doby většinu z nich prokázal. Přispěly na něm CMU, Stanford, MIT CSAIL, NVIDIA a Tsinghua.

Co dělá dobře:

• Propustnost. Genesis dosahuje na jediné grafické kartě RTX 4090 při zátěži s inverzní kinematickou stránkou od Franky přes 40 milionů FPS. U humanoidů je toto číslo nižší, ale stále se pohybuje v řádu milionů. Architektura je od začátku postavena na paralelní simulaci hmoty.
• Multifyzika. Tuhé, tekuté, měkké těleso, granulární, MPM. Pokud váš úkol zahrnuje něco jiného než tuhý kontakt (deformovatelná manipulace, lití tekutin, granulární interakce), Genesis je jediný simulátor v tomto seznamu, který to zvládá nativně.
• Generativní nástroje pro tvorbu scén. Genesis je dodáván s generováním scén řízeným prompty. Popíšete prostředí v textu a dostanete scénu.

Co to dělá špatně:

• Novější ekosystém. Méně předpřipravených modelů, méně tutoriálů, menší komunita než u MuJoCo nebo Isaaca.
• Méně prověřené bitvami pro simulaci v reálném světě. Fyzika je rychlá; jestli se na hardwaru přenáší stejně dobře jako MuJoCo, komunita teprve zjišťuje.
• Mezery v dokumentaci. Běžné u rychle se vyvíjejících výzkumných projektů.

Kam se to hodí v roce 2026. Genesis je tou správnou volbou pro RL v akademickém stylu, kde chcete maximální propustnost prostředí a jste ochotni psát více vlastních vláknů. Pro dnešní produkční simulaci v reálném prostředí je bezpečnější volbou MuJoCo nebo Isaac. Sledujte tento prostor.

Simulace reality, vydání 2026

Praktický stav simulace v reálném životě, květen 2026:

• Randomizace domén je povinná. Nemůžete trénovat s jedinou sadou fyzikálních parametrů a očekávat přenos. Hmota, tření, zpoždění motoru, šum senzorů, latence – to vše se během tréninku náhodně mění v určitém rozsahu.
• Odklad jednání je důležitější, než si lidé připouštějí. Pohony skutečného robota mají zpoždění 5–25 ms od povelu k momentu. Simulátor, který běží bez tohoto zpoždění, vytváří pravidla, která oscilují na hardwaru. Začleňte zpoždění do simulátoru od prvního dne.
• Musí být vnesen šum senzoru. Drift IMU, šum kamery, výpadky hloubkového senzoru. Práce z roku 2026, které fungují, zahrnují všechny tyto aspekty v tréninkových programech.
• Trénink na více simulátorech je tou nejlepší volbou. PolySim a podobné frameworky se trénují současně na platformách MuJoCo + Isaac + někdy i Gazebo. První výsledky jsou dobré. Výpočetní náklady jsou 2–3× oproti trénování na jedné simulaci.
• Pohyb těžkého humanoida je stále obtížný. Přeprava nákladu, zotavení se z tlačení při přenášení něčeho – i tyto činnosti se na platformách v simulaci sníží o 50–80 %. R01.

Počítejte s tím, že dvě třetiny vašeho reálného výkonu budou pocházet ze simulace. Zbývající třetinu tvořte doladění hardwaru, identifikace systému a náročné ladění.

Betonový recept: G1 + ROS 2 Humble + Isaac Lab na serveru K-AI

Hardware:
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 DOF)
  - K-AI 256 Turin Dual / 4× RTX 5090 / 1× RTX Pro 6000 Blackwell
    (the Pro 6000 for sim, the 5090s for batched policy training)
  - Wi-Fi 6E AP, line of sight to working area
  - 10 GbE switch, wired link from K-AI to AP

Software on the K-AI server:
  - Ubuntu 22.04, CUDA 13, Docker
  - Isaac Sim 5.x + Isaac Lab (Omniverse runtime, Nucleus local)
  - ROS 2 Humble (or Jazzy, if starting fresh today)
  - PyTorch 2.x, JAX, RSL RL
  - vLLM serving a VLM for high-level perception (see I02)
  - MuJoCo + MJX as the second sim, for cross-sim validation

Software on the G1:
  - Unitree SDK2 (C++ joint-control loop)
  - unitree_ros2 (Humble) on the Jetson
  - Custom ROS 2 nodes: command_router, perception_relay
  - gRPC client to vLLM on the K-AI server

Workflow:
  1. Train a locomotion or whole-body policy in Isaac Lab on the
     Pro 6000 (4,000+ parallel G1 instances, RSL RL).
  2. Validate the policy in MJX (4× 5090 batched) with different
     domain randomization seeds.
  3. Deploy the policy via TorchScript to the G1's Jetson, wrapped
     in a ROS 2 node that the Unitree SDK2 control loop calls.
  4. ROS 2 high-level commands flow from the lab's task graph
     through the command_router into the policy.
  5. Heavy perception (VLM) lives on the K-AI server, reached over
     Wi-Fi 6E + gRPC.

Celková doba potřebná k přípravě týmu s předchozími zkušenostmi s ROS 2 je dva až tři týdny. Celková doba potřebná k přípravě týmu, který se učí ROS 2 od nuly, je dva až tři měsíce. Naplánujte si to podle toho. Výpočetní část serveru K-AI je jednodušší.

Upřímný pohled

Tři názory, jasně řečeno:

1. ROS 2 je ta správná abstrakční vrstva. Nativní SDK jsou nezbytné, ale nestačí. Stavět na ROS 2 wrapperu a zacházet s SDK výrobce jako se službou, kterou wrapper spotřebovává. Přechod na proprietární systém vám nic nekoupí a stojí vás zbytek ekosystému.
2. Isaac Sim je budoucnost, ale přítomností je pro většinu týmů MuJoCo + ROS 2. Pokud se vaše práce zaměřuje na RL (Real-Activity-Driven) v oblasti lokomoce a obratné manipulace, je MuJoCo / MJX levnější, rychlejší a snadněji nasaditelná volba. Pokud se vaše práce zaměřuje na fotorealistické vnímání, generování dat ve velkém měřítku nebo doladění základních modelů ve stylu VLA, je Isaac jedinou volbou. Většina laboratoří potřebuje obojí a server K-AI má dostatek prostoru pro spuštění obou.
3. Nejmodernější laboratoře používají všechny čtyři. Isaac za renderování a pipeline foundation-model. MuJoCo za vnitřní smyčku RL. Gazebo za integrační testy ROS 2. Genesis za práci s více fyzikami. Předstírat, že budete potřebovat jen jeden, je způsob, jakým týmy po roce přepisují svůj stack.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.