Laufroboter: Wie aus einem Engineering-Problem ein Lernproblem wurde

Vor zehn Jahren brauchte es ein Team von Ingenieuren und jahrelange Feinabstimmung, damit ein Roboter über einen flachen Boden lief. Heute wird eine in der Simulation trainierte Policy auf echte Hardware übertragen und läuft dort ohne Nacharbeit. Im RobTalk-Podcast erklärt Felix Frank, Tech Lead im Robot-Intelligence-Team von RobCo, was sich tatsächlich verändert hat. Er hat rund sechs Jahre in der Robotikforschung bei Volkswagen gearbeitet, danach an Whole-Body-Control bei einem US-Startup für humanoide Robotik. Heute beschäftigt er sich mit Manipulation. Dieser Artikel zeichnet nach, was er beschreibt: wie sich die Laufrobotik von handgebauten Regelungsarchitekturen zu gelerntem Verhalten entwickelt hat, und was dieser Wandel für Fabriken bedeutet.

Das Wichtigste in Kürze

• Laufen war ein Modellierungsproblem: Die klassische Regelung zerlegte Lokomotion in Schrittplanung, Zustandsschätzung und eine große Online-Optimierung. Jedes Teilproblem wurde einzeln von Hand abgestimmt.
• Der Engpass war das Unerwartete: Alles, was der Roboter bewältigen sollte, musste vorab im Plan stehen. Genau das machte Kontakt mit Türen, Wänden oder Objekten extrem schwer modellierbar.
• Reinforcement Learning verlagert die Arbeit nach vorn: Statt Regler im Betrieb nachzujustieren, stimmen Ingenieure heute Simulationen und Belohnungsfunktionen ab und übertragen die trainierte Policy anschließend auf die Hardware.
• Domain Randomization macht den Transfer belastbar: Variiert die Simulation Physik, Reibung und Massenverteilung, entstehen Policies, die robust genug für echte Hardware sind, ohne einen einzigen Trainingsdatenpunkt aus der realen Welt.
• Die Methoden lassen sich übertragen: Dieselbe Pipeline von der Simulation in die Realität macht gelernte Manipulation in der Fabrikhalle möglich.

Was macht Laufroboter so schwer zu steuern?

Ein Laufroboter muss aufrecht bleiben und dabei den Bodenkontakt permanent lösen und neu herstellen. Frank beschreibt Laufen als Vorgang, über den kaum jemand bewusst nachdenkt: „Man kann es sich als kontrolliertes Fallen vorstellen. Man lehnt sich nach vorn, fällt nach vorn und fängt sich dann mit den Füßen wieder auf.“

Stimmt der Rhythmus, gleichen die Kontaktkräfte in den Füßen die Schwerkraft aus. Stimmt das Timing nicht, fällt man. Ein Roboter auf Rädern kennt dieses Problem nicht, denn sein Bodenkontakt ist durchgehend und vorhersagbar. Ein Laufroboter dagegen steht mit jedem Schritt neu vor dieser Aufgabe.

Die vielen Freiheitsgrade machen es noch schwieriger. Ein Humanoid hat Dutzende Gelenke, die alle miteinander gekoppelt sind. Bewegt sich eines, verschiebt sich die Massenverteilung des gesamten Systems.

Wie brachten Ingenieure Roboter vor dem Machine Learning zum Laufen?

Der klassische Ansatz zerlegte Lokomotion in Teilprobleme, löste jedes einzeln und setzte alles zu einer Regelungsarchitektur zusammen. Frank benennt die Bausteine:

• Schrittplanung: Aus Gelände und Richtung ergibt sich, wo jeder Fuß aufsetzt.
• Schwerpunktplanung: Der Körperschwerpunkt bleibt innerhalb der Fläche, die die geplanten Schritte aufspannen.
• Zustandsschätzung: Aus Inertialsensoren und Gelenkgeberdaten wird bestimmt, wo der Roboter gerade wirklich ist.
• Online-Optimierung: Das gesamte Balanceproblem wird laufend gelöst, mit Raten von bis zu einem Kilohertz.

