Was den Roboter-Einsatz bremst: Agility nennt drei Bremsen

Auf dem RoboCon Physical AI Salon in San Francisco diskutierten Agility Robotics und das Simulationsunternehmen Moonlake über den Alltag mit Robotern. Ihr Fazit: Das Modell ist selten das Problem. Es scheitert eher an Rechenleistung, Kontaktphysik und der Frage, wem die Betriebsdaten gehören.

Bremse eins: die Simulation lügt ein bisschen. Vivek Ramaswamy von Agility beschreibt Simulation als Filter, nicht als Ersatz. Politiken werden zuerst simuliert, die Hardware bekommt nur die Fälle, bei denen die Simulation unsicher ist. Sharon Lee von Moonlake nutzt dafür mehrere Engines, darunter MuJoCo und Drake. Ihr Punkt: Ein Bild kann noch so echt aussehen — stimmt die Physik nicht, bricht die Politik in der Halle.

Was besonders schwer ist. Kontakt. Kräfte zwischen Greifer und Bauteil, zwischen Fuß und Lagerboden, auch bei nasser Fläche. Dazu verformbare Objekte und Prozesse, bei denen sich der Zustand des Materials ändert. Das heißt konkret: Genau die Aufgaben, bei denen Hallenböden schmutzig und Kartons weich sind, brauchen die meisten echten Tests.

Bremse zwei: das Modell muss zur Halle passen. Ramaswamy stellt infrage, ob es für Kundenaufgaben immer ein großes Basismodell braucht. Rechenleistung, Stromverbrauch und Verzögerung begrenzen, was wirtschaftlich auf dem Roboter läuft. Sein Vorschlag: Planung darf in die Cloud, die schnelle Regelung bleibt am Gerät. Lee ergänzt kleinere Modelle, die auf eine Aufgabe und eine Umgebung zugeschnitten sind.

Bremse drei: wem gehören die Daten. Ein Lagerkunde fragte, ob aufgezeichnete Betriebsdaten zum Training der Modelle verwendet werden — es ging um Abläufe, die er nicht teilen will. Selbst der Nachbau einer Halle für die Simulation braucht eine Einigung darüber, was mit den Daten passiert. Das ist kein Technikthema, sondern eine Vertragsfrage, und sie kommt vor der Bestellung.

Was der Kunde wirklich messen sollte. Ramaswamy sagt, Erfolgsquoten aus Benchmarks interessierten seine Kunden wenig. Sie wollten wissen, ob ihre eigene Aufgabe erledigt wird und ob die Leistung über viele Wiederholungen hält. Wie hoch eine akzeptable Fehlerquote sein darf, hängt vom Preis eines Fehlers ab. Für die Einführung heißt das: Testreihe mit der eigenen Aufgabe, nicht mit der Demo des Herstellers.