Robot SDK'er, ROS 2 og simuleringsmiljøer

En robotplatform fra 2026 – humanoid eller firbenet – leveres med tre softwarehistorier, du skal håndtere, før din egen kode kører. Producentens SDK, der kommunikerer med leddene. ROS 2-wrapperen, der kommunikerer med alt andet. Og simulatoren, du bruger, fordi det at flyve en Unitree G1 EDU til 43 dollars ind i en væg er en dyr måde at fejlrette en tastefejl på.

Disse tre lag er ikke udskiftelige. SDK'et er realtidsbaseret og proprietært. ROS 2 er det lingua franca, der lader resten af ​​verdens robotkode arbejde med din platform. Simulatoren er der, hvor du udfører det arbejde, du ikke ønsker at udføre på den rigtige robot - forstærkningslæring, generering af storskala data, scenedesign, headless CI. De fleste teams bruger for lidt penge på alle tre.

Denne artikel gennemgår, hvad hvert lag rent faktisk leverer i 2026, hvor grænserne går, og hvilke kombinationer der er værd at satse på med et reelt robotlaboratoriebudget. Referenceplatformene er dem i R01 og R02 . Referencecomputeren er Kentino AI-serien (4× eller 8× RTX 5090 eller RTX Pro 6000 Blackwell, EPYC eller Xeon-vært).

SDK-laget — hvad producenterne rent faktisk giver dig

Enhver troværdig robotleverandør leverer et Software Development Kit. Navnet er det samme; indholdet er ikke. Her er, hvad der rent faktisk er i æsken.

To opdelinger betyder mere end resten.

Åben vs. gated. Unitree, Booster, EngineAI og DeepRobotics giver dig adgang på fælles niveau. Du kan udstede momentkommandoer ved 500 Hz til 1 kHz direkte til aktuatorerne. Det er, hvad du har brug for til implementering af RL-politik, brugerdefineret bevægelsesforskning og alt dynamisk. Boston Dynamics og ANYbotics holder fælles kontrol lukket - du får primitiver på højt niveau (gå hertil, klatre op ad det, manipuler dette), SDK'et eksponerer dem som RPC-kald, og virksomhedens egen controller udfører fælles arbejdet. Det er et bevidst valg. Den lukkede stak er mere pålidelig, og autonomisoftwaren er det, du betaler $74-$200 for. Det er også den forkerte stak, hvis din forskning er i lavniveaukontrol.

Realtid vs. ikke. Unitree SDK2 bruger Cyclone DDS over en dedikeret netværksgrænseflade og giver dig en rundtur på under et millisekund på joint-løkken. Boosters stak er lignende. Spot SDK er gRPC over HTTP/2 - fint til at kommandere en adfærd, ubrugeligt til at lukke en kontrolløkke ved 1 kHz. Hvis dit arbejde har brug for en løkke på under 2 ms, er arkitekturen vigtigere end sproget.

En bemærkning til Python-spørgsmålet. Alle leverandører tilbyder Python-bindinger. Ingen af ​​dem er det sprog, kontrolløkken kører i. Mønsteret på tværs af branchen er identisk: C++ til realtidscontrolleren, Python til alt over den. Leverandør-SDK'er afspejler dette: C++-bindingerne eksponerer mere, kører hurtigere og er det, som leverandørens egne eksempler er skrevet i. Python-bindinger er førsteklasses til arbejde på højt niveau og en wrapper til stien på lavt niveau. Vælg C++, når du skriver den indre kontrolløkke, og Python til orkestrering, perception glue og integration med inferensserveren.

ROS 2 — hvorfor alle normaliserer sig over for det

Det native SDK får dig ind i robotten. ROS 2 får dig ind i økosystemet.

Der er tre grunde til, at enhver seriøs integration ender med at tale ROS 2, selv når producentens SDK er tilstrækkeligt:

