Projekt UR5e

Schon vor Beginn des Semesters fing ich an, den Raum für die Benutzung des Roboterarms umzustrukturieren. Zunächst musste ein Arbeitsbereich geschaffen werden, in dem der Roboter ohne Gefahr betrieben werden könnte. Auch, wenn es sich um einen Cobot handelt, der für den Einsatz mit Menschen gedacht ist, besteht trotzdem ein erhebliches Risiko einer Verletzung durch Fahrlässigkeit. Im Zuge der Umgestaltung wurden neue Lampen angebracht, ein neuer Computer angeschafft und der Raum etliche Male neu angeordnet. Ziel war es hier, mindestens 2 Arbeitsplätze zu schaffen, die einen nahen Zugang zu dem Roboter gewähren würden. Auch wurden der Ultimaker 2+ sowie ein weiterer FDM-Drucker auf einem der Arbeitsplätze installiert, da ein direkter Zugriff auf die Drucker ein sehr schnelles Prototyping ermöglichen würde. Für hochqualitative Drucke werden jedoch die Drucker aus dem Rapid Prototyping-Labor genutzt.

Um die Sicherheit in Bezug auf Benutzung des Roboters zu erhöhen, habe ich virtuelle Begrenzungen in den Roboter eingespeichert, in denen er sich nur bewegen darf. So kann ich mir sicher sein, dass er gewisse Bereiche nicht antasten kann, jedoch wird diese Funktion je nach Anwe dung deaktiviert, wenn mehr Flexibilität benötigt wird und diese Grenzen übergangen werden müssen. Da ich nicht alleine an dem Arm arbeite, kann ich nicht garantieren, dass diese Grenzen aktiviert sind. Sofern man nicht direkt neben dem Arm steht, droht auch keine Gefahr. Selten wird der Arm mit Geschwindigkeiten betrieben, die für Beisteher gefährlich werden könnten. Die Gefahr geht da eher von den angebrachten Werkzeugen aus.

Zum jetzigen Zeitpunkt ist die Ver- und Bearbeitung von Programmen relativ umständlich. Die Probleme, die sich ergeben, liegen vor allem an der von uns benutzten Software, da sich diese oft noch im Beta-Stadium befindet und nicht vollends ausgereift ist.

Rechts zu sehen war der nötige Prozess, um bisher ein Programm ausführen zu können.
Nachdem wir eine Idee generiert haben, haben wir damit begonnen, die in Rhino erstellten Formen in Linien oder Pfade umzuwandeln. Diese konnten dann in HAL übertragen werden, wo sie in Targets, also einzelne Wegpunkte unterteilt wurden, die der Roboter als Punkte im Raum erkennen kann. Sollte das nicht möglich gewesen sein, so konnten wir dies schon in einer integrierten Simulation erkennen. Diese ist aber bis zum jetzigen Zeitpunkt nicht zwingend akkurat. Hatten wir nun ein Programm kreiert, welches unseren Ansprüchen genügt hat, so haben wir das Script aus HAL exportiert und in Visual Studio Code importiert. Dort veränderten wir die moveP-in moveL-Befehle und löschten die Nutzlast des Werkzeugflansches aus dem Programmbaum. In einigen Fällen wurde am Ende des Programms noch ein „stopj(2)“ Befehl eingefügt, dieser sorgte für ein langsames Anfahren des letzten Punktes. Dies war nötig, da der Arm sonst abrupt stehen blieb und sich aufgrund von Achslastgrenzen ausgeschaltet hat.

Das Script wurde anschließend erneut gespeichert und auf das Teach Panel des Ur5e übertragen. Dort wurde es geladen und hat im besten Fall funktioniert. In der Realität kam es jedoch zumeist zu Fehlermeldungen, die den Roboter herunterfuhren. Im Endeffekt musste das Programm überarbeitet werden und der Kreislauf begann von Neuem. Dies erwies sich vor allem bei experimentellen Tests als äußert langwierig und unnötig umständlich.

Um in Zukunft deutlich effektiver arbeiten zu können, muss der Weg vom Erstellen der Targets bis hin zur Ausführung durch den Roboter deutlich verbessert werden. Dies wird hoffentlich in Zukunft über die TCP IP6 Schnittstelle möglich sein. Der unangenehmste Faktor in dem bisherigen Prozess ist der unnötige Zeitverlust. Kleinste Veränderungen, oft nicht mehr als eine Geschwindigkeitsanpassung oder Interpolations-Optimierung, dauern mitunter Stunden. Dies behindert vor allem den Arbeitsrhythmus enorm, da man ständig aufgrund von Problemen ausgebremst wird.

Die Versuche, einen Upload direkt aus HAL heraus zu ermöglichen, sind bisher gescheitert. Mit RoboDK war dies jedoch schon erfolgreich.
Das Team von Interaction Design hatte diese Upload-Probleme auch nicht. Sie haben sich dem Ur5e mit Processing genähert und konnten über den Port 30002 erfolgreich in Echtzeit auf den Arm zugreifen.

Die Erfahrungen und Erkenntnisse aus diesen Herange- hensweisen könnten uns helfen, das Problem mit HAL selbst zu beheben.
Im besten Fall wird die Übertragung von Daten bald durch ein Softwareupdate auch aus HAL möglich sein.

Sollten in Zukunft alle Programme den direkten Upload unterstützen und die Anbindung multipler Computer möglich sein, so werden viele der bisher sehr mühseligen Schritte hinfällig werden.

Bei HAL handelt es sich um eine Grasshopper-basierte Programmierungs- und Simulationssoftware. HAL unterstützt dabei eine breite Auswahl an Industrierobotern und Cobots. Durch diese Basis ist die Programmierung von Bewegungen und Aktionen des Roboters nicht ganz so leicht, wie es bei anderen Programmen der Fall sein mag, jedoch eröffnet HAL gleichzeitig ein großes Maß an Möglichkeiten. Durch die Grasshopper-Schnittstelle ist es außerdem möglich, sehr schnell Veränderungen in Rhino bzw. am Projekt in HAL zu übertragen. Des Weiteren ist Grasshopper selbst ein potentes Werkzeug, um Formen und Strukturen zu schaffen, weshalb die Integration von HAL besonders Arbeitszeit im Exportieren und Importieren von Daten minimiert. Es ist somit nicht nötig, mehrere Programme für eine Arbeit zu nutzen.

