Ein Roboter, der eine Tasse fallen lässt, hat bereits versagt. Die operative Frage lautet, ob seine Steuerung den Fehler früh genug erkennt, um anzuhalten, sich zurückzuziehen, Hilfe anzufordern oder eine sicherere Wiederherstellung zu versuchen. Diese Unterscheidung gewinnt an Bedeutung, während Vision-Language-Action-Modelle (VLA) von kurzen Demonstrationen zu längeren Manipulationsaufgaben übergehen. Ein kleiner Fehler im ersten Schritt kann dort eine Folge zunehmend unpassender Aktionen auslösen.

Ein kollaborativer Roboterarm hält vor dem Greifen einer Tasse in einem Forschungslabor inne und veranschaulicht die frühe Fehlererkennung.

Ein am 3. September 2026 bei arXiv eingereichtes Preprint namens FailureSpot konzentriert sich auf genau dieses schmale, aber folgenreiche Problem. Die Arbeit von Jie Ma, Zongxi Liu und Yi Zhu schlägt keine weitere allgemeine Roboterpolitik vor. Sie ergänzt einen Detektor, der den Zeitpunkt identifizieren soll, an dem eine von einem VLA gesteuerte Trajektorie zu scheitern beginnt. Das zentrale Argument des Papers ist praktisch: Ein abschließendes Erfolgs- oder Misserfolgslabel ist für einen Roboter, der während der Bewegung eingreifen muss, zu grob.

Das Ergebnis gehört zur frühen Forschung. Es ist weder eine Produktzertifizierung noch ein Beleg dafür, dass ein Haushalts- oder Industrieroboter ohne Aufsicht betrieben werden kann. Die Bedeutung liegt an anderer Stelle. FailureSpot macht das Überwachungsproblem explizit, zeigt, warum vorhandene Labels oft irreführend sind, und bietet eine Möglichkeit, knappe menschliche Annotierungszeit auf die Teile einer Trajektorie zu lenken, die am wichtigsten sind. Das ist eine andere Einsatzfrage als die, ob ein Modell eine Aufgabe in einer sauberen Demonstration abschließen kann.

Der fehlende Moment zwischen Aktion und Fehler

Die meisten Roboterbewertungen verdichten einen gesamten Versuch zu einer einzigen Zahl. Eine Policy soll ein Objekt ablegen, eine Schublade öffnen oder eine mehrstufige Manipulationsfolge abschließen. Der Lauf erhält ein Erfolgs- oder Misserfolgslabel. Für den Vergleich von Systemen ist dieser Wert nützlich, doch er verbirgt das Ereignis, über das ein Bediener tatsächlich Bescheid wissen muss: Wann hörte der Lauf auf, sinnvoll voranzukommen?

Nehmen wir eine Pick-and-Place-Aufgabe mit langem Zeithorizont. Der Roboter kann das Objekt korrekt lokalisieren, sich nähern, den Greifer etwas zu früh schließen und anschließend Bewegungen ausführen, die auf der falschen Annahme beruhen, das Objekt sei sicher gefasst. Der erste Greiffehler ist der Punkt, an dem ein Eingriff am wenigsten Aufwand verursacht hätte. Am Ende der Trajektorie schwingt der Roboter möglicherweise, wiederholt ähnliche Befehle oder bewegt sich zu einem Ort, der nicht mehr zur Aufgabe passt. Ein Klassifikator nach dem Lauf kann feststellen, dass der Versuch gescheitert ist. Er verhindert jedoch nicht automatisch die unnötigen Bewegungen oder die nächste unsichere Aktion.

FailureSpot formuliert das Ziel als Erkennung auf Zeitstempel-Ebene. Der Detektor fragt nicht nur, ob Trajektorie i gescheitert ist, sondern schätzt für jeden Zeitschritt, ob sich der Roboter in einem Fehlerzustand befindet, und sucht nach dem Beginn dieses Zustands. Nach der Definition des Papers beginnt ein Fehler, wenn der Roboter keinen sinnvollen Fortschritt mehr in Richtung des Aufgabenziels macht. Beispiele sind ein verfehltes Ziel, Feststecken oder Untätigkeit, unvorhersehbare Bewegungen im freien Raum sowie Aktionen, die nicht zur vorgesehenen Aufgabe passen.