1. Interoperabilitet. Din perceptionsstak, din SLAM, din navigation, din manipulationsplanlægger, din teleop – alle disse har ROS 2-implementeringer, der vedligeholdes af hundredvis af bidragydere. Ingen af ​​dem bruger Unitree DDS-emneformatet som native. Pak SDK'et ind i ROS 2-beskeder én gang, og hele økosystemet åbner sig.
2. Flåder med flere leverandører. Den dag du tilføjer en anden robot fra en anden leverandør, kollapser den native SDK-tilgang. ROS 2 er den eneste abstraktion, der tillader en Spot, en ANYmal og en G1 at dele den samme kortserver, den samme opgavegraf og den samme menneske-maskine-grænseflade.
3. Ansættelse. Folk kender ROS 2. De kender ikke Unitree DDS' emnenavngivningskonventioner. Et team, der bygger på ROS 2, kan ansætte fra en global pulje. Et team, der bygger på en proprietær stak, kan ikke.

ROS 2 distributionsstat, maj 2026:

Den ærlige læsning. Produktionsinstallationer kører stadig Humble i dag. Humble er det LTS, som leverandørerne sigter mod — Unitrees unitree_ros2, Boosters stak, fællesskabet spot_ros2, og ANYbotics' grid_map har alle stabile Humble-grene. Jazzy er der, hvor nye builds bør starte: det har yderligere tre års LTS-levetid, og migreringsværktøjerne er modne. Lyrical Luth er for nyt til at forpligte sig til det — vent til slutningen af ​​2026, før du sætter et produktionssystem op på det.

Hvis du starter et projekt i maj 2026, så vælg Jazzy. Hvis du forlænger et, der startede i 2023, så bliv på Humble, indtil det næste robotkøb tvinger migreringen frem. Spring Iron og Kilted helt over; ikke-LTS-udgivelser er til folk, der ønsker at følge Gazebo Harmonic-opgraderinger nøje og acceptere vedligeholdelsesafgiften.

Kontrolsløjfeopdelingen

Dette er den arkitektoniske beslutning, der overrasker de fleste teams.

Kontrolsløjfen opdelt: realtids C++ SDK-lag nedenfor, ROS 2 Python-orkestrering ovenfor, forbundet ved 10-50 Hz via DDS-tilstandsbeskeder.

Kontrolsløjfen forbliver på robotten i C++. Højniveaulaget kører i ROS 2-noder, enten på robottens applikationsprocessor (Jetson Orin AGX) eller, til tungere arbejde, på den eksterne inferensserver (se I01 ). De to lag kommunikerer ved 10-50 Hz over DDS. De deler ikke en proces.

Denne opdeling er ikke valgfri. En Python ROS 2-node kan ikke lukke et 1 kHz joint loop — garbage collectoren alene gør det umuligt. At forsøge på det er den mest almindelige fejl i førsteårs humanoidarbejde. Leverandørens SDK eksisterer præcist, så du ikke behøver at gøre det.

Når du har brug for en simulator (og når du ikke har)

En simulator er obligatorisk til fire typer arbejde:

• Forstærkende læring. Du kan ikke træne en bevægelsespolitik fra bunden på en rigtig robot. Robotten ville gå i stykker, træneren ville give op, og omkostningerne ville være uanstændige. RL foregår i simulation — millioner af episoder, tusindvis af miljøer parallelt.
• Datagenerering i stor skala. Syntetiske data til finjustering af VLM, sceneforståelse og manipulationsforståelser. De banebrydende teams (R09) genererer hundredtusindvis af mærkede scener natten over.
• Hovedløs CI. Du vil have, at hvert git push verificerer, at robotten stadig går. Det er upraktisk at gøre det på hardware. En natlig simulationskørsel, der træner bevægelses- og perceptionsstakken, er det.
• Miljødesign. Indretning af et lager, en fabrikscelle, et laboratorium – at vide, om robotten kan navigere i det, før man bygger det.

Du behøver ikke en simulator til:

• Tidlig prototypefremstilling. Hvis du skriver en demo om "få robotten til at vinke", er en simulator overhead. Brug den rigtige robot.
• Simpel manipulation. At tage en kasse op, åbne en skuffe. Afstanden mellem sim og virkelighed på disse opgaver er ofte større end den tid, du ville have brugt på at gøre det på den rigtige robot.
• Teleop-udvikling. Hele pointen med teleop er mennesket i loopet. Simulatoren hjælper ikke.
• Engangsadfærd. Alt hvad du løber to gange og smider væk.

