Simulation & digitale Zwillinge für das Robotertraining (Sim-to-Real)

Erfahrung mit realer Roboter-Hardware zu sammeln ist langsam, teuer und mitunter unsicher. Physik- simulatoren und digitale Zwillinge erlauben es Teams, Tausende virtuelle Roboter parallel laufen zu lassen, Bedingungen zufällig zu variieren, beschriftete synthetische Daten zu erzeugen und Software zu testen, bevor eine Maschine gebaut oder angehalten wird. Die trainierte Policy oder das Wahrnehmungsmodell wird dann übertragen („Sim-to-Real“) und mit wenigen realen Daten verfeinert. Typischer Nutzen: schnellere Entwicklungszyklen, weniger physische Crashs und frühere Validierung von Randfällen.

Problem & Nutzen

• Heute: Roboterverhalten wird von Hand programmiert oder mit realen Demonstrationen trainiert. Jede reale Stunde an Daten kostet Bedienerzeit, Verschleiß und Zellenstillstand; seltene Fehlerfälle (herabfallende Teile, ungewöhnliche Beleuchtung, eintretende Personen) sind schwer zu erfassen und lassen sich nicht gefahrlos absichtlich provozieren.
• KI-Nutzen: Simulation liefert günstige, parallele und sichere Erfahrung. GPU-beschleunigte Simulatoren lassen Tausende Umgebungen gleichzeitig laufen, sodass Reinforcement Learning (RL) für Fortbewegung und Manipulation in Minuten bis Stunden konvergiert statt in Wochen realen Betriebs [1][3]. Generative Weltmodelle und 3D-Generierung sorgen für visuelle Vielfalt und neue Szenarien [2].
• Digitale Zwillinge: Eine kalibrierte virtuelle Kopie einer Linie oder eines Lagers ermöglicht die virtuelle Inbetriebnahme (Test von SPS- und Robotercode vor der Installation), Was-wäre-wenn-Analysen des Layouts und laufende Regressionstests von Software-Updates.
• Belege: In der Simulation trainierte Policies für Laufroboter und geschickte Handmanipulation liefen ohne weiteres Training (Zero-Shot) auf realer Hardware [3][4]; eine unabhängige durchschnittliche Kosteneinsparung ist nicht belegt, messen Sie daher gegen Ihre eigene Ausgangsbasis.

Varianten

• Policy-Training (RL / Imitation): Fortbewegung, Manipulation und Ganzkörpersteuerung für Humanoide und Arme (siehe ROBO-004, ROBO-003).
• Synthetische Wahrnehmungsdaten: domänenrandomisierte Bilder, Tiefen- und Punktwolkendaten für Greif- erkennung und Segmentierung (ROBO-001, GEN-020).
• Virtuelle Inbetriebnahme / digitaler Zwilling einer Zelle: Roboterprogramme, SPS-Logik und Sicherheitslayouts vor der Installation testen.
• Flotten-/Anlagenzwillinge: Verkehrs- und Layout-Simulation für AMR (ROBO-002); Szenariotests für autonome Fahrzeuge/Drohnen (ROBO-005/006).

So funktioniert es

1. CAD / URDF / USD + Scans der realen Zelle
2. Asset-Erstellung & Szenenaufbau (3D-Generierung, Photogrammetrie, Gaussian Splats)
3. Physiksimulation (GPU-parallel, Kontakte, Sensoren, Aktuatoren)
4. Domänenrandomisierung (Reibung, Masse, Beleuchtung, Texturen, Latenz, Sensorrauschen)
5. Training (RL, Imitationslernen, VLA-Feintuning) + Erzeugung synthetischer Daten
6. Bewertung in zurückgehaltenen simulierten Szenarien (Regressionstestsuite)
7. Übertragung auf den realen Roboter (Zero-Shot oder mit Feintuning auf Realdaten, Systemidentifikation)
8. Überwachung am realen Roboter
9. Logs fließen zurück, um den Zwilling zu kalibrieren

