Wandelbots: Roboter programmieren ohne Roboterkurs?

Ein Roboterkurs dauert Wochen, und danach hängt jede Änderung an der Zelle wieder an der Person, die ihn besucht hat. Für Betriebe mit kleinen Stückzahlen ist das der eigentliche Kostenblock, nicht der Roboter selbst. Das Dresdner Unternehmen Wandelbots bewirbt seit Jahren einen anderen Zugang: Bewegung vormachen statt Programmcode schreiben. Was davon trägt, lässt sich nur zum Teil nachprüfen, weil belastbare Zahlen aus dem laufenden Betrieb öffentlich fehlen. Dieser Text trennt deshalb, was belegt ist, von dem, was das Unternehmen über sich selbst sagt.

Welche Programmierarbeit verschwindet?

Industrieroboter sprechen nicht dieselbe Sprache. KUKA-Controller arbeiten mit KRL, Universal Robots mit URScript, ABB mit RAPID. Wer eine Zelle umbaut, braucht jemanden, der diese Sprache beherrscht, die Bahnpunkte kennt und weiß, wie der Greifer angesteuert wird. Teach-in setzt früher an: Eine Person führt den Arm entlang der gewünschten Bahn, die Software zeichnet die Bewegung auf und erzeugt daraus ein Programm.

Wandelbots hat dieses Prinzip nicht erfunden, aber früh auf eine herstellerunabhängige Zwischenschicht gesetzt. Nach der Darstellung der TU Dresden, aus der das Unternehmen 2017 als Ausgründung hervorging, nahm ein Gerät die Bewegung des Menschen auf und übergab sie an eine Software, die daraus ein Bewegungsmodell für unterschiedliche Roboter erzeugte. Gedacht war das ausdrücklich für Betriebe ohne eigene Robotikabteilung.

Was damit verschwindet, ist ein Teil der Programmierarbeit: Bahnbefehle schreiben und zwischen Herstellerdialekten übersetzen. Was bleibt, ist Prozessarbeit. Ein Roboter braucht eine definierte Lage des Werkstücks, einen Greifer, der zum Teil passt, eine Taktzeit, die in den Ablauf passt, und eine Antwort auf die Frage, was passiert, wenn ein Teil nicht in der erwarteten Position liegt. Wer zum ersten Mal eine Zelle plant, sollte den Versuch auf eine einzige Frage zuschneiden; wie das geht, beschreibt der Beitrag über den Pilot, der klein bleiben darf.

Wer trägt die Verantwortung an der Zelle?

Die Programmierung ist die einfachere Baustelle. Die Sicherheitsfrage entscheidet, ob eine Zelle überhaupt in Betrieb gehen darf. Die Normen ISO 10218 für Industrieroboter und ISO/TS 15066 für die Zusammenarbeit von Mensch und Roboter beschreiben Anforderungen an Kräfte, Geschwindigkeiten und Abstände. Sie ersetzen keine Gefährdungsbeurteilung, und die erstellt der Betreiber, also der Betrieb, der die Zelle aufstellt. Bei einer wesentlichen Änderung muss er sie erneut prüfen.

Genau dort trifft die Idee der einfachen Programmierung auf ihre Grenze. Wenn eine angelernte Person eine Bahn verschiebt, kann sich ein Sicherheitsabstand ändern. Wer ohne Zaun arbeiten will, braucht kollaborierende Roboter mit entsprechender Zulassung und eine Risikobeurteilung, die diesen Betrieb abdeckt. Ob die Software eine Änderung als prüfpflichtig markiert, ist deshalb eine Frage, die vor dem Kauf wichtiger ist als die Zahl der Achsen.

Dieselbe Frage stellt sich beim Datenweg. Eine Zelle, die ihre Programme aus einer Cloud lädt, hängt am Netz. Wann das vertretbar ist und wann nicht, sortiert der Beitrag über Edge Computing und die Frage, was lokal bleiben muss. Wer prüfen will, ob eine Bestandsmaschine überhaupt Daten liefert, mit denen sich etwas anfangen lässt, findet die nüchterne Variante im Beitrag über die Smart Factory, die beim Datenstecker beginnt.

Für welchen Betrieb ist das realistisch?

