Roboter sprintet schneller als Usain Bolt – und was das mit Rechenleistung zu tun hat

Hallo, liebe Leser, hier ist wieder Kora. Eine Meldung aus Peking hat mich diese Woche schmunzeln und gleichzeitig nachdenken lassen: Ein zweibeiniger Roboter ist die 100 Meter schneller gelaufen als Usain Bolt. Und ja – ein anderer hat dabei Feuer gefangen.

Was in Peking passiert ist

Bei den World Humanoid Robot Games treten aktuell 2.056 humanoide Roboter aus 16 Ländern gegeneinander an, verteilt auf 51 Disziplinen und über 1.000 Wettkämpfe – von Leichtathletik über Boxen bis Tennis. Der Aufreger: Der vom Beijing Humanoid Robot Innovation Center entwickelte „Tiangong Ultra“ absolvierte die 100 Meter in 9,39 Sekunden. Bolts Bestmarke von 2009 liegt bei 9,58 Sekunden. Das Modell „Lightning“ von Honor kam mit 9,47 Sekunden ebenfalls darunter. Über 400 Meter legte „Tiangong Ultra“ 38,16 Sekunden hin – der menschliche Rekord von Wayde van Niekerk liegt bei 43,03 Sekunden.

Bevor jetzt jemand die Menschheit abschreibt: Beim Abbremsen hörte die Überlegenheit abrupt auf. Mehrere Maschinen krachten nach der Ziellinie ungebremst in eine gepolsterte Wand und mussten anschließend eingesammelt werden. Zwei Roboter stürzten in einem Testlauf, einer davon fing Feuer und musste gelöscht werden. Sportlich fair verglichen ist das Ganze also ohnehin nicht – es geht hier nicht um Muskeln, sondern um Aktuatoren, Sensorik und vor allem um Software.

Warum mich das als Rechenzentrumsmensch interessiert

Ein Sprint dieser Art ist im Kern ein Echtzeit-Regelungsproblem. Der Roboter muss Lagesensoren, Gelenkwinkel und Bodenkontakt in sehr kurzen Intervallen auswerten und daraus Stellbefehle berechnen – auf dem Gerät selbst, denn für einen Umweg über ein Netzwerk bleibt bei diesen Zykluszeiten keine Zeit. Genau das ist der Grund, warum die Roboter beim Beschleunigen brillieren und beim kontrollierten Anhalten scheitern: Bremsen ist regelungstechnisch deutlich anspruchsvoller als geradeaus rennen.

Das eigentlich Spannende passiert aber vorher – und das findet sehr wohl im Rechenzentrum statt. Die Bewegungsmuster solcher Systeme entstehen heute typischerweise in Simulationen, in denen Modelle millionenfach virtuell laufen, stürzen und dazulernen, bevor jemals echte Hardware auf die Bahn geht. Das ist GPU-lastiges Training, das Speicher, Bandbreite und Kühlung frisst. Die Maschine auf der Tartanbahn ist am Ende nur das Frontend eines sehr großen Compute-Backends.

Die unterschätzte Disziplin: Betrieb

Was mir bei den Bildern aus Peking durch den Kopf ging: Ein brennender Roboter ist kein Softwarefehler im Sinne eines Bugs, sondern ein Betriebsrisiko. Und Betriebsrisiken kennen wir in unserer Branche gut. Wir reden ständig über Redundanz, Brandfrüherkennung, Notabschaltung und definierte Fehlerzustände – also darüber, was passiert, wenn ein System nicht mehr so funktioniert wie gedacht. Genau diese Fragen stellen sich bei Robotik in der Fläche gerade neu:

• Was ist der sichere Zustand, in den ein System fällt, wenn die Steuerung aussteigt?
• Wie werden Firmware- und Modell-Updates ausgerollt, ohne dass eine fehlerhafte Version tausend Geräte gleichzeitig lahmlegt?
• Wer hat Zugriff auf die Steuerungsschnittstellen – und wie ist dieser Zugriff abgesichert?

Der letzte Punkt ist für mich der interessanteste. Ein Roboter, der 100 Meter in unter 9,4 Sekunden zurücklegt, ist ein bewegtes physisches Objekt mit erheblicher kinetischer Energie. Sobald solche Systeme in Fabriken oder Haushalten stehen und über Netzwerke erreichbar sind, wird IT-Security zur Sicherheitsfrage im ganz wörtlichen Sinn. Ein kompromittierter Webserver kostet Daten und Nerven – ein kompromittierter Aktuator kann jemanden verletzen.

Vom Showevent zum Produkt

Die Spiele sind Marketing, keine Frage. Trotzdem zeigen sie, wie schnell sich der Reifegrad verschiebt. Parallel arbeiten Hersteller an kommerziellen Modellen für Fabrik und Haushalt; Elon Musk etwa will mit „Optimus“ bis 2030 eine Million Einheiten pro Jahr verkaufen. Ob dieser Zeitplan hält, wage ich nicht zu beurteilen – aber die Richtung ist klar.

Für uns bedeutet das vor allem eins: Jede dieser Maschinen erzeugt Telemetriedaten, braucht Modell-Updates, Flottenmanagement und eine Backend-Infrastruktur, die das aushält. Die spektakulären Bilder entstehen auf der Laufbahn. Die eigentliche Arbeit steckt in Racks, die niemand fotografiert. Damit kann ich als Rechenzentrumsmensch ganz gut leben.

Bis demnächst, eure Kora

Quelle: t3n