Es gibt online einige gute Einsteiger-Tutorials, die die grundlegende Bedienung abdecken, HAL bietet jedoch ein Maß an weiteren Funktionen, die wir längst nicht alle ausprobieren konnten. Einige dieser Befehle scheinen zum Zeitpunkt des Schreibens dieser Dokumentation auch noch nicht zu funktionieren.

Der Grasshopper-Programmbaum sieht wie folgt aus:

• Zu allererst wird der Roboterarm definiert. Dabei wird das Modell festgelegt, in unserem Fall der UR5e. Anschließend wird das Werkzeug in Form eines Polygonnetzes eingespeichert, sowie der TCP als Punkt definiert. Der TCP (tool center point) ist in den meisten Fällen die Werkzeugspitze. Auch die Achsausrichtung als Grundposition kann hier bestimmt werden.
• Der grüne Block beinhaltet alle nötigen Parameter, um das Programm zu fahren. Hier werden Beschleunigung, Geschwindigkeit und Interpolation festgelegt. Dieser Block kann an alle Aktionen angeschlossen werden.
• Nach dem Definieren des Roboters folgt das Anfahren einer Anfangsposition. Dies ist nicht immer nötig, es hilft aber, sowohl vor dem Programm als auch nach dem Programm einen Punkt zu haben, der nicht direkt mit dem Pfad verbunden ist. So entfernt sich der Roboter immer von dem eigentlichen Werkstück und bietet Freiraum zum Arbeiten.
• Der größte Bereich besteht aus den Input-Informationen. Hier werden die zu fahrenden Linien importiert, unterteilt in Targets und ausgerichtet, sodass das Werkzeug im richtigen Winkel zu dem Werkstück steht.
• Direkt danach werden alle Aktionen in einem „merge“-Befehl zusammengefügt. Dieser strukturiert die Daten durch und fügt jede Einzelbewegung zu einem flüssigen Programm zusammen. Er ist außerdem nötig, da die einzelnen Aktionen logisch nicht direkt ausgeführt werden können. Dies liegt an HALs interner Programmierung.

• Zuletzt wird das Programm berechnet. Alle zusammengefügten Aktionen werden nun in UR-Script transformiert, anschließend wird eine Simulation erstellt. An dieser lässt sich oft feststellen, ob das Programm wie antizipiert verläuft. Zuletzt wird das Programm exportiert oder kann direkt auf den Ur5e hochgeladen werden. Diese Funktion war bei uns fehlerhaft.

RoboDK ist genau wie HAL eine Simulations- und Programmierungssoftware für diverse Roboterarme verschiedenster Marken und Größen. Es bietet außerdem ein Rhino-Plugin, welches uns erlaubt, Kurven und damit Pfade direkt aus Rhino zu importieren. Der Funktionsumfang scheint bei RoboDK in etwa dem vom HAL zu entsprechen, dies lässt sich aber nicht bestimmt sagen, da nicht annähernd alle Funktionen aus beiden Programmen bisher von uns benutzt wurden.

Bei unserer bisherigen Arbeit stand RoboDK HAL in nichts nach. Eher das Gegenteil ist der Fall. Mit RoboDK ist es Martin Kuhlenkamp gelungen, bestimmte Programme nicht nur flüssiger und effizienter zu fahren, auch die Anzahl an Fehlermeldungen war deutlich geringer. Mit RoboDK war es außerdem möglich, eine direkte Verbindung zwischen Computer und Roboter zu erstellen und so Programme erfolgreich in Echtzeit auszuführen.

Schnell fällt auf, dass RoboDK vor allem deutlich Nutzer- und Anfängerfreundlich ist. Die Oberfläche ist minimalistisch gestaltet und es finden sich gut strukturierte Anleitungen und Tutorials im Internet, die besonders den Einstig in die Thematik der Roboterprogrammierung erleichtern. Auch wenn ich persönlich nicht viel mit RoboDK gearbeitet habe, so fühlt sich RoboDK weiter entwickelt als HAL an. Die Anzahl der unterstützten Roboterarme ist deutlich höher, die Simulation um einiges verlässlicher und die Integration bestimmter Funktionen nicht dem Nutzer überlassen.

Warum HAL und nicht RoboDK?

Natürlich stellt sich die Frage, warum wir nicht alle RoboDK benutzt haben, wo dies uns sicherlich viel Mühe und Zeit erspart hätte. Ich würde dieser Annahme definitiv zustimmen, jedoch konnten wir dies einfach nicht von Anfang an wissen. Die Beschäftigung mit dem Arm war für

uns alle eher ein Lernprozess als ein Produktionsprozess, bei dem wir Unmengen an Modellen oder Objekten generiert haben.
In meinen Augen ist dies aber auch der richtige Schritt gewesen. Der Arm sollte nicht ähnlich einer CNC Tag und Nacht Modelle erzeugen, nur um wirtschaftlich zu werden. Der Arm ist eine Forschungsplattform und erlaubt uns, diverse Anwendungen auszuprobieren und zu erforschen. Dass sich die Teams aus unterschiedlichen Richtungen und mit einer Vielzahl an Programmen dem UR5e genähert haben, hat uns vor allem gezeigt, was in Zukunft für uns relevant bleiben wird, aber auch, was nicht oder nicht gut funktioniert hat. HAL wird in keinem Fall obsolet werden, nur weil RoboDK in einigen Punkten besser ist als HAL.

Jedes Programm hat seine eigenen Stärken und Schwächen. Da diese Technik noch so neu ist, kann es durchaus sein, dass es in einem halben Jahr multiple Programme gibt, die besser als HAL oder RoboDK sein könnten. Besonders das Austesten verschiedenster Möglichkeiten zeigt, dass dieses Projekt für unsere Hochschule ein Forschungsgebiet ist, ein Feld, in dem man sich erst zurechtfinden muss und das keinesfalls Plug-and-Play ist. Dies macht es jedoch auch äußerst spannend, da wir die Evolution der Technik aus nächster Nähe verfolgen und verstehen können. Dazu zählen nicht nur die Erfolge, sondern auch die Probleme.