Allein die Zustandsschätzung war ein erheblicher Aufwand. Inertialsensoren, dieselbe Sensorklasse wie in jedem Smartphone, rauschen. Um sie zu nutzen, muss das System zuerst wissen, welcher Fuß gerade aufgesetzt ist. Erst dann kann es diesen Fuß als feste Referenz behandeln und den Rest über die Kinematik rekonstruieren, also über die Kette aus bekannten Gelenkwinkeln. Das trieb die Hardwarekosten in die Höhe. Laut Frank brauchten die meisten Roboter teure Kraftsensoren in den Füßen, nur um zu erkennen, ob sie fest standen oder rutschten.

Gelingt das gut, entsteht so etwas wie ein digitaler Zwilling des Roboters, vollständig aus Sensordaten abgeleitet.

Wo der klassische Ansatz an seine Grenzen kam

Das Problem war nicht die Genauigkeit. Es war die Störanfälligkeit. Frank formuliert es so: „All das musste fehlerfrei zusammenspielen. Jede kleine Störung, die man nicht einplanen konnte, brachte das System zum Scheitern.“

Schwerer wog: Alles, was der Roboter tun konnte, musste im Plan vorgesehen sein. Über freien Boden zu laufen ist ein einfacher Fall, mit zwei Füßen und einer ebenen Fläche als einzigen Kontakten. Kommt ein dritter Kontakt hinzu, ändert sich die Rechnung. Eine Tür öffnen, sich an eine Wand lehnen oder ein Objekt aufnehmen bringt äußere Kräfte ins Spiel, die von der Hand durch den ganzen Körper wirken. Jeder dieser Fälle musste einzeln modelliert und kompensiert werden.

Menschen erledigen das, ohne darüber nachzudenken. Wie Frank anmerkt, verbringen wir als Kinder unzählige Stunden damit, zu spielen und Dinge auszuprobieren. Das mit handabgestimmten Gleichungen nachzubauen, erwies sich als mühsam.

Gescheitert ist der Ansatz deshalb nicht. Der Atlas-Roboter von Boston Dynamics absolvierte schon vor Jahren Parkour-Strecken und Salti, aufgebaut auf genau dieser Methodik. Der Weg dahin kostete allerdings enormen Entwicklungsaufwand, und der Fortschritt erreichte irgendwann ein Plateau.

Was hat sich mit Reinforcement Learning verändert?

Hier setzt Reinforcement Learning in der Robotik an: Die Forschung löste Teilprobleme nicht mehr von Hand, sondern lernte ganze Verhaltensweisen aus Daten. Podcast-Host Clemens zieht eine Parallele zur Sprachverarbeitung. Syntax, Semantik, Entitätenerkennung und maschinelle Übersetzung waren einmal getrennte Forschungsstränge. Große Sprachmodelle haben sie alle abgelöst.

Frank ordnet den Umschwung zeitlich grob ein: bei vierbeinigen Robotern etwa 2019 bis 2020, bei Humanoiden später, eher 2023 oder 2024. Zwei Entwicklungen machten ihn möglich.

Die erste war erschwingliche Hardware. Vor zwanzig Jahren mussten Labore ihre Humanoiden selbst bauen, teuer und störanfällig. Das Cheetah-Programm des MIT brachte das Design von Vierbeinern voran, günstige Plattformen folgten. Bei Humanoiden machte Unitrees G1 aus dem Forschungsroboter etwas, das einem Werkzeug von der Stange nahekommt.

Die zweite war GPU-parallelisierte Simulation. Reinforcement Learning ist nicht dateneffizient. Praktikabel wird es erst, wenn ein Simulator riesige Mengen an Erfahrungsdaten in kurzer Zeit erzeugt. NVIDIAs Isaac Gym, 2021 veröffentlicht, setzte hier den Standard. Die Folgearbeit „Learning to Walk in Minutes“ trainierte Lokomotions-Policies in Minuten statt in Tagen.

Training in der Simulation mit Domain Randomization

Eine in perfekter Simulation trainierte Policy würde auf echter Hardware sofort versagen, denn keine Simulation ist perfekt. Domain Randomization löst das, indem sie die Simulation absichtlich inkonsistent macht.

Im Training variiert das System Massenverteilung, Reibungskoeffizienten und kleine Abweichungen in der kinematischen Struktur. Frank erklärt die Logik nüchtern: „Man bekommt nie zweimal denselben Roboter.“ Zwei Exemplare vom selben Band unterscheiden sich leicht, und jeder Boden, den sie betreten, ebenso.