Diese Perspektive verändert den Wert eines Detektors. Ein brauchbarer Alarm muss früh genug eintreffen, um eine sichere Reaktion auszulösen. Zugleich darf er nicht so viele Fehlalarme erzeugen, dass der Roboter unbrauchbar wird. Erkennungsverzögerung, Fehlalarme und die Wahl des Wiederherstellungsverhaltens sind mindestens ebenso wichtig wie eine herausgestellte Erfolgsquote.

Warum Trajektorien-Labels die falsche Lektion vermitteln

Das Paper benennt ein Aufsichtsproblem, das leicht übersehen wird. Wenn jeder Zeitschritt einer erfolglosen Trajektorie als Fehler markiert wird, behandelt der Trainingsdatensatz den normalen Teil dieses Laufs so, als sei er bereits schlecht gewesen. Ein Roboter kann sich mehrere Sekunden lang korrekt verhalten, bevor der erste Greifversuch misslingt. Ein Label auf Trajektorien-Ebene verteilt den Fehler jedoch rückwirkend auf die früheren Aktionen. Der Detektor erhält damit eine widersprüchliche Anweisung: Er soll normales Verhalten als Fehlersignal erkennen, nur weil später etwas schiefging.

Das ist keine nebensächliche Frage der Datenpflege. Die Grenze zwischen normaler Ausführung und Fehler ist genau das, was ein Laufzeitmonitor lernen muss. Wird diese Grenze verwischt, kann der Detektor zu früh auslösen, den Übergang verpassen oder Korrelationen lernen, die sich nicht auf eine neue Aufgabe übertragen lassen. Auch die Bewertung wird weniger aussagekräftig. Ein System kann bei einem Trajektorienwert ordentlich abschneiden und das Problem trotzdem zu spät erkennen, um Objekt, Roboter oder eine in der Nähe befindliche Person zu schützen.

Dichte Zeitstempel-Annotationen würden helfen, sind aber teuer. Menschliche Prüfer müssen Trajektorien ansehen, die erste folgenschwere Abweichung bestimmen und eine einheitliche Definition über verschiedene Policies und Aufgaben hinweg anwenden. Der Aufwand steigt schnell, wenn ein Forschungsteam viele Rollouts sammelt, mehrere Modelle testet oder seltene Fehlermuster abdecken möchte. Auch Fehlerdaten sind ungleich verteilt: Häufige Fehler lassen sich leichter sammeln als ungewöhnliche Kombinationen aus Unordnung, mehrdeutiger Wahrnehmung und einer ungünstigen Roboterkonfiguration.

FailureSpot behandelt Annotation daher als Problem der Ressourcenverteilung. Zuerst extrahiert die Methode schwache Signale aus den eigenen Aktionsblöcken des Roboters. Anschließend nutzt sie aktives Lernen, um dort detaillierte menschliche Labels anzufordern, wo der Detektor am unsichersten ist. Das Design beseitigt menschliches Urteil nicht. Es versucht, dieses Urteil auf Beispiele zu konzentrieren, die den Monitor voraussichtlich am stärksten verbessern.

Was der Detektor beobachtet

Die Methode nutzt Muster in den von der VLA-Policy vorgeschlagenen Aktionen zusammen mit den internen Repräsentationen der Policy. Das Paper hebt drei übergeordnete Signale für schwache Supervision hervor. Aufeinanderfolgende Aktionsblöcke können inkonsistent sein. Die Policy kann einfrieren oder untätig bleiben. Oder sie kann aggressive, zufällig wirkende Bewegungen erzeugen. Keines dieser Muster beweist in jeder Umgebung, dass eine Aufgabe gescheitert ist. Eine Pause kann beabsichtigt sein, und eine große Bewegung kann in einem geräumigen Arbeitsbereich korrekt sein. Als Ausgangssignale sind die Muster dennoch nützlich, weil sie sich aus protokolliertem Verhalten berechnen lassen, ohne dass ein Mensch jedes Einzelbild annotieren muss.

Die Wahl ist relevant, weil der Monitor damit nahe am Regelkreis sitzt. Ein visueller Prüfer bemerkt einen Fehler womöglich erst, nachdem ein Objekt gefallen oder der Greifer am Ziel vorbeigefahren ist. Ein aktionsbasierter Detektor kann untersuchen, was die Policy als Nächstes ausführen will, und möglicherweise Alarm schlagen, bevor die physische Folge sichtbar wird. Darin liegt zugleich seine Grenze: Der Aktionsstrom spiegelt die Interpretation der Szene durch die Policy wider. Eine selbstsicher falsche Policy kann daher gleichmäßige, intern konsistente Aktionen erzeugen.