Den fejl, holdene begår, er at behandle simulatoren som standard. Det er den ikke. Den er et værktøj til de fire ovenstående tilfælde, plus det åbenlyse sikkerhedsargument "Jeg vil ikke have den rigtige robot til at crashe."

Simulatorudvalget for 2026

Der er fire simulatorer, der er vigtige for robotteknologi med ben i 2026. De er ikke ens, og valget er baseret på meninger.

Tallene i kolonnen parallel-envs er praktiske, ikke teoretiske. De afhænger af modellens kompleksitet. En Franka-arm kører med højere parallelle tællinger end en 41-DOF humanoid med Dex-hænder.

Isaac Sim og Isaac Lab — NVIDIAs væddemål

Isaac Sim er den fotorealistiske, GPU-accelererede simulator, der er bygget på Omniverse-stakken. Isaac Lab er robotlæringsframeworket, der ligger ovenpå. Sammen er de NVIDIAs svar på alle spørgsmål om robotsimulering.

Hvad den gør godt:

• Fotorealistisk gengivelse. Strålesporet belysning, præcise materialer, kameramodeller fra den virkelige verden. Hvis din perceptionsstak har brug for at lære, hvordan verden rent faktisk ser ud, er dette den eneste simulator, der leverer det i stor skala.
• GPU-accelereret fysik. Parallelle miljøer lever i GPU-hukommelsen. En enkelt RTX 5090 kører tusindvis af humanoide instanser med hundredvis af fysiktrin i sekundet.
• Isaac Lab. Et rent RL-framework med indbygget understøttelse af RSL RL, RL-Games, SKRL og Stable Baselines3. De 16+ præbyggede robotmodeller inkluderer G1, H1, Spot, ANYmal, Franka og en voksende liste af nytilkomne.
• GR00T-integration. NVIDIAs humanoide fundamentmodelstak findes her. Hvis du vil træne en vision-sprog-handlingspolitik og implementere den på tværs af platforme, er dette vejen frem.

Hvad den gør dårligt:

• Smerte ved opsætning af Omniverse. Omniverse-runtime-versionen er påståelig, tung og ikke venlig over for en standard Ubuntu-installation. Forvent en dag med kamp mod launcheren, Nucleus-serveren og asset-cachen, før din første simulering kører.
• GPU-bundet. Isaac Sim kører ikke på en CPU. Den kører ikke godt på en enkelt 4090. Referenceopsætningen er minimum en 5090, en Pro 6000 Blackwell foretrækkes, og en EPYC-vært til at forsyne dataene.
• Meningsfuld. Aktivformaterne er USD. Fysikken er PhysX. Rendering er RTX. Hvis du ønsker en anden fysikmotor, er du i den forkerte simulator.

Beregn virkeligheden. En Kentino AI-server med 4× RTX 5090 kører Isaac Lab humanoid-træning komfortabelt — 4,000-8,000 parallelle miljøer, fuld fotoreal ved 30-60 FPS gengivelse, politikkonvergens på en bevægelsesopgave på 6-24 timer. Med 8× 5090 kan du skalere bredere eller køre flere eksperimenter parallelt. Pro 6000 Blackwell er det rigtige valg, når hukommelse er den bindingsmæssige begrænsning (store batchstørrelser, større humanoide assetbiblioteker).

MuJoCo og MJX — fysik-først-svaret

MuJoCo er DeepMinds fysiksimulator. MJX er XLA/JAX-omskrivningen, der kører MuJoCo på GPU'en med fuld batching. MJWarp er et nyere samarbejde mellem NVIDIA og Google, der skriver MuJoCo i Warp og skalerer bedre til kontaktrige scener.

Hvad den gør godt:

• Hastighed. Ren kontaktrig rigid-body fysik, skrevet til GPU'en fra bunden. På en enkelt RTX 5090 kører MJX tusindvis af humanoide miljøer med fysiktrin per sekund, som Isaac Sim ikke kan matche for den samme scenekompleksitet.
• Determinisme. Samme frø, samme bane. Reproducerbar RL er en funktion.
• DeepMind-opbakning. Alle større DeepMind-robotforskningsartikler i de sidste fem år bruger MuJoCo. Modelbibliotekerne (MuJoCo Menagerie) inkluderer G1, H1, Spot, ANYmal, Franka-armen og Shadow Hand.
• Enklere. Ingen Omniverse, ingen USD, ingen Nucleus. Pip installere, køre.

Hvad den gør dårligt:

• Visuel gengivelse. MuJoCos renderer er fra OpenGL-æraen. Tilstrækkelig til visualisering, ubrugelig til fotorealistisk datagenerering.
• Aktivøkosystem. Mindre end Isaac. URDF-importen virker, men poleringen er lavere.
• Sensormodeller. Kamera-, dybde- og LiDAR-modeller er grundlæggende. Hvis din politik er afhængig af realistisk sensorstøj, skal du selv bygge disse modeller.

Beregn virkeligheden. En enkelt RTX 5090 kører 4,000-16,000 parallelle MJX humanoide miljøer afhængigt af kontaktkompleksiteten. En 4× 5090 Kentino AI-server kan køre mere end 50,000 humanoide miljøer parallelt til bevægelses-RL. Dette er den matematik, som DeepMind og de fleste akademiske laboratorier på MuJoCo bruger til den indre løkke af policytræning.

Gazebo Harmonic — den oprindelige ROS 2

Gazebo er den open source-simulator, der har været standardversionen af ​​ROS i to årtier. Gazebo Harmonic er det nuværende LTS og fungerer perfekt sammen med ROS 2 Humble og Jazzy.

Hvad den gør godt:

• ROS 2-integration. Første klasse. Den ros_gz Bridge betyder, at dine ROS 2-noder fungerer i simulation uden ændringer.
• Åben og gratis. Ingen licens, ingen Omniverse, ingen NVIDIA-afhængighed. Kører på CPU, AMD GPU'er, på hvad som helst.
• Ret til integrationstest. Når dit mål er "at verificere nav-stakken og at planlæggeren stadig fungerer efter en refactoring", er Gazebo det rette valg.

Hvad den gør dårligt:

• Langsom. Enkelttrådet fysik, softwaregengivelse som standard. Parallelle miljøer betyder at køre flere Gazebo-processer. Du træner ikke RL-politikker i Gazebo; du røgtester dem.
• Ikke GPU-venlig. Ingen GPU-batching. Tilføjelse af renderingsacceleration hjælper, men ændrer ikke den grundlæggende skalering.
• Forskellen mellem sim og reel er værre. Kontaktmodellen er mindre stringent end MuJoCo, sensormodellerne er mindre realistiske end Isaac.

Beregn virkeligheden. Gazebo kører på hvad som helst, du har. Kentino AI-serveren er overkill til det. En bærbar computer er fint. Ulempen er, at for enhver ikke-triviel RL-arbejdsbyrde vil du vokse fra Gazebo inden for få dage.

Genesis — den akademiske kandidat til højkapacitetsudbytte

Genesis er den multiinstitutionssimulator, der lanceredes i slutningen af ​​2024 med dristige præstationskrav, og som siden har bevist de fleste af dem. CMU, Stanford, MIT CSAIL, NVIDIA og Tsinghua bidrog alle.

Hvad den gør godt:

• Gennemløb. Genesis rammer over 40 millioner FPS på et enkelt RTX 4090-kort for en Franka inverse-kinematics-arbejdsbelastning. For humanoider er tallet lavere, men stadig i millionvis. Arkitekturen er bygget op omkring masseparallel-simulering fra starten.
• Multifysik. Stiv, flydende, blød krop, granulær, MPM. Hvis din opgave involverer andet end stiv kontakt (deformerbar manipulation, væskehældning, granulær interaktion), er Genesis den eneste simulator på denne liste, der håndterer det native.
• Generativ sceneværktøjsføring. Genesis leveres med promptdrevet scenegenerering. Du beskriver et miljø i tekst, og du får en scene.

Hvad den gør dårligt:

• Nyere økosystem. Færre præbyggede modeller, færre tutorials, mindre fællesskab end MuJoCo eller Isaac.
• Mindre kamptestet til sim-to-real. Fysikken er hurtig; om den overføres lige så godt som MuJoCo på hardware, er stadig under fastlæggelse i fællesskabet.
• Dokumentationshuller. Almindeligt med forskningsprojekter i hastig udvikling.

Hvor det passer ind i 2026. Genesis er det rette valg til akademisk RL, hvor du ønsker maksimal miljøgennemstrømning og er villig til at skrive mere af din egen lim. Til en produktions-sim-til-real-pipeline i dag er MuJoCo eller Isaac det sikreste valg. Hold øje med dette.

Sim-til-virkelig virkelighed, 2026-udgave

Den praktiske tilstand af sim-to-real, maj 2026:

• Domænerandomisering er obligatorisk. Du kan ikke træne på et enkelt sæt fysikparametre og forvente overførsel. Masse, friktion, motorforsinkelser, sensorstøj, latenstid – alle disse bliver randomiseret over et interval under træning.
• Udsættelse af handling betyder mere, end folk indrømmer. En rigtig robots aktuatorer har en forsinkelse på 5-25 ms fra kommando til moment. En simulator, der kører uden denne forsinkelse, producerer politikker, der oscillerer på hardwaren. Integrer forsinkelsen i simulatoren fra dag ét.
• Sensorstøj skal injiceres. IMU-drift, kamerastøj, udfald i dybdesensorer. De dokumenter fra 2026, der fungerer, inkluderer alle disse elementer i træning.
• Multisimulatortræning er den nyeste teknologi. PolySim og lignende frameworks trænes på tværs af MuJoCo + Isaac + nogle gange Gazebo samtidigt. Tidlige resultater er gode. Beregningsomkostningerne er 2-3 gange single-sim træning.
• Tungt belastet humanoid bevægelse er stadig vanskelig. At bære en nyttelast, at komme sig efter et skub, mens man bærer noget – disse nedbrydes stadig med 50-80% fra simulation til realitet på platformene i R01.

Planlæg, at to tredjedele af din ydeevne i den virkelige verden skal komme fra simulering. Planlæg, at den sidste tredjedel skal være finjustering af hardware, systemidentifikation og genstridig fejlfinding.

Konkret opskrift: G1 + ROS 2 Humble + Isaac Lab på en Kentino AI-server

Hardware:
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 DOF)
  - Kentino 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 Kentino AI to AP

Software on the Kentino 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 Kentino 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 Kentino AI server, reached over
     Wi-Fi 6E + gRPC.

Den samlede stående tid for et team med tidligere ROS 2-erfaring er to til tre uger. Den samlede stående tid for et team, der lærer ROS 2 fra bunden, er to til tre måneder. Planlæg i overensstemmelse hermed. Beregningssiden af ​​Kentino AI-serveren er den nemmere del.

Den ærlige holdning

Tre meninger, helt enkelt:

1. ROS 2 er det højre abstraktionslag. Native SDK'er er nødvendige, men ikke tilstrækkelige. Byg videre på ROS 2-wrapperen, og behandl producentens SDK som en tjeneste, som wrapperen forbruger. At blive proprietær køber dig ingenting og koster dig resten af ​​økosystemet.
2. Isaac Sim er fremtiden, men nutiden er MuJoCo + ROS 2 for de fleste hold. Hvis dit arbejde er RL med bevægelse og fingerfærdig manipulation, er MuJoCo / MJX det billigere, hurtigere og nemmere valg at implementere. Hvis dit arbejde er fotorealistisk perception, storskala datagenerering eller finjustering af fundamentsmodeller i VLA-stil, er Isaac det eneste valg. De fleste laboratorier har brug for begge dele, og Kentino AI-serveren har pladsen til at køre begge dele.
3. De banebrydende laboratorier bruger alle fire. Isaac for renderingen og fundamentsmodellens pipeline. MuJoCo for RL's indre loop. Gazebo for ROS 2-integrationstestene. Genesis for multifysikarbejdet. At lade som om, man kun behøver én, er sådan teams ender med at omskrive deres stak efter et år.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.