• Physik-Engines: Starrkörper- und Kontaktsimulatoren (PhysX, MuJoCo/MJX, Newton, Genesis), die auf GPUs für massive Parallelität laufen.
• Sim-to-Real-Techniken: Domänenrandomisierung, Systemidentifikation des realen Roboters, aus realen Daten gelernte Aktuatormodelle, Destillation von privilegiertem Lehrer zu Schüler, Residual- Learning auf klassischen Reglern.
• Mensch-in-der-Schleife (Human-in-the-Loop): Ingenieure legen Aufgaben, Belohnungen und Sicherheitsgrenzen fest; jede Policy durchläuft einen simulierten und dann einen beaufsichtigten Test in der realen Welt (reduzierte Geschwindigkeit, sicherheitsgerichtete Überwachung) vor der Freigabe. Sicherheitsfunktionen werden nie allein einer gelernten Policy überlassen (siehe ROBO-016).

Datenaufbereitung

Simulation braucht genaue Geometrie- und Verhaltensdaten: CAD/STEP-Modelle von Zellen, Robotern und Produkten, Kinematik- und Traglastdaten vom Roboterhersteller, Layoutzeichnungen, Taktzeiten sowie Sensor- oder Kameradaten der realen Zelle zur Kalibrierung. In einem KMU liegen diese typischerweise im CAD/PDM-System, in PDFs der Hersteller, in Excel-Taktzeitlisten, in SPS-Projekten und auf den Laptops der Ingenieure.

Typische Lücken: vereinfachte oder veraltete CAD-Modelle, fehlende physikalische Parameter (Reibung, Masse, Toleranzen), keine aufgezeichneten realen Referenzläufe zur Validierung, auf einzelne Ingenieure verstreutes Wissen und unklare Rechte an CAD-Dateien von Lieferanten.

Schritte der Aufbereitung: (1) ein geprüftes Modell je Zelle sammeln und in Simulationsformate (USD, URDF) umwandeln; (2) reale Referenzdaten (Taktzeiten, Kamerabilder, Gelenk-Logs) für die Kalibrierung aufzeichnen (siehe PREP-005, PREP-011); (3) Erfolgskennzahlen und einen Testsatz von Szenarien mit den Fachexperten festlegen (PREP-018); (4) IP- und Lizenzrechte an CAD-Daten klären (PREP-025); (5) synthetische Variationen (Beleuchtung, Positionen) mit Domänenrandomisierung erzeugen. Werkzeuge: CAD-Konverter, Isaac Sim/Omniverse, ROS-2-Bag-Aufzeichnung.

Grober Aufwandsanteil: 40–50 Prozent, denn Modelltreue und Kalibrierung entscheiden, ob Sim-to-Real funktioniert. Führen Sie zuerst GUIDE-003 durch.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg B — ein verwalteter Simulations- oder Integratorservice passt am besten, weil der Zwilling mit der eigenen Roboterzelle und den eigenen CAD-Daten verbunden werden muss und kein Standardprodukt dies abdeckt.
• Großunternehmen: Weg C — eine gemeinsame interne Simulationsplattform auf eigenen GPU-Servern bedient viele Roboter- und Linienprojekte, hält CAD- und Prozessdaten im Haus und vermeidet hohe Lizenzkosten pro Arbeitsplatz und Cloud-GPU-Kosten.
• Entwickler: Weg C — Open-Source-Simulatoren und RL-Frameworks (z. B. Isaac Lab, MuJoCo, Gazebo) sind die Standard-Werkzeugkette für Sim-to-Real-Arbeiten.

Weg A — Kaufen (Standardsoftware)

• Suiten von Roboterherstellern und der Automatisierung: Siemens Process Simulate / Tecnomatix und Siemens Xcelerator (DE, EU), Dassault Systèmes DELMIA (FR, EU), Visual Components (FI, EU, jetzt Teil von KUKA), ABB RobotStudio, FANUC ROBOGUIDE, Simulator von Universal Robots, auf NVIDIA Omniverse basierende Blueprints für Fabrikzwillinge. Am stärksten bei virtueller Inbetriebnahme und Offline-Programmierung.
• A wählen, wenn: Sie Standardroboter in Zellen integrieren und Inbetriebnahme- und Layout- Validierung benötigen, keine neuartigen gelernten Fähigkeiten.

