Ai2 ToyBlocks: Planungsfehler von Bewegungsfehlern trennen

Mit dem neuen Framework ToyBlocks können Robotikteams kontrolliert untersuchen, ob eine Aufgabe an der übergeordneten Planung oder an der Bewegungsausführung scheitert. Das ist eine Forschungsumgebung, kein Nachweis für die Einsatzreife einer Policy in der Fabrik. Für Unternehmen lautet die unmittelbare Entscheidung: Lohnt sich ein klar begrenzter Evaluationspilot? Nicht: Darf das Modell bereits Produktionsanlagen steuern?

Was sich geändert hat

Am 6. November 2026 stellte Ai2 ToyBlocks und den Ansatz FoundationWorlds vor: bewusst eingegrenzte Simulationswelten mit generierten Aufgaben, Demonstrationen und Bewertungsmetriken. ToyBlocks beginnt mit einem Arm, der Klötze auf einem Tisch schiebt, dreht und stapelt. Der enge Rahmen erleichtert es, Änderungen an Trainingsdaten und Fehlerursachen gezielt zu untersuchen.

Das öffentliche Repository verbindet Simulation mit Isaac Sim und Isaac Lab, automatisch erzeugte Demonstrationen im LeRobot-Format, Trainingsinfrastruktur und Evaluation im geschlossenen Regelkreis. Eine hierarchische Policy kann ein übergeordnetes Entscheidungsmodell mit einer untergeordneten visuomotorischen Policy kombinieren. Beide Ebenen lassen sich jeweils durch eine Referenzkomponente, ein sogenanntes Orakel, ersetzen.

Der Unterschied zu einer erfolgreichen Videodemonstration liegt in den Vergleichsmöglichkeiten: Sie können untersuchen, warum ein Versuch scheitert und ein anderer gelingt. Daraus folgt nicht, dass jeder Ursachenbeitrag perfekt isoliert wird. Auch Beobachtungstransformationen, Aufgabendefinitionen und Simulatorverhalten gehören zum Experiment.

Zugang, Lizenzen und Betriebskosten

Die Installationsdokumentation nennt Linux, eine NVIDIA-GPU und einen Treiber mit Unterstützung für CUDA 12.8, ab Treiberversion 570. Der Docker-Pfad setzt x86_64-Linux und das NVIDIA Container Toolkit voraus. Dokumentiert ist ein Test mit einer RTX 5090 mit 32 GB. Eine getestete Konfiguration ist keine allgemeine Zusicherung zum minimalen Speicherbedarf.

Das Repository ist öffentlich; der Hauptcode steht unter Apache-2.0. Diese Lizenz gilt nicht automatisch für sämtliche Abhängigkeiten, Modelle und heruntergeladenen Assets. Das Repository weist ausdrücklich auf separate Lizenzen der Submodule und Assets hin. Die Einrichtung beschreibt zudem einen CC0-HDRI-Pool sowie einen anderen Indoor-HDR-Datensatz mit Beschränkung auf Forschungsnutzung. Prüfen Sie die tatsächlich ausgewählten Rendering-Assets, bevor Sie Daten für ein kommerzielles Projekt erzeugen. Unklare Nutzungsrechte gehören in eine rechtliche Prüfung.

Die Quellen beschreiben selbst betriebene Software, keinen gehosteten Dienst mit festem Nutzungstarif. Planen Sie GPU-Zeit, Videospeicher, Umgebungspflege und Entwicklungsaufwand getrennt ein. Der optionale Pfad für agentische Robotik ruft Modelle über OpenRouter auf und benötigt einen API-Schlüssel. Damit kommen externe Inferenzkosten und eine Prüfung der Datenflüsse hinzu. Ein lokaler Simulator beweist nicht, dass das gesamte Experiment lokal bleibt.

Die Investitionsfrage: Welche Ebene braucht die nächste Verbesserung?

Ein illustratives Beispiel ist eine Sortieraufgabe: Die Policy greift nach einem Klotz, bewegt ihn und endet mit der falschen Anordnung. Ein größeres Sprachmodell könnte eine falsche Planung verbessern. Es behebt nicht zwangsläufig eine fehlerhafte Koordinatentransformation, eine schwache Bewegungspolicy oder eine abweichende Simulationskonfiguration. Umgekehrt beseitigen zusätzliche Bewegungsdemonstrationen nicht automatisch eine falsche Aufgabenreihenfolge.

Die Evaluationsdokumentation unterstützt den Austausch beider Policy-Ebenen durch Orakel sowie die Wiedergabe aufgezeichneter Expertenaktionen. Beginnen Sie mit der vollständig gelernten Policy. Tauschen Sie anschließend eine Komponente aus und halten Sie Episodenmanifest und Bewertungsregeln konstant. Vergleichen Sie gelernte Planung mit Referenzausführung sowie Referenzplanung mit gelernter Ausführung.

Eine Verbesserung ist ein Hinweis zur Fehlerlokalisierung, kein sauber isolierter prozentualer Ursachenanteil. Der Austausch verändert Eingaben und Bewegungsverläufe für die andere Komponente. Auch Orakel können scheitern: Die dokumentierten Metriken erfassen feststeckende Orakelplanung und Fehler der untergeordneten Referenzausführung. Bewahren Sie diese Ergebnisse auf, statt die Referenz stillschweigend als fehlerfrei zu behandeln.

Das ergänzt Freigabeprüfungen für getrennte Fehlersegmente. Die neue Entscheidung betrifft hier die Zuordnung eines Robotikfehlers innerhalb einer kontrollierten Simulation, nicht die Auswahl einer allgemeinen Modellkennzahl.