Nach Angaben des Papers verwendet FailureSpot einen schlanken Detektor über der internen Repräsentation des VLA und untersucht Varianten mit einem Multilayer-Perzeptron sowie mit Long Short-Term Memory. Der Detektor wird nicht als Ersatz für Kollisionsprüfung, die Einhaltung von Gelenkgrenzen, Kraftmessung oder einen menschlichen Not-Halt beschrieben. Er ist eine Überwachungskomponente, die zusätzliche Hinweise darauf liefern kann, ob das Verhalten der Policy abdriftet.

Der Ablauf besteht aus zwei Phasen. Zunächst liefern aus Aktionen abgeleitete schwache Labels ein breites Vortrainingssignal, ohne eine dichte manuelle Annotation zu benötigen. Danach wählt aktives Lernen unsichere Trajektorien für eine Kennzeichnung auf Zeitstempel-Ebene aus. Mit diesen informativen Beispielen wird der Detektor anschließend feinjustiert. Im Prinzip soll dadurch die Menge der Annotationen sinken, die nötig ist, um dem Modell den Beginn eines Fehlers zu zeigen, während es weiterhin aus einem deutlich größeren Pool nicht annotierter Rollouts lernen kann.

Was das neue Paper tatsächlich belegt

Die Autoren berichten Verbesserungen bei der Erkennung von Fehlern auf Zeitstempel- und Trajektorien-Ebene über mehrere VLA-Policies hinweg. Das arXiv-Abstract behauptet nicht, dass die Methode physische Sicherheit allgemein löst. Das Paper sollte als Forschungsergebnis gelesen werden, nicht als validierter Sicherheitsnachweis. Sein stärkster Beitrag ist die Verbindung von drei Ideen: den Beginn eines Fehlers ausdrücklich definieren, Aktionsverhalten für schwache Supervision nutzen und detaillierte Labels für unsichere Fälle einsetzen.

Das Paper berichtet außerdem, dass verschiedene Policies unterschiedliche Fehlersignaturen zeigen. Nach den Beobachtungen der Autoren erzeugt π0 häufig wiederholte, aber erfolglose Greifversuche. π0-FAST produziert demnach eher übermäßige Pendelbewegungen, während OpenVLA häufig stagniert. Das ist ein nützlicher Hinweis für alle, die einen allgemeinen Monitor bauen wollen. Ein Detektor, der auf die charakteristischen Fehler einer Policy trainiert wurde, muss bei einer anderen Policy nicht unverändert funktionieren, selbst wenn beide denselben Roboter steuern.

Diese Abhängigkeit von der Policy wirkt in beide Richtungen. Interne Repräsentationen können wertvolle Signale über die Unsicherheit des Controllers oder den Verlust an Fortschritt enthalten. Sie sind aber keine universelle Sprache des Scheiterns. Ein neues Modell kann seine Aktionsblöcke, sein Timing oder sein bevorzugtes Wiederherstellungsverhalten verändern. Auch die Hardware verändert die Bedeutung einer Aktion: Ein Befehl, der an einem Arm harmlos ist, kann an einem anderen unerreichbar, zu schnell oder schlecht kalibriert sein. Überwachung muss deshalb über Policies, Verkörperungen, Controller-Einstellungen und Aufgabenverteilungen hinweg getestet werden.

Auch die berichtete Verbesserung sollte mit Vorsicht interpretiert werden, weil es sich um ein Preprint handelt. Sie ist nicht dasselbe wie eine unabhängige Sicherheitsbewertung in einer Fabrik, einem Lager, einer Klinik oder einem Haushalt. Simulationen und Benchmark-Trajektorien können wichtige Schwächen sichtbar machen. Sie bilden jedoch nicht jeden Sensordefekt, jedes Kontaktgeschehen, jeden mechanischen Fehler, jede Kommunikationsverzögerung, jede Unterbrechung durch Menschen oder jede Umweltveränderung nach, die ein eingesetzter Roboter erleben kann.

Wie die Methode in den breiteren Sicherheitsstapel passt