Weg B — Auf Cloud-KI-Diensten aufbauen / verwaltete Simulation (empfohlen)

• Verwaltete GPU-Simulation: NVIDIA Isaac Sim und Isaac Lab auf Cloud-GPU-Instanzen (EU-Regionen von AWS, Azure, Google Cloud; EU-Anbieter wie OVHcloud, Scaleway, STACKIT, IONOS für GPUs).
• Generative Erweiterung: NVIDIA Cosmos World Foundation Models, Cloud-Schnittstellen zur Video-/Bild- generierung für Szenenvariationen [2].
• Orchestrierung: Kubernetes/Ray-Trainingsjobs, MLflow, ROS-2-Brücke zum Roboter.
• B wählen, wenn: Sie gelernte Policies oder Wahrnehmung benötigen, aber nicht von Anfang an einen GPU-Cluster besitzen wollen.

Weg C — Selbst betreiben (Open Source)

• Simulatoren: MuJoCo und MJX/MuJoCo Playground (Google DeepMind, Apache 2.0) [3][5], NVIDIA Isaac Lab (BSD-3; Isaac Sim hat eine eigene Lizenz) [1], die Physik-Engine Newton (Linux Foundation, Open Source, gemeinsam entwickelt von Disney Research, Google DeepMind und NVIDIA), Genesis, Gazebo (Open Robotics), PyBullet, ManiSkill, Drake.
• Lern-Stack: PyTorch/JAX, RL-Bibliotheken (rsl_rl, skrl, Stable-Baselines3, RLlib), LeRobot (Hugging Face, Imitationslernen und Datensätze) [6], offene VLA-Modelle (GR00T N1.x mit offenen Gewichten, OpenVLA, pi0 mit offenen Gewichten).
• Hardware: HW2 genügt für MuJoCo/MJX-Experimente und kleine Isaac-Lab-Aufgaben (RTX-GPU mit RT-Kernen für das Rendering in Isaac Sim erforderlich); HW3–HW4 für großskaliges paralleles RL, bildbasiertes Training und VLA-Feintuning. Betriebsaufwand: mäßig, vor allem Pflege von GPU und Treibern.

Weg D — Eigenes Training

In diesem Anwendungsfall der Standard: Policies und Wahrnehmungsmodelle werden auf Ihrem Roboter, Ihren Teilen und Ihrer Zelle trainiert. Erforderlich sind ein genaues Robotermodell, Identifikationsdaten für Aktuatoren/Sensoren von der realen Maschine (Minuten bis Stunden an Logs), ein Aufgaben- und Belohnungsdesign sowie einige hundert reale Demonstrationen in Kombination mit Imitationslernen. Das Feintuning eines Roboter-Foundation-Modells mit einigen Dutzend bis Hunderten Demonstrationen ist der übliche Weg für Manipulation.

Stand der Technik (2026)

