Sim-to-Real-Transfer und der Reality Gap: Was Robotertraining in Simulation wirklich leistet

Sim-to-Real-Transfer bezeichnet ein einfaches Versprechen: Man trainiert eine Steuerungs-Policy (die gelernte Steuerungsstrategie) zuerst in einem Physiksimulator, wo Versuch und Irrtum fast nichts kosten, und überträgt sie danach mit wenig oder gar keinem Nachtraining auf echte Hardware. Das Problem steckt im Detail. Zwischen der sauberen Simulationswelt und der widerspenstigen Realität liegt der Reality Gap — die Diskrepanz zwischen dem, was eine Policy im Simulator leistet, und dem, was sie auf dem realen Roboter tatsächlich schafft. Eine Policy kann im Simulator zuverlässig funktionieren und auf der Hardware trotzdem scheitern, weil Reibung, Latenz, Sensorrauschen und Fertigungstoleranzen nie exakt abgebildet sind. Die wichtigste Technik, um diese Lücke zu überbrücken, ist Domain Randomization. Und selbst sie macht aus einem geschönten Demo-Video noch lange keinen einsatzfähigen Roboter. Warum Handlungen in der realen Welt überhaupt anderen Regeln folgen als reine Software-KI, ordnet der Grundlagenartikel zu physischer KI ein.

Warum überhaupt Robotertraining in Simulation?

Moderne Steuerungsverfahren, allen voran Reinforcement Learning (RL, bestärkendes Lernen), brauchen Millionen bis Milliarden von Interaktionsschritten, bis eine Policy stabil läuft. Auf echter Hardware ist das nicht bezahlbar: Ein realer Roboter läuft in Echtzeit, verschleißt, braucht menschliche Aufsicht und geht bei Fehlversuchen kaputt. Ein Simulator dreht dieses Verhältnis um. Er lässt sich nach jedem Fehlversuch in Millisekunden zurücksetzen, rechnet schneller als in Echtzeit und startet Tausende Roboter-Instanzen parallel.

NVIDIA gibt für seinen GPU-beschleunigten Simulator Isaac Sim an, Trainingsumgebungen könnten mit rund dem Tausendfachen der Echtzeit und Tausenden paralleler Instanzen laufen (Herstellerangabe, nicht unabhängig nachgemessen; Stand 2025). Isaac Sim 5.0 und das darauf aufsetzende Isaac Lab 2.2 wurden rund um die SIGGRAPH im August 2025 allgemein verfügbar. Ob diese Faktoren im eigenen Aufbau erreicht werden, hängt stark von Szene, Sensorik und Kontaktkomplexität ab — die Zahl ist eine Obergrenze unter günstigen Bedingungen, kein Betriebsversprechen.

Entscheidend für den Betrieb: Simulation macht RL überhaupt erst praktikabel. Sie erkauft diese Praktikabilität aber mit einer Vereinfachung der Physik — und genau daraus entsteht der Reality Gap.

Was ist der Reality Gap — und warum verschwindet er nicht?

Den Begriff prägten Nick Jakobi, Phil Husbands und Inman Harvey 1995 in der Arbeit „Noise and the Reality Gap: The Use of Simulation in Evolutionary Robotics“ (3rd European Conference on Artificial Life, Springer LNCS Bd. 929). Gemeint ist die Diskrepanz zwischen der in Simulation gemessenen Leistung und der Leistung nach der Übertragung auf reale Hardware.

Der Reality Gap ist kein Fehler, den man einmalig behebt, sondern eine strukturelle Eigenschaft jeder Simulation. Ein Simulator ist immer ein vereinfachtes Modell der Welt. Kontaktdynamik, Reibung, verformbare Materialien, Aktuator-Latenz, Kabelzug, Temperaturdrift, Kalibrierfehler und Sensorrauschen lassen sich nie vollständig abbilden. Jeder nicht modellierte Effekt ist eine potenzielle Quelle des Gaps. Deshalb gilt in der Praxis: Je stärker eine Aufgabe von Kontakt und Materialverhalten abhängt — etwa Greifen, Manipulieren oder Balancieren —, desto größer fällt die Lücke typischerweise aus.

Wie schließt Domain Randomization den Reality Gap?

Domain Randomization begegnet dem Reality Gap mit einem kontraintuitiven Kniff. Die grundlegende Arbeit dazu lieferte 2017 ein Team von OpenAI und der UC Berkeley um Josh Tobin: „Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World“ (IEEE/RSJ IROS 2017, arXiv:1703.06907). Das Team trainierte ein neuronales Netz ausschließlich auf nicht-fotorealistischen, simulierten RGB-Bildern mit zufällig variierten Texturen, Beleuchtungen und Kamerapositionen — und übertrug es ohne ein einziges echtes Trainingsbild auf die reale Objektlokalisierung, mit einer Genauigkeit von rund 1,5 Zentimetern.

