AWS verbindet NVIDIA GR00T, Isaac Sim und Cosmos zu einer Physical-AI-Toolchain

Roboterarme in einer automatisierten Logistikumgebung als Illustration der AWS Physical AI Toolchain
AWS verbindet NVIDIA-Technologien für Robot Learning, Simulation und Modelltraining in einer gemeinsamen Entwicklungsinfrastruktur. Bild: Amazon Web Services / Symbolbild

Amazon Web Services (AWS) hat am 7. Oktober eine neue Physical-AI-Toolchain veröffentlicht, die Robotikunternehmen beim Training, Testen und Bereitstellen von KI-Modellen unterstützen soll. Die frei zugängliche Sammlung aus Referenzarchitekturen, Code und Automatisierungswerkzeugen integriert unter anderem NVIDIA GR00T, Isaac Sim, Isaac Lab und Cosmos in die AWS-Cloud.

Anders als ein neues Robotermodell soll die Toolchain vor allem die Entwicklungsinfrastruktur vereinfachen. Roboterhersteller können damit Trainingsdaten verarbeiten, Modelle anpassen, Bewegungen simulieren und deren spätere Ausführung auf echter Hardware vorbereiten.

AWS hat die Architektur und die technischen Komponenten öffentlich dokumentiert. Der Beispielcode ist auf GitHub verfügbar. Allerdings sind noch nicht sämtliche Bestandteile der geplanten End-to-End-Lösung fertiggestellt.

GR00T trainiert, Cosmos erzeugt Daten, Isaac Sim testet

Die Toolchain verbindet mehrere bestehende NVIDIA-Technologien, die unterschiedliche Aufgaben im Entwicklungsprozess übernehmen.

NVIDIA GR00T dient zum Anpassen von Vision-Language-Action-Modellen an konkrete Roboterdaten. Solche Modelle verbinden visuelle Wahrnehmung und Anweisungen mit physischen Aktionen. Isaac Lab ermöglicht Reinforcement Learning in zahlreichen parallelen Simulationsumgebungen.

Mit Cosmos können Entwickler zusätzliche synthetische Trainingsdaten und visuelle Varianten vorhandener Szenen erzeugen. Isaac Sim übernimmt die physikbasierte Simulation und Validierung, bevor eine trainierte Steuerung auf realer Hardware getestet wird.

NVIDIA OSMO koordiniert die verschiedenen Rechenaufgaben. AWS stellt dafür unter anderem GPU-Instanzen über EC2, Datenspeicherung mit S3 sowie Trainingskapazitäten über SageMaker und AWS Batch bereit.

Die Architektur ist modular aufgebaut. Entwickler können einzelne Komponenten verwenden, ohne die gesamte Toolchain übernehmen zu müssen.

Von Teleoperationsdaten bis zur Steuerung mit ROS 2

Ein typischer Ablauf beginnt mit Demonstrationsdaten, die beispielsweise durch die Fernsteuerung eines Roboters gesammelt werden. Die Toolchain unterstützt unter anderem Zarr-Daten und das LeRobot-Format sowie Roboterbeschreibungen im URDF-Format.

Die Daten werden anschließend für das Modelltraining verwendet und können durch synthetische Beispiele ergänzt werden. Nach der Validierung in der Simulation lassen sich optimierte Modelle für die Ausführung auf Edge-Hardware vorbereiten.

AWS sieht dafür unter anderem NVIDIA-Jetson-Systeme und AWS IoT Greengrass vor. Die eigentliche Robotersteuerung kann über ROS 2 angebunden werden. ROS 2 ist dabei die Schnittstelle zur Robotiksoftware und kein zusätzliches KI-Grundmodell.

Wichtig ist die Trennung zwischen Cloud und Roboter. Das Training großer Modelle und aufwendige Simulationen können in Rechenzentren stattfinden. Zeitkritische Bewegungssteuerung und sicherheitsrelevante Entscheidungen müssen dagegen mit ausreichend geringer Latenz auf der Maschine oder in ihrer unmittelbaren Umgebung ausgeführt werden.

Ein solches Zusammenspiel aus Cloud-Infrastruktur und lokaler Steuerung ist auch für die Bewertung fortgeschrittener Physical-AI-Systeme relevant, bei denen Reaktionszeiten und Hardwaregrenzen eine zentrale Rolle spielen.

AWS liefert ein Beispiel mit 27 Roboter-Demonstrationen

Für Entwickler enthält das öffentliche GitHub-Projekt ein konkretes Pick-and-Place-Beispiel. Verwendet werden ein industrieller UR3-Roboterarm, ein Robotiq-Greifer und 27 aufgezeichnete Teleoperationssequenzen.

Mit diesen Daten lässt sich der Trainingsablauf nachvollziehen, bevor eigene Roboter und Datensätze eingebunden werden. AWS liefert dafür Konfigurationen, Terraform-Module und technische Anleitungen.

Der Umfang des Beispiels zeigt allerdings auch die Grenzen der Veröffentlichung. 27 Demonstrationssequenzen belegen, dass sich ein Trainingsworkflow nachvollziehen lässt. Sie sind kein Nachweis dafür, dass daraus bereits eine universell einsetzbare oder industriell validierte Robotersteuerung entsteht.

Auch der Implementierungsstand unterscheidet sich zwischen den Komponenten. Nach dem aktuellen GitHub-Projekt sind unter anderem GR00T, Isaac Sim, Isaac Lab und OSMO als verfügbar ausgewiesen. Die standardisierte Edge-Deployment-Komponente ist dagegen noch geplant. Die zusätzliche Isaac-Lab-Arena-Evaluierung wird als Preview geführt.

Für Robotikunternehmen wird die Infrastruktur zum eigenen Kostenfaktor

Mit der Toolchain adressiert AWS einen Teil der Entwicklung, der in Roboterdemos selten sichtbar wird. Forschungsgruppen und Hersteller müssen bisher häufig Datenformate, GPU-Umgebungen, Simulationssoftware, Trainingsjobs und Deployment-Prozesse selbst miteinander verbinden.

Eine standardisierte Infrastruktur kann diesen Integrationsaufwand reduzieren. Das bedeutet jedoch nicht automatisch, dass Roboter dadurch zuverlässiger werden oder weniger reale Trainingsdaten benötigen.

Die entscheidenden technischen Probleme bleiben bestehen: Generalisierung auf neue Aufgaben, robuste Manipulation, Unterschiede zwischen Simulation und Realität sowie sichere Ausführung unter wechselnden Bedingungen. Wie stark die Modellarchitektur selbst dabei eine Rolle spielt, zeigt auch die Forschung zu World-Action-Modellen wie ModAR.

AWS nennt unter anderem den deutschen Humanoid-Hersteller NEURA Robotics im Umfeld seiner Physical-AI-Initiative. Für Unternehmen dieser Art könnte eine gemeinsame Entwicklungsinfrastruktur insbesondere beim Übergang von einzelnen Prototypen zu größeren Roboterflotten relevant werden.

Die Veröffentlichung ist damit weniger ein Durchbruch bei der Roboterintelligenz als ein Infrastrukturangebot für deren Entwicklung. Ob die Toolchain den Weg vom trainierten Modell zum produktiven Robotereinsatz tatsächlich verkürzt, müssen reale Projekte und vollständig implementierte Deployment-Prozesse erst belegen.