Die Umsetzung ist bis heute nicht ganz gelungen. Jasper Kühn hat es geschafft, eine Verbindung zum Roboter aufzubauen, mit dieser ist es jedoch nur möglich, einfache Socket-Befehle an den Arm zu senden. Der Anschluss des Roboters erfolgt dabei nicht direkt an die Ethernet-Schnittstelle des Computers, sondern über einen Router. Dieser Router bildet damit ein eigenes Netzwerk, welches es nun möglich macht, dem UR5e eine IP-Adresse zu geben. Nach erfolgreicher Identifikation im Netzwerk muss ein entsprechender Port angewählt werden, für die Verwendung von Socket-Befehlen ist dies der Port 29999. Diese sogenannten Socket-Befehle ermöglichen es, einfache einzeilige Befehle abzurufen. Auf diese Weise lässt sich ein Programm starten, der Arm ein- und ausschalten, und sogar die Temperatur der einzelnen Achsen überwachen. Mit diesen Befehlen lässt sich jedoch nur die werksseitige Benutzeroberfläche von Universal Robots beeinflussen. Möchte man ein Programm laden, muss man dieses jedoch zuvor erst anlegen und abspeichern, was den Prozess des Abspielens eher verlängert als verbessert. Auch wenn diese Verbindung sich als durchaus praktisch erweist, erfüllt sie nicht unsere Ansprüche.

Um eine Echtzeitübertragung zu ermöglichen, müssen die Befehle direkt aus den Programmen heraus auf den Arm exportiert werden. Dies erwies sich als begrenzt durchführbar. Mit RoboDK war Martin Kuhlenkamp in der Lage, eben diesen Upload über den Port 30002 durchzuführen, das Programm verlief jedoch nicht wie erwartet. Bei einem Programm, welches über das sogenannte „Teach Panel“, also das Tablet, welches zum Arm gehört, erstellt wurde, wurde die Interpolation der einzelnen Wegpunkte vom internen Controller übernommen. Wird nun das Programm jedoch über den PC gestartet, so werden dem Arm nur die einzelnen Wegpunkte, aber keine Verkettung dieser übermittelt. Dies hat zur Folge, dass die Punkte nicht interpoliert werden und die Fahrbewegung stark ruckelt oder sich der Roboter aufgrund von zu hoher Achslast sogar ausschaltet. Mit HAL war es gar nicht erst möglich, diese Befehle zu schicken, da keine Verbindung zum Arm hergestellt werden konnte. Nach Rücksprache mit den Entwicklern von HAL sollte dies aber möglich sein.

Auch ist es uns bisher noch nicht gelungen, mehreren Geräten gleichzeitigen Zugriff auf den Roboterarm zu verschaffen. Es war zwar möglich, ein Programm über RoboDK zu starten, jedoch konnte dieses nicht über die Socket-Befehle von einem anderen Computer aus pausiert, gestoppt oder anderweitig beeinflusst werden. Bei einem versuchten Zugriff wurde der jeweilige andere Computer aus dem Netzwerk entfernt.

Anpassung der Parameter

Die Parameter, mit denen ich mich am meisten beschäftigt habe, sind Beschleunigung, Geschwindigkeit und Interpolation. Diese drei befinden sich in einem sensiblen Zusammenhang zueinander, und das Verändern einer dieser Einstellungen kann entscheidend sein, um ein Programm flüssig zu fahren. Viele Programme unterstützen mittlerweile eine automatische Anpassung dieser Parameter, so z.B. auch RoboDK.

HAL hingegen bietet den Nutzern die Freiheit, diese selbst anzupassen. Dies bringt viel Spielraum mit sich, ist am Anfang aber alles andere als hilfreich. Sollte man keine der Parameter verändern, greift HAL auf interne zurück, diese sind jedoch bedingt nutzbar. Je höher die Interpolation, desto mehr Probleme machen diese Einstellungen. Wenn weniger Targets vorliegen, wirkt die Fahrweise flüssiger, da der Roboter nur bei Richtungsänderungen die Targets berührt. Eine hohe Interpolation ist aber für unsere Zwecke ein wichtiger Faktor, denn besonders beim Schreiben und Erstellen von Grafiken ist höchste Präzision gefragt. Man könnte das Programm sicherlich auch schlecht optimiert fahren, jedoch würde das heftige Anfahren und Abbremsen für eine hohe Belastung der internen Motoren sowie Bremsen sorgen. Der Verschleiß würde sich drastisch erhöhen und die Gelenke an Präzision verlieren, im schlimmsten Fall würden sie beschädigt werden.

Eine Optimierung dieser Einstellungen ist also dringend notwendig, weshalb ich viel Zeit damit zugebracht habe, diese zu testen. Letztendlich habe ich Werte gefunden, von denen ich ausgehe, dass diese gut funktionieren sollten. Problematisch wird es erst wieder, falls die von mir festgelegte Interpolation verändert werden sollte, dann ist eine flüssige Fahrbewegung nicht mehr garantiert. Zuletzt haben auch die Anzahl der erstellten Targets sowie der Target-Filter direkten Einfluss auf diese Einstellungen.

Um eine perfekte und damit auch gelenkschonende Fahrbewegung durchzuführen, müssen alle 3 Parameter, also Beschleunigung, Geschwindigkeit und Interpolation, aufeinander abgestimmt werden. Ist dies der Fall, so läuft der Arm hörbar leise und ruckelfrei, sodass unter anderem gezeichnete Linien sauber dargestellt werden können. Der Verschleiß der Elektromotoren nimmt dabei auch drastisch ab.

Ist die Geschwindigkeit nicht an die Beschleunigung angepasst, so fährt der Roboter lange bei eingestellter Geschwindigkeit. Dies ist nicht zwingend ein Problem, sofern die Targets weit voneinander entfernt liegen. Ist dies nicht der Fall, so muss der Roboter aufgrund von zu kurzer Beschleunigung hart abbremsen, bevor ein neuer Punkt angefahren wird.

Ist wiederum die Beschleunigung zu stark, die Endgeschwindigkeit aber im Verhältnis zu gering, so muss der Arm vor jedem Punkt stark bremsen und es kommt wieder zu einer ruckelnden Bewegung. Anschließend muss er wieder von der langsameren Endgeschwindigkeit hochbeschleunigen. Die Interpolation zu erhöhen, hilft hier nur bedingt.

Sind Geschwindigkeit und Beschleunigung nicht an die Interpolation angepasst, so kommt es zu starken Ruckelbewegungen, die oft nicht vom Arm gefahren werden können. Der Roboter versucht, in den engen Raum zwischen den Targets sowohl die Beschleunigungs- als auch die Geschwindigkeitsparameter unterzubringen.