Die Idee dahinter ist einfach zu benennen, aber schwer zu verinnerlichen. Statt die Simulation möglichst realistisch zu machen, variiert man viele Simulationsparameter so breit, dass die reale Welt für das Modell statistisch nur wie „eine weitere Variante“ der Simulation aussieht. Man jagt also nicht dem Fotorealismus hinterher, sondern der Varianz.

In der Praxis unterscheidet man zwei Gruppen von Parametern:

• Visuelle Parameter: Texturen, Farben, Beleuchtung, Kameraposition und -winkel.
• Physikalische Parameter: Masse, Reibung, Dämpfung, Latenz und Sensorrauschen.

OpenAI trieb diesen Ansatz mit der Roboterhand Dactyl auf die Spitze. Die Arbeit „Learning Dexterity“ zur Manipulation in der Hand erschien 2018; das einhändige Lösen eines Zauberwürfels folgte im Oktober 2019. Aufschlussreich ist der Zeitverlauf: Das Würfellösen gelang in Simulation bereits Mitte 2017, auf dem physischen Roboter aber erst 2019. Zwischen simulierter und realer Fähigkeit lagen also rund zwei Jahre — ein nüchterner Maßstab dafür, wie weit „geht im Simulator“ und „geht auf der Hardware“ auseinanderliegen können.

Zu wenig oder zu viel Zufall — der Kompromiss

Domain Randomization hat einen Haken: Bei zu wenig Variation überträgt sich die Policy schlecht, bei zu viel lernt sie gar nicht erst stabil. Um dieses Abwägen nicht mehr von Hand zu erledigen, führte OpenAI 2019 Automatic Domain Randomization (ADR) ein — ein Verfahren, das die Randomisierungsbereiche während des Trainings automatisch erweitert.

Der aktuell (2025–2026) in mehreren Übersichtsarbeiten beschriebene Praxisstandard — etwa in der arXiv-Arbeit „The Reality Gap in Robotics“ (arXiv:2510.20808) — kombiniert drei Bausteine: Visuelle Parameter werden aggressiv randomisiert; physikalische Parameter werden konservativ um Werte herum variiert, die zuvor per Systemidentifikation an echter Hardware gemessen wurden; und ein kleiner Satz realer Demonstrationen dient der Feinabstimmung (Fine-Tuning). Das ist ein beschriebenes Vorgehensmuster und keine allgemeingültige Kennzahl — als sich abzeichnender Konsens zu verstehen, nicht als harte Zahl.

Funktioniert Sim-to-Real-Transfer in der Praxis?

Ja — unter den richtigen Bedingungen und für bestimmte Aufgabenklassen. Das bislang überzeugendste öffentliche Beispiel für Fortbewegung liefert das Robotic Systems Lab der ETH Zürich. In „ANYmal Parkour: Learning Agile Navigation for Quadrupedal Robots“ (Hoeller, Rudin, Sako, Hutter; Science Robotics, Bd. 9, Nr. 88, 2024; Vorabdruck arXiv:2306.14874; ETH-Mitteilung März 2024) wurden Fortbewegungs- und Wahrnehmungs-Policies vollständig in Simulation trainiert und auf den realen Vierbeiner ANYmal übertragen. Der Roboter überwand Hindernisse mit Geschwindigkeiten von bis zu rund 2 m/s. Vergleichbare RL-Sim-to-Real-Arbeiten an Laufrobotern gab es an der ETH schon früher (um 2019); konkrete Kennzahlen dazu sind hier nicht belastbar belegt und dienen nur als Hintergrund.

Bei der Manipulation ist die Beleglage dünner. Verschiedene domain-randomisierte Trainingsansätze für massiv parallelisiertes Training auf Tausenden simulierten Umgebungen berichten von deutlich niedrigeren Erfolgsraten bei neuen, unbekannten Objekten als bei bereits gesehenen — konkrete Prozentzahlen dazu ließen sich hier nicht an einer Primärquelle verifizieren und werden deshalb bewusst nicht zitiert. Genau das ist die Lehre für den Betrieb: Erfolgsraten beim Greifen neuer Objekte liegen deutlich unter denen bei der Fortbewegung — und je konkreter eine Zahl klingt, desto genauer sollte man ihre Quelle prüfen.

Warum täuschen geschönte Demo-Videos?