Fehlererkennung ist nur eine Schicht eines sicheren Roboters. Ein Monitor kann erkennen, dass ein Verhalten verdächtig geworden ist; das System braucht trotzdem eine Reaktionspolicy. Diese Reaktion kann darin bestehen, die Bewegung zu stoppen, die Position zu halten, in eine bekannte sichere Konfiguration zu fahren, ein Objekt loszulassen, Teleoperation anzufordern oder mit einem veränderten Plan erneut zu versuchen. Welche Wahl richtig ist, hängt von Roboter, Nutzlast, Umgebung und Aufgabe ab. Ein Alarm ohne festgelegten und getesteten Eingriffspfad ist ein Beobachtungsinstrument, kein Sicherheitsmechanismus.

Das entspricht dem Argument in Modular Safety Guardrails Are Necessary for Foundation-Model-Enabled Robots in the Real World, einem Preprint aus dem Jahr 2026 von Forschenden der Texas A&M University, Purdue, Amazon und NVIDIA. Die Autoren unterscheiden zwischen Aktionssicherheit, Entscheidungssicherheit und menschenzentrierter Sicherheit. Ein Controller kann physisch umsetzbar, aber semantisch falsch sein. Er kann einen Befehl verstehen und zugleich eine geometrische Einschränkung verletzen. Oder er kann eine Bewegung abschließen, die eine Person vernünftigerweise vermeiden wollte. Es ist unwahrscheinlich, dass ein einziges gelerntes Modul all diese Fälle abdeckt.

In einer solchen Architektur würde ein Detektor nach dem Vorbild von FailureSpot neben anderen Kontrollen arbeiten. Eine geometrische Schicht könnte Gelenk-, Geschwindigkeits-, Kraft- und Kollisionsgrenzen durchsetzen. Eine semantische Schicht könnte prüfen, ob gewähltes Objekt und Aktion zur Anweisung passen. Ein Fortschrittsmonitor könnte feststellen, ob die Aufgabe noch vorankommt. Eine Eingriffsschicht könnte bei Überschreiten einer Risikoschwelle einen Stopp oder eine Übergabe erzwingen. Diese Trennung ist nicht Selbstzweck. Sie macht einzelne Komponenten leichter testbar, aktualisierbar und prüfbar, wenn sich Umgebung oder Policy ändern.

Die Unterscheidung zwischen Fehlererkennung und Sicherheitsdurchsetzung ist besonders wichtig. Ein Detektor kann korrekt erkennen, dass der Roboter feststeckt, und trotzdem eine schnelle Kollision übersehen, die zwischen zwei Beobachtungen stattfindet. Umgekehrt kann ein Regler auf niedriger Ebene eine Kollision verhindern, ohne zu verstehen, dass der Roboter seit dreißig Sekunden versucht, das falsche Objekt zu greifen. Das sind verschiedene Fehlerklassen, die verschiedene Signale erfordern.

Das Benchmark-Problem ist größer als ein einzelner Detektor

Eine weitere aktuelle Forschungsrichtung zeigt, warum die Laufzeitüberwachung von Fehlern breiter bewertet werden muss. LIBERO-Safety führt einen Benchmark und eine Pipeline zur Datengenerierung für physische und semantische Sicherheit in VLA-Modellen ein. Das Projekt berichtet 19.664 kollisionsfreie Demonstrationen, stochastische sicherheitskritische Szenarien sowie Bewertungen über acht VLA-Modelle und zwei verkörperte Foundation-Modelle hinweg. Zu den ausdrücklich genannten Ergebnissen gehören ein Spannungsverhältnis zwischen Generalisierung und Sicherheit. Außerdem bleibt der Aufgabenabschluss durch schwache Trajektoriensynthese und semantische Fehlanpassung begrenzt.

Diese Fehlermuster sind nicht austauschbar. Ein Roboter kann kollisionsfrei bleiben und trotzdem scheitern, weil er anhält, schwingt, den Zeithorizont überschreitet oder ein semantisch falsches Objekt auswählt. Ein Monitor, der nur auf heftige oder sichtbar unruhige Bewegungen trainiert wurde, kann die leiseren Fehler übersehen, die bei praktischer Manipulation entscheidend sind. Nähert sich ein System sicher dem richtigen Objekt, beendet den Griff aber nie, ist das ein Fortschrittsproblem. Greift es dagegen reibungslos nach dem falschen Objekt, liegt ein Verankerungs- oder Grounding-Problem vor.