Ein Segment, dem ich mich ursprünglich nicht gewidmet habe, in das ich dann später aber doch eingestiegen bin, war der Modellbau. Ziel hier war es, vor allem durch Hinterschnitte die Alleinstellungsmerkmale eines 6-Achs-Roboterarmes aufzuzeigen. Um dies herauszufinden, haben wir mit einem Heißdrahtschneider7 und EPS (expandiertes Polystyrol) gearbeitet. Diese Methode ermöglichte es uns relativ schnell und unkompliziert, grobe Formen zuzuschneiden. Um mich mit der Materialität besser vertraut zu machen, habe ich zunächst einen Stuhl ausgeschnitten, der aus einer einfachen 2-dimensionalen Form extrudiert wurde.

Dieser erste Test machte deutlich, dass besonders die Interpolation und Geschwindigkeit angepasst werden mussten, um optimale Ergebnisse zu erhalten. Bei geringer Interpolation sieht man deutliche Stufen in der Oberfläche, die teils noch durch die Hitze des Drahtes verstärkt werden. Da die Temperatur jedoch nicht angepasst werden konnte, musste die Geschwindigkeit angepasst werden, um einen sauberen Schnitt zu ermöglichen. Fährt der Arm zu langsam, würde der Draht zu viel Material wegschmelzen und keine Detailtreue mehr gewährleisten. Fährt er jedoch zu schnell, werden Kurven und Richtungsänderungen nicht akkurat abgebildet, und der Draht könnte im schlimmsten Fall reißen.

Da die Geschwindigkeitsparameter in direkter Korrelation zu der Anzahl der Targets und der Überblendung (Interpolation) zwischen diesen Punkten stehen, habe ich die späteren Fahrgeschwindigkeiten nur noch mit der Override des Ur5e Teach Panel angepasst.

Ein späterer Test zeigte in Bezug auf die Parameter deutliche Erfolge, und so konnten wir Schnitte zu der Flächennormalen einer vorgegebenen Form ausführen. Diese Verdrehung des Werkzeugs zur Form ist mit keiner anderen Technik möglich und ein Alleinstellungsmerkmal des Roboterarms.
Ein weiterer Vorteil des Roboters lag in der Geschwindigkeit, in der der Zuschnitt erfolgte. Würde es möglich sein, die Formen zu fräsen, so würde dies maschinell deutlich länger dauern, abgesehen davon, dass die Materialität nicht gut zu fräsen ist.
Da die Verortung von Objekt und Werkzeug zwischen der Software und der Realität nicht immer korreliert, habe ich ein Testprogramm erstellt, mit dem es mir gelang, die Umrisse der Styroblöcke mit der Software zu synchronisieren. Gestalterisch habe ich mich mit Akustikelementen zur Schallabsorption auseinandergesetzt. Mein Ziel war es, durch Hinterschneidungen Formen zu generieren, die den Schall einfangen sollten, um ein Abprallen und Zurückwerfen der Schallwellen zu verhindern. Dies würde den Effekt von porösen Schallabsorptionsplatten verstärken. Obwohl EPS in der Form nicht das beste Material für den genannten Zweck darstellt, bietet es doch eine günstige Experimentiergrundlage.

Aus dieser Idee entwickelte ich diverse Formen, jedoch konnte ich nicht alle Vorteile des Roboters nutzen. Da die Elemente entformbar bleiben mussten, habe ich darauf verzichtet, die eben beschriebene Möglichkeit zu nutzen, das Werkzeug verdrehen zu können. Letzten Endes bestanden meine Akustikelemente alle aus extrudierten Kurven, das Experimentieren mit verdrehten Formen wird erst mit elastischen Thermoplasten möglich sein, da sich diese trotz Verschränkungen entformen lassen.

Den Roboter etwas schreiben zu lassen war eine der ers ten Zielsetzungen, an die wir uns herangewagt haben. Anfangs haben wir noch versucht, durch das Festlegen einzelner Wegpunkte auf dem Teach Panel den Roboter „HAWK“ schreiben zu lassen. Dies war zwar möglich, das Ergebnis aber nicht zufriedenstellend. Nur um diese 4 Buchstaben, die auch nur aus 2-Punkt-Polylinien bestehen, zu schreiben, haben wir Stunden gebraucht. Die Programme konnten nur von Anfang an gestartet werden, kleinste Veränderung waren mühsam zu implementieren. Wir wussten bereits, dass wir später dies Problem mit geeigneter Software viel leichter würden lösen können, jedoch galt es auch, das Potenzial der vorhandenen Benutzeroberfläche in Form des Teach Panels auszutesten. Letztendlich stellte sich heraus, dass das Teach Panel nicht annähernd ausreichen würde, um unseren Ambitionen gerecht zu werden.

Nachdem wir die HAL-Lizenz bekommen hatten, war es möglich, Kurven in Rhino zu erstellen, die ich dann abfahren konnte. Zunächst habe ich die Buchstaben HAWK zu einer einzigen Polylinie zusammengefasst, da ich so nur eine Linie in Targets verwandeln musste. Dies würde später deutlich Zeit sparen und die Fehleranfälligkeit minimieren. Nach den ersten Tests musste ich feststellen, dass der Arm den Stift nicht anheben würde, wenn er mit dem Schreibprozess fertig war. Da sich Anfangs- und Endpunkt auf derselben 2-dimensionalen Höhe befanden, fuhr der Roboter den kürzesten Weg zurück zum Anfang und zog dabei einen Strich über das zuvor Geschriebene. Der Arm nimmt immer den kürzesten Weg zwischen zwei ihm vorgegeben Punkten, dies bedeutet, er würde es auch zwischen zwei unterschiedlichen Buchstaben machen. Da auch die Orientierung der Linien beim Generieren der Bahnen zufällig ist, kommt es auch dazu, dass der Arm selbst bei nur einem Buchstaben zusätzliche und ungewollte Linien zieht.

Für jegliche Weiterarbeit zu diesem Thema war es nötig, dass der Roboter eine Freifahrtbewegung ausführte, sobald er mit einer Linie fertig war. Natürlich hätte man manuell beim Erstellen der Linien diese in Z-Ebene verlängern können, jedoch hätte man das für jeden Buchstaben einzeln machen müssen. Dies wäre nicht nur minutiöse Arbeit gewesen, sondern auch extrem zeitaufwendig. Ich habe das Problem direkt in Grasshopper gelöst.