Hier trennt sich die Praxissicht vom Marketing. Ein Hochglanz-Video beweist nicht, dass eine autonome, in Simulation trainierte Policy die gezeigte Aufgabe unbeaufsichtigt löst. Es kann ebenso gut aus ausgewählten Aufnahmen, gestellten Umgebungen, einstudierten Abläufen und nicht offengelegter Teleoperation bestehen.

Der prominenteste Fall ist Tesla Optimus. Bloomberg berichtete im Oktober 2024, dass Teile des „Cybercab“-/Optimus-Auftritts in Burbank von Menschen ferngesteuert wurden — per Joystick beziehungsweise Teleoperation —, während die Inszenierung mehr Autonomie suggerierte. Tesla-Manager Milan Kovac räumte später ein, die Roboter seien „human assisted to some extent“ gewesen. Im Dezember 2025 zeigte ein Optimus-Video aus Miami, wie der Roboter stürzte und dabei eine Handbewegung machte, die zum Absetzen eines VR-/Teleoperations-Headsets durch einen Operator passt — was die Debatte neu befeuerte. Was Teleoperation als Trainings- und Datenerfassungsmethode von einer bloß geschönten Demo unterscheidet, ordnet ein eigener Beitrag zu Teleoperation und Datenerfassung für Roboter ein. Elon Musk erklärte, einzelne Vorführungen (etwa eine Kampfkunst-Sequenz) seien KI-gesteuert und nicht teleoperiert gewesen („Nobody was controlling it“) — eine Herstelleraussage, die hier nicht unabhängig verifiziert ist. In einem Bericht über eine Tesla-Bilanzvorlage im Januar 2026 hieß es zudem, zu diesem Zeitpunkt habe kein einziger Optimus „nützliche“ Fabrikarbeit geleistet (einzelne Sekundärquelle, zeitkritisch — vor dem Zitieren am Primärtranskript prüfen).

Fairerweise gehört auch die andere Seite dazu. Die viralen Videos von Boston Dynamics — Atlas-Rückwärtssaltos, tanzende Roboter — zeigen laut mehreren Faktenchecks (u. a. Snopes) echte physische Roboter und sind keine CGI-Animation. Aber auch hier gilt: Ein fertiger Clip von rund einer Minute kann das Ergebnis umfangreicher Auswahl und Schnittarbeit über viele Aufnahmen hinweg sowie monatelanger Entwicklungs- und Dreharbeit sein (Boston-Dynamics-„Behind the Scenes“-Berichte, u. a. New Atlas). Die oft zitierte Angabe von „fünf bis sechs Teams, die monatelang für eine Minute Material arbeiten“ stammt aus einer einzelnen Sekundärquelle und ist als grobe, unbestätigte Schätzung zu lesen.

Für den Betrieb folgt daraus eine einfache Prüffrage: nicht „Sieht die Demo beeindruckend aus?“, sondern „Wie hoch ist die Erfolgsrate über tausend Versuche in meiner Umgebung, ohne Operator im Headset?”

Wo passen Simulation und digitale Zwillinge in die Physical-AI-Entwicklung?

Simulation ist längst mehr als das Trainingsgelände für eine einzelne Policy. Sie ist zum Werkzeug geworden, um die Daten zu erzeugen, mit denen generalistische Modelle trainiert werden — und um Anlagen zu planen, zu validieren und zu überwachen. Ein digitaler Zwilling ist dabei das synchron gehaltene virtuelle Abbild einer realen Zelle, Linie oder Flotte. Wie Betreiber solche digitalen Zwillinge konkret für Training, Layout-Planung und Überwachung einsetzen, beschreibt ein eigener Beitrag zu Robotersimulation und digitalen Zwillingen.

Die wichtigsten Bausteine im Überblick (Stand 2026):

Werkzeug	Typ	Rolle im Sim-to-Real-Transfer
NVIDIA Isaac Sim / Isaac Lab	GPU-Simulator (Omniverse/OpenUSD)	Massiv paralleles RL-Training; visuelle und physikalische Randomisierung
MuJoCo	Physik-Engine (2021 von DeepMind übernommen, Apache 2.0 seit 2022)	Schnelle, genaue Kontakt- und Starrkörperphysik für die RL-Forschung; kein eingebautes Fotorealismus-Rendering
Newton	GPU-Physik-Engine (DeepMind, Disney Research, NVIDIA; Linux Foundation)	Offene, auf NVIDIA Warp/OpenUSD aufbauende Engine; interoperabel mit MuJoCo Playground und Isaac Lab
NVIDIA Cosmos	Weltmodelle (WFMs)	Erzeugung synthetischer, steuerbarer Trainingsvideos für das Nachtraining
NVIDIA Isaac GR00T	VLA-Basismodelle für Humanoide	Basismodelle plus synthetische Datenpipeline („GR00T Blueprint“)