Eine Zelle trägt sich nicht dadurch, dass sie sich leichter programmieren lässt. Sie trägt sich, wenn die Aufgabe gleichmäßig anfällt und die Aufnahme stimmt. Im fiktiven Beispiel prüft ein Zulieferer mit zwölf Beschäftigten, ob eine Schweißzelle zwei Teilefamilien übernehmen kann. Beide Teile liegen in festen Aufnahmen, die Reihenfolge ist gleich, die Taktzeit liegt deutlich über der Zeit, die der Roboter für die Bahn braucht. Solche Konstellationen sind der Fall, für den sich der Aufwand rechnen kann. Kommt dagegen jedes Teil anders, verschiebt sich die Arbeit vom Programmieren zum Rüsten, und die Zelle steht.

Der zweite Realitätscheck betrifft die Daten. Eine Automatisierung, die an eine Maschine anschließt, muss wissen, was diese Maschine liefert. Wie unterschiedlich das in der Praxis ausfällt und warum die Reihenfolge von Auftrag, Material und Maschine wichtiger ist als das Dashboard, beschreibt der Branchenblick zur Blechbearbeitung und ihren Betriebsdaten.

Der dritte Punkt ist die Auswahl des Vorhabens. Wer eine Zelle, eine Prüfstation oder ein Assistenzsystem plant, wählt in Wahrheit ein Problem aus, das klein genug für einen ersten Versuch ist. Die Kriterien dafür, mit welcher Aufgabe ein solcher Versuch beginnt, gelten für Roboterzellen ebenso wie für Textarbeit.

Was das Unternehmen heute beschreibt

Auf seiner Website stellt Wandelbots seine Software heute als Plattform für Anwendungen mit Robotern dar, mit einer Entwicklungsumgebung, einer Cloud-Komponente und der Möglichkeit, Abläufe vorab zu simulieren und danach auf mehrere Standorte zu übertragen. Das Unternehmen nennt einen Industriekunden als Referenz und spricht von geringerem Engineering-Aufwand und schnellerer Inbetriebnahme. Alle diese Angaben sind Unternehmensangaben. Wir haben sie nicht nachgemessen und übernehmen sie nicht als Wirkungsnachweis.

Was ein Simulationsmodell leisten kann und wann es zur Attrappe wird, die niemand pflegt, steht im Beitrag über den digitalen Zwilling, der einen echten Prozess braucht.

Öffentlich gut belegt ist dagegen ein Bruch in der Unternehmensgeschichte. Im Sommer 2024 beschrieb Mitgründer Christian Piechnick in einem Interview mit dem Gründermagazin deutsche-startups.de, das ursprüngliche Geschäftsmodell sei nicht skalierbar gewesen: Jede Anwendung habe viel Wissen über den konkreten Prozess verlangt, die Anforderungen seien stark unterschiedlich gewesen, und die Arbeit sei nur über Personal gewachsen. 2023 habe man sich entschieden, das Hardwaregeschäft mit dem Eingabestift TracePen aufzugeben und sich ganz auf Software zu konzentrieren. Mit Kunden habe man die bestehenden Verträge einvernehmlich beendet und Übergänge zu Systemintegratoren vermittelt.

Was wir nicht behaupten: wie viele Zellen mit dieser Software produktiv laufen, wie stark sie die Rüstzeit senkt, wie viele Menschen das Unternehmen beschäftigt und wie es wirtschaftlich dasteht. Dazu liegen keine öffentlich belastbaren Angaben vor, und geschätzte Zahlen wären für eine Kaufentscheidung wertlos.

Bleibt der Roboterkurs erspart?

Für einen Teil der Arbeit ja. Eine Bewegung vorzuführen und daraus ein Programm erzeugen zu lassen, ersetzt die Controller-Sprache. Die Sorgfalt, die ein Betrieb aufbringen muss, verschiebt sich nur: Gefährdungsbeurteilung, Werkstückaufnahme, Taktzeit und die Frage, wer eine Änderung freigibt. Das ist kein Roboterkurs, aber es ist Arbeit, die jemand verantworten muss.

Offen bleibt die belastbare Antwort auf die Frage, was ein solcher Zugang in einem deutschen Zulieferbetrieb tatsächlich verändert. Dafür bräuchte es Zahlen aus dem laufenden Betrieb über einen längeren Zeitraum, und die liegen öffentlich nicht vor.