• GPU-parallele Simulation ist der Standard: Isaac Lab, MJX/MuJoCo Playground und Newton trainieren Fortbewegungs-Policies in Minuten auf einer GPU und haben Zero-Shot-Transfer für Lauf- und Humanoidroboter gezeigt [1][3][5].
• Zero-Shot-Geschicklichkeit: Starke Domänenrandomisierung übertrug Manipulation in der Hand [4]; kontaktreiche Montage bleibt schwieriger.
• Generative Simulation: Weltmodelle (z. B. NVIDIA Cosmos) und Videogenerierung ergänzen oder ersetzen Teile des Renderers; sie steigern den visuellen Realismus, sind aber physikalisch nicht exakt [2].
• Roboter-Foundation-Modelle (VLA, siehe ROBO-004) werden zunehmend auf Mischungen aus realen, teleoperierten und simulierten Daten vortrainiert, wobei die Simulation die Menge für seltene Fälle liefert.
• Grenzen und Fehlerbilder: die Sim-to-Real-Lücke (Kontakt, Reibung, verformbare Objekte, Kabel, Flüssigkeiten, weiche Teile, Sensorrauschen, Aktuator-Latenz); Reward Hacking, das Eigenheiten des Simulators ausnutzt; ein Zwilling, der nach Wartung oder Umrüstung von der Realität abdriftet; falsche Sicherheit, weil die Testszenarien dieselbe Verteilung wie das Training haben; fotorealistische, aber physikalisch falsche generative Szenen. Ein bestandener Simulationstest ist ein Indiz, keine Zertifizierung.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (Simulation + Reinforcement Learning + Robotersteuerung): ROBO-003 Programmierung durch Vormachen, ROBO-004 Humanoide/VLA, ROBO-001 Griff in die Kiste (synthetische Trainingsbilder), ROBO-002 Flotten- und Layout-Simulation.
• Datenpipeline: GEN-020, GEN-025 (Gaussian-Splat-Scans von Baustellen) und DATA-005 teilen sich Rendering-Werkzeuge.
• Sicherheit und Validierung: ROBO-016 KI-Sicherheitsfunktionen, ROBO-005 szenariobasierte Tests autonomer Fahrzeuge.
• Hardware: Ein GPU-Cluster (HW3–HW4) bedient Simulation, RL, VLA-Feintuning und Bildgenerierung; SCI-005 Simulations-Surrogate nutzen eine ähnliche Infrastruktur.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis wenige Monate für Inbetriebnahme-Abläufe; Lizenzen pro Arbeitsplatz, in der Regel der Hauptkostenblock.
• Weg B: 3–6 Monate für eine erste übertragene Policy oder eine Pipeline für synthetische Daten; GPU-Stundenkosten und Engineering-Zeit dominieren.
• Weg C: 3–9 Monate inkl. Einarbeitung des Teams; ein oder mehrere GPU-Server und Robotik-RL-Expertise.
• Kennzahlen: Erfolgsquote Simulation vs. Realität (Sim-to-Real-Lücke), eingesparte reale Roboterstunden, benötigte reale Daten pro Fähigkeit, Zeit von CAD bis zum ersten lauffähigen Programm, bei der virtuellen Inbetriebnahme gefundene Fehler, Szenarioabdeckung, Inbetriebnahmezeit vor Ort.

Menschen & Veränderung

Beziehen Sie die Geschäftsleitung für Umfang und Budget ein, die Abteilungsleitung (Produktion oder Robotik-Engineering) als Verantwortliche, IT und IT-Sicherheit für GPU-Server, Lizenzen und Netztrennung sowie die Datenverantwortlichen für CAD- und SPS-Daten. Bediener und Instandhaltungspersonal, die später neben dem Roboter arbeiten, müssen früh in die Festlegung der Szenarien einbezogen werden.

Betriebsrat: abhängig vom Einzelfall. Eine reine Engineering-Simulation mit CAD-Daten berührt in der Regel keine Beschäftigtendaten. Sie greift, sobald Bewegungen oder Leistungsdaten von Bedienern aufgezeichnet werden oder digitale Zwillinge Beschäftigte oder Schichtleistung abbilden (§ 87 Abs. 1 Nr. 6 BetrVG). Die Einführung von Robotern verändert zudem Arbeitsabläufe; unterrichten Sie den Betriebsrat daher rechtzeitig nach § 90 Abs. 1 Nr. 3 und vereinbaren Sie Regeln zu Sicherheit und zum Ausschluss von Leistungsüberwachung.

Eine DSFA ist in der Regel nicht nötig, solange keine Personen aufgezeichnet werden; beziehen Sie die Datenschutzbeauftragte ein, wenn Kameradaten von Mitarbeitenden in den Zwilling gelangen. Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung) durch Schulungen zu den Grenzen der Simulation und zur Realitätslücke. Beginnen Sie mit einer Zelle und einer kleinen Engineering-Pilotgruppe, kommunizieren Sie, dass Simulation die Inbetriebnahme verkürzt und kein Personal ersetzt, und gehen Sie auf Sorgen vor veränderten Tätigkeiten ein. Die Menschen behalten die Kontrolle: Jede in der Simulation trainierte Policy durchläuft vor dem realen Betrieb von Menschen beaufsichtigte Tests mit Sicherheitsfunktionen.