Das im ACL-2026-Tagungsband veröffentlichte Paper RoboFailRing verfolgt einen anderen Ansatz: retrieval-augmentierte Fehlererkennung und kausales Schlussfolgern für VLM-gestützte Manipulation. Die Bewertung umfasst mehr als 6.000 simulierte Fehlertrajektorien und 81 Manipulationsaufgaben. Die Autoren berichten eine Erfolgsrate von 80 Prozent bei der Fehlererkennung außerhalb der Trainingsverteilung, eine ungefähr halbierte mittlere Erkennungszeit und einen durchschnittlichen Zuwachs von 35 Prozent bei der Genauigkeit der Fehlerbegründung auf realen Systemen. Diese Zahlen stammen aus den eigenen Experimenten des Papers. Sie sind kein direkter Vergleich mit FailureSpot, da sich Methoden, Aufgaben, Datensätze und Metriken unterscheiden.

Zusammengenommen legen diese Studien nahe, dass eine nützliche Robotikbewertung mehr als den Aufgabenerfolg ausweisen sollte. Sie sollte festhalten, wann ein Fehler beginnt, wie schnell das System ihn bemerkt, wie oft es einen erfolgreichen Lauf unterbricht, ob es die wahrscheinliche Ursache erkennt und ob die anschließende Wiederherstellung das Risiko senkt. Physische Verstöße sollten von semantischen Irrtümern und unvollständigem, aber sicherem Verhalten getrennt werden. Ohne diese Details können zwei Systeme mit derselben Erfolgsquote sehr unterschiedliche operative Profile haben.

Was Betreiber vor dem Einsatz fragen sollten

Für ein Team, das einen VLA-Controller in Betracht zieht, lautet die praktische Lehre nicht, einen bestimmten Forschungsdetektor zu installieren und das Problem damit als gelöst zu betrachten. Entscheidend ist, Fehlerbehandlung zu einer ausdrücklichen Anforderung zu machen, bevor die Autonomie erweitert wird. Eine Einsatzprüfung sollte mit einer auf die Aufgabe bezogenen Fehlertypologie beginnen. Verfehlte Griffe, die Auswahl des falschen Objekts, zu hohe Kontaktkräfte, verdeckte Sensoren, Schwingungen, Leerlaufschleifen, unerreichbare Befehle, ein veraltetes Szenenverständnis und der Verlust der Kommunikation sind Beispiele, keine vollständige Liste.

Danach sollte das Team für jede Klasse den frühesten sinnvollen Eingriffspunkt bestimmen. Ein verfehlter Griff kann eine Pause und eine erneute Beobachtung erlauben. Eine Kraftspitze kann sofortiges Zurückziehen erfordern. Bei der Auswahl des falschen Objekts kann menschliche Bestätigung nötig sein, statt automatisch einen neuen Versuch zu starten. Eine Leerlaufschleife ist in einer Umgebung vielleicht harmlos, kann aber gefährlich werden, wenn der Roboter ein heißes, scharfes oder zerbrechliches Objekt hält. Die Ausgabe des Monitors muss mit diesen Konsequenzen verbunden sein.

Bei der Datensammlung sollte die vollständige zeitliche Abfolge erhalten bleiben, nicht nur das Endergebnis. Protokolle brauchen die Anweisung, Kamerabeobachtungen, den Roboterzustand, Aktionsblöcke, Controller-Transformationen, Kontakt- oder Kraftmessungen, sofern vorhanden, Eingriffsereignisse und das abschließende Aufgabenergebnis. Speichert die Datenpipeline nur erfolgreiche Videos und für Fehler einen binären Wert, entfernt sie einen großen Teil der Informationen, die zum Lernen eines Detektors für den Fehlerbeginn notwendig sind.

Die Bewertung sollte auch die Kosten von Fehlalarmen enthalten. Ein Monitor, der jedes Mal stoppt, wenn eine Policy pausiert, kann in einem Benchmark vorsichtig wirken, im Betrieb aber nutzlos sein. Zu viele Eingriffe erhöhen den Verschleiß, senken den Durchsatz und können dazu führen, dass Bediener Warnungen ignorieren. Das Ziel ist nicht maximale Empfindlichkeit für sich genommen. Es geht um ein vertretbares Verhältnis aus früher Erkennung, übersehenen Fehlern, falschen Stopps und der Schwere der Ereignisse, die durchrutschen.

Schließlich muss der Monitor außerhalb der Bedingungen geprüft werden, unter denen er trainiert wurde. Verändert werden sollten Objektplatzierung, Beleuchtung, Unordnung, Formulierung der Anweisung, Kameraperspektive, Nutzlast, Aktionsskalierung und Roboterhardware. Bekannte Aufgaben mit unbekannten Anordnungen und unbekannte Aufgaben mit bekannten Objekten gehören beide in die Prüfung. Dieselbe Policy sollte mit unterschiedlichen Controller-Einstellungen laufen. Ein Fehlerdetektor, der nur für das exakt beim Training verwendete Modell und dessen Kalibrierung funktioniert, kann ein trügerisches Gefühl von Abdeckung erzeugen.