Wiedergabe ist eine Referenz, keine Zusage identischer Abläufe

ToyBlocks kann eine Evaluation mit Roboterpose, Klotzpositionen und -größen, Tischhöhe und Ziel einer aufgezeichneten Episode initialisieren. Ein Prüfschritt vergleicht die rekonstruierte Szene mit der Aufzeichnung. So lassen sich Unterschiede im Versuchsaufbau erkennen, bevor Sie Policies vergleichen.

Ai2 beschreibt die Reproduzierbarkeit jedoch ausdrücklich als statistisch, nicht als bitgenau. Parallele Umgebungen teilen eine PhysX-Szene. Batch-Zusammensetzung, Warteschlangenreihenfolge, Rücksetzungen und geteilter Rendering-Zustand können Abläufe beeinflussen. Hardware, Treiber und Isaac-Versionen spielen ebenfalls eine Rolle. Die Determinismusoption reduziert Abweichungen auf einer Maschine zulasten der Geschwindigkeit, garantiert aber keine identischen Trajektorien auf anderer Hardware.

Dokumentieren Sie deshalb Simulatorversion, GPU, Treiber, Anzahl paralleler Umgebungen, Episodenmanifest, Policy-Revision und Bewertungsoptionen gemeinsam. Nutzen Sie für auffällige Episoden einen Diagnosepfad mit einer einzelnen Umgebung und vergleichen Sie anschließend aggregierte Ergebnisse wiederholter Läufe. Eine kleine Verbesserung ist kein belastbarer Fortschritt, wenn sie innerhalb der beobachteten Schwankung der Referenz liegt. Wie bei der Validierung digitaler Zwillinge anhand realer Sensordaten ist nachvollziehbare Dokumentation notwendig, belegt aber noch keine physikalische Genauigkeit.

Prüfen Sie die Erfolgsdefinition vor dem Ergebnis

Bei generierten Aufgaben entsteht das Erfolgskriterium aus einem PDDL-Ziel sowie Bedingungen für ruhende Zielobjekte und einen geöffneten Greifer. PDDL beschreibt die Aufgabe logisch. Erfüllte Prädikate bedeuten, dass das kodierte Ziel erfüllt wurde, nicht automatisch sämtliche betrieblichen Anforderungen.

Die Metrikreferenz unterscheidet Erfolg zu irgendeinem Zeitpunkt von Erfolg am letzten Zeitschritt. Zusätzlich gibt es Teilfortschritt und kollisionsbezogene Ergebnisse. Ein kurzzeitig fertiger Stapel, der anschließend umfällt, darf ohne Erläuterung der Bewertungsregel nicht als stabil abgeschlossene Aufgabe gelten.

Besonders leicht lässt sich die Kollisionsbewertung missverstehen. Die dokumentierte Kollisionsmetrik der Evaluationsschleife verwendet die Verschiebung oder Drehung eines nicht zur Zielmanipulation gehörenden Klotzes als Kriterium. Sie erfasst damit nicht umfassend sämtliche Kontakte oder sicherheitsrelevanten Kräfte. Kontaktmessung pro Zeitschritt ist eine separat konfigurierbare Funktion mit zusätzlichem Speicherbedarf. Das Abschalten der Kollisionsbewertung verändert das Experiment; es beseitigt keine Kollision.

Abnahmematrix für einen Pilotversuch

Die folgende Matrix ist ein technischer Vorschlag auf Grundlage der dokumentierten Funktionen. Sie ist weder eine Ai2-Zertifizierungsprüfung noch das Ergebnis eines auf dieser Website durchgeführten Benchmarks.

Halten Sie einen eingefrorenen Prüfsatz außerhalb von Training und Generierung zusätzlicher Wiederherstellungsdemonstrationen. Wenn fehlgeschlagene Evaluationszustände in neue Trainingsbeispiele einfließen, bewerten Sie das geänderte Modell auf einem separaten, unberührten Prüfsatz. Sonst kann die Rückkopplung den Messwert verbessern, indem sie die Prüfaufgaben trainiert, statt die Generalisierung zu verbessern.

Was die Veröffentlichung offenlässt

ToyBlocks begrenzt die Domäne bewusst. Fortschritte bei Tischklötzen belegen keine Zuverlässigkeit bei öligen Metallteilen, nachgiebigen Verpackungen, wechselnder Beleuchtung oder einer realen Fertigungszelle. Sensorlatenz, Reglerverhalten und Kontaktdynamik benötigen eigene Prüfungen am Zielsystem. Die Veröffentlichung ist für Robotikforschung und industrielle KI-Teams relevant, die Evaluationsmethoden untersuchen. Sie ist kein schlüsselfertiges Angebot zur Fabrikautomatisierung.

Für diese Analyse wurden Ankündigung, Repository und Dokumentation geprüft. ToyBlocks wurde von uns nicht ausgeführt; Leistungsangaben wurden nicht unabhängig reproduziert. Daher werden hier weder Durchsatzwerte noch Genauigkeitsgewinne oder Wirtschaftlichkeitskennzahlen behauptet.

Erhalten Sie vor jedem physischen Versuch die unabhängige OT-Sicherheits- und Steuerungsgrenze. Simulationsergebnisse dürfen weder die Anlagenabnahme umgehen noch autonome Eingriffe freigeben. Für einen begrenzten Evaluationspilot können Sie eine Prüfung Ihrer industriellen KI-Implementierung anfragen: Definieren Sie den zu unterscheidenden Fehler, die aufzubewahrenden Nachweise und das Ergebnis, das die nächste Investition rechtfertigt oder stoppt.