Der Benutzer kann Schrift unbearbeitet in Rhino generieren und in HAL übertragen. Dort werden dann die Anfangs- und Endpunkte einer jeden Linie extrahiert und in Z Ebene verschoben, der Abstand ist dabei frei einstellbar. Danach werden die veränderten Punkte der Originallinie wieder zugefügt. Beim Prozess des Umwandelns von Punkten in Targets erkennt HAL diese Punkte als Teil der Linie und erzeugt weitere Targets zwischen verändertem Punkt und der Linie. Somit ist der Übergang zwischen Ein- und Ausfahrtpunkt sanft und präzise. Der größte Vorteil hierbei ist die adaptive Fähigkeit. Jede Schrift oder Grafik kann so fehlerfrei 2-dimensional abgebildet werden.
Später fand Martin Kuhlenkamp heraus, dass RoboDK diese Art der Bewegung schon werksseitig implementiert hat. Dies war jedoch nicht sonderlich ärgerlich, da die Möglichkeiten von Grasshopper uns später deutlich mehr Freiheiten geben würden.
Im nächsten Schritt wird nun versucht, menschliche Handschrift einzuscannen, in definierte Buchstaben zu transformieren und diese dann vom Roboter schreiben zu lassen. Dies wird zusammen mit dem Thema Gestik die Bestrebung den Roboterarm menschliche Züge zu verleihen einhergehen.

Während des Semesters wurden einige Werkzeuge hergestellt, die zumeist sehr unterschiedlichen Zwecken dienten. Dies ergab sich aus der Notwendigkeit heraus, dass es kein universelles Werkzeug gibt, das für unsere Anwendungen nutzbar wäre. Zu Beginn haben wir viel mit dem 2-Finger-Greifer von OnRobot gearbeitet, der zwar viele Aufgaben erledigen konnte, jedoch nicht in der Qualität, in der es von uns gewünscht war. So konnte man z.B. einen Stift einspannen und damit schreiben, er verschob sich jedoch schnell in den Spannbacken und es konnte nicht mehr ausreichend Anpressdruck gewährleistet werden. Die Werkzeuge waren daher eher Mittel zum Zweck, um unsere Ziele zu erreichen, boten jedoch auch viel Spielraum für Kreativität.

Die Bedienung und Programmierung eines Industrieroboters ist zweifelsohne nicht direkt mit Design verbunden, besonders nicht in den Anfängen, wenn es um den Erwerb des nötigen Knowhows geht. Die Werkzeuge hingegen mussten gestaltet werden. Und auch, wenn es weniger um das Styling als um Funktionalität ging, so gab es doch immer einen Designprozess, so kurz er auch teilweise ausgefallen sein mochte. So musste immer aufs Neue über die Anwendung, den Funktionsumfang, die Materialität, die Handhabung, die einwirkenden Kräfte und natürlich auch über die Formalästhetik entschieden werden.

Beim Bau dieser Werkzeuge kam es vor allem auf Geschwindigkeit an. Von der Erstellung bis zum ersten Druck dauerte es oft nur ein paar Stunden, wenn nicht weniger. Dies beschleunigte natürlich die Wartezeit bis zur Nutzung, jedoch mussten auch oft noch Teile nachgedruckt werden, da Details oder Funktionen nicht wie erwartet ausfielen.

In diesem Semester sind unter anderem ein federgelagerter Stifthalter für Schreibzwecke, ein Halter für eine Gartenharke, ein Universalflansch zum Anbringen diverser Werkzeuge, ein 2-Finger Greifer, ein Bajonettanschluss zum Anbringen einer Orthese sowie ein Extruder und ein Massageroller entstanden. Dabei wurde der Massageroller von Dennis Rezvan und der Extruder von Martin Kuhlenkamp und Jasper Kühn gebaut.

Geplant sind diverse weitere Werkzeuge, in erster Linie jedoch ein funktionaler Extruder für den 3D-Druck.

Ursprünglich wurde der Drehteller von Tobias Brambor gebaut und von Jasper Kühn programmiert.
Die Idee hinter dem Drehteller war es, mehr Möglichkeiten für die Erstellung von Objekten durch z.B. Styroschnitt zu schaffen. Die Grenzen des Roboterarmes liegen vor allem in der Reichweite, so ist es nur begrenzt möglich, ein Objekt aus verschiedenen Richtungen zu bearbeiten. Die Drehachse soll dies weitgehend realisieren. So kann ein Objekt, welches um 360 Grad gedreht wird, aus 5 Richtungen bearbeitet werden. Einzig die Bodenfläche bzw. Standfläche ist dann noch unbearbeitet.

Zu diesem Zeitpunkt wird der im Drehteller verbaute Schrittmotor über einen Arduino gesteuert, der wiederum durch physische Knöpfe bedient wird. Das Problem hierbei ist, dass der Drehteller über eine externe Anweisung gestartet werden muss, nicht über den Roboter selbst. Diese Integrierung wurde später teilweise umgesetzt, sodass Befehle für die digitalen Schnittstellen des Roboters direkt auf der UR Bedienoberfläche gestartet werden konnten. Jedoch löst dies die Probleme der vollständigen Integration des Drehtellers als vollautomatisches Objekt nicht. Die Bearbeitungsprogramme, die am PC erstellt werden, kommen in Form von Skripten an den Ru5e an. Dieser liest dann das Skript, kann aber keine digitalen Befehle mehr in das einbinden. Daher müssen die Befehle schon innerhalb der Software eingebettet werden. Dies ist zum jetzigen Zeitpunkt jedoch nur bedingt möglich. HAL erlaubt zwar die Integration dieser Befehle in das Script, jedoch funktioniert das zu diesem Zeitpunkt noch nicht, da HAL einfach noch nicht ausgereift genug ist. Über RoboDK vermag ich keine Aussage zu treffen, da habe ich es bisher noch nicht getestet.

Nachdem wir uns weiter mit dem Modellbau beschäftigen wollten, sollte der Drehteller auch wieder in Funktion treten. Um die Programmierung des Drehtellers jedoch einfacher und vor allem verständlicher für andere Studenten zu gestalten, habe ich den Code von Jasper Kühn weiter angepasst und die Dateien bereinigt. Nun sollte jeder Student/Dozent in der Lage sein, den Drehteller auch ohne Programmierungskenntnisse zu bedienen.