Neben dem reinen Physiktraining wächst die Rolle synthetischer Daten. NVIDIAs Weltmodell-Familie Cosmos (angekündigt März 2025) erzeugt aus Segmentierungskarten, Tiefen-, Lidar-, Posen- und Trajektorien-Eingaben steuerbares Trainingsvideo; laut Hersteller flossen rund 20 Millionen Stunden realen Videomaterials in das Training ein (Herstellerangabe zur Größenordnung). Im Juni 2026 kündigte NVIDIA auf der GTC Taipei (1. Juni) Cosmos 3 an — eine neue Mixture-of-Transformers-Architektur, als omnimodales Modell beschrieben; die Details sind frisch und über die Herstellermitteilung hinaus noch nicht unabhängig geprüft. Als frühe Anwender nennt NVIDIA unter anderem 1X, Agility Robotics und Figure AI. Die „GR00T Blueprint“-Pipeline soll geschätzte 6500 Stunden menschlicher Teleoperationsdaten auf rund 11 Stunden Rechenzeit verdichten (ebenfalls Herstellerangabe, nur durch eine Quelle belegt). GR00T N1 wurde auf der GTC im März 2025 vorgestellt, N1.5 folgte als Weiterentwicklung; höhere Versionsnummern sind Stand Anfang 2026 unsicher und sollten vor Veröffentlichung geprüft werden.

Solche Pipelines speisen Vision-Language-Action-Modelle (VLA) wie RT-2 (Google DeepMind, 2023), das offene OpenVLA (rund 7 Mrd. Parameter, 2024) oder π0 von Physical Intelligence (vorgestellt Oktober 2024). Der rote Faden: Simulation verschiebt sich von „trainiere eine Policy“ hin zu „erzeuge die Daten, die ein generalistisches Modell trainieren“. Auch hier ändern sich Versions- und Datumsangaben schnell — Zahlen jenseits des Stands Anfang 2026 sollten vor Veröffentlichung nachgeprüft werden.

Wie groß der Markt ist, hängt stark von der Definition ab, und die Schätzungen der Analysehäuser gehen weit auseinander. Für das eng gefasste Segment „Physical AI Simulation and Digital Twin for Robotics“ nennt Marketintelo 3,8 Mrd. US-Dollar für 2025 und prognostiziert bei rund 28,5 Prozent jährlichem Wachstum etwa 34,6 Mrd. US-Dollar bis 2034. Für den breiter gefassten Digital-Twin-Markt (inklusive Anwendungen außerhalb der Robotik) nennt Fortune Business Insights rund 35,8 Mrd. US-Dollar für 2025, MarketsandMarkets dagegen rund 21,14 Mrd. US-Dollar — mit einer Prognose von rund 149,81 Mrd. US-Dollar bis 2030. Man sollte diese Zahlen nicht mitteln, sondern als das lesen, was sie sind: Schätzungen einzelner Marktforscher mit unterschiedlichem Zuschnitt, grob im Bereich von 21 bis 36 Mrd. US-Dollar für 2025. Auf der Venture-Capital-Seite berichten Sekundärquellen von mehr als 2,2 Mrd. US-Dollar, die 2025 in Startups für Roboter-Basismodelle geflossen sind — eine einzelne, ungefähre Angabe, die als solche zu kennzeichnen ist.

Was heißt das für den Betrieb?

Nüchtern zusammengefasst:

• Der Reality Gap lässt sich verkleinern, aber nicht schließen. Planen Sie Budget und Zeit für die Iteration auf echter Hardware ein — Sim-to-Real endet nicht mit der Inbetriebnahme.
• Verlangen Sie nachvollziehbare Belege. Systemidentifikation an Ihrer Hardware, Feinabstimmung mit realen Daten aus Ihrer Umgebung und Erfolgsraten über viele Versuche wiegen mehr als ein einzelnes Video.
• Fragen Sie explizit nach Teleoperation. Eine Demo, die Autonomie zeigt, muss offenlegen, ob und wo ein Mensch eingriff.
• Trennen Sie Aufgabenklassen. Fortbewegung überträgt sich heute deutlich zuverlässiger als kontaktreiche Manipulation neuer Objekte.

Sim-to-Real-Transfer ist eine reife, belegte Methode — kein Marketingbegriff. Aber zwischen dem, was ein Roboter im Simulator kann, und dem, was er am ersten Tag unbeaufsichtigt in Ihrer Halle leistet, liegt genau der Reality Gap, den dieser Text beschreibt. Wer das einplant, trifft bessere Beschaffungsentscheidungen als jemand, der dem Video glaubt. Dieser Beitrag gehört zum Themenfeld Grundlagen der physischen KI.