Leitfäden: GUIDE-008, GUIDE-009, GUIDE-004.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): abhängig vom Einzelfall. Simulation selbst hat minimales Risiko. Eine trainierte Policy, die als Sicherheitsbauteil einer Maschine wirkt, ist nach Art. 6 Abs. 1 und Anhang I hochriskant (die Maschinenverordnung (EU) 2023/1230 gilt ab 20. Januar 2027), wobei die Pflichten für Hochrisiko-Systeme bei solchen Produkten ab August 2028 gelten (Digital Omnibus, VO (EU) 2026/1744) [7][8]. Reine F&E-Nutzung vor dem Inverkehrbringen fällt weitgehend nicht in den Anwendungsbereich (Art. 2 Abs. 8). Emotionserkennung am Arbeitsplatz und andere Praktiken nach Art. 5 sind verboten und dürfen nicht in Roboter- oder Zwilling-Datenpipelines aufgenommen werden.
• Maschinensicherheit: Die Maschinenverordnung, ISO 10218 (Industrieroboter), ISO/TS 15066 (kollaborativer Betrieb) und ISO 13849 verlangen weiterhin überprüfbare Sicherheitsfunktionen; gelernte Policies benötigen deterministische Sicherheitsebenen und dokumentierte Verifikation. Simulation kann die Validierung unterstützen, aber nicht ersetzen.
• DSGVO: Zwillinge von Arbeitsplätzen können Bewegungen, Gesichter oder Stimmen von Beschäftigten erfassen (Scans, Kamera-Logs); entfernen oder anonymisieren Sie diese, beziehen Sie den Betriebsrat ein (BetrVG in Deutschland), führen Sie eine DSFA durch, wo Beschäftigtenüberwachung möglich ist. Synthetische Daten verringern diese Pflicht, heben sie aber nicht auf, wenn sie aus echten Personen erzeugt wurden.
• IP und Lizenzen: Prüfen Sie Lizenzen für CAD, Scans, Assets, Simulatoren und Modelle (z. B. nicht-kommerzielle Bedingungen).
• Cybersicherheit: Zwillinge enthalten detaillierte Anlagendaten; NIS2 und der Cyber Resilience Act können gelten; segmentieren Sie die Umgebung.
• Gegenmaßnahmen: zurückgehaltene und gegnerische Testszenarien, gestufter Rollout, Geschwindigkeits- und Kraftgrenzen, unabhängige Sicherheitssteuerung, Drift-Überwachung von Zwilling gegenüber Realität.

Erste Schritte

1. Wählen Sie eine enge Aufgabe mit klarer Erfolgskennzahl (z. B. eine Teileklasse greifen, einen Gang zur Fortbewegung).
2. Erstellen oder importieren Sie ein genaues Modell von Roboter und Zelle (URDF/USD); protokollieren Sie reale Daten, um Aktuator- und Reibungsparameter anzupassen.
3. Erstellen Sie einen Prototyp in MuJoCo/MJX oder Isaac Lab auf einer GPU; fügen Sie die Domänenrandomisierung schrittweise hinzu.
4. Testen Sie die Policy am realen Roboter mit reduzierter Geschwindigkeit und zertifizierter Sicherheitsebene; erfassen Sie die Sim-to-Real-Lücke.
5. Speisen Sie reale Logs in den Zwilling zurück; skalieren Sie auf weitere Aufgaben erst, wenn die Lücke gemessen und stabil ist.

Quellen

1. NVIDIA Isaac Lab (open-source robot learning framework) - https://github.com/isaac-sim/IsaacLab
2. NVIDIA Cosmos world foundation models - https://github.com/nvidia-cosmos
3. Google DeepMind - MuJoCo Playground (paper, arXiv 2502.08844) - https://arxiv.org/abs/2502.08844
4. OpenAI et al. - Solving Rubik's Cube with a Robot Hand - https://arxiv.org/abs/1910.07113
5. MuJoCo / MJX documentation - https://mujoco.readthedocs.io/
6. Hugging Face LeRobot - https://github.com/huggingface/lerobot
7. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Regulation (EU) 2023/1230 (Machinery Regulation) - https://eur-lex.europa.eu/eli/reg/2023/1230/oj