Auch habe ich die Elektronik überarbeitet und modifiziert, um die Handhabung weiter zu erleichtern. Der Schrittmotor wird über einen Motorentreiber mit einen Arduino Uno angesteuert. Der Motorentreiber unterstützt bis zu 16-faches „microstepping“, also Mikroschritte, die eine flüssigere Drehbewegung ermöglichen. Diese Funktion wird momentan noch nicht genutzt, kann aber manuell direkt auf der Platine eingestellt werden. Wenn dies gemacht wird, so muss im Code die gewünschte Schrittanzahl mit dem Mikroschritt-Unterteilungsfaktor multipliziert werden.

Gesteuert wird der Drehteller manuell über 3 SMD-Taster, der grüne startet das Programm, der rote setzt das Programm zurück. der gelbe Taster soll in Zukunft ein Pausieren des Programms ermöglichen.

An den Arduino sind zudem 2 weitere Kabel angelötet, welche über die digitalen Ausgänge des Ur5e Controllers Signale direkt an den Schrittmotor senden können.
Für die gesamte Elektronik wird ein Schaltplan erstellt, der eine Übersicht über die Signale und Verkabelung verschaffen soll.

Eine der Notwendigkeiten, die sich sehr schnell herauskristallisiert hat, war die Benutzung einer Universalverbindung zwischen Werkzeug und Flansch, um die M6-Gewinde des Ur5e nicht abzunutzen. Dies ist nicht nur notwendig, um den Verschleiß und im schlimmsten Fall den daraus resultierenden Austausch des Flansches zu umgehen, sondern auch, um den Werkzeugwechsel deutlich schneller und einfacher zu gestalten.

Da die Industrie schon auf solche Systeme zurückgreift, habe ich mich nach einer Recherche für eine Schnellspannverbindung entschieden. Diese ermöglicht eine hohe Haltekraft bei geringer Fehleranfälligkeit. Ähnliche Systeme kommen vor allem bei Fahrrädern zum Einsatz. Mechanisch umschließt ein Verbindungsstück die beiden Hälften des Adapters und des Werkzeugs. Ein Formschluss verhindert, dass diese sich wieder voneinander trennen können, während eine weitere Verkantung in Form einer zahnradähnlichen Extrusion im Zentrum der beiden Hälften, eine Torsion verhindert.

Die Spannbacken werden mit einer M3-Schraube am Öffnen gehindert.
Der Universalflansch wurde in Form und Größe an den 3D-Druck angepasst und sollte Zugkräfte von ~25 Kilo aushalten.

Dieser Universalflansch dient bis auf weiteres als funktionale Gestaltungsgrundlage weiterer Werkzeuge. Die Maße sind der technischen Zeichnung zu entnehmen.

Der Greifer ist das bisher komplexeste Werkzeug, das ich im Rahmen des Projekts erstellt habe. Nach der Vorarbeit durch Jasper Kühn, die die Elektronik des Extruders von Martin Kuhlenkamp sowie die digitale Kommunikations-Schnittstelle des Ur5e betraf, begann ich damit, den Greifer mitsamt Elektronik zu konstruieren. Aufgrund des hohen Zeitdrucks in Verbindung mit dem Interaction Design Team entschied ich mich, einen als CAD Daten im Internet erhältlichen Greifer 3D zu drucken, um so nur die Elektronik implementieren zu müssen. Schnell wurde jedoch klar, dass die Vorlage meinen Ansprüchen an Stabilität, Mechanik und Formalästhetik nicht genügen würde. Andere Modelle boten leider auch keine bessere Alternative. So habe ich letzten Endes den gesamten Greifer neu konstruiert, und nur die Größe und einige Funktionsweisen stimmen mit der Vorlage überein. Dabei habe ich mich an den Abmessungen des Onrobot Greifers orientiert, der sich lange Zeit in unserem Besitz befand.

Technisch habe ich den Greifer mit einem Nema 17 Stepper Motor betreiben, da ich mit diesen Motoren schon Erfahrungen sammeln konnte und mir erhofft hatte, eine höhere Greifkraft als mit vergleichbaren Servomotoren zu erreichen.

Auch hatte ich die Absicht, die gesamte Elektronik zu verstecken und ein geschlossenes System schaffen, welches „Plug and Play“ funktionieren sollte.
Die Elektronik wurde im Vergleich zum Extruder deutlich in der Größe reduziert, ohne an Funktionalität einzubüßen, und befindet sich nun komplett in einem Sockel unter dem Greifer selbst. Es führt nur noch ein Kabel von dem Sockel zu der digitalen Schnittstelle am Greifarm, wie es auch bei den Industrieprodukten der Fall ist. Dieses sendet nicht nur die Signale an die Motoren, sondern versorgt die Elektronik mit Strom und ermöglicht, ein digitales Feedback durch Sensorik am Greifer zu bekommen.

Ein großes Problem in Bezug auf die Elektronik ist der benötigte Strombedarf. Der Werkzeugflansch kann nur bis zu einem Ampere an Stromstärke abgeben. Sollte dieser Wert aufgrund des hohen Bedarfs überschritten werden, so wird eine Fehlermeldung ausgelöst und der Roboter schaltet sich ab. Daher ist es nötig, die Motorentreiber an diese Vorgabe anzupassen. Wichtig ist, dabei zu beachten, dass trotz niedrig eingestellter Spannung Stromspitzen, die beim Ein- und Ausschalten auftreten, diese Fehlermeldung auslösen können.

Die Kosten des Greifers belaufen sich auf etwa 200€, den 3D-Druck mit eingerechnet. Dies entspricht etwa 1/10 einer vergleichbaren Industrieversion. Obwohl der Greifer in Greifkraft und Optimierung nicht mit den Industrieprodukten mithalten kann, bietet er doch eine gute Grundlage, mit der es möglich ist, den Nutzen und mögliche Anwendungsgebiete zu testen, bevor reichlich mehr investiert werden muss, um einen Industriegreifer zu erwerben. Dies bietet gerade Neulingen in der Robotik eine optimale Möglichkeit, sich mit solchen 6-Achs-Armen vertraut zu machen.

Die deutlich sichtbaren Schrauben waren nötig und wurden damit Gestaltungsmerkmal. Wo es hingegen möglich war, wurden diese versteckt. Die Schrauben selbst sollten daher ästhetisch wirken und es wurden Innensechskant-Zylinderkopf- und Senkkopfschrauben verwendet. Insgesamt befinden sich in dem Modell 28 Schrauben. Formalästhetisch hatte ich die Absicht, den Greifer leicht zu gestalten und habe daher die Greifarme eher organisch designt. Der Rest des Greifers wurde eher minimalistisch gestaltet, um sich mehr dem UR5e anzunähern, der auch sehr schlicht gehalten ist.