Die Randomisierung deckt auch aktive Störungen ab. Der Roboter „wird trainiert, während er permanent angestoßen und herumgeschubst wird, und muss gegen all das robust sein“. Eine Policy, die Millionen simulierter Stöße verarbeitet hat, fängt ein echtes Stolpern ab, das sie nie erlebt hat.

Sim-to-Real-Transfer ohne Daten aus der realen Welt

Das Ergebnis ist Zero-Shot-Transfer: eine Policy, die vollständig in der Simulation trainiert und ohne einen einzigen realen Datenpunkt auf die Hardware gebracht wird. Das funktioniert aus zwei Gründen. Die zugrunde liegende Physik ist newtonsch und gut verstanden. Und die Randomisierung zwingt die Policy, den Bereich abzudecken, in dem Simulation und Realität auseinanderlaufen.

Der Engineering-Aufwand verschwindet dadurch nicht. Er wandert nur an eine andere Stelle. In Franks Worten: „Das Engineering-Problem hat sich verlagert, von wir stimmen all diese Algorithmen für die Teilprobleme von Hand ab zu wir stimmen die Simulation und die Belohnungsfunktionen ab.“

Die tiefere Veränderung betrifft die Architektur. Die alte Regelungsarchitektur ließ eine schwere Optimierung laufen, während der Roboter sich bewegte. Die neue erledigt diese Arbeit im Voraus: „Dieses komplizierte Optimierungsproblem wird in einen Funktionsapproximator überführt.“ Das neuronale Netz gibt eine Lösung aus, ohne zur Laufzeit zu optimieren, weil es das Problem zuvor millionenfach gelöst hat.

Der Vergleich zeigt: Lernen hat Lokomotion nicht einfacher gemacht. Es hat verschoben, welches Problem Ingenieure lösen. Statt Robustheit zur Laufzeit sind heute Simulation und Belohnungsfunktionen die Stellschrauben.

Wie lernen Roboter, sich wie Menschen zu bewegen?

Frühe Policies aus dem Reinforcement Learning liefen zuverlässig, sahen dabei aber nicht menschlich aus. Menschliche Daten spielten dabei keine Rolle. Stattdessen bestanden die Belohnungsfunktionen aus zehn bis fünfzehn handgeschriebenen Termen. Oberkörper aufrecht halten, Füße hoch genug anheben, nah an einer Standardpose bleiben, einer vorgegebenen Geschwindigkeit folgen.

Zwei Forschungsrichtungen änderten das.

Bewegungsimitation und Retargeting

Der erste Ansatz zeichnet menschliche Bewegung per Motion Capture auf und trainiert die Policy darauf, sie nachzubilden. Das ersetzt einen Stapel handabgestimmter Belohnungsterme durch ein einziges Ziel. Frank fasst es zusammen: „Es läuft darauf hinaus: Verfolge, was der Mensch tut.“

Möglich macht das ein Zwischenschritt. Menschliches Skelett und Roboter haben unterschiedliche Proportionen und Gelenkstrukturen, die aufgezeichnete Bewegung lässt sich also nicht direkt übertragen. Retargeting bildet die menschliche Trajektorie auf eine Bewegung ab, die der Roboter innerhalb seiner kinematischen Grenzen ausführen kann. Die Policy verfolgt dann einfach diese umgerechnete Trajektorie.

Dieser Forschungsstrang geht auf DeepMimic zurück, veröffentlicht 2018. Die Arbeit führte Belohnungsfunktionen ein, die allein auf dem Verfolgen einer Referenzbewegung beruhen.

Adversarial Motion Priors: menschlich aussehen lernen

Der zweite Ansatz verfolgt keine bestimmte Bewegung. Er lernt, wie menschliche Bewegung generell aussieht.

Ein Diskriminator-Netz wird darauf trainiert zu beurteilen, ob eine Bewegung von einem Menschen oder einem Roboter stammt. Die Policy wird dafür belohnt, den Diskriminator zu täuschen. Die Technik wurde 2021 als Adversarial Motion Priors vorgestellt. Ein Roboter lernt, vorwärts zu laufen und aufrecht zu bleiben, und bewegt sich dabei erkennbar menschlich. Niemand muss diesen Stil in Gleichungen fassen.

Was bedeutet das für die Fertigung?

