In der Simulation trainierte Policies versagen regelmäßig auf der Hardware. Die Gründe sind konkret und behebbar — aber nur, wenn man die gesamte Pipeline versteht: physikalische Simulation, Domänen-Randomisierung, synthetische Datengenerierung, Sim-to-Real-Transfer, virtuelle Inbetriebnahme und Edge-Inferenz auf dem Roboter. Dieser Leitfaden erläutert jede Phase, behandelt die führenden Plattformen (NVIDIA Isaac Sim, Gazebo, MuJoCo), geht durch VLA-Policy-Architekturen und ordnet die Sicherheitsanforderungen nach ISO 10218 / ISO TS 15066 / IEC 61508 ein, die die KI-Steuerung in produktiven Roboterzellen regeln.
Zuletzt geprüft: Mai 2026
Sim-to-Real-Transfer ist der Prozess, eine Roboter-Steuerungs-Policy — eine Funktion, die Sensorbeobachtungen auf Aktorbefehle abbildet — vollständig oder überwiegend in der Simulation zu trainieren und sie dann auf physischer Hardware einzusetzen. Die zentrale Herausforderung besteht darin, dass kein Simulator die reale Physik, Wahrnehmung und Aktordynamik perfekt nachbildet. Das Schließen der daraus resultierenden Leistungslücke erfordert eine systematische Pipeline: hochpräzise physikalische Simulation, Domänen-Randomisierung, synthetische Datengenerierung, Hardware-in-Loop-Validierung und sorgfältige Edge-Inferenz-Bereitstellung. Richtig umgesetzt, macht sie die groß angelegte Erfassung realer Daten überflüssig; falsch umgesetzt, versagt der Roboter bei seiner ersten Interaktion mit der physischen Welt.
Eine vollständig in der Simulation trainierte und direkt auf der Hardware eingesetzte Roboter-Policy versagt — oft sofort, mitunter katastrophal. Das ist keine Überraschung; es ist eine erwartete Folge der grundlegenden Diskrepanz zwischen Simulation und Realität. Genau zu verstehen, wo und warum Policies versagen, ist die Voraussetzung für den Entwurf einer Pipeline, die Policies hervorbringt, die tatsächlich übertragbar sind.
Die Lücke hat zwei Dimensionen. Die erste ist physikalisch: Simulatoren approximieren Kontaktdynamik, Reibung, Aktorverhalten und Sensorcharakteristik. Diese Approximationen sind unvermeidlich — selbst die hochpräzisesten Physik-Engines treffen vereinfachende Annahmen, die von der Realität in einem Ausmaß abweichen, das für eine Steuerungs-Policy bedeutsam ist. Die zweite Dimension ist die Wahrnehmung: simulierte Kameras rendern idealisierte Beleuchtung, Textur und Geometrie. Reale Kameras begegnen Bewegungsunschärfe, strukturiertem Rauschen, spiegelnden Reflexionen und Umgebungsvariationen, die die Policy im Training nie gesehen hat.
Die praktische Folge ist ein Aktionsverteilungs-Shift: Die Policy hat eine Abbildung von simulierten Beobachtungen auf Aktionen gelernt, und wenn reale Beobachtungen (die sich von simulierten auf die oben beschriebene Weise unterscheiden) präsentiert werden, erzeugt die Policy Aktionen, die zur erwarteten Simulationsbeobachtung passen, nicht zur tatsächlich empfangenen realen. Dies äußert sich in unregelmäßiger Bewegung, Greiffehlern und im schlimmsten Fall in unsicherer, unkontrollierter Bewegung.
Domänen-Randomisierung ist die primäre Gegenmaßnahme: Durch Training über eine breite Verteilung simulierter Bedingungen (variierte Reibung, variierte Beleuchtung, variierte Objektposen) lernt die Policy Repräsentationen, die über jede einzelne Simulationskonfiguration hinaus generalisieren. Die reale Welt wird zu einer weiteren Stichprobe aus dieser Verteilung — eine, die die Policy nicht gesehen hat, deren Eigenschaften aber in den Bereich fallen, für den sie trainiert wurde. Das funktioniert in dem Maße, in dem die reale Welt innerhalb der Randomisierungs-Hülle liegt. Sicherzustellen, dass dies der Fall ist, erfordert eine sorgfältige Systemidentifikation.
Simulatoren rendern idealisierte Texturen, Beleuchtung und Objektgeometrie. Hardware-Kameras begegnen Bewegungsunschärfe, spiegelnden Glanzlichtern, Staub und perspektivischen Verzerrungen, die die Policy nie gesehen hat. Selbst kleine Wahrnehmungsabweichungen verursachen einen katastrophalen Aktionsverteilungs-Shift.
Kontaktdynamik — Reibung, Nachgiebigkeit, Spiel, Kabelspannung — ist bekanntermaßen schwer präzise zu modellieren. Auf Starrkörper-Simulationsannahmen trainierte Policies versagen sofort beim Greifen verformbarer Objekte oder beim Betrieb auf unebenen Fabrikböden.
Reale Servoregler weisen Latenz, Stromgrenzen, thermische Sättigung und Spiel auf. Simulationen nehmen typischerweise sofortige, perfekte Aktorik an. Eine Policy, die in der Simulation präzises Timing ausnutzt, kämpft gegen die Hardware.
IMUs driften, Kraft-/Momentsensoren sind temperaturabhängig, Tiefenkameras haben strukturiertes Rauschen. Policies, die nicht auf realistischen Sensorrauschverteilungen trainiert wurden, versagen beim Einsatz auf realer Hardware.
Die Simulation kann nicht jede reale Konfiguration vorhersehen: leicht fehlplatzierte Teile, beschädigte Verpackung, Feuchtigkeitseinflüsse auf die Greiferreibung. Die Abdeckung des gesamten Long-Tail realer Bedingungen ist die grundlegende Herausforderung.
In der Simulation ist der Ground-Truth-Zustand stets verfügbar. Auf der Hardware muss der Zustand aus verrauschten Sensoren abgeleitet werden. Policies, die von präzisen Posenschätzungen abhängen, brechen, wenn die Schätz-Pipeline Unsicherheit einführt.
Ein produktiver Sim-to-Real-Einsatz ist kein einzelner Algorithmus — er ist eine Pipeline aus sechs eigenständigen Phasen, jede mit eigenem Werkzeug, eigenen Entscheidungspunkten und Versagensmodi. Die Phasen sind sequenziell: Die Qualität jeder Phase setzt die Obergrenze für die nächste.
Im Folgenden wird jede Phase so beschrieben, wie Hyperion sie in Industrierobotik-Projekten umsetzt. Plattformverweise sind neutral — die Pipeline funktioniert mit jeder der wichtigsten in Abschnitt 3 beschriebenen Simulationsumgebungen.
Erstellung eines hochpräzisen Physikmodells des Roboters, seines Endeffektors, des Arbeitsraums und aller relevanten Objekte. Starrkörper- und Mehrkörperdynamik, Kontaktmodelle (Coulomb-Reibung, weicher Kontakt) und kinematische Zwangsbedingungen werden hier festgelegt. Die Qualität des Physikmodells setzt die Obergrenze für den nachgelagerten Transfer.
Schlüsselentscheidungen
Werkzeuge
Gezieltes Variieren physikalischer und visueller Parameter über Trainingsepisoden hinweg, um die Policy zu zwingen, generalisierende Repräsentationen zu lernen. Randomisierung wirkt als Regularisierer: Eine Policy, die unter einer breiten Verteilung von Simulationsbedingungen erfolgreich ist, bewältigt mit höherer Wahrscheinlichkeit die spezifischen (unbekannten) Bedingungen des realen Einsatzes.
Schlüsselentscheidungen
Werkzeuge
Erzeugung umfangreicher Trainingsdatensätze aus der Simulation: RGB-D-Bilder mit perfekten Ground-Truth-Labels, 6-DoF-Posenannotationen, Segmentierungsmasken und Trajektorien-Demonstrationen. Synthetische Daten überbrücken den Annotationsengpass, der überwachtes Lernen aus realen Daten begrenzt.
Schlüsselentscheidungen
Werkzeuge
Anwendung von Transfertechniken zum Schließen der Restlücke nach der Domänen-Randomisierung. Die Systemidentifikation gleicht Simulationsparameter an reale Hardwaremessungen an. Adaptionsschichten (RAPID, RMA oder ähnlich) konditionieren die Policy auf einen gelernten Kontextvektor, der reale Umgebungseigenschaften aus kurzen Interaktionsfenstern kodiert.
Schlüsselentscheidungen
Werkzeuge
Vor dem Einsatz auf physischer Hardware wird die trainierte Policy in einem digitalen Zwilling der Produktionszelle ausgeführt — einschließlich SPS-Logik, Fördererzeitsteuerung und Roboter-zu-Roboter-Koordination. Die virtuelle Inbetriebnahme erkennt Integrationsfehler (Timing-Konflikte, Arbeitsraum-Kollisionen, unerwartete Zustandsmaschinenübergänge), ohne Hardwareschäden zu riskieren.
Schlüsselentscheidungen
Werkzeuge
Einsatz der trainierten Policy auf der bordseitigen Recheneinheit des Roboters für Echtzeit-Inferenz. Latenz, Speicherbedarf und Leistungsbudget sind die zentralen Beschränkungen. Policies werden typischerweise auf INT8 oder FP16 quantisiert und mit TensorRT oder ONNX Runtime für die Zielhardware (NVIDIA Jetson, Orin oder AMD Kria SOM) kompiliert.
Schlüsselentscheidungen
Werkzeuge
Die drei dominierenden Simulationsplattformen für die Industrierobotik besetzen jeweils eine eigene Nische. Die Wahl richtet sich nach Aufgabentyp, Zielhardware, Team-Expertise und Lizenzbeschränkungen — nicht nach Anbieterpräferenz. Alle drei können einsatzfähige Policies erzeugen, wenn die Pipeline korrekt konfiguriert ist.
Offenlegung: Hyperion unterhält keine kommerzielle Partnerschaft, Wiederverkäufervereinbarung oder Zertifizierung von NVIDIA, Open Robotics, Google DeepMind oder einem anderen Simulationsplattform-Anbieter. Die Plattformbeschreibungen beruhen auf öffentlicher Dokumentation und Hyperions Umsetzungserfahrung.
Isaac Sim ist NVIDIAs Robotik-Simulationsumgebung auf Basis der Omniverse-USD-Plattform. Isaac Lab (Nachfolger von Isaac Gym) stellt die Trainingsinfrastruktur für bestärkendes Lernen bereit. GPU-parallelisierte Simulation ermöglicht das gleichzeitige Ausführen Tausender paralleler Umgebungen — entscheidend für die Anforderungen an die Stichprobeneffizienz moderner RL-Policies. Isaac Lab integriert APIs zur Domänen-Randomisierung, Importer für Roboter-Assets (URDF, MJCF) und eine standardmäßige Trainingsschleife für bestärkendes Lernen.
Industrieeignung
Höchster Fotorealismus durch Raytracing-Rendering; engste Integration mit der Edge-Inferenz-Hardware NVIDIA Jetson und AGX Orin. Beste Wahl, wenn visueller Realismus ein vorrangiges Sim-to-Real-Anliegen ist oder beim Einsatz auf NVIDIA-Edge-Rechenleistung.
Einschränkungen
Erfordert eine NVIDIA-GPU für die Simulation (kein AMD- oder reiner CPU-Pfad). Die Lizenzbedingungen erfordern für Produktionseinsätze eine Prüfung.
Gazebo ist der De-facto-Open-Source-Simulator für die ROS-2-Entwicklung. Gazebo Harmonic (2023+) ist die aktuelle stabile Version unter Open Robotics, mit einer Plugin-Architektur, die mehrere Physik-Backends unterstützt (DART, Bullet, ODE). Die native ROS-2-Integration über gz_ros2_control und ros_gz_bridge macht es zur natürlichen Wahl für Teams, die auf ROS 2 aufbauen. Die Open-Source-Lizenz und die aktive Community machen es für Proof-of-Concept- und Entwicklungsarbeiten kosteneffizient.
Industrieeignung
Am besten für ROS-2-native Entwicklungspipelines. Starke Community-Unterstützung für AMR-Navigation (Autonome Mobile Roboter), Manipulation und Sensorsimulation. Kostenlos und für den industriellen Einsatz anpassbar.
Einschränkungen
Physikgenauigkeit und Renderingqualität unter Isaac Sim. Paralleles Training erfordert eine eigene Infrastruktur (keine eingebaute GPU-parallele RL-Unterstützung).
MuJoCo (Multi-Joint dynamics with Contact) ist eine Physik-Engine, die eigens für Robotik- und Biomechanik-Simulation entwickelt wurde. Ihr Kontaktdynamikmodell gilt weithin als das genaueste, das für kontaktreiche Manipulationsaufgaben verfügbar ist. 2021 von Google DeepMind übernommen und für alle Nutzer kostenlos freigegeben, ist MuJoCo das bevorzugte Physik-Backend für die Manipulationsforschung (die meisten akademischen Manipulations-Benchmarks nutzen MuJoCo). Das MJCF-Modellformat ist ausdrucksstark und gut dokumentiert.
Industrieeignung
Beste Physikgenauigkeit für Manipulationsaufgaben — Greifen, Montieren, Schrauben, Handhabung verformbarer Objekte. Unerlässlich, wenn der Erfolg kontaktreicher Aufgaben von präziser Dynamiksimulation abhängt.
Einschränkungen
Nativ keine GPU-parallele Simulation (MJX, der JAX-Port, ergänzt begrenzte GPU-Unterstützung). Renderingqualität für das Training visueller Policies geringer als bei Isaac Sim.
Unsicher, welche Simulationsplattform zu Ihrer Aufgabe passt oder wo Ihre aktuelle Pipeline Leistung verliert? Hyperion führt einen fokussierten Discovery-Sprint durch — 2 Wochen —, der Ihre Roboterzelle abbildet, die spezifischen Sim-to-Real-Versagensmodi identifiziert, denen Sie wahrscheinlich begegnen, und eine Pipeline-Architektur für Ihre konkrete Aufgabe und Hardware erstellt.
Die neueste Generation von Roboter-Policies geht über aufgabenspezifisches RL oder Imitationslernen hinaus, indem sie die Steuerung in großen, vortrainierten Vision-Language-Modellen verankert. Diese VLA-Policies (Vision-Language-Action) bieten semantische Generalisierung — die Fähigkeit, natürlichsprachliche Anweisungen zu befolgen und neuartige Objektkategorien zu bewältigen — die herkömmliche aufgabenspezifische Policies nicht erreichen. Der Kompromiss liegt in Rechenaufwand und Inferenzlatenz. Im Folgenden werden die vier dominierenden Policy-Architekturen beschrieben, die in industrienaher Sim-to-Real-Arbeit verwendet werden.
Diffusion Policy modelliert Roboter-Aktionssequenzen als Entrausch-Diffusionsprozess über den Aktionsraum. Sie lernt eine Score-Funktion, die bei gegebener verrauschter Aktionsvorschlag und aktueller Beobachtung den Score-Gradienten in Richtung der demonstrierten Aktionsverteilung vorhersagt. In der Praxis: stark multimodal — kann mehrere gültige Aktionsmodi für dieselbe Beobachtung darstellen. Starke Generalisierung auf neue Objektpositionen. Zur Inferenzzeit rechenintensiver als MLP-basierte Ansätze.
Beste Eignung
Manipulationsaufgaben mit multimodalen Aktionsverteilungen: Pick-and-Place mit variablen Objektposen, Montage mit Bahnflexibilität.
ACT nutzt eine Transformer-Encoder-Decoder-Architektur, die per Imitationslernen (CVAE-artig) trainiert wird, um Blöcke künftiger Aktionen statt Einzelschritt-Aktionen vorherzusagen. Action-Chunking reduziert sich aufschaukelnde Fehler und verbessert die zeitliche Kohärenz. ACT wurde an beidhändigen Manipulationsaufgaben (ALOHA-Hardware) demonstriert und weist einen starken Realwelt-Transfer aus Teleoperations-Demonstrationen auf.
Beste Eignung
Beidhändige Montage, Falten und Aufgaben, die koordinierte Zweiarm-Bewegung erfordern. Funktioniert gut mit 50–200 menschlichen Teleoperations-Demonstrationen.
Ansätze in der RT-2-Linie passen große Vision-Language-Modelle (VLMs) so an, dass sie Roboteraktionen direkt als tokenisierte Sequenzen ausgeben. Das VLM-Backbone bietet ein reiches semantisches Verständnis des Szeneninhalts und ermöglicht eine Zero-Shot-Generalisierung auf neuartige, in natürlicher Sprache beschriebene Objektkategorien. OpenVLA (Open Source, 7B Parameter) macht diese Modellklasse ohne proprietäre Infrastruktur zugänglich.
Beste Eignung
Aufgaben, die semantisches Verständnis erfordern: „die rote Komponente aus dem Behälter nehmen“, „das Objekt auf das beschriftete Tablett legen“. Bewältigt neuartige Objektkategorien zur Inferenzzeit.
Modellfreies RL mit GPU-paralleler Simulation bleibt der dominierende Ansatz für Lokomotion und kontaktreiche Aufgaben, bei denen sich die Belohnungsfunktion entwerfen lässt. In Isaac Lab oder Brax mit Domänen-Randomisierung trainierte PPO (Proximal Policy Optimization) und SAC (Soft Actor-Critic) erzeugen Policies, die über die Restdynamiklücke auf die Hardware übertragen. Die Lokomotions-Policies von AnyBotics ANYmal und Boston Dynamics Atlas sind kanonische Beispiele.
Beste Eignung
Lokomotion (Laufroboter, AGV-Hindernisvermeidung), kontaktreiche Aufgaben (Mutter-/Schraubenmontage, Ventildrehen), bei denen Reward-Shaping machbar ist.
KI-trainierte Roboter-Policies existieren nicht außerhalb des sicherheitsregulatorischen Rahmens. Sie sind Steuerungsprogramme, und die Sicherheitsnormen, die Robotersysteme regeln, gelten für sie vollumfänglich. Das entscheidende Architekturprinzip — das Hyperion bei jedem Einsatz umsetzt — lautet: Die KI-Policy läuft im nicht sicherheitsgerichteten Kanal. Die Sicherheitsdurchsetzung wird stets unabhängig in der zertifizierten Sicherheitsschicht der Robotersteuerung umgesetzt.
Prinzip der Sicherheitsarchitektur: Der KI-Inferenz-Stack ist nicht das Sicherheitssystem. Geschwindigkeitsbegrenzung, Kraftbegrenzung, Kollisionsvermeidung und sicherheitsgerichtete überwachte Stopps werden in der zertifizierten Sicherheits-SPS der Robotersteuerung umgesetzt — unabhängig vom KI-Inferenzpfad und hierarchisch über ihm. Das KI-System operiert innerhalb der Sicherheitshülle; es definiert sie nicht.
Roboter und Robotikgeräte — Sicherheitsanforderungen für Industrieroboter
ISO 10218-1 betrifft Roboterhersteller; ISO 10218-2 betrifft Systemintegratoren von Robotern. Gemeinsam definieren sie die Sicherheitsanforderungen für Entwurf, Installation und Schutz von Industrierobotern. KI-gesteuerte Roboter müssen dieselben mechanischen und schutztechnischen Anforderungen erfüllen wie konventionell programmierte Roboter. ISO 10218-2 ist die für Physical-AI-Einsätze relevanteste Integrationsnorm.
KI-Implikation
Eine per Sim-to-Real trainierte Policy ist ein Steuerungssystem. Ihre Ausgaben (Gelenkgeschwindigkeiten, Kräfte) müssen durch sicherheitsgerichtete überwachte Stopps und Geschwindigkeits-/Kraftbegrenzung begrenzt werden — Funktionen, die in der Sicherheits-SPS der Robotersteuerung umgesetzt werden müssen, nicht im KI-Inferenz-Stack.
Roboter und Robotikgeräte — Kollaborierende Roboter
ISO TS 15066 spezifiziert Anforderungen an kollaborierende Robotersysteme, die in Szenarien direkten Mensch-Roboter-Kontakts betrieben werden. Sie definiert vier kollaborierende Betriebsarten: sicherheitsgerichteter überwachter Stopp, Handführung, Geschwindigkeits- und Abstandsüberwachung (SSM) sowie Leistungs- und Kraftbegrenzung (PFL). Für KI-gesteuerte Cobots sind SSM und PFL die relevantesten Betriebsarten.
KI-Implikation
KI-Policies müssen die vom SSM-System berechneten dynamischen Sicherheitszonen einhalten. Die Policy-Ausgaben müssen ratenbegrenzt und begrenzt werden, bevor sie die Servo-Schicht erreichen. Das KI-Inferenzsystem ist nicht das Sicherheitssystem — es operiert innerhalb der vom Cobot-Controller definierten Sicherheitshülle.
Funktionale Sicherheit sicherheitsbezogener E/E/PE-Systeme
IEC 61508 ist die grundlegende Norm zur funktionalen Sicherheit für elektrische, elektronische und programmierbar elektronische Systeme. Sie definiert Sicherheits-Integritätslevel (SIL 1–4) und den systematischen Prozess zur Entwicklung und Validierung sicherheitsbezogener Software. Ihre branchenspezifischen Ableitungen (IEC 62061 für Maschinen, ISO 26262 für die Automobilindustrie) regeln Sicherheitssysteme von Industrierobotern unmittelbar.
KI-Implikation
KI-Inferenzkomponenten, die an Sicherheitsfunktionen beteiligt sind (z. B. Kollisionsvermeidung, Kraftbegrenzung), müssen hinsichtlich funktionaler Sicherheit bewertet werden. In der Praxis besteht der Ansatz darin, den KI-Inferenzpfad im nicht sicherheitsgerichteten Kanal zu halten und Sicherheitsfunktionen unabhängig in einer zertifizierten Sicherheits-SPS oder der Sicherheitsschicht der Robotersteuerung umzusetzen. Die Architektur trennt KI-Autonomie von der Sicherheitsdurchsetzung.
EU-Maschinenverordnung — Ersatz für die Maschinenrichtlinie 2006/42/EG
Die neue EU-Maschinenverordnung (ab 2027 vollständig anwendbar) befasst sich ausdrücklich mit autonomen Maschinen und kollaborierenden Robotern. Sie verlangt Risikobeurteilungen für autonome Entscheidungsfunktionen und führt Anforderungen für Maschinen ein, die ihr Verhalten anpassen können. KI-gesteuerte Industrieroboter fallen eindeutig in ihren Anwendungsbereich.
KI-Implikation
KI-gesteuerte Industrieroboter, die nach 2027 auf dem EU-Markt in Verkehr gebracht werden, müssen ein Konformitätsbewertungsverfahren nach der Maschinenverordnung durchlaufen. Anforderungen an Entwurfsdokumentation, Risikobeurteilung und Marktüberwachung gelten für das KI-Steuerungssystem, nicht nur für die mechanische Struktur.
Im Folgenden eine sachliche Darstellung des Hintergrunds von Hyperion in Bezug auf Sim-to-Real-Robotik-Einsätze. Dies sind belegte Fakten, keine Marketingaussagen.
Hyperion hat Auralink entwickelt — eine Edge-deployte Agentenplattform mit über 400 Microservices und etwa 20 KI-Agenten. Auralink umfasst eine ROS-2-Brücke zur Steuerung physischer Infrastruktur und eine Schicht zur verteilten Agenten-Arbitrierung, das im arXiv-Preprint 2603.08736 beschriebene Architekturmuster. Die Systemarchitektur, die Multi-Agenten-Arbitrierung über verteilte Edge-Knoten ermöglicht — Planung, Wahrnehmung und Aktorik —, lässt sich direkt auf Industrierobotik-Einsätze übertragen. Das ist nicht hypothetisch; es ist eine Produktions-Codebasis (etwa 1,7 Mio. Codezeilen).
Ein auf arXiv veröffentlichter Preprint (2603.08736) behandelt autonome, Edge-deployte KI-Agenten für physische Infrastruktur — und adressiert die Herausforderungen verteilter Koordination, Zustandsschätzung und Echtzeitsteuerung, die den Sim-to-Real-Einsatz prägen. Hinweis: Dies ist ein Preprint, keine peer-reviewte Veröffentlichung. Seine Relevanz ist hier architektonisch: Die beschriebenen Muster zur Agenten-Koordination und Edge-Inferenz sind unmittelbar auf Einsätze in industriellen Roboterzellen anwendbar.
Hyperion hat ein Portfolio von KI-Ventures aufgebaut — interne F&E, nicht in Produktion. Die architektonische Tiefe, die zum Aufbau und Betrieb dieses Portfolios erforderlich ist — über Edge-Inferenz, Multi-Agenten-Koordination, ROS-2-Brücken und souveränen KI-Einsatz hinweg —, ist dieselbe Tiefe, die für Sim-to-Real-Robotikarbeit erforderlich ist. Das ist keine allgemeine KI-Beratung; es ist Systemtechnik.
Gründer Mohammed Cherifi verbrachte über 17 Jahre in der Automobil- und Embedded-Systems-Entwicklung, darunter Tätigkeiten bei der Renault-Nissan-Mitsubishi Alliance, Cisco und ABB. Dieser Hintergrund bedeutet, dass Hyperion die betrieblichen Randbedingungen von Produktionsumgebungen — Anforderungen an die Sicherheitszertifizierung, Echtzeit-Steuerungsarchitekturen und die Lücke zwischen Laborvorführungen und Einsätzen in der Werkhalle — aus direkter Erfahrung versteht.
Hyperion fertigt keine Roboter, liefert keine zertifizierten Sicherheits-SPS und ist kein Hardware-Integrator. Das Engagement-Modell umfasst KI-Architektur, Sim-to-Real-Pipeline-Design, Methodik des Policy-Trainings und Edge-Inferenz-Einsatz — in Zusammenarbeit mit dem Roboter-OEM und dem Systemintegrator, nicht als deren Ersatz. Diese Abgrenzung ist wichtig: Das richtige Engagement mit Hyperion ist jenes, bei dem Ihr OEM die Hardware übernimmt und Hyperion die Intelligenzschicht.
Ein produktiver Sim-to-Real-Einsatz ist ein systemtechnisches Projekt. Im Folgenden die Entscheidungspunkte, die jedes Robotik-Team bei der Integration adressieren muss.
Policy-Inferenz für Manipulation läuft typischerweise mit 10–50 Hz. NVIDIA Jetson AGX Orin (275 TOPS INT8) bewältigt Echtzeit-Inferenz für transformer-basierte Policies bis ~200M Parameter bei 30 Hz. Größere Policies (VLA-Skala, 7B+) erfordern einen GPU-Rechenknoten in der Zelle statt Edge-Hardware pro Roboter. Das AMD Kria K26 SOM ist eine Alternative für kostensensitive Einsätze bei kleineren Modellgrößen.
Der Policy-Knoten in ROS 2 abonniert Beobachtungs-Topics (Kamerastreams, Gelenkzustände, Kraft/Moment) und veröffentlicht Aktions-Topics (Gelenkgeschwindigkeitsbefehle oder kartesische Posenziele). Das ros2_control-Framework verbindet sich über Hardware-Interface-Plugins mit der Robotersteuerung. Ein separater Sicherheits-Watchdog-Knoten überwacht die Inferenzlatenz und löst einen sicherheitsgerichteten Stopp aus, wenn der Policy-Knoten seine Frist verfehlt.
Jede eingesetzte Policy-Version muss zusammen mit ihrer Trainingskonfiguration, ihren Domänen-Randomisierungsparametern und ihren Bewertungsmetriken versioniert werden. Ein Rollback-Verfahren muss vor dem Produktionseinsatz definiert und getestet werden. In der Praxis: mindestens zwei Policy-Versionen auf der Edge-Recheneinheit vorhalten, mit einem Hardware-Schalter oder einem ROS-2-Parameter zum Zurücksetzen auf die vorherige Version.
Reale Bedingungen weichen mit der Zeit von der Trainingsverteilung ab: Greiferverschleiß ändert die Reibung, das Erscheinungsbild der Objekte ändert sich mit dem Produktionslos, die Beleuchtung ändert sich saisonal. Ein Laufzeitmonitor, der die Policy-Unsicherheit verfolgt (Ensemble-Uneinigkeit oder MC-Dropout-Varianz) und eine menschliche Prüfung auslöst, wenn die Konfidenz unter einen Schwellenwert fällt, ist für produktionsreife Autonomie unerlässlich.
Die KI-Policy läuft im nicht sicherheitsgerichteten Kanal. Sicherheitsfunktionen (Geschwindigkeitsbegrenzung, Kraftbegrenzung, Kollisionsvermeidung per Sicherheitsscanner) laufen in der zertifizierten Sicherheits-SPS der Robotersteuerung, unabhängig vom KI-Inferenz-Stack. Diese Architektur erlaubt es der KI-Schicht, sicher auszufallen, ohne sich darauf zu verlassen, dass das KI-System seine eigenen Ausfälle erkennt. Die Sicherheits-SPS muss nach IEC 62061 auf den entsprechenden SIL ausgelegt sein.
Jeder Policy-Fehler auf der Hardware — verfehlter Griff, unerwarteter Kontakt, ausgelöste Wiederherstellung — sollte mit dem vollständigen Beobachtungsfenster (Kamerabilder, Gelenkzustände, Sensormesswerte) und der ergriffenen Aktion protokolliert werden. Dieser Fehlerdatensatz treibt die nächste Runde der Domänen-Randomisierungs-Erweiterung und Feinabstimmung an. Ohne systematische Fehlerprotokollierung kann sich die Policy nach dem Einsatz nicht verbessern.
Die Sim-to-Real-Lücke ist die Leistungsminderung, die eine Roboter-Policy beim Transfer von einer Simulationsumgebung auf physische Hardware erfährt. Sie entsteht, weil kein Simulator die reale Physik (Kontaktdynamik, Aktorverhalten, Sensorrauschen) oder das Erscheinungsbild (Beleuchtung, Textur, Tiefenkamerarauschen) perfekt erfasst. Domänen-Randomisierung verringert die Lücke durch Training über eine breite Verteilung von Simulationsbedingungen, doch eine Restlücke bleibt stets bestehen und muss durch Systemidentifikation, Hardware-Adaption oder Feinabstimmung auf realen Daten geschlossen werden.
Das hängt stark von der Aufgabenkomplexität, der Qualität der Domänen-Randomisierung und der verwendeten Transfermethode ab. Gut konzipierte Sim-to-Real-Pipelines mit aggressiver Domänen-Randomisierung können einen nahezu Zero-Shot-Transfer für Manipulationsaufgaben mit strukturierten Arbeitsräumen erreichen (Montage mit festen Objektpositionen). Für Aufgaben mit hoher Wahrnehmungsvariabilität (Bin-Picking zufällig orientierter Objekte) sind 100–500 reale Demonstrationen zur Feinabstimmung typisch. Residual-Policy-Ansätze (bei denen die Sim-Policy durch ein auf wenigen realen Daten trainiertes Residuum ergänzt wird) können mit nur 20–50 realen Trajektorien funktionieren.
Isaac Sim ist nicht erforderlich. MuJoCo (kostenlos, hohe Physikgenauigkeit) und Gazebo Harmonic (Open Source, native ROS-2-Unterstützung) sind beide produktionsreife Alternativen. Die Plattformwahl sollte sich nach dem Aufgabentyp richten (kontaktreiche Manipulation begünstigt die Physik von MuJoCo; ROS-2-Integration begünstigt Gazebo; das Training visueller Policies begünstigt die Renderingqualität von Isaac Sim) sowie nach der Ziel-Inferenz-Hardware (NVIDIA-Edge-Rechenleistung integriert sich sauberer mit dem Isaac-Ökosystem). Hyperion bevorzugt keine Plattform und unterhält keine kommerzielle Beziehung zu einem Simulator-Anbieter.
Sicherheitsnormen gelten für das Robotersystem, nicht speziell dafür, wie der Roboter programmiert ist. Eine KI-trainierte Policy ist ein Steuerungsprogramm: Ihre Ausgaben (Gelenkgeschwindigkeiten, kartesische Befehle) müssen durch dieselben sicherheitsgerichteten Funktionen begrenzt werden, die für jedes Roboterprogramm erforderlich sind — sicherheitsgerichtete überwachte Stopps, Geschwindigkeits- und Kraftbegrenzung. Das entscheidende Architekturprinzip ist, dass die KI-Inferenz im nicht sicherheitsgerichteten Kanal läuft und die Sicherheitsdurchsetzung unabhängig in der zertifizierten Sicherheits-SPS der Robotersteuerung umgesetzt wird. Das KI-System kann nicht das Sicherheitssystem sein.
Eine VLA-Policy ist eine Roboter-Steuerungs-Policy, die auf einem vortrainierten Vision-Language-Modell-Backbone (VLM) aufbaut und so feinabgestimmt ist, dass sie Roboteraktionen direkt ausgibt. Das VLM liefert ein reiches semantisches Szenenverständnis und ermöglicht eine Zero-Shot-Generalisierung auf neuartige, in natürlicher Sprache beschriebene Objekte. VLA-Policies sind angemessen, wenn die Aufgabe ein semantisches Szenenverständnis erfordert — „die Befestigung aus dem beschrifteten Behälter nehmen“ — und wenn ein großes vortrainiertes Modell auf Roboter-Demonstrationen feinabgestimmt werden kann. Für reine Lokomotion oder hochfrequente kontaktreiche Aufgaben, bei denen kleinere, schnellere Policies genügen, sind sie weniger geeignet.
Simulationsbasiertes Training erzeugt die Roboter-Policy. Die virtuelle Inbetriebnahme validiert, dass die trainierte Policy innerhalb der vollständigen Produktionszelle korrekt funktioniert — einschließlich SPS-Logik, Fördererzeitsteuerung, Roboter-zu-Roboter-Koordination und Sicherheitsverriegelungssequenzen — bevor physische Hardware eingesetzt wird. Die virtuelle Inbetriebnahme erkennt Integrationsfehler, die das Trainingssimulation nicht modelliert: Eine isoliert korrekt funktionierende Policy kann versagen, wenn der vorgelagerte Förderer Teile in unregelmäßigen Abständen liefert oder wenn die Bewegung eines benachbarten Roboters unerwartete Arbeitsraumkonflikte erzeugt.
Nein. Der Leistungsumfang von Hyperion ist KI-Architektur: Sim-to-Real-Pipeline-Design, Methodik des Policy-Trainings, Edge-Inferenz-Einsatz und ROS-2-Integration. Hardwareauswahl, mechanische Integration, CE-Kennzeichnung und Zertifizierung der Sicherheits-SPS werden vom Roboter-OEM und vom zertifizierten Systemintegrator durchgeführt. Hyperion arbeitet mit diesen Partnern zusammen; es ersetzt sie nicht. Diese Abgrenzung ist wichtig: Eine KI-Beratungsfirma für Hardwarelieferung oder Sicherheitszertifizierung heranzuziehen, ist eine Fehlbesetzung des Leistungsumfangs.
Ein fokussiertes Projekt — eine Aufgabe, ein Robotermodell, ein Arbeitsraum — dauert typischerweise 12–20 Wochen vom Scoping bis zu den ersten Produktionsversuchen. Das gliedert sich wie folgt: 2–4 Wochen für die Einrichtung der Simulationsumgebung und die Systemidentifikation; 4–6 Wochen für das Policy-Training mit Domänen-Randomisierung; 2–4 Wochen für den Sim-to-Real-Transfer und Hardwareversuche; 2–4 Wochen für die virtuelle Inbetriebnahme und die Produktionsintegration. Komplexe Mehrfachaufgaben- und Mehrroboter-Einsätze mit neuartigen Objektkategorien und Anforderungen an die Sicherheitszertifizierung können sich auf 6–12 Monate erstrecken.
Tobin, J. et al. (2017). "Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World."
Kontext: IEEE/RSJ IROS 2017. Wegweisende Arbeit, die Domänen-Randomisierung als Sim-to-Real-Transfertechnik für robotisches Greifen mithilfe synthetischer Trainingsdaten einführt.
Kumar, A. et al. (2021). "RMA: Rapid Motor Adaptation for Legged Robots."
Kontext: Robotics: Science and Systems (RSS) 2021. Führt das Teacher-Student-Adaptionsframework ein, das einen Zero-Shot-Sim-to-Real-Transfer für Vierbeiner-Lokomotion ermöglicht, indem ein Adaptionsmodul aus privilegiertem Simulationskontext gelernt wird.
Chi, C. et al. (2023). "Diffusion Policy: Visuomotor Policy Learning via Action Diffusion."
Kontext: Robotics: Science and Systems (RSS) 2023. Führt diffusionsbasierte Aktionsgenerierung für die Robotermanipulation ein; demonstriert einen starken Realwelt-Transfer aus Simulationsdemonstrationen.
Zhao, T. et al. (2023). "Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware."
Kontext: IEEE/RSJ IROS 2023 (ACT-Arbeit). Führt Action Chunking with Transformers für die beidhändige Manipulation ein; demonstriert einen Transfer von 50–200 Teleoperations-Demonstrationen auf reale Hardware.
Open Robotics / OSRF (2024). "Gazebo Harmonic Documentation."
Kontext: Offizielle Dokumentation zur physikalischen Simulation Gazebo Harmonic, zur ROS-2-Integration über gz_ros2_control und zur Sensor-Plugin-API.
NVIDIA Corporation (2024). "Isaac Lab: GPU-Accelerated Robot Learning."
Kontext: Offizielle Dokumentation zu NVIDIA Isaac Lab (Nachfolger von Isaac Gym): Training in parallelen Umgebungen, API zur Domänen-Randomisierung, Pipeline zum Import von Roboter-Assets.
DeepMind / Google (2024). "MuJoCo Physics Engine Documentation."
Kontext: Offizielle MuJoCo-Dokumentation zu Kontaktdynamikmodellen, dem MJCF-Format und dem MJX-JAX-Port für GPU-parallele Simulation.
ISO (2011). "ISO 10218-1/2: Safety Requirements for Industrial Robots."
Kontext: Internationale Norm mit Sicherheitsanforderungen für den Entwurf von Industrierobotern (Teil 1: Roboterhersteller) und die Systemintegration (Teil 2: Integrator). Überarbeitung im Gange (Stand 2024).
ISO (2016). "ISO/TS 15066: Collaborative Robots."
Kontext: Technische Spezifikation für kollaborierende Robotersysteme: vier Betriebsarten, biomechanische Schmerzschwellengrenzwerte für Leistungs- und Kraftbegrenzung sowie Anforderungen an die Geschwindigkeits- und Abstandsüberwachung.
IEC (2010). "IEC 61508: Functional Safety of E/E/PE Safety-Related Systems."
Kontext: Grundlegende Norm zur funktionalen Sicherheit; definiert die Level SIL 1–4 und systematische Anforderungen an den Sicherheitslebenszyklus. Übergeordnete Norm zu IEC 62061 (Maschinen) und ISO 26262 (Automobil).
Hyperion Consulting (2026). "arXiv preprint 2603.08736: Autonomous Edge-Deployed AI Agents for Physical Infrastructure."
Kontext: Preprint des Hyperion-Gründers (nicht peer-reviewt) zur verteilten Agenten-Arbitrierung und ROS-2-Brückenarchitektur für Edge-deployte KI-Systeme. Die Architekturmuster sind unmittelbar auf Einsätze in industriellen Roboterzellen anwendbar.
Ob Sie Ihre erste Sim-to-Real-Pipeline für eine Manipulationszelle entwerfen oder diagnostizieren, warum eine trainierte Policy auf der Hardware unterdurchschnittlich abschneidet — die früh getroffenen Architekturentscheidungen prägen alles Weitere. Hyperion bringt über 17 Jahre Erfahrung in Embedded Systems und Fertigungstechnik mit, ergänzt um eine produktive Erfolgsbilanz bei Edge-deployten KI-Agentensystemen. Beginnen Sie mit einem Gespräch.
Gründer & Leiter KI-Strategie
Mohammed Cherifi ist der Gründer von Hyperion Consulting und verfügt über mehr als 17 Jahre Erfahrung in der Automobil- und Embedded-Systems-Entwicklung. Er ist auf Physical-AI-Einsätze spezialisiert — und bringt operative Erfahrung von der Renault-Nissan-Mitsubishi Alliance, Cisco und ABB in die Industrierobotik und die Edge-Inferenz-Architektur ein.
End-to-End-Design der Sim-to-Real-Pipeline und Edge-Inferenz-Einsatzdienste
Der 6-schichtige Physical AI Stack für Robotik, Edge-KI und industrielle Automatisierung
Souveräne KI für die Fertigung: Mistral-Einsatz on-premise und in abgeschotteten Umgebungen
Compliance-Anforderungen für Hochrisiko-KI-Systeme in industriellen Umgebungen