Die Endkappen an den Greifarmen sind austauschbar, was mehr Variabilität für speziellere Anwendungen ermöglichen soll.
Sollten wir später einmal speziellere Druckmethoden zur Verfügung haben, so könnten hier besonders flexible, gummiartige Endkappen aus TPE oder TPU12 zum Einsatz kommen.
Optimiert werden muss vor allem das Spiel in den Armen, denn diese treffen mit einem Versatz von etwa 1mm aufeinander und können unter Druck nachgeben. Eine Materialeigenschaft, die dem 3D-Druck geschuldet ist, jedoch lässt sich der Spielraum sicherlich noch verringern.

Ein optimierter Universalflansch soll einen automatischen Werkzeugwechsel ausgehend vom Roboter ermöglichen. Dies muss nicht zwingend zusätzliche Elektronik erfordern, sondern sollte im Idealfall rein mechanisch passieren. Das würde zusätzliche Kabel an Werkzeug und Bauplattform des Roboterarms sparen und wäre schneller umzusetzen. Erste Prototypen dieser Verbindung arbeiten mit einem Bajonett-System, bei dem der Arm sich selbst nach Fixierung des Werkzeugs aus dem Werkzeug heraus- oder in das Werkzeug hineindreht.

Der Greifer muss elektronisch und damit funktional auf eine Ebene gebracht werden, in der dieser wartungsfrei funktioniert. Außerdem soll ein weiterer Greifer konstruiert werden, der über eine Spindelverbindung mehr Greifkraft aufbauen kann. Zusätzliche, andere Greifer sind denkbar.

Der Extruder von Martin Kuhlenkamp sollte mit neuer Elektronik und einigen Verbesserungen am Gehäuse erneut gebaut werden. Der Extruder hat einige Zeit gut funktioniert, nun jedoch gibt es einen unauffindbaren Wackelkontakt, der die Benutzung unmöglich macht. Dieser sollte dadurch auch behoben werden. Da Extruder und Greifer die gleiche Elektronik verbaut haben, sollte die Fehlerbehebung des einen auch Fortschritte beim anderen erzeugen.

Die Akustikelemente werden aus einem passenden Material geschnitten und im besten Fall vermessen, um Streuung und Schallabsorption analysieren zu können. Gleichzeitig werde ich weitere Elemente entwickeln, die verdrehte Formen beinhalten. So werden die Einsatzmöglichkeiten des Armes noch deutlicher und die Gestaltung subjektiv ansprechender. Weitere Experimente in Bezug auf Styroschnitt beschäftigen sich mit der Maximierung der Objektgröße sowie einer 360-Grad-Bearbeitung. Auch andere Materialien kommen nun für uns in Frage.

Grafisch wäre es wünschenswert, durch die Implementierung von Pinseln oder anderweitigen Werkzeugen eine Hausfassade gestalten zu können. Dies würde eine erste echte Anwendung in 2-dimensionaler, gestalterischer Sicht darstellen.

Auf digitaler Ebene muss noch einiges getan werden. Die Grasshopper-Dateien wurden gegen Ende des Semesters von mir überarbeitet, um als Vorlagedateien für spätere Projekte zu dienen. Diese müssen jedoch noch weiter angepasst und verändert werden, im Idealfall versehen mit Notizen und Erklärungen.

Rein organisatorisch werden die Dateien dann für alle zugänglich sein, die Erstellung dieses Netzwerkes ist bereits angestoßen worden. Damit sollte der Datenaustausch deutlich verbessert werden und auch das Teilen von Informationen wird optimiert.

In Bezug auf Fehlerbehebungen diverser Arten gibt es auch noch Verbesserungspotenzial. So müssen die Fahrparameter weiter angepasst werden. Im besten Fall geschieht dies durch Funktionen, die alle Einstellungen in Korrelation zueinander gleichzeitig verändern. So könnten Veränderungen der Datei adaptiv erfolgen, ohne weitere Probleme auszulösen.

Einige Zukunftsprojekte werden auf den nächsten Seiten vorgestellt. Diese befinden sich in meiner persönlichen Planung, andere Studenten mögen für das kommende Semester eigene Ziele haben.

Eine der eher spielerischen Ideen, die während des Semesters entstanden ist, war die Erstellung einer fahrbaren Plattform, auf die der Ur5e installiert werden kann. Dies würde uns erlauben, den Roboter nicht nur zu Installationszwecken leichter an anderen Orten aufstellen zu können, sondern würde uns auch die praktischen Nutzungsmöglichkeiten erweitern. So würde der Arbeitsbereich besonders bei grafischen Anwendungen z.B. an Wänden deutlich vergrößert werden. Auch interaktiv würde der Roboter durch eine verbesserte Mobilität mehr Einsatzmöglichkeiten bieten.

Der Gedanke, Roboterarmen durch eine solche Plattform mehr Einsatzgebiete zu verschaffen, ist weder revolutionär noch neu. Es gibt einige Ansätze, die sich dieser Idee verschrieben haben, der prominenteste davon kommt von KUKA, einem Konkurrenzunternehmen zu Universal Robots. Dies ist wenig verwunderlich, da die Arme so in logistischen Industrieaufgaben eingesetzt werden können. Um die Möglichkeit zu testen, eine solche Plattform selbst bauen zu können, habe ich den Physical Computing Kurs von Jasper Kühn genutzt. Dort baute ich einen Arduino basierten Prototyp. Dieser Prototyp wurde deutlich komplizierter gestaltet, als es für die Plattform nötig sein würde, dies bot jedoch die Chance, verschiedenste Funktionen zu testen.

Nach diesem erfolgreichen Test wäre eine Umsetzung zu einem voll funktionalen Modell durchaus denkbar, bleibt jedoch noch in der Planung, da die Anpassung in Größe und Tragkraft noch einiges an Entwicklungszeit benötigen würde.