Warum dies eine Einsatzgeschichte und nicht nur eine Modellgeschichte ist

Die Robotikbranche hat über Jahre hinweg die Fähigkeit verbessert, eine plausible Aktion zu erzeugen. Die nächste operative Schicht besteht darin zu entscheiden, ob diese Aktion noch sinnvoll ist, wenn die Welt nicht mitspielt. Objekte rutschen. Menschen betreten den Arbeitsbereich. Visuelle Annahmen veralten. Der erste Greifversuch misslingt. Ein Modell, das selbstsicher weitermacht, ist im sicherheitsrelevanten Sinn nicht autonom; es bleibt lediglich hartnäckig.

FailureSpot ist wertvoll, weil die Arbeit den Moment isoliert, in dem diese Hartnäckigkeit enden sollte. Schwache Aktionssignale adressieren die Kosten dichter Labels. Das aktive Lernen berücksichtigt zugleich, dass die informativsten Daten häufig nahe an der unsicheren Grenze zwischen Fortschritt und Fehler liegen. Die Arbeit macht außerdem einen größeren Punkt: Wenn VLA-Policies allgemeiner werden, können ihre Fehler weniger vorhersehbar und nicht weniger wichtig werden. Eine einzige Erfolgszahl kann diese Veränderung nicht beschreiben.

Kurzfristig zeichnet sich wahrscheinlich eine Überwachung in Schichten ab. VLA-Policies können Aktionen vorschlagen und Sprache interpretieren, während unabhängige Monitore Fortschritt, physische Grenzen, semantische Konsistenz und Unsicherheit verfolgen. Wenn diese Monitore widersprüchliche Signale liefern, sollte der Roboter ein konservatives Übergabe- oder Stoppverhalten besitzen, das an der tatsächlichen Maschine getestet wurde. Diese Architektur bringt zusätzlichen Entwicklungsaufwand mit sich. Sie verwandelt Fehler aber von einer Statistik nach Abschluss der Aufgabe in ein Ereignis, das das System ausdrücklich bewältigen soll.

Für Leserinnen und Leser, die Robotikversprechen bewerten, ist die nützlichere Frage daher einfach: Nicht nur „Wie oft hat der Roboter die Aufgabe beendet?“, sondern auch „Woran hat er erkannt, dass er nicht mehr auf dem Weg zum Abschluss war, und was tat er danach?“ Die Antwort verrät mehr über die Einsatzreife als ein weiteres ununterbrochenes Demonstrationsvideo.

Quellen und Forschungsstatus

FailureSpot ist ein am 3. September 2026 eingereichtes arXiv-Preprint und wird hier nicht als peer-reviewter Produktnachweis dargestellt. Der umgebende Kontext stammt aus den eigenen Preprints der Autoren, dem Eintrag von RoboFailRing in der ACL Anthology sowie den offiziellen Projekt- und Paper-Seiten von LIBERO-Safety. Die berichteten Metriken bleiben ihren ursprünglichen Studien zugeordnet; ein Ranking über die Papers hinweg ist nicht gemeint.

Die zentralen Quellen sind FailureSpot: Label-Efficient Timestamp-Level Failure Detection for Vision-Language-Action Models auf arXiv, RoboFailRing: Retrieval-Augmented and Language Grounding Failure Detection for VLM-enabled Robotic Manipulation in der ACL Anthology, LIBERO-Safety: A Comprehensive Benchmark for Physical and Semantic Safety in Vision-Language-Action Models sowie die offizielle LIBERO-Safety-Projektseite. Zum Sicherheitskontext gehört außerdem Modular Safety Guardrails Are Necessary for Foundation-Model-Enabled Robots in the Real World, ein Preprint von Forschenden der Texas A&M University, Purdue, Amazon und NVIDIA. Als weiterer Kontext ist das RSS-Paper Can We Detect Failures Without Failure Data? Uncertainty-Aware Runtime Failure Detection for Imitation Learning Policies aufgeführt. Diese Quellen werden nicht zu einer gemeinsamen Rangliste vermischt; jede berichtete Zahl gehört zu der Studie, aus der sie stammt.