Laufroboter selbst sind nicht das, was Fabriken am dringendsten brauchen. Eine Plattform auf Rädern ist stabiler und effizienter, um Material über einen flachen Hallenboden zu bewegen. Das Wertvolle an der Laufrobotik-Forschung ist die Methode, nicht die Bauform.

Diese Methode wandert gerade in die Manipulation. Genau dort liegt Franks heutige Arbeit. Das schwierige Problem in einer Fabrik ist nicht das Laufen. Es ist der Kontakt: ein Teil greifen, dessen Lage variiert, die richtige Kraft aufbringen, Objekte handhaben, die nie ganz identisch sind. Die klassische Architektur tat sich mit zusätzlichen Kontakten aus demselben Grund schwer wie mit dem Öffnen einer Tür.

Das ist die Grundlage von Physical AI. Genau darauf setzt RobCo mit KI in der Robotik für reale Produktionsumgebungen:

• Gelerntes Verhalten, wo Variation das Problem ist: Autonome Industrieroboter übernehmen Anwendungen wie Maschinenbeladung, Palettieren und Materialumschlag. Dazu kommen Bin Picking und Sortieren in unstrukturierten Umgebungen, in denen jedes Teil anders liegt.
• Simulation vor dem Einsatz: Dieselbe Pipeline aus digitalem Zwilling und Domain Randomization, die Lauf-Policies erzeugt hat, macht einen Roboter robust gegen die Variation einer echten Produktionslinie.
• Modulare Hardware, umkonfiguriert statt ersetzt: Die modularen Roboter bestehen aus austauschbaren Komponenten. Eine neue Aufgabe bedeutet, Module zu tauschen, nicht den ganzen Roboter zu ersetzen. Entwickelt wird die Technologie am Hauptsitz in München, gefertigt in Deutschland und den USA (Austin, TX).
• Bedienbar durch die Menschen in der Halle: Die Programmierung läuft über No-Code-Software (RobFlow). Mitarbeitende in der Werkshalle richten die Roboter ohne Robotik-Vorkenntnisse ein und passen sie an. Routineaufgaben werden automatisiert, damit sich Menschen auf wertvollere Arbeit konzentrieren können.

Wie autonome Roboter von der Anweisung zur physischen Bewegung kommen, zeigt unser Artikel Wie autonome Roboter funktionieren im Detail.

Sie möchten wissen, welche Aufgaben sich in Ihrer Fertigung heute schon automatisieren lassen? Vereinbaren Sie einen Beratungstermin.

Häufige Fragen zu Laufrobotern

Was sind Laufroboter?

Laufroboter sind Maschinen, die sich auf Beinen bewegen statt auf Rädern oder Ketten, darunter vierbeinige Roboter und Humanoide. Sie stellen den Bodenkontakt bei jedem Schritt neu her. Das macht Balance und Lokomotion deutlich schwerer zu steuern als Fahren auf flachem, vorhersagbarem Untergrund.

Wie lernen Laufroboter das Laufen?

Die meisten Laufroboter lernen das Laufen heute per Reinforcement Learning in der Simulation. Eine Policy wird durch Versuch und Irrtum über Millionen simulierter Durchläufe trainiert, geleitet von Belohnungsfunktionen oder vom Verfolgen aufgezeichneter menschlicher Bewegung. Danach wird sie auf echte Hardware übertragen.

Was ist Domain Randomization?

Domain Randomization ist eine Trainingstechnik, die simulierte Physik absichtlich variiert, darunter Reibung, Massenverteilung und äußere Stöße. Muss eine Policy über all diese Varianten hinweg funktionieren, entsteht Verhalten, das robust bleibt, selbst auf Hardware, die sie nie gesehen hat.

Was ist Sim-to-Real-Transfer?

Sim-to-Real-Transfer bedeutet, eine vollständig in der Simulation trainierte Policy ohne zusätzliches Training auf einen echten Roboter zu bringen. Das funktioniert, weil newtonsche Physik präzise simulierbar ist und randomisiertes Training die Lücke zwischen Simulation und Realität abdeckt.

Sind Laufroboter in Fabriken sinnvoll?

Laufroboter sind für Fabrikarbeit selten die passende Bauform, denn Plattformen auf Rädern sind auf flachen Böden stabiler und effizienter. Wertvoll ist die Methode: Die Pipeline aus Simulation und Lernen, die für Lokomotion entwickelt wurde, erlaubt Robotern heute unstrukturierte Manipulationsaufgaben.

‍