Der Ardunio Prototyp besitzt 4 Mecanum-Räder, welche insgesamt 10 Bewegungsrichtungen erlauben. Verbunden sind die Räder mit Nema 17-Schrittmotoren, die individuell angesteuert werden können. Dies ist auf der einen Seite nötig, um das Potenzial der Mecanum-Räder auszureizen, auf der anderen Seite erlaubt es uns, die Plattform hochpräzise zu steuern und ein gewisses Maß an Autonomie zu implementieren. Die Plattform verfügt zudem über Ultraschall-Distanzsensoren, die für Sicherheit sorgen, und Endschalter, die den Roboter herunterfahren, sollte eine Wand oder ein Gegenstand angefahren werden. Zudem verfügt sie noch über ein LED-Band, welches um den Roboter herum angebracht ist, um die Fahrtrichtung sowie eventuelle Gefahrenbereiche oder Probleme zu indizieren. Gesteuert werden kann die Plattform über eine Funkfernbedienung oder über Bluetooth in Verbindung mit einer App auf dem Smartphone.

Ursprünglich handelt es sich hierbei um ein Projekt von Dennis Rezvan und Felix Ewald, in das ich erst später eingestiegen bin. Nachdem Dennis die MDF-Bauteile des Beetes gelasert hatte, habe ich diese verleimt und zusammengebaut, anschließend bin ich dazu übergangen, ein Programm zu schreiben, mit dem es möglich sein sollte, den Arm die Pflanzen autonom pflegen zu lassen. Wichtig war dabei vor allem die Bewässerung der Pflanzen. Aus den Erfahrungen mit dem Kaffeeautomaten war mir wichtig, den Fokus auf adaptive Programmgestaltung zu setzen. Der Roboter sollte nicht darauf programmiert werden, täglich eine bestimmte Menge Wasser aus einem Gefäß über den Pflanzen zu verteilen. Vielmehr musste er reaktiv auf den Wasserbedarf der Pflanzen eingestellt werden. Dies ging jedoch nicht ohne weitere Elektronik.

Da jedoch kein Roboter benötigt wird, um ein funktionales autonomes Beet mithilfe von Arduino zu konstruieren, musste ich einen echten Nutzen für den Roboter finden. Die automatische Bewässerung aus unterirdisch verlegten Schläuchen ist deutlich effektiver als die Bewässerung von oben, jedoch gilt dies nicht für alle Pflanzen. Gerade tropische Pflanzen wie Bromelien profitieren von einer Bewässerung von oben und einer hohen Luftfeuchtigkeit. Aufgrund dieser Tatsache könnte der Roboter mit einem Sprühwerkzeug ausgestattet werden, welches an einen Wasservorrat angeschlossen ist. So wäre es dem Roboter möglich, eine 360-Grad-Besprühung einzelner Pflanzen adaptiv zum Pflanzenwachstum zu tätigen.

Dabei würden Feuchtigkeitssensoren an der Pflanze und im Boden messen, wann der Roboter aktiviert werden muss, und das Programm würde gestartet werden. Ein Arduino würde die Überwachung der Sensoren übernehmen und entsprechende Signale an einen Computer schicken. Dieser würde dann zuvor eingespeicherte Programme über die bereits erklärten Socket-Befehle abrufen.

Dies kann jedoch aufgrund des Apperaturaufbaus nicht innerhalb des Semesters umgesetzt werden und wird deshalb hoffentlich im Frühjahr 2020 getestet. Nach den dann folgenden Semesterferien wird sich herausstellen, ob das Projekt ein Erfolg war.

Um das Segment MRK (Mensch-Roboter-Kollaboration) anzugehen, gab es die Überlegung, dem Arm menschliche Züge in seinen Bewegungen zu verleihen. Da ich zum jetzigem Zeitpunkt noch an dem Thema arbeite, beschreibe ich hier das Projekt eher konzeptionell.

Um eine Gestik, eine Bewegung oder Aktion auf den Roboter zu übertragen, gilt es als erstes, diese einzufangen. Momentan geschieht dies mithilfe von Virtual Reality. Mit der HTC Vive und dem Programm Mindesk, welches eine Rhino-Schnittstelle erzeugt, bin ich der Lage, eine Polylinie in den 3-dimensionalen Raum zu zeichnen. Dann kann die Rhino-Datei mit HAL geöffnet werden. Die Polylinie wird als Fahrbewegung erfasst und kann auf den Ur5e übertragen werden. Obwohl dies funktioniert, ist es natürlich noch lange nicht optimal oder erfüllt das von mir ge- steckte Ziel. Der Weg von der menschlichen Bewegung zu der des Roboters ist zu lang. Hier wäre eine Echtzeitübertragung absolut wünschenswert und nötig.

Auch ist der Weg selbst nicht wirklich intuitiv oder direkt. Virtual Reality bzw. das Mindesk ist in Unity programmiert, muss dann in Rhino/HAL und anschließend in UR-Script umgewandelt werden. Hier wäre es sicherlich besser, wenn man die Bewegungen in Unity einfangen und über Processing direkt an den Roboter schicken könnte. Ob das in der Art funktionieren kann, bleibt einer intensiven Recherche überlassen.

Auch wichtig ist zu wissen, wo sich der Roboter im Raum befindet und wie weit eine Bewegung gehen darf. Ein Echtzeitmodell des Roboters in Unity würde dabei helfen, keine Bewegungen zu machen, die in Fehlern aufgrund von ausgereizten Gelenkgrenzen enden.

Sollte dies jedoch erfolgreich sein, könnte man durch eine Echtzeitbedienbarkeit nicht nur einen größeren Bezug der Menschen zum Objekt generieren, sondern auch die Einsatzmöglichkeiten drastisch erweitern.
Auch „machine learning“, also das Aufnehmen und Verarbeiten von Informationen, könnte eine bedeutende Rolle spielen. Der Roboter würde dann von uns lernen, indem wir Bewegungen vormachen, die anschließend von Algorithmen erfasst und ausgewertet werden können. Diese Daten würden dann als Grundlage der vom Roboter imitierten Bewegungen dienen.

Da ich persönlich zum jetzigen Zeitpunkt jedoch noch nicht über die erforderlichen Kenntnisse verfüge, um das Vorhaben in der beschriebenen Form umsetzen zu können, bleibt der Erfolg dieses Projektes abzuwarten. Jedoch verfügt die Hochschule über viele kreative Köpfe, sodass eine Umsetzung durchaus denkbar wäre. Des Weiteren gibt es einige interessante Ansätze anderer Universitäten, die sich bereits mit dieser Idee beschäftigt haben. Es wird spannend sein herauszufinden, ob es für uns möglich ist, an deren Arbeit anzuknüpfen. Viele Universitäten beschäftigen sich eher mit „machine learning“ oder „reinforcement learning“ und nutzen diese Technologien, um die Programmierung der Arme zu erleichtern.