Artikel – botzeit

Robotics for Software Engineers – Interview mit Andreas Bihlmaier

Posted on 19. Juli 202220. Juli 2022 by Arne

Mitte Mai habe mich mit Andreas Bihlmaier unterhalten, mittlerweile Chief Software Architect bei ABB. Ich kenne Andreas schon länger und er schreibt aktuell an dem Buch „Robotics for Software Engineers“, von dem man schon erste Leseproben und Kapitel lesen kann.

Worum es in dem Buch geht und wie es dazu kam, habe ich mit ihm besprochen.

Andreas Bihlmaier, Chief Software Architect bei ABB

Ich: Andreas, woher und wie lange kennen wir uns eigentlich?

Andreas Bihlmaier: Wir sind uns glaube ich im ERF-Universum (European Robotics Forum) immer wieder über den Weg gelaufen. Das Thema Software Engineering for Robotics liegt mir ja schon länger sehr am Herzen und da warst Du ja schon deutlich aktiver als ich, z.B. in der Topicgroup. Ich glaube, das waren die ersten Überschneidungen. Vermutlich haben wir uns auch 2014 auf de SIMPAR in Bergamo in Italien gesehen.

Das stimmt! Da haben wir uns bestimmt gesehen, da war ich auf jeden Fall auch für den DSLRob-Workshop.

Also 8 Jahre kennen wir uns damit auf jeden Fall schon! Davon abgesehen verbinde ich Dich immer schon mit dem Thema „Software & Systems Engineering for Robotics“, ERF, und der euRobotics Topicgroup „Software Engineering, Systems Integration and Systems Engineering“.

Damals warst Du aber ja noch bei robodev.

Genau! Beziehungsweise ganz am Anfang war ich noch am Lehrstuhl. Dann habe ich noch einen kleinen Abstecher zu Google Research gemacht, Ende 2015 meine Dissertation fertig geschrieben und dann im April 2016 robodev gründet. Unter der Flagge war ich dann seither auf den ERFs unterwegs.

Unser gemeinsames Thema war allerdings immer schon Softwareengineering und Robotik, darum dreht sich ja auch in diesem Gespräch. Da ist noch viel zu tun und da ist das letzte Wort definitiv auch noch nicht gesprochen.

Aber Du hast ein Wort gesprochen! Du hast ja nämlich ein Buch darüber geschrieben: Robotics for Software Engineers. Darauf bin ich via LinkedIn aufmerksam geworden, habe die schon verfügbaren Kapitel gelesen und darüber möchte ich heute mit Dir sprechen. Kannst Du für all diejenigen, die das Buch noch nicht gelesen haben kurz zusammenfassen, worum es geht?

Inhaltsverzeichnis zum Zeitpunkt des Interviews, mit den ersten 4 Kapiteln schon online verfügbar (mittlerweile sind es schon mehr).

Ja, gerne! Das Buch kam dadurch zustande, dass mich jemand vom Manning-Verlag angeschrieben hat, ob ich eine Idee für ein Buch hätte. Meine erste Reaktion war: „Nein, das Schreiben der Dissertation hat mir genügt.“

Dann habe ich aber überlegt, was mir denn eigentlich noch fehlt. Es gibt ja schließlich schon zig Bücher über Robotik: das Springer Handbook of Robotics, Modern Robotics, Klassiker wie Probabilistic Robotics und A Modern Approach, Understanding Intelligence, etc. Wahnsinnig viele Robotikbücher, zum Teil sehr angewandt – wie programmiere ich Roboter mit ROS – zum Teil sehr akademisch oder forschungsorientiert; da übersteht man dann die ersten drei Seiten nicht ohne Lie-Gruppen und irgendwelche Exponential Maps. Und dann gibt es noch eine dritte Kategorie der Art „so bau ich mir einen Roboter“. Da geht es dann zu achtzig Prozent darum, wie ich einen DC-Motor anlöte und um den Mikrocontroller, um so ein bisschen Linien zu folgen. Und dann gibt es natürlich auch Bücher zum Programmierenlernen, die lediglich einen Roboter als Beispiel nutzen.

Das ist ja eigentlich wunderbar, aber irgendetwas fehlte mir. Nämlich ein Buch, das ich neu eingestellten Softwareentwickler:innen in die Hand drücken kann, die nicht per se Robotiker:innen sind. Das können Embedded-Software-Entwickler:innen sein, Cloud-Fullstack-Entwickler:innen, C++-Pogrammierer:innen und so weiter sein. Viel Softwareentwicklung für die Robotik ist ja nicht Hardcore-Regelungstechnik, oder Algorithmus-Engineering, sondern häufig ganz normales (embedded) Software Engineering. Ob ich das in Automotive mache oder für einen Roboter oder für eine Waschmaschine oder ein IoT device … ich brauche nicht immer extrem viel Domänenwissen.

Was mir immer gefehlt hat, ist ein Buch, das ich Personen in die Hand geben kann, die Software in einer einigermaßen modernen Sprache schreiben können – Python, C++, von mir aus auch Javascript – von Robotik aber noch nicht viel gehört haben – abseits vielleicht vom Terminator, Nummer 5 lebt!, und ein paar Boston-Dynamics-Videos. So fange ich dann bezogen auf die Robotik wirklich bei Adam und Eva an, aber ich muss nichts über grundlegende Programmstruktur erklären. So ein Buch habe ich tatsächlich nicht gefunden.

Aber die Robotik wächst ja auch als Feld. Es gibt ja sehr viele Bereiche um die Kernrobotik herum, sei es Serviceroboter, autonome Fahrzeuge, Drohnen, etc. Das ja ein breites Feld und es passiert extrem viel…

…und braucht entsprechend viele neue Softwareentwickler:innen.

Absolut! Und das ist die Zielgruppe.

Du hast erklärt, wie es zu der Kernidee und dem Titel des Buches gekommen ist und tatsächlich bin ich immer wieder über den Titel gestolpert. Irgendwie habe ich unbewusst immer wieder ein Buch zu „Softwareengineering in der Robotik“ erwartet, aber das ist es ja gerade nicht. Du willst ja stattdessen Softwareentwickler:innen und Programmierer:innen befähigen, zu verstehen, was eigentlich Softwareengineering für Roboter ausmacht und wie sie von Software in verwandten Disziplinen unterscheidet.

Genau! Es wird natürlich auch ein Kapitel dazu geben, worauf ich umgekehrt achten sollte, wenn ich Robotiksoftware schreiben will – im Sinne von Software Best Practices: welche Patterns sollte ich vielleicht nutzen oder wiedererkennen. Aber der Hauptteil ist wirklich wie du sagst: „ich bin schon Programmierer:in, jetzt möchte in der Robotik erfolgreich arbeiten können“.

Es ist also nicht das Buch, das ich Robotiker:innen gebe, die aus der Regelungstechnik kommen und Dynamikgleichungen ohne zu zögern an die Tafel schreiben, aber eben auch genauso ihren Code schreiben würden: also unwartbar und unverständlich.

Denn eigentlich ist ja Programmieren in der Robotik nicht so anders als in anderen Domänen: wenn ich ein Ziel habe, sammele ich mir die benötigten Softwarebibliotheken zusammen. Möchte ich einen Roboter bewegen, lade ich mir z.B. Bibliotheken herunter, die mir Kinematik machen. In diversen ROS-Büchern, z.B. Programming Robots with ROS von Quigley und Gerkey und Co. sehe ich aber, dass man als Robotik-Neuling dann mitunter ROS mit Robotik verwechselt. ROS ist so dominant, dass man dann z.B. denkt, der tf-Baum sei das fundamentale Konzept und nicht verteilte Koordinatensysteme oder wie ich diese repräsentiere. Das möchte ich anders handhaben und bringe erst einmal Grundlagen bei. Allerdings ohne Beweise und immer in der Robotik angewendet. Das ist natürlich ein schmaler Grat zwischen einfachen Kochrezepten und einem Buch über Mathematikgrundlagen.

Was ist denn Deiner Meinung nach der Vorteil davon, nicht tf zu lernen, sondern zu verstehen, warum verteilte Koordinatensystem in der Robotik so essentiell sind?

Ich denke, das ist eine grundlegende Herangehensweise: erst das Konzept, dann die Implementierung, nicht umgekehrt. Denn die Implementierung ist ja häufig willkürlich: warum ich mich für die eine konkrete Ausprägung der API entschieden habe und wie sich die Software genau sich verhält. Es ist also eher ein pädagogisches Grundkonzept, vor der spezifischen tf-API z.B. erst einmal zu verstehen, wie ich die Bewegung von Körpern im Raum relativ zueinander beschreiben kann.

Neben dem persönlichen Vorgeschmack für diesen Aufbau spricht aber auch die bessere Übertragbarkeit. Die großen Roboterhersteller – für einen davon arbeite ich ja seit einiger Zeit – haben ja ihre eigenen proprietären Robotik-Softwarestacks. Das heißt, wenn ich mich dann extrem gut mit ROS auskenne, aber das Konzept nicht verstanden habe, kann ich das schwer auf andere Implementierung übertragen und stehe auf verlorenem Posten. Ich glaube tatsächlich, dass es möglich ist, einen ROS Nav-Stack für mein mobilen Roboter aufzusetzen oder MoveIt zum Laufen zu bekommen ohne eigentlich Ahnung davon zu haben, was ich tue. Das ist aber natürlich kein robotik-spezifisches Problem…

… und erst einmal ja auch nicht schlimm, sondern auch eine Stärke von ROS, die wichtig für die Robotik war. Dadurch finden Leute einen Einstieg, die sich so irgendwann mal für Bücher wie Deines interessieren, aber ohne ROS erst einmal vor eine Wand gerannt wären – und vielleicht abgebrochen hätten.

Absolut! Ich werde auch nach den ersten paar Kapiteln, in denen ich noch gar keine Implementierung brauche, auf ROS 2 und Gazebo eingehen und Beispiele dann damit zeigen. Mit was denn auch sonst?! Ich konstruiere ja nicht extra irgendein Spielzeug-Robotikframework nur für ein Buch. Das hat dann vielleicht eine schöne und saubere API, aber ich kann halt nichts real damit tun. Ich erkläre den Lesern lieber, wie ich grundsätzlich z.B. inverse Kinematik mache und wie ich das beispielhaft mit RVIZ und URDF umsetze und mit Code, der gegen ROS linkt.

Das ist natürlich ein Spagat: ich habe ja selbst auch viele Jahre sehr intensiv mit ROS gearbeitet, so dass ich da nicht auch selber in die Falle tappen will. Ich verwechsle dann selbst auch schonmal den Namen des ROS-Pakets mit dem eigentlichen Problem, das ich lösen will.

Das ist natürlich auch schwer, weil es ja schon eine Art Best Practice gibt, Robotiksysteme zu bauen. Und viele dieser Methoden und Best Practices sind ja auch in ROS bzw. ROS 2 umgesetzt. Wenn man deswegen ROS-artig über Systeme nachdenkt, ist man meines Erachtens ja häufig auch nicht ganz weit davon entfernt, insgesamt eine plausible Sicht auf Robotersysteme zu haben. Das macht es natürlich umso schwieriger, die Teile zu erkennen, in denen ROS eine sehr spezifische Implementierung gewählt hat – zum Beispiel vielleicht tf – die vielleicht nicht immer auch gleichzeitig die Nützlichste ist. Sondern dann wieder zur abstrahieren: was ist eigentlich das zugrundeliegende Problem und was sind dann mögliche Lösungen?

Genau. Um eben auch sicherzustellen, dass die Leute verstehen, was hinter den Kulissen passiert. Ich will zumindest versuchen zu erklären, dass man inverse Kinematik nutzt, wenn man zum Beispiel von MoveIt eine Gelenkposition für eine kartesische Pose anfragt. Und dass ich das auf diese und jene Art angehen kann, dass die praktische Realisierung aber meistens eine numerische Lösung ist, usw. Die Leser:innen sollen zumindest verstehen, was dort im Hintergrund abläuft und ein Gefühl dafür bekommen, was passiert.

Best Practice versuche ich, vom Anfang an zu vermitteln. Also, kein Mensch würde seine Datenbank oder Webapplikationen so programmieren, dass er im Webserver mit dem Treiber der Festplatte redet, sondern da sind diverse Abstraktionsschichten zwischen. Und in der Robotik, gerade im Hobbybereich (manchmal auch von Leuten, die es an der Uni so betrieben haben) findet man zum Teil Systeme komplett ohne alle Abstraktionen. Da wird ein digitaler Eingang alle Ebenen hochgereicht. Da gibt es dann zwar eine ROS-Nachricht für, aber keine sinnvolle Semantik mehr.

Gerade in Robotiksystemen, weil sie oft komplex und vielfältig sind, muss ich mir von Anfang über die Architektur Gedanken machen, z.B. wie ich konzeptionell in verschiedene Belange aufteilen kann, die von verschiedenen Leuten bearbeitet werden können. Es muss dann ja auch nicht alles hardcore embedded Software sein. Es gibt einfach vielfach dieses Vorurteil, um überhaupt was mit Robotik machen zu können, müsse man sich erst einmal Mathematik reinziehen und dann quasi tief in den Registern herumstochern. Das schreckt viele ab.

Interessant! Diesem Vorurteil bin ich noch nicht begegnet. Ich habe manchmal den gegenteiligen Eindruck: dass viele Leute sehr hemdsärmlig herangehen, sich einen best effort ROS-Grafen zusammenhauen und sich um ganz viele Control- und Realtime-Aspekte gar nicht kümmern. Wenn das irgendwie läuft, ist das Robotik.

Es funktioniert ja beides leider nicht. Es geht nicht, nur mit Registern und Signalen zu arbeiten, dann habe ich schnell ein unwartbares System, das wahrscheinlich auch von Anfang an nicht das tut, was es tun soll. Aber das Gegenteil funktioniert auch nicht. Ich kann mir das, was sich vielleicht Webapplikationen, die vielleicht noch in einer Cloud laufen, leisten können, in der Robotik nicht leisten. Nämlich, dass ich mir alles in aller Schönheit abstrahieren und verteile. Sonst gehen mir die ganzen Regelkreise auf die Bretter, die vielleicht auch noch Realtime sein müssen.

Ich brauche halt eine Organisation von all diesen Aspekten. Denn wir haben ja mittlerweile in der Robotik auch Aspekte, die mitunter in der Cloud laufen müssen: Fleet Management, Deep Learning, Object Detection, und so weiter … aber in der Robotik muss es dann trotzdem am Ende irgendwie – im zweifel safety-kritisch, realtime, sehr verstanden und vorhersagbar – irgendwo in schnellen Regelkreisen enden.

Genau! Und da kommen wir zu der Frage, was denn der Kern der Robotik ist. Je nachdem, von welcher Richtung in der Robotik man blickt, sind es ganz unterschiedliche Dinge. Die einen sagen, alles oberhalb der Roboter-Dynamik ist nur Beiwerk. Die anderen sehen den Roboter als reines Positionier-Eisen und das wirklich spannende heutzutage liefe in der KI, der Bildverarbeitung, in Wissensmodellierung. Aber wie du sagst, spielt das alles mit.

Wenn jemand sich 15 Jahre um Echtzeit-Embeddedsysteme gekümmert hat und dann anfängt, Cloud-Systeme zu entwickeln, dann geht das schief. Und das Gegenteil habe ich auch schon gesehen: wenn Leute, die bisher skalierbare Softwarelösungen für Onlinedienste entwickelt haben, plötzlich Embedded-Robotiksoftware entwickeln, dabei aber alles erst einmal durch fünf Versionen von Memcashed und Redis schieben, kommt dabei auch nichts Gutes raus.

Es ist eben das Spannende an der Robotik, dass all diese Aspekte eine Rolle spielen. Das möchte ich mit dem Buch anreißen, um einfach den Lesern auch zu zeigen: hey, wenn du keinen Bock auf Regelungstechnik hast, aber trotzdem Robotik geil findest, dann gibt es für dich immer noch die anderen 90% dessen, was es braucht, um eine Robotikanwendung in die echte Welt zu bringen. Je nachdem, was ich eben mag: mag ich Mikrocontroller, mag ich Clouddienste, mag ich Echtzeit, mag ich Regelungstechnik, mag ich Algorithmik, mag ich Physiksimulation … da muss für jede:n Softwareentwickler:in was dabei sein.

Wir kreisen gerade um eine Frage herum, die ich mir auch schon gestellt habe. Gibt es eine Kernaussage, einen Kerngedanken, den Du mit diesem Buch transportieren möchtest? Der der besonders wichtig ist, weil es den so deutlich noch nicht gibt? Oder würdest du sagen, dass ist eher ein strukturiertes Zusammentragen von bekanntem Wissen der Robotik-Software-Community ist?

Ich würde nicht behaupten, dass ich mit diesem Buch jetzt etwas dem Robotics Body of Knowledge hinzufüge. Ich hab jetzt allerdings mehrere Wochenenden damit zugebracht, zu versuchen, mal nur für dieses Buch eine einheitliche Notation zu finden, die nicht nur für Manipulatoren passt oder nur für mobile Roboter. Daran bin ich fast verzweifelt. Du nimmst drei Bücher zur Hand und findest mindestens fünf Notationen. Aber man wird ja ein Buch sofort wegwerfen, wenn die Notation zwischen den Kapiteln über Kinematik von Manipulatoren und dem über mobile Roboter plötzlich inkonsistent ist. Das ist vielleicht so ein kleiner Beitrag, aber auch da orientiere ich mich natürlich an den großen Werken und erfinde nichts komplett Neues.

Ansonsten ist es eine einheitliche Darstellungen auf einem zugänglichen Niveau, würde ich sagen. Meine Kernbotschaft ist, was ich auch auf einer der ersten Seiten schreibe, dass für mich die Robotik das Feld ist, das sich damit beschäftigt, wie ich aus der virtuellen Welt in die reale Welt hinausreichen kann, und aus der realen Welt wieder zurück in die virtuelle Welt. Jedes Smartphone hat natürlich irgendwie einen Vibrationsalarm, ein Display und eine Kamera, aber in der Robotik ist es ja weit mehr. Die Frage, wie ich das, was ich in Software ausdrücken kann, in eine Manipulation oder Einflussnahme der echten Welt umsetzen kann. Das finde ich faszinierend!

Was wäre denn zum Beispiel das Robotik-Äquivalent zur universellen Turingmaschine. Also: wir wollen ein Mapping haben von dem, was wir in Software frei und flexibel ausdrücken können in die echte Welt. Es ist ja wirklich fast schon Magie: ich schreib hier in irgendwelchen arkanen Sprachen Symbole hin und dadurch teleportiert sich irgendwie der Kaffee von der Kaffeemaschine auf meinen Tisch. Nur dass die Teleportation momentan noch etwas kompliziert über ein mobilen Roboter erledigt wird, aber hey … es ist nah dran.

Dann jetzt ein Sprung zurück zum Buch selbst. Als ich die ersten Kapitel gelesen habe, die ich übrigens echt gerne gelesen habe, ist mir aufgefallen, dass es eine erstaunliche Zahl Vorwärtsreferenzen gibt. Die versucht man ja typischerweise beim Schreiben von wissenschaftlichen Arbeiten zu vermeiden. Als ich die so las, habe ich mich gefragt, ob das Dein Schreibstil ist, oder vielleicht ein Kernproblem der Robotik. Dass so viele Dinge so eng verzahnt sind, dass ich die gar nicht nicht systematisch oder chronologisch aufbauen kann.

Wenn man ein Buch oder Kapitel konzipiert, fragt man sich natürlich immer, von welcher Seite man den Gaul jetzt aufsattelt. Was ich auf jeden Fall vermeiden wollte, ist eine systematische Einführung. Also: erst einmal kommen zwei Kapitel Mathematik, dann x Kapitel Geometrie, etc. … und ganz am Ende vom Buch rede ich mal über Anwendungen in der Robotik. Das wäre zwar eine akademisch saubere Struktur, aber ich würde da viele Leser einfach früh verlieren. Das ist also der Mission des Buches geschuldet.

Das andere ist aber auch: es hängt natürlich vieles miteinander zusammen, wie Du gesagt hast. Nehmen wir z.B. Regelkreise: ich möchte den Lesern am Anfang über Vorwärtsreferenzen als Motivation direkt mitgeben, dass das noch an mehreren Stellen auftauchen wird. Relativ früh, wie ich den einzelnen Motor auf Geschwindigkeit oder auf Position bringen kann. Bei mobilen Robotern brauch ich dann irgendeine Rückmeldung aus der Umgebung, via LIDAR, Taster, und so weiter… ich möchte da früh die Augen öffnen: das kommt jetzt über den Rest des Buchs verteilt vor und taucht noch in der Sensordatenverarbeitung, der Bildverarbeitung etc. vor.

Das ist dann ja auch der direkte Anschluss zum Software Engineering: ich kann das ja auch abstrahieren und im Einzelfall ignorieren, dass ich keine perfekte Positionsregelung habe und das natürlich auch nicht instantan passiert. Aber ich ziehe bewusst eine Abstraktionsebene ein, ab der es nur noch um Positionen geht und alle Dynamik darunter ignoriere ich. Das kann eine gute oder eine sehr schlechte Idee sein. In der Robotik ist es glaube ich schwer, diese guten Ebenen zu finden. Denn es hängt auch vom Robotertyp und der Anwendung ab. Wenn ich mit einem normalen Industrieroboter eine einfache Anwendung mit niedrigen Geschwindigkeiten habe, arbeite ich mit Positionen. Wenn ich dann aber Anspruchsvolleres als z.B. Pick & Place will, dann wird es plötzlich extrem wichtig, auf diese Ebenen doch noch runter zu schauen. Diese natürliche Abstraktionsebenen wie zum Beispiel das Betriebsystemlevel in der IT gibt es in der Robotik noch nicht. Und diese Suche nach nützlichen Abstraktion zieht sich durch das gesamte Buch.

Es kommen ja noch ziemlich viele coole Kapitel, die hast Du jetzt zum Teil schon angedeutet. Zum Beispiel Simulation, KI, etc. Was erwartet uns denn sonst noch, zum Beispiel im Kapitel 23: „More awesome Robotics“?

Da gehe ich zum Einen auf neue Robotertypen ein, also Schwarmroboter, selbst-rekonfigurierende Roboter, modulare Roboter, humanoide Roboter, Soft Robotics, Bionik, etc. … jedes natürlich für sich selbst nochmal mindestens ein weiteres Buch wert. Damit möchte ich das Feld weiten, um zu zeigen: das gibt es auch noch alles und Du verstehst jetzt vielleicht schon 80% davon. Das mache ich ja auch in jedem Kapitel klar: das lernst Du, das hast Du jetzt verstanden, und das kannst Du damit schon schon anfangen. Auch wenn das konkrete Beispiel gerade vielleicht ein Last Mile Delivery Robot ist und Du eigentlich einen stationären Roboter programmieren willst, der Fritten zubereitet … das Grundwissen ist in beiden Anwendungen relevant und übertragbar. Das versuche ich zu zeigen mit dem Buch: das autonome Auto hat deutlich mehr mit einem humanoiden Roboter zu tun oder mit meinem klassischen Industrieroboter, als auf den ersten Blick ersichtlich.

Ich selbst habe mich ja in der Diplomarbeit mit selbstkonfigurierenden modularen Robotern beschäftigt, danach dann eine Promotion im Bereich Chirurgierobotik, dann ein Unternehmen im Bereich modulare Robotik für Industrieanwendungen gegründet, und bin jetzt in eine Unternehmen für Industrieroboter und mobile Roboter. Das geht ja nur, weil man nicht alles wieder von vorne lernen muss, sondern weil sich halt unglaublich viel übertragen lässt an Herangehensweisen, Grundlagen, Konzepten, bis hin zu Algorithmen und Implementierungen.

Das ist eine perfekte Überleitung zu meiner wahrscheinlich ungefähr letzten Frage: wie viel von diesem Buch ist robodev-Andreas und wie viel ist ABB-Andreas?

… und wieviel ist Sonderforschungsbereich125-Andreas?

Genau. Wie viel Einfluss haben Deine verschiedenen Stationen auf das Buch?

Das ist eine gute Frage, da habe ich noch nicht drüber nachgedacht. Ich glaube, die Einflüsse kommen vielmehr aus den Interaktionen mit den Menschen, mit denen ich zusammen gearbeite habe. Mein Anspruch ist, dass Leser:innen anschlussfähig sind und sich mit den verschiedenen Kolleg:innen der verschiedenen Disziplinen austauschen können. Also dass man eben nicht dasteht und man so spezialisiert auf das Thema ist, dass man kein Wort versteht von dem, worüber sich die Kolleg:innen beim Kaffee unterhalten. Dieses Grundwissen sicher zu stellen, da haben mich sicher alle bisherigen Robotikerfahrungen geprägt.

Ich finde, dass man mit relativ wenig Grundkenntnissen schon Brücken zwischen erstaunlich fortgeschrittenen Details der verschiedenen Robotikdisziplinen spannen kann. Das war sowohl im Startup also auch im großen Konzern wichtig, weil man immer die Spezialisierungen hat, aber gleichzeitig gemeinsam an einem System baut. Natürlich wollen wir unser System modular aufbauen, damit sich jeder Experte auf sein Teilsystem konzentrieren kann, aber es muss am Ende eben gut integrierbar sein. Was in der Robotik aus meiner Sicht eben gar nicht funktioniert – egal ob im kleinen oder großen Unternehmen – ist ein Modul über den Zaun zu werfen oder sich abzuschotten, jede Abteilung baut ihr Spezial-Softwaremodul und dann stecke ich die zusammen. Ich möchte ja am Ende ein Robotiksystem haben, das seine Aufgabe erfüllt. Dann ist es mir völlig egal, ob die Computervision ihr Ding jetzt richtig macht, die Bewegungsplanung ihr Ding richtig macht und das Basissystem seine Sache richtig gemacht habe, wenn die am Ende nicht zusammen funktionieren.

Ich bewundere immer wieder die Uni-Labore, die es schaffen, hochkomplexe Robotiksysteme auf Jahre aufzubauen und am leben zu halten. Ich beschäftige mich mit Gaits, Gait Learning, etc., möchte mich nur um die Algorithmik kümmern, muss aber trotzdem die Maschine bauen, muss mich dann trotzdem mit der Motorenregelung herumschlagen, muss mich trotzdem irgendwie um verteilte Softwaresysteme und eine halbwegs skalierbaren Infrastruktur kümmern, damit ich Daten aufnehmen und auswerten kann. Sobald ich mich von der Zeichnung oder Simulation weg bewege, fange ich mir extrem schnell ganz ganz viel von der gesamten Robotik ein. Deshalb muss man seinen Kontext verstehen, um seine Spezialität richtig ausüben zu können.

Es ist tatsächlich gut, wenn man sich gegenseitig versteht. Dann werden am Ende beide Seiten bessere Entscheidungen treffen, um einen real funktionierenden Roboter hinzubekommen. Und nur real funktionierende Roboter finde ich interessant, Roboter nur auf Papier oder nur in der Simulation finde ich langweilig.

Das sehe ich genauso. Ich will noch erklären, wie ich auf die vorige Frage gekommen bin. Du führst ja am Anfang eine Sicht auf Robotersysteme ein: jedes System besteht aus Aktuator, Acting, Sensor, Sensing, Planning, und Environment. Diese Sicht kombiniert mit Deinem Hinweis im Buch: Überlegt euch mal für einzelne Features Eurer Robotersysteme, ob ich die gut mit einem einfachen Hardwarebaustein lösen kann oder mit Software, oder einer Kombination … da klang für mich robodev durch. Wir werden aber wahrscheinlich in dem Buch auch viele Sichtweisen lesen, die Du Dir bei ABB angeeignet hast.

Da ist sicher viel dran. Vieles stammt auch aus der Zeit vor beidem, als ich mich viele Jahre an der Uni damit beschäftigt habe, wie man für Robotikforschung eine flexible Infrastruktur mit ROS aufbaut. Z.B. für Medizinrobotik, aber im Kontext eines sehr kreativen Pulks von zehn bis zwanzig Doktorand:innen – und dementsprechender Stabilität und Qualität der einzelnen Komponenenten.

Ich hatte ja beim ERF mal ein paar Workshops zum Thema Modularität in der Robotik. Dabei ist auch immer wieder die Frage aufgekommen, wie wichtig das einzelne Modul ist oder geht es am Ende nicht immer nur um das gesamte System. Meine Module, sozusagen meine Legosteine, baue ich natürlich am Ende nicht aus Selbstzweck, sondern um damit ein Haus, ein Schiff, etc. bauen zu können. Ich muss dementsprechend mein System in Einzelteile zerlegen können, darf es aber gleichzeitig nicht so weit zerlegen und die Einzelteile isoliert bearbeiten, dass ich den Kontext vergesse, in dem diese Bausteine arbeiten.

Jetzt könnte man meinen, Du redest gerade über die Konzernwelt.

*lacht* Ja, das ist sicher im Startup ein geringeres Problem als in eine großen Unternehmen. Im Startup machen die meisten alles, im großen Unternehmen habe ich spezialisierte Teams für alle Aspekte. Aber es kommt immer wieder glaube ich zu ähnlichen Konstellationen: ich möchte Spezialisierung – in Personen wie in der Implementierung – aber gleichzeitig darf ich den holistischen Gedanken, den Systemgedanken nicht aus den Augen verlieren. Im Startup hast du vielleicht manchmal zu wenig Spezialisierung, im großen Unternehmen manchmal so viel, dass es auch schon wieder nicht mehr gut tut. Es geht darum, dass man Schnittstellen einzieht, auch Information Hiding betreibt und auch mal Blackboxes baut, aber gleichzeitig nicht so undurchsichtig wird, dass es zu rigide wird. Das sind dann Architektur- und Designthemen: wie kann ich Software strukturieren, damit es unabhängige Komponenten sind, aber gleichzeitig sie nicht so weit in Komponenten zerlegen, dass die Integration wieder ein Problem für sich wird.

Noch eine letzte Frage: wann kann man das Buch kaufen?

Uuuh, schwierige Frage. Die späteren Kapitel werden etwas kürzer werden und wahrscheinlich auch etwas leichter zu schreiben als die Grundlagenkapitel zu Beginn. Ziel ist, dass es irgendwann im ersten Halbjahr 2023 fertig erscheint.

Ich habe es auf jeden Fall schon gekauft – sozusagen die Katze im Sack. Die ersten vier Kapitel konnte ich mir deswegen einfach runterladen und auf meinen Ebook-Reader schieben.

Genau, wenn man es jetzt kauft, gibt es auch einen Rabatt, zeitweise bis 30%. Und wenn die Kapitel aktualisiert werden oder neue Kapitel erscheinen, bekommt man dann die neuen Versionen. Das finde ich von Manning gut gemacht, auch alle early access Kapitel sind nämlich schon vom Editor sprachlich und inhaltlich redigiert.

Vielen Dank, Andreas, und viel Erfolg weiterhin mit dem Buch!

NotMyRobots – Interview mit Arne Maibaum

Posted on 5. April 20202. Januar 2021 by Arne

(this interview is available in English)

Schon seit längerem geplant und jetzt in Vorbereitung eines längeren Artikels endlich mal dazu gekommen: ein Interview mit Arne Maibaum von NotMyRobots über NotMyRobots.

HAL 9000, augenzwinkerndes Logo von NotMyRobots [Quelle]

Ich bin eigentlich nur mit einigen, wenigen Fragen ins Interview gegangen, rund um eine Kernfrage in Vorbereitung meines Artikels. Das Gespräch hat dann aber doch insgesamt fast eine Stunde gedauert und war extrem interessant. Es ging um den Terminator und Roboter, die uns die Jobs weg nehmen, aber auch um viele unerwartete Aspekte wie Sexismus, Rassismus und Epistemologie. Wie Arne Maibaum zum Ende des Gesprächs sagt: „Das kommt davon, wenn man mit SozialwissenschaftlerInnen redet.“ Hier also das ganze Interview:

Ich: Hallo, Arne! Für alle, die es noch nicht kennen: Was ist NotMyRobots überhaupt?

Arne Maibaum: Wir haben ja auch eine kleine Beschreibung in unserem Twitter-Profil und auf unserer Website. Vor allem auf Twitter haben wir gesehen, dass wahnsinnig viele ganz fürchterliche, unrealistische, aber vor allem auch tatsächlich falsche Visualisierungen für populärwissenschaftliche Robotik-Artikel benutzt werden. Allerdings teilweise auch in Teasern zu wissenschaftlichen Artikeln. Das sind unrealistische Bilder in Artikeln zu Robotern, aber auch – in letzter Zeit immer mehr – in Artikeln zu AI, die ja häufig auch mit Robotern bebildert werden.

‚Wir‘ sind dabei Philipp, Lisa, Laura und ich. Phillip und ich arbeiten bei einer Robotikgruppe an der TU Berlin. Laura und Lisa sind in München und arbeiten auch aus einer sozial- bzw. kultur-wissenschaftlichen Perspektive an dem Thema Robotik. Phillip und ich sind zwar beide Soziologen, sind aber in der Mensch-Roboter-Interaktion gelandet. Wir haben alle schon immer diese Bilder gesammelt. Das heißt, alle von uns hatten ohnehin schon so eine kleiner Galerie des Schreckens in der Hand. Lisa widmet sich außerdem in ihrer Arbeit dem Roboter in der Popkultur der Amerikanischen Geschichte. Das heißt, sie hat das auch in Ihrer Dissertation benutzen können.

Aus diesem Konglomerat haben wir uns dann überlegt, dass wir das in irgendeiner Weise publik kritisieren müssen. Als eine Maßnahme dafür haben wir den Twitter-Account @NotMyRobots gegründet, der versucht, auf Twitter aufzuzeigen, wenn diese Symbolbilder verwendet werden. Wenn uns jemand solche Bilder über den Hashtag #notmyrobot zuträgt, das machen mittlerweile ziemlich viele, re-tweeten und sammeln wir die. Je nach Bild versuchen wir auch mit eigenen kritischen Kommentaren aufzuzeigen, warum wir das nicht gut finden.

Wie sind die Leute auf Euch gekommen? Also wie ist das passiert, dass da jetzt mittlerweile so viele mithelfen?

Ich denke mal, viele Robotiker stört das ganz gewaltig. Ich glaube aber auch, gerade viele Leute, die aus den Humanwissenschaften kommen, sind da auch extrem sensibel für. Viele von denen haben solche Bilder auch vorher schon immer gesehen und den Kopf geschüttelt. Da ergibt sich dann eine gewisse Anzahl von Leuten, die dieses Problem auch sehen und denen unsere Initiative gefällt. Die nutzen dann unseren Hashtag oder taggen uns.

Das ist interessant. Mir fallen diese Bilder natürlich auch seit Jahren auf, mindestens seitdem ich selber in der Robotik bin. Ich rolle dann auch mit den Augen, habe aber nie wirklich reflektiert, dass das wirklich schädlich ist. Warum ist das denn so schlecht?

Also wovon wir immer ausgehen ist, dass Technik nicht aus dem leeren Raum kommt und Roboter nicht einfach so gebaut werden, wie es die Technik empfiehlt. Sondern, und das ist jetzt die soziologische Perspektive, Technik ist immer mensch-gemacht und immer sozial konstruiert. Als ein solches ist sie natürlich auch Aushandlungsprojekt davon, wie die Gesellschaft Robotik und Roboter sieht. In die Kommunikation darüber, wie so eine Technologie konstruiert wird, spielt natürlich Visualisierung eine große Rolle. Bei Pflegerobotern zum Beispiel sehen wir zwei Erwartungen, die stark mit Visualisierungen gekoppelt sind:

Als allererstes ist da immer der Terminator-Roboter, der aus irgendwelchen Gründen bei Robotik-Artikeln immer wieder auftaucht. Damit geht die Erwartung einher, dass zukünftige Roboter eiskalt sein werden und potentiell tödliche Maschinen sind, mit Metallgreifern, die nach uns greifen wollen. Das ist natürlich das Horrorszenario, das schürt Angst und führt dazu, dass Leute damit nichts mehr zu tun haben wollen.

Eines meiner liebsten Beispiele ist aus einem Projekt, in dem ich als Student tätig war. Wir hatten autonom fahrende Transportsysteme, die in Krankenhäusern zum Beispiel zum Transport von Wäschekisten eingesetzt wurden: der Casero-Roboter. Die sollten dann auf einer Bohrinsel eingesetzt werden, also bei Männern, die über viele Kilometer explosionsfähiges Material anbohren. Die haben sich aber strikt geweigert, einen solchen Roboter auf ihre Bohrinsel zu nehmen, weil sie Angst davor hatten, dass der sie alle umbringt. Dieses Bild kommt natürlich durchaus aus der Science-Fiction und dieser Angst, einer solchen Maschine ausgeliefert zu sein. Und wenn wir dann Artikel sehen, die so ein Bild unter ‚Roboter sollen uns helfen‘ setzen, ist das natürlich inhärent problematisch dafür, wie die Technik wahrgenommen wird. Das hat natürlich dann auch Einfluss auf Fördergelder usw.

DRC Wettkampftage

Posted on 17. Juni 201527. Januar 2020 by Jörn

(this article is also available in English)

Eine Woche ist es her, seit der DARPA Robotics Challenge (DRC). Noch am Abend des zweiten Wettkampftages haben wir Walkman wieder verpackt und auf den Heimweg geschickt. Anschließend hatten wir Zeit, Schlaf nachzuholen, ein wenig Californien zu erkunden und die DRC-Woche Revue passieren zu lassen.

In der Tat, es ist nicht bei den zwei gestürzten Robotern während des Testlaufs geblieben. Am ersten Wettkampftag sind nahezu alle Zweibeiner früher oder später gestürzt. Jemand hat sich die Mühe gemacht einige der Stürze in einem Video zusammenzufassen:

Stürzende Roboter, via IEEE Spectrum

Etwa ab Sekunde 00:19 ist Walkman zu sehen. Die Aufnahme zeigt unseren ersten Lauf in der zweiten Gruppe am Freitag Morgen. Innerhalb von acht Minuten und zwölf Sekunden hatte Walkman den Polaris Ranger von der Startlinie durch den Parcours zu Eingangstür der simulierten Industrieanlage gefahren und damit den ersten Punkt geholt. Wie im nachfolgenden Video ab Sekunde 50 zu sehen, wurde Walkman dabei kräftig angefeuert.

Walkman’s erster Lauf, angefeuert von seinem Team

Zu diesem Zeitpunkt hatte Walkman zunächst die beiden Atlas Teams, die offenbar technische Schwierigkeiten hatten, weit hinter sich gelassen. Doch dann standen plötzlich für mehrere Minuten auf allen vier Bahnen sämtliche Roboter still. Offenbar gab es bei allen Teams Probleme mit der Kommunikation zwischen den Piloten und dem Roboter. Die Verzögerungszeit auf allen Bahnen wurde daher an die Wettkampfzeit angehängt. Allerdings zehrten die Roboter während dieser Zeitspanne weiterhin von ihren Batterien…

Als es weiterging, öffnete Walkman problemlos die Tür und setzte an, die diese zu durchschreiten. Wir hatten dies in unserer Garage mehrfach geübt. Aufgrund der sehr breiten Schultern des Roboters (ca. 80 cm), ist das Durchschreiten der Tür nicht ganz einfach. Die Strategie bestand also in einer Drehung des Roboters auf der Stelle um 90°. Anschließend passierte Walkman die Tür mit Seitwärtsschritten. Leider brach Walkman unmittelbar nach dem Öffnen der Tür plötzlich einfach zusammen (siehe Video). Glücklicher Weise hat sich Walkman bei diesem Zusammenbruch quasi abgerollt, sodass nichts passiert ist. In der Tat ist von diesem Sturz kaum ein Kratzer zu sehen.

Die Ursache für den Zusammenbruch ist nicht klar. Die Batteriekapazität lag noch bei 80 %. Faszinierender Weise stürzte exakt zur gleichen Zeit auf der Roboter auf der Nachbarbahn. Bei einem Sturz schaltet das Team den Roboter per Funk über einen sogenannten E-Stop Schalter aus, um weitere Schäden zu vermeiden und eine sichere Annäherung an den Roboter zu ermöglichen. Da ein Übersprechen zwischen den E-Stops beider Teams nicht ausgeschlossen werden konnte, gewährte uns die Wettkampfleitung freundlicher Weise eine Wiederholung des Laufs ab dem Zeitpunkt der Kommunikationspanne. Das bedeutet, wir durften am Abend des gleichen Tages noch einen Versuch unternehmen. Der Versuch startete an der Stelle vor der Tür mit der uns am Morgen an dieser Stelle noch verbliebenen Zeit. Dieses mal gelang es die Tür zu durchschreiten. Leider geriet Walkman unmittelbar auf der anderen Seite der Tür ins Straucheln, fiel mit lautem Scheppern auf die Seite und drehte sich anschließend auf die Frontseite. Er kam auf den Knien und dem Schutzkäfig am Kopf jenseits der Türlinie zum liegen. Damit hatten wir dann immerhin unseren zweiten Punkt geholt.

Die am Roboter angebrachten Polster haben auch bei diesem Sturz schlimmeres Verhindert. Eine Schraube zur Befestigung des Ellenbogen Polsters war deutlich verbogen. Diese Schraube hatte beim Aufprall ein Loch im Asphalt der Wettkampfbahn hinterlassen. Darüber hinaus war dem Roboter scheinbar nichts ernstes passiert. Dennoch wurden einige Rekalibrationen erforderlich, die wir dann bis in die Nacht hinein durchführen mussten.

Am nächsten Morgen ging es dann nach einem kurzen Testlauf in der Garage zum zweiten Wettkampflauf. Beim Fahren des Polaris Rangers konnte Walkman die Zeit vom Vortag nahezu halbieren. Vor der Tür begannen dann leider wieder die Schwierigkeiten. Zuerst machte sich ein Rattern während der Bewegung des linken Ellenbogengelenks bemerkbar. Während des Drehens auf der Stelle vor der Tür berührte Walkman den Türrahmen und geriet zunächst gefährlich ins Wanken. Wenige Minuten später mussten wir letztendlich Walkmans letzten Sturz des Wettkampfs mitansehen… Dieses Mal hat sich Walkman wohl das Fußgelenk verknackst…

Schade ist, dass wir nach so kurzer Zeit und einem so guten Start in den zweiten Wettkampftag dann doch so früh abbrechen mussten. Dennoch herrscht Einigkeit im Team und auch so manch anderer bekannter Robotiker in Fairplex hat uns das bestätigt: angesichts der kurzen Entwicklungszeit haben wir einen für den Wettkampf ernstzunehmenden Roboter präsentiert, eine gute Leistung gezeigt und sind damit doch sehr weit gekommen. Wir haben zwei Punkte geholt und haben so mit dem 17. Platz immerhin sechs weitere Teams hinter uns gelassen. Das Technologiekonzept scheint also prinzipiell zu stimmen, am Reifegrad der Technologie dürfen wir noch arbeiten. Da der Roboter von der ersten Schraube bis zum letzten Softwarebit selbst entwickelt worden ist, können wir alle gelernten Lektionen auch unmittelbar umsetzten.

Als Fazit war die Woche für jeden vons eine großartige Erfahrung und anders als bei vielen der anderen Teams stellt die Teilnahme an dem Wettkampf nicht das Projektfinale dar. Für das Team Walkman war dies nur ein früher Meilenstein nach einem Drittel der Projektzeit.

Hier noch ein paar Eindrücke von unseren Vorbereitungen in der Garage:

Team Walkman bei den Vorbereitungen

sowie den Wettkampftagen:

Team Walkman beim Wettkampf

Und da es offensichtlich noch Bedarf zur Nachbesserung in Sachen Balance gibt, begann Team Walkman sogleich mit einem passenden Aufbauseminar… am Strand von San Diego

/images/blog/surfing.jpg — Nachhilfe in Sachen Balance am Strand von San Diego

Das war’s. Das Team Walkman dankt allen, die die Daumen gedrückt und uns angefeuert haben!

/images/blog/007087e517b.jpg — via newscientist.com

Ein paar Eindrücke von den DRC Finals

Posted on 4. Juni 201527. Januar 2020 by Jörn

So, nach nunmehr drei Tagen am Austragungsort der DARPA Robotics Challenge in Pomona mit viel zu viel Fastfood und wenig Schlaf nehme ich mir die Zeit ein paar Eindrücke über botzeit zu teilen.

Zum Hintergrund des Walkman Projekts

Der Roboter ist 1.85 groß und wiegt etwa 120 kg. Der gesamte Roboter wurde in nicht mehr als 10 Monaten entwickelt, gefertigt und erstmalig in Betrieb genommen. Als ich im Januar in Genua ankam, steckten die extern gefertigten Teile noch in der Zollabfertigung fest…

Als schließlich alle Teile im Institut angekommen waren, wurde der Roboter binnen zwei Wochen zusammengebaut und in Betrieb genommen. Zu diesem Zeitpunkt blieb uns für die Fertigstellung der Qualifikationsvideos für die DRC Finals dann noch ein knapper Monat Zeit.

Auch nach der Qualifikation blieb nicht viel Zeit zum Durchatmen. Während der Qualifikationsexperimente hatten sich ein paar Tücken sowohl in der Hardware, wie auch in der Software offenbart. Alles andere wäre vermutlich auch sehr überraschend gewesen…

Am vergangenen Samstag sind wir schließlich hier in Pomona nahe Los Angeles angekommen und bereiten uns seither auf den Wettkampf vor.

/images/blog/P1100270.JPG — Ein Blick in die Garage von Team Walkman

Eine Art Tagebuch

Sonntag: Registrierung, Begrüßung und Instruktionen

Der Sonntag Vormittag dient im Wesentlichen der Orientierung hier vor Ort. Es ist das einzige Zeitfenster, in dem wir einen kurzen Blick auf die Gegend um Los Angeles erhaschen und einige wenige Sehenswürdigkeiten besuchen können. Nach der Registrierung am Nachmittag findet dann die offizielle Begrüßung und Auftaktveranstaltung statt. Ein kurzer Überblick über die Daten und Fakten zum Event: es sind etwa 600 Team-Mitglieder angereist, betreut wird die Veranstaltung von 300 freiwilligen DARPA-Mitarbeitern. Zahlreiche internationale Pressevertreter haben sich angekündigt. Darunter unter anderem: ARD, BBC News, Daily Planet, IEEE Spectrum, MIT Technology Review, NBC News, Playboy.com, Spiegel Online, TEDx, ZDF.

Montag: der Einzug in die Team Garage

Wir bekommen ab 08:00 Uhr Zugang zu unserer Team Garage. Das ist der Ort, wo wir unsere Rechner, unsere Werkstatt, den Roboter und eine kleine Trainingsumgebung aufbauen.

Wir verbringen den ganzen Tag weitestgehend mit dem Einzug, dem Aufbau der Arbeitsplätze und ausgiebigen Tests des Roboters. Die beste Nachricht des Tages:
Walkman ist gesund und munter angekommen. Der Roboter funktioniert einwandfrei. Auch das restliche Equipment hat den Transport unbeschadet überstanden.

Für die meisten endet dieser erste Tag etwa um Mitternacht mit dem Rückweg zum Hotel.

Dienstag: Modultest

Um 09:00 Uhr geht es für mich weiter. An diesem Tag steht Lokomotion im Fordergrund. Wir sind unsicher, wie Walkman mit dem unebenen Wettkampfgelände und vorhandenen Steigungen zurecht kommen wird. Entsprechend werden nach dem Transport einige Modellparameter überprüft und rekalibriert sowie Reglereinstellungen verfeinert.

Am Nachmittag können wir erstmalig den Roboter in eines der von der DARPA für den Wettkampf zur Verfügung gestellten Autos setzen und unsere Fahrzeugmodifikationen für diese Aufgabe testen.

/images/blog/IMG_20150602_171306.jpg — Walkman im Auto

Anschließend haben sowohl Roboter als auchTeam einen offiziellen Fototermin.

http://www.theroboticschallenge.org/sites/default/files/20150602_SUN_WALK-MAN_bleachers_web.jpg — Team Walkman (theroboticschallenge.org)

Am Abend geht es weiter mit Lokomotion. Eine Holzplatte und ein paar Balken dienen dienen als Testplattform. Wir testen das Stehen, Laufen und Drehen auf der Stelle auf der hölzernen Ebene mit bis zu 8° Grad Neigung. Der Roboter meistert die Tests und wir beenden unsere Arbeit sehr zufrieden um 03:00 Uhr am Morgen. Wir werden von den Jungs abgelöst, die nun das Autofahren testen werden. Die Kollegen vom IHMC haben uns freundlicherweise zu diesem Zweck bis 11:00 Uhr ihren Polaris Ranger überlassen. Mille mille grazie dafür!

Mittwoch: Manipulation Day Öffnen und Durchschreiten der Tür, Ventil-Aufgabe

Heute steht Manipulation auf der Tagesordnung. Im speziellen das Öffnen und Durchschreiten einer Tür, sowie das Drehen eines Industrieventils. Bei den Arbeiten bereitet uns das linke Kniegelenk Probleme. Einer der Magnetencoder versagt den Dienst. Am Morgen war bereits ein Fehler in der Leistungselektronik aufgetreten. Mir gibt der Ausfall die Zeit, diese Zeilen zu schreiben, während unsere Techniker daran arbeiten, nicht nur das defekte Teil zu ersetzen, sondern auch die Ursache für den Ausfall festzustellen…

Die Atmosphäre in der Garage:

Insgesamt ist die Atmosphäre sehr angenehm. Insbesondere das Miteinander mit den übrigen Teams empfinde ich als sehr angenehm. Die Halle hier ist voll von Menschen, die mit großer Begeisterung an ihren Robotern arbeiten. Bis auf ein einziges Team hängt in jeder Garage ein grünes Schild, dass die Aufnahme von Fotos und Videos ausdrücklich erlaubt. Die Wissenschaftler und Techniker laufen von Garage zu Garage und informieren sich wissbegierig über die Konstruktion, Hard- und Software der anderen Teams. Die eigenen Erfahrungen werden meist gerne geteilt und wie es aussieht, knüpfen manchmal nicht nur Menschen, sondern auch Roboter neue Kontakte:

/images/blog/IMG_20150602_185312.jpg — Atlas und Walkman verstehen sich.

Insgesamt gehen alle Teams sehr hilfsbereit miteinander um. Man leiht sich gegenseitig Ersatzteile und Werkzeug. Gegen Abend zeigt sich dann, welche Teams schon lange dabei sind und entsprechend eine ausgereifte Hard- und Software vorweisen können. Diese Teams verlassen ihre Garage am Abend und genießen ein wenig Freizeit. Andere Teams, die noch jung im Rennen sind und meist ihre Roboter vollständig selbst gebaut haben, bleiben bis in die Nacht hinein. Viele arbeiten im Schichtbetrieb – so wie wir.

Turniamo a’lavoro!

Alles Fake – Ein trauriger Monat für die Robotik

Posted on 17. März 201426. Januar 2020 by Jörn

In der vergangenen Woche fand das European Robotics Forum statt. Dabei handelt es sich um eine Networking-Veranstaltung, bei denen aktuelle und zukünftige Trends in der europäischen Forschungslandschaft diskutiert werden. Einem Blick ins Programm der Veranstaltung verrät bereits einen guten Überblick, was die deutsche Robotik Gemeinde umtreibt. Ein wesentlicher Aspekt ist es, die Verknüpfung zwischen Wahrnehmung und Handlung in Robotern zu verbessern. Es geht darum, einen Roboter in die Lage zu versetzen, komplexe Bewegungen und Manipulationsaufgaben, die einen hohen Grad an Geschick erfordern, selbstständig oder durch Demonstration zu erlernen und zu adaptieren.

In meinen Augen ist das ein hochspannendes Thema, in dessen Kontext ich vor etwas längerer Zeit bereits auf nachfolgende beeindruckende Videos aufmerksam geworden bin:

Das Video zeigt, wie ein Mensch einem Roboter das Tischtennis Spielen demonstriert. Anschließend erprobt und verbessert der Roboter selbstständig seine Fähigkeiten. Schließlich, spielt der Roboter Tischtennis mit einem Menschen.

Der Tischtennis Demonstrator ist meiner Ansicht nach sehr gut geeignet um Forschungsergebnisse dieser Art darzustellen. Es gibt viele Freiheitsgrade. Die Dynamik der Aufgabe ist hoch und fordernd. Eine Tischtennisplatte hat vertretbare Abmessungen, sodass sich der Demonstrator in einem Labor gut realisieren lässt. Das Spiel mit einem echten Menschen ist nicht planbar. Es kommt zu unvorhersehbaren Ballwechseln. Daher demonstriert das Experiment prinzipell sehr gut die Generalisierungsfähigkeit aber auch die Grenzen entwickelter Algorithmen.

Hohe Erwartungen

Im Februar kündigte der Roboterhersteller KUKA mit nachfolgendem Video ein Tischtennis Duell zwischen einem KUKA Roboter und dem Tischtennisprofi Timo Boll an.

Vor dem Hintergrund der zuvor dargestellten Forschungsarbeiten war ich natürlich freudig gespannt auf das Event. Und damit war ich nicht allein. Aus den Kommentaren:

„Hmm…ein Fake wird es nicht sein, glaube aber nicht das der Bot den Hauch einer Chance gegen Boll hat, sobald der mit Topspin angreift. […]“
„Fantastic. Cant wait to see this in action…“
„Well…never thought I’d be so hyped for a ping pong match!“

Auf IEEE Spectrum News schreibt Evan Ackermann: „Wow, Kuka wouldn’t have set this whole thing up unless it was actually going to be a good match! Maybe we’ll see some amazing feats of high speed robot arms, vision systems, and motion tracking!“

Ernüchterung

Die geschürte Erwartung bestand in einem tatsächlichen „Duell“ im Sinne eines echten Spiels zwischen Mensch und Roboter. In meinem durchaus robotisch geprägten Umfeld wurden rege Diskussionen geführt, wie das hypothetische Match ausgehen würde. Ebenso wurden Vermutungen über technische Realisierungen diskutiert. Die oben angesprochenen Forschungsergebnisse haben die prinzipielle Machbarkeit ja bereits vor einiger Zeit demonstriert. Bis hier her: schöne Arbeit seitens des Marketings. Das mit Spannung erwartete Duell war in aller Munde. Am 10.03. erschien dann das ernüchternde Video:

Für sich genommen ein nettes Werbe-Video. Aber nicht das angekündigte Spiel zwischen Mensch und Maschine. Nur ein mit Spezialeffekten voll gepumpter Trickfilm. Die Story: erst dominiert der Roboter, dann reißt Timo das Ergebnis noch einmal mit spektakulären Spielzügen rum. Die wohl beabsichtigte Botschaft des Roboterherstellers wird am Ende noch einmal explizit formuliert:

„Not the best in table tennis. But probably the best in robotics.“

Die in meinem Umfeld gespiegelte Botschaft fiel eher anders aus. Sie war mehr von Enttäuschung geprägt. Herauszuhören war zusammenfassend: „KUKA hat ein Duell versprochen, aber nur einen Trickfilm geliefert.“ Auch das spiegelt sich in den sozialen Netzwerken wieder:

„Agreed, great idea for marketing, but poorly developed“
„I was so excited to see a duel between a robot and a world champion in table tennis. Expectations were like Kasparov vs Deep Blue, right? Turns out it’s just a very well shot but fake commercial.“

Evan Ackermann trifft auf IEEE Spectrum News den Nagel auf den Kopf: „But the encounter wasn’t the „robot vs. human duel“ we were promised. What Kuka gave us instead is an overproduced, highly edited commercial that, in our view, will puzzle (rather than amaze) those of us who follow robotics technology closely.“

In meinen Augen eine verpasste Chance, Menschen zu begeistern und durch technologische Leistung zu überzeugen.

Zu allem Überfluss erschien diese Woche dann ein weiteres Fake-Video (dieses Mal nicht von KUKA) von einem Tischtennisroboter, der angeblich in einer heimischen Garage realisiert wurde:

In der Beschreibung zum Video steht: „Nach ca. 2 Jahren Entwicklungsarbeit habe ich mit meinem Freund Michael nun unseren selbst gebauten Tischtennis Roboter soweit fertig gestellt, dass man mit ihm schon ordentliche Ballwechsel spielen kann.“ Leider ist das Video offensichtlich montiert, wie einige aufmerksame Kommentatoren anmerken:

„It is fake, look at 1:09! You can see that the camera in the upper right of the garage door is in front of the table tennis racket because it was added to the footage later.“
„Had me fooled until the close up at 2:20. Those movements don’t seem real, and it seems weird that every movement has the same sound even tough the speeds are different and so are the moves.“

Vieles davon finden wir auf Mikrokontroller.net wieder:

https://www.mikrocontroller.net/attachment/210215/busted.jpg — camera in the upper right of the garage door is in front of the table tennis racket

Als Trickfilm-Projekt ist das Video sicherlich überzeugend gut gemacht. Das belegen auch die zum Teil auch emotional aufgeladenen Diskussionen zur Echtheit des dargestellten Experiments…

Zwei Aspekte haben mich schließlich zur Wahl des Titels für diesen Blogeintrag bewegt:

Enttäuschung

Beide Videos, das von KUKA und das Garagen-Video, haben eine unglaublich rasante Verbreitung in den sozialen Netzwerken erfahren. Für den geneigten Robotik-Laien, so befürchte ich, mag allerdings durch beide Videos ein falscher Eindruck von dem entstehen, was Roboter heute leisten können. Die damit verbundenen komplexen Problemstellungen hat Arne in einem früheren Blogeintrag bereits ausführlich thematisiert.

Darüber hinaus erscheint Tischtennis als Demonstrator für die eingangs beschriebenen Forschungsprojekte erst einmal verbraucht. Bei jeder zukünftigen Demonstration des Experiments und jedem neuen Video dazu schwingt zunächst einmal unterschwellig mit: „Schau mal, da hat wieder einer so getan, als könnte er mit einem Roboter Tischtennis spielen“. Vielleicht fällt ja jemandem ein alternativer, hinsichtlich Komplexität, Anzahl der Freiheitsgrade und Realisierbarkeit im Labormaßstab vergleichbarer alternativer Demonstrator ein?

Aus robotischer Sicht finde ich die Ereignisse in Summe also sehr schade und komme zu dem Schluss: dies war ein trauriger Monat für die Robotik.

Elastische Roboterarmkörper: Fluch oder Segen? (Teil 2)

Posted on 29. August 20132. Januar 2021 by Jörn

(this article is available in English)

Grundsätzlich wird die strukturelle Elastizität in Roboter-Armkörpern bislang nachteilig gesehen. Sie verlängert Ausregelzeiten und verschlechtert die Positioniergenauigkeit. Allerdings wurde die Realisierbarkeit einer schnellen und genauen Positionierung eines gliedelastichen Roboterarms anhand von Ballfang-Experimenten exemplarisch gezeigt ¹. Darüber hinaus kann die intrinsische Nachgiebigkeit jedoch auch vorteilhaft dazu ausgenutzt werden, die tatsächlich effektive Nachgiebigkeit des gesamten Arms aktiv zu beeinflussen. Wie im ersten Teil zu diesem Thema bereits dargestellt, setzt dies eine Kompensation der unerwünschten Effekte durch eine geeignete unterlagerte Regelung voraus. Dabei wurde die Wahrscheinlichkeit, auch zerbrechliche Objekte im Falle einer unvorhergesehenen Kollision zu beschädigen, deutlich gemindert.

Das obenstehende Video geht einen Schritt weiter. Beabsichtigte oder auch unbeabsichtigte Kontakte werden explizit auf Basis eines Modells der gedämpften Armdynamik detektiert und ermöglichen eine entsprechende Reaktion. Das Video stellt das gliedelastische Experimentalsystem TUDOR vor und zeigt insgesamt sieben Experimente zur Schwingungsdämpfung, zur Detektion genau wiederholbarer stumpfer wie auch scharfer Einschläge auf Luftballons sowie zerbrechlicher Christbaumkugeln, weniger exakt wiederholbarer Einschläge auf einen menschlichen Arm und schließlich zur physischen Interaktion mit dem Roboter.

Die Paare von Dehnungs-Messstreifen, die in der Nähe der Gelenke auf jedem nachgiebigen Arm appliziert sind, fungieren als lastseitige Drehmomentsensoren. Unter der Voraussetzung einer hinreichenden Schwingungsdämpfung kann die verbliebene Dynamik des Arms in Analogie zu konventionellen starren Roboterarmen modelliert werden. Diese Vorgehensweise ermöglicht die unmittelbare Anwendung von Verfahren zur Kollisionsdetektion und -reaktion, wie sie zuvor bei gelenkelastischen sowie starren Roboterarmen vorgestellt worden sind ² .

Die dargestellen Ergebnisse verdeutlichen, dass die strukturelle Elastizität in Roboter-Armkörpern nicht zwingend als nachteilig gesehen werden muss. Vielmehr können sich mit Hilfe entsprechender Regelungsansätze aus der Ausnutzung dieser Eigenschaften neue Möglichkeiten ergeben.

Mensch und Roboter Hand in Hand

Posted on 6. August 201326. Januar 2020 by Arne

Wer hat sich nicht schon einmal einen Roboter gewünscht, der im Haushalt hilft? Der zum Beispiel schon einmal den Kuchenteig anrührt, knetet und ausrollt, während man selbst die Glasur vorbereitet, bzw. einem das lästige Gemüseschnibbeln beim Kochen abnimmt. Oder einen kleinen Roboterassistenten, der einem bei heimischen Bastelarbeiten die richtigen Werkzeuge anreicht, wie man es aus OP-Sälen in Krankenhäusern kennt: „Roboter, Schraubenzieher!“ – „Schraubenzieher, und weiter?“ – „Schraubenzieher, bitte!“

/images/blog/flexirob-hand-in-hand.jpg — Die Vision: Roboter und Mensch arbeiten zusammen [johanneswienke.de]

Zumindest in Industrieszenarien ist das keine allzu weit entfernte Zukunftsvision mehr. Flexibel anpassbare Roboter, die autonom oder Hand in Hand mit dem Menschen in einer Werkstatt oder Produktionsstrasse arbeiten und diesen bei Fertigungsaufgaben unterstützen, sind schon seit geraumer Zeit ein strategisches Anliegen europäischer Wissenschaftler und der Robotikindustrie. So führt bereits die im Jahr 2009 ausgerufene europäische Strategic Research Agenda diese beiden Szenarien, den „Robotic Worker“ und den „Robotic Co-Worker“, als Kernanwendungsszenarien zukünftiger Industrierobotik mit auf. Dabei geht es nicht um Großserien-Vollautomatisierung wie man sie z. B. aus der Automobilindustrie kennt, in der Roboter an Roboter aufgereiht in Käfigen und – aus Sicherheitsgründen – abgeschottet vom Menschen monatelang exakt die gleiche Aufgabe ausführen:

Vollautmatisierte Montage von Automobilen bei KIA

Es geht vielmehr um die Unterstützung von Mitarbeitern in kleinen und mittelständischen Unternehmen, deren Auftragslage sich relativ schnell ändern kann. Denkbar ist die Fertigung von Prototypen, von denen häufig nur geringe, einstellige Stückzahlen gefertigt werden. In diesem Kontext sind zur Zeit Handarbeitsplätze immer noch die Regel, d. h. Fachkräfte montieren und bearbeiten Bauteile bzw. bestücken und entladen Maschinen manuell. Häufig sind diese Arbeiten verbunden mit anstrengender körperlicher Arbeit.

Eine Vollautomatisierung im klassischen Sinne, also mit Robotern, die genau auf diesen einen Zweck ausgelegt sind und in aller Regel nicht oder nur sehr aufwendig an neue Fertigungsaufgaben angepasst werden können, macht hier allein schon aus ökonomischen Gründen keinen Sinn. Der durch die Einsparung einer Fachkraft gewonnene finanzielle Vorteil wird sofort wieder zunichte gemacht durch den notwendigen, häufigen und kostenintensiven Einsatz von Experten, die den Roboter bei jeder Änderung im Produktionsablauf wieder an seine neue Aufgabe anpassen und umprogrammieren müssen. Zusätzlich sind viele Teilaufgaben in solchen Fertigungsprozessen sehr komplex und wenn überhaupt nur mit enorm hohem technischen Aufwand automatisch zu bewerkstelligen, wie z. B. der berühmte Griff in die Kiste.

Die Idee ist vielmehr, den Menschen zu unterstützen, indem man ihm diejenigen Arbeiten überlässt, die er z. B. auf Grund besserer visueller Wahrnehmung und guten Fingerfertigkeiten kompetenter und schneller durchführen kann als jede Maschine, ihn aber durch den Roboterassistenten von körperlich belastenden Arbeiten zu befreien … der Roboter als dritte Hand. Damit jedoch beide, Roboter und Mensch, an einem Arbeitsplatz gemeinsam sinnvoll zusammenarbeiten können, sind einige Herausforderungen zu bewältigen. Ein bisschen Buzzword-Bingo:

Flexibilität: Um sich den ständig wechselnden Aufgaben anpassen zu können und in beliebigen (engen, eingeschränkten) Arbeitsräumen mit dem Menschen zusammen zu arbeiten, ist im Vergleich zu herkömmlichen Industrierobotern zusätzliche Flexibilität nötig. Diese erhält man z. B. durch zusätzliche Bewegungsachsen: übliche Industrieroboter verfügen über bis zu sechs Achsen, ab sieben Achsen erhält man durch Redundanz zusätzliche Flexibilität.

Interaktion: Um teures und zeitaufwendiges Umprogrammieren der Roboter durch Experten zu umgehen, muss der Mitarbeiter vor Ort in der Lage sein, durch einfache, direkte Interaktion den Roboter an seine neuen Aufgaben und Arbeitsbedingungen anzupassen und ihn den eigenen Bedürfnissen entsprechend zu programmieren.

Sicherheit: Die direkte physische Kooperation zwischen Mensch und Maschine erfordert andere Sicherheitsmechanismen als Zäune und strikte Arbeitsraumtrennung, um die Sicherheit für den Menschen dennoch zu gewährleisten.

Technisch gesehen scheinen obige Herausforderungen so gut wie gelöst. Der vom Deutschen Luft- und Raumfahrtszentrum und KUKA gemeinsam entwickelten Leichtbauroboter IV (LBR IV), dessen serienreifer Nachfolger KUKA LBR iiwa auf der diesjährigen Hannover Messe erstmals vorgestellt wurde, ist ein Beispiel. Das geringe Gewicht, Kraftsensoren zur Kollisionserkennung und eine sehr schnelle Regelung sind gute Voraussetzungen für eine sichere Interaktion mit dem Menschen. Außerdem ist der LBR mit seinen sieben Bewegungsachsen redundant, bietet also genügend Flexibilität, um um Hindernisse herumzugreifen oder Aufgaben auf mehr als nur eine Art zu erledigen.

Dass trotzdem nun nicht jeder sofort einem solchen Roboter Aufgaben beibringen kann, sieht man im folgenden Video, welches im Verlaufe einer umfangreichen Feldstudie ¹ mit Mitarbeitern der Firma Harting entstand:

Auch moderne Roboter sind nicht leicht zu bedienen.

Die Aufgabe für die Probanden bestand im Prinzip aus einer Art Heißer-Draht-Spiel:
Der vorn am Roboter montierte Greifer sollte möglichst genau an dem Styropor-Parcours entlang geführt werden, währenddessen natürlich jede Kollision sowohl vorne am Greifer als auch am Rest des Roboterkörpers mit den Umgebungsobjekten vermieden werden sollte. Der Hintergrund: Genau durch diese Art des Führens (englisch: Kinesthetic Teaching) können dem Roboter Aufgaben beigebracht werden. Die in der Interaktion entstandenen Bewegungen werden aufgezeichnet und können auf Befehl schneller, langsamer oder leicht verändert wieder abgespielt werden. Der Fachbegriff hierfür lautet Teach-In und bezeichnet das aktuell übliche Verfahren, um Roboter „anzulernen“.

Wie man in dem Video sieht, geht das zum Teil gehörig schief! Die Versuchspersonen scheinen (trotz einer vorherigen Eingewöhungsphase mit dem Roboter) überfordert von der Aufgabe, dem LBR den Parcours kollisionsfrei beizubringen. Das liegt nicht an der Komplexität der Aufgabe: Eine einfache vorgegebene dreidimensionale Bewegung wie die des Parcours aus der Studie nachzufahren, ist für uns Menschen typischerweise zu bewältigen und wie wir später sehen werden auch in Verbindung mit einem Roboter leicht möglich. Der Grund ist die durch jahrelange Ingenieurskunst geschaffene, komplizierte Technik des LBR, die technische Vorteile, aber auch erhöhte Komplexität mit sich bringt. Denn hinter dem einen „I“ des Wortes „Interaktion“ verstecken sich noch zwei weitere: intuitiv und intelligent. Einem Roboterarm mit sieben Gelenken eine bestimmte dreidimensionale Bewegung beizubringen und dabei gleichzeitig darauf achten zu müssen, dass er mit seinen sieben Achsen nicht mit Hindernissen im Arbeitsraum kollidiert, ist nicht intuitiv. Und eine vorgemachte Bewegung abspeichern und wieder abspielen zu können, ist nicht sonderlich intelligent.

Dieses Beispiel zeigt, dass in der Praxis mehr notwendig ist als nur die technischen Möglichkeiten zu schaffen. Der Schlüssel, davon sind wir überzeugt, liegt in einer systematischen Integration von Hochtechnologie, maschinellem Lernen und einfacher Interaktion. Um ein solches Robotiksystem für den Arbeiter vor Ort bedienbar zu machen, muss die eigentliche technologische Komplexität im besten Fall hinter intuitiven Benutzerschnittstellen und schrittweiser Interaktion versteckt werden. Am Forschungsinstitut für Kognition und Robotik (CoR-Lab) der Universität Bielefeld beschäftigen wir uns seit Jahren genau damit. Das Robotersystem, das oben im Video zu sehen war und auf einem KUKA LBR IV aufbaut, ist unsere Forschungsplattform FlexIRob: ein Beispielszenario, bei dem wir diese Art von Integration untersuchen. Um die obige Aufgabe zu erleichtern, haben wir einen Ansatz entwickelt, mit dem jeder einen solchen Roboter an neue Umgebungen und Aufgaben anpassen kann. Die Idee ist im Prinzip einfach und beruht darauf, die komplexe Aufgabe in zwei Teilschritte zu unterteilen. Dass das funktioniert, ist im folgenden Video zu sehen:

Erleichterung der Interaktion durch Aufteilung in explizite Konfigurations- und assistierte Programmierphase (ab ca 1:15)

Der erste Teilschritt der Aufgabe heißt Konfigurationsphase und ist unabhängig von der Aufgabe, die der Roboterarm später ausführen soll. In dieser Phase bringt der Nutzer bzw. der Mitarbeiter dem Roboter seine neue Umgebung bei, d. h. eventuelle dauerhafte Hindernisse, welche in seinem Arbeitsbereich platziert sind, wie z. B. herumliegende Objekte, Säulen oder Regale. Als Mensch hat er dabei ein intuitives Verständnis der Szenerie: Er sieht die Hindernisse, er weiß, dass und wie man um sie herumgreifen muss und ist deswegen instinktiv in der Lage, den LBR dabei in ausgesuchte Regionen zu führen und dort mit ihm zusammen einige Beispielbewegungen durchzuführen, ohne mit den Hindernissen zu kollidieren. Von diesen Beispielbewegungen kann nun der Roboterarm lernen, wie er sich in seinem Arbeitsbereich zu bewegen und wie er die Hindernisse im Zweifel zu umgreifen hat. Die Methoden zum Lernen, die dabei verwendet werden, gehen über simples Aufnehmen und Reproduzieren hinaus. Mit Hilfe von künstlichen neuronalen Netzen ist das System nämlich nicht nur in der Lage sich innerhalb der trainierten Bereiche zu bewegen, sondern auch zwischen diesen hin- und her zu manövrieren und kollisionsfreie Bewegungen für den Arm zu wählen. Diese Eigenschaft von Lernverfahren nennt man Generalisierungsfähigkeit und beschreibt die Fähigkeit, von wenigen Beispieldaten ein generelles Verhalten zu erlernen und dieses auf unbekannte Daten zu übertragen. In unserem Fall sind die Beispieldaten die Trainingsdaten, welche vom Nutzer zur Verfügung gestellt werden und im Video als grüne Punkte dargestell sind. Von diesen lernt der Roboter innerhalb weniger Minuten, beliebige Zielpositionen anzufahren, ohne dabei mit den Hindernissen zu kollidieren. Und das nicht nur in den Trainingsbereichen, sondern auch darüber hinaus ².

Im nächsten Schritt, geht es nun darum, ihm die eigentliche Aufgabe beizubringen. Das kann z. B. eine Schweiß- oder Klebenaht sein und auf verschiedenen Wegen passieren, z. B. erneut mit Hilfe von Kinesthetic Teaching, also dem direkten Führen des Roboters. Da dieser sich aber in seiner Umgebung nun schon zu bewegen weiß, braucht der Nutzer nicht mehr alle Gelenke gleichzeitig zu kontrollieren. Es reicht, dass er ihn vorn am Greifer entlang der spezifischen Aufgabe führt und der Roboter assistiert ihm dabei sozusagen bei der Hindernisvermeidung, wie in dem Video ab Minute 2:10 zu sehen ist. Diese Phase nennen wir deshalb Assisted Programming.

Der Knackpunkt zur Vereinfachung dieser Interaktion liegt also in der Aufteilung der Gesamtaufgabe in zwei oder mehr aufeinander aufbauende Teilschritte, um den Nutzer bzw. Mitarbeiter des Roboters nicht zu überfordern. Im letzten Jahr haben wir mit Unterstützung der Firma Harting oben genannte Pilotstudie zum Thema Kinesthetic Teaching durchgeführt und die beschriebene Idee evaluiert. Dabei haben 48 Mitarbeiter, unterteilt in zwei Versuchsgruppen, mit dem System interagiert und versucht, dem Roboter obigen Parcours beizubringen. Die Ergebnisse der einen Gruppe waren bereits im ersten Video zu sehen. Von 24 Versuchsteilnehmern, haben es gerade einmal zwei Probanden geschafft, den Parcours kollisionsfrei abzufahren; eine Probandin brach ihren Versuch nach einiger Zeit frustriert ab. Die zweite Versuchsgruppe hingegen benutzte den assistierten Modus und zeigte signifikant bessere Ergebnisse. Diese Teilnehmer benötigten im Schnitt weniger als die Hälfte der Zeit, um den Roboter anzulernen, die beigebrachten Bewegungen waren signifikant näher an der Vorgabe und wesentlich ruckelfreier.

Unsere Experimente und Studien legen nahe, dass moderne Robotiksysteme durchaus über die Flexibilität verfügen, regelmäßig und vor Ort an wechselnde Aufgaben angepasst zu werden, wie es zum Beispiel für Kleinserienfertigung oder Prototypenbau notwendig ist. Dazu reicht die rein technische Flexibilität allerdings nicht aus, denn sie erfordert immer noch lange Einarbeitung und Robotikexperten. Erst in der Kombination mit lernenden Systemen und einfachen Interaktionsschnittstellen spielen solche Systeme ihr volles Potential aus.

Christian Emmerich und Arne Nordmann sind Doktoranden am Forschungsinstitut für Kognition und Robotik der Universität Bielefeld und beschäftigen sich mit lernenden, interaktiven Robotiksystemen.

Ein Roboter-Rüssel lernt wie ein Baby

Posted on 26. Mai 201327. Januar 2020 by Arne

(this article is also available in English)

/images/blog/bha.jpg — Festos Bionic Handling Assistent (BHA), inspiriert von einem Elefantenrüssel

Schon vor gut einem Jahr habe ich über Festos Bionic Handling Assistent (BHA) geschrieben, der damals frisch mit dem Deutschen Zukunftspreis gekrönt war. Wir haben einen von diesen Robotern bekommen und im April letzten Jahres haben wir bereits hier über unsere ersten Gehversuche und die Simulation des Roboters geschrieben. In diesem Artikel wird es nun darum gehen, wie wir von Babys gelernt haben, den Roboter zu kontrollieren.

Vor einigen Wochen wurde der BHA in der Sendung mit der Maus gezeigt. Wer das Video bis zu Minute 5:00 verfolgt, bekommt jedoch den Haken mit: so faszinierend der Roboter, insbesondere der BHA, auch ist … es ist ebenso kompliziert, ihn zu bewegen.

Die Sendung mit der Maus – Festos BHA und Robotino

In der Sendung und bei den meisten Vorführungen des Roboters steht daher jemand an einer Fernbedienung, oder öffnet und schließt händisch die Ventile, wie zu Beginn des Videos zu sehen. Von einem praktischen Einsatz, bei dem der Roboter eigenständig Aufgaben erledigt, ist das noch meilenweit entfernt.

Das liegt unter anderem daran, dass der Rüssel anders ist, als andere Roboter. Seine elastischen Bewegungen sind sehr schwierig und nur annähernd in mathematische Gleichungen zu fassen. Genau diese Bewegungsgleichungen benötigen aber die klassische Verfahren zur Robotersteuerung. Selbst unser Modell reicht dazu kaum aus, denn es kann keine Auskunft über die Reichweite der vielen Aktuatoren liefern. Diese müsste man sehr genau kennen um den Roboter (klassisch) ansteuern zu können: es ergeben sich schnell sehr große Fehler, wenn der Regler einem Aktuator einen Befehl gibt, der außerhalb seiner Reichweite liegt.

Was das Ganze noch schwieriger macht sind die Verzögerungen im Bewegungsverhalten: der Roboter bewegt sich mittels Luftkammern, die mit Druckluft aufgeblasen werden, die aber erst mit Verzögerung in den Kammern ankommt. Danach dauert es einige Zeit, mitunter bis zu 20 Sekunden, bis der Roboter seine neue Postur erreicht und sich stabilisiert hat. Diese Verzögerungen machen viele der sonst auf Robotern verwendeten Regler praktisch nutzlos, da sie schnelles und exaktes Roboterverhalten benötigen.

Schwierig … aber dafür gibt es maschinelle Lernverfahren, von denen es unzählige Methoden gibt, um Roboter Bewegungen lernen zu lassen. Zunächst muss man den Roboter seinen Bewegungsraum explorieren lassen, also ausprobieren welche resultierenden Bewegungen durch verschiedene Motorkommandos hervorgerufen werden. Da liegt allerdings schon die nächste Krux mit dem BHA, denn: es gibt sehr, sehr viele verschiedene Motorkommandos. Die Standard-Ansätze zum Lernen erfordern, sie alle auszuprobieren. Auf dem BHA benutzen wir aktuell neun Aktuatoren (die Luftkammern). Möchte man pro Aktuator nur 10 verschiedene Kommandos ausprobieren, ergeben sich bereits eine Milliarde (10^9) Kombinationen. Es würde Jahrzehnte dauern, würde man ernsthaft versuchen die alle auf dem Roboter zu explorieren. In der Praxis würde man daher eher zufällige Kommandos auswählen, und einfach irgendwann aufhören. Natürlich ändert das aber auch nichts daran, dass man eigentlich alle Kommandos ausprobieren müsste, damit das Bewegungslernen funktionieren kann.

Was tun?

Um diesem Problem zu begegnen, haben wir uns Inspiration aus der Biologie geholt. Die Aufgabe, den BHA-Rüssel kontrollieren zu lernen, ist nämlich in vielerlei Hinsicht der Aufgabe von Babys sehr ähnlich, in den ersten Lebensmonaten zu lernen, ihre eigenen Gliedmaßen zielgerichtet zu bewegen. Sie müssen dafür lernen, 600 Muskeln zu koordinieren, und sind dabei unglaublich effizient. Was ist also der Trick, den wir lernen müssen, wenn wir unsere Experimente mit dem BHA ähnlich effizient durchführen wollen?

Einen Hinweis liefert eine wegweisende Studie von Claes von Hosten aus dem Jahr 1982. Diese Studie konnte zeigen, dass selbst Neugeborene sich nicht ‐ wie es zuerst scheint ‐ zufällig bewegen, sondern von Beginn an zielgerichtet in Richtung bewegter Objekte greifen. Das folgende Bild zeigt dies unglaublicherweise bereits bei einem wenige Tage alten Baby:

/images/blog/ronnqvist-hofsten-1994-infant-reach.jpeg — Ein wenige Tage altes Neugeborenes zeigt bereits zielgerichtete Bewegung Richtung bewegter Objekte

Diese Erkenntnis wurde lange von der Machine Learning Community ignoriert, und sollte uns den entscheidenden Hinweis geben. Der von Matthias Rolf entwickelte Ansatz Goal Babbling, versucht nicht mehr durch zufällige Bewegungen den Bewegungsraum zu explorieren (Motor Babbling), sondern tut es von Anfang an zielgerichtet [Rolf et al., 2011]. Die Ergebnisse in Simulation waren vielversprechend, und haben gezeigt, dass dieser Ansatz auch mit 50 Freiheitsgraden zurecht kommt und nicht einmal mehr Zeit benötigt als für einen Roboter mit nur zwei Gelenken. Das ist ein entscheidender Vorteil gegenüber dem zufälligen Explorieren des Raumes, dessen Zeit zum Explorieren exponentiell mit der Anzahl der Dimensionen steigt. Mit Goal Babbling erhalten wir erste brauchbare Resultate bereits nach wenigen hundert Bewegungen, was sogar mit der Geschwindigkeit menschlichen Lernens vergleichbar ist [Sailer and Flanagan, 2005]. Wir können also offenbar wirklich mit der biologischen Vorlage das Lernen massiv beschleunigen! Zeit also, das biologisch-inspirierte Lernen auf dem biologisch inspirierten Roboter anzuwenden.

In unseren ersten Experimenten lernte der Roboter lediglich einfache Bewegungen des Greifers nach links und rechts. Nicht besonders nützlich, aber trotzdem beeindruckend als Live-Demonstration, denn der Roboter konnte innerhalb von zwei Minuten eigenständig lernen, seine neun Kammern zu koordinieren und diese Bewegung auszuführen. Schnell zeigte sich außerdem, wie gut das Verfahren mit Hardware-Defekten umgehen konnte, obwohl wir wahrlich nicht vor hatten, das herauszufinden. Eines Tages während der Experimente stellten wir jedoch ein kleines Loch in einer der Luftkammern fest, durch das Luft entwich: die Kammer konnte sich nicht mehr aufblasen. Schlimmer noch: die Kammer bewegte sich passiv wie eine mechanische Feder mit, was die Bewegung des gesamten BHA-Rüssels beeinflusste. Das Lernverfahren scherte das kaum. Es lernte einfach die anderen Aktuatoren entsprechend einzusetzen ‐ zusammen mit der passiven Bewegung des defekten Aktuators. Wohlgemerkt: wir mussten dem Verfahren dafür nicht mitteilen, dass etwas defekt war. So einfach kann es manchmal sein!

Eine ähnlich gute Entdeckung machten wir, als jemand den Roboter hin und her schob, während er grade explorierte und lernte. Durch das Anschubsen des Roboters konnte man ihm tatsächlich unter die Arme greifen und ihm zeigen, wie sinnvolle Bewegungen aussehen. Schiebt man ihn in die Richtung, in die er sich gerade bewegen will (also die richtige Richtung), spürt man bemerkenswerterweise kaum Widerstand vom Regler. Das Lernen geschieht in diesen Momenten so schnell, das der Roboter die Bewegung schon während des Führens in den gelernten Regler einarbeitet. Folglich reicht es aus, ihm die Bewegung ein einziges mal zu zeigen. Das Ganze ist überhaupt nur möglich, weil das ziel-gerichtete Explorieren und sehr schnelles kontinuierliches Lernen des Goal Babblings mit dem leichten, nachgiebigen BHA-Rüssel aufeinander treffen. Preis-gekrönte ¹, biologisch inspirierte Hardware und preis-gekröntes ², biologisch inspiriertes Lernen.

Bei dem gesamten Vorhaben leistete uns die vorher entwickelte Simulation des Bewegungsverhaltens gute Dienste. Auch wenn das Lernen und Explorieren auf dem echten Roboter stattfand, war die Simulation für allerhand Visualisierungen und zusätzliche Vorhersagen nützlich. So ließ sich nun die Bewegung des Roboters bezüglich selbst-generierter (und ausschließlich virtuell existierender) Ziele während des Lernens darstellen, und das Lernen auf dreidimensionale Ziele (anstatt nur links/rechts) erweitern. Wir konnten nun Einblick in das Lernen nehmen und live während des Lernens vorhersagen, wie gut der gerade lernende Regler verschiedene Positionen im Raum anfahren kann. Wir lernten dadurch, dass sich das Lernen auf dem echten Roboter ganz ähnlich entfaltet wie es unsere ersten Simulations-Experimenten 2010 bis Anfang 2011 (noch komplett ohne den BHA) gezeigt haben.

Biologisch inspiriertes Lernen auf einem biologisch inspirierten Roboter

Auf dem Rüssel liefert Goal Babbling schnell nützliche Ergebnisse. Nach dem Lernen lässt sich der Greifer mit ca. 2 cm Genauigkeit im Raum positionieren. Das ist nicht direkt perfekt, aber reicht in vielen Fällen schon aus, da der flexible Fin-Gripper Gegenstände großräumig mit seinen elastischen Fingern umschließt. Um den Rüssel so schnell und gezielt wie im Video bewegen zu können, darf man nicht auf Feedback (also Bewegungsantworten) vom Roboter warten, da das bei der Pneumatik zu lange dauert. Solch einen Regler, der ohne Feedback auskommt, liefert uns das Lernen. Dadurch weiß der Roboter sofort, wo er hin muss, anstatt sich langsam und Schritt für Schritt ans Ziel heranzutasten. Feedback ist dann lediglich eine zusätzliche Hilfe, die wie in der letzten Sequenz im Video zu sehen, die Genauigkeiten auf 6-8 mm erhöht. In Anbetracht der Tatsache, dass der Rüssel selbst permanent ca. 5 mm hin- und herschwankt, ist das beachtlich.

Erwähnenswert ist außerdem: das Ganze funktioniert nicht nur einmalig und im Video. Wir haben sehr ausgiebige Experimente dazu gemacht, und es funktionierte in jedem Durchgang. Das Lernen von links-/rechts-Bewegungen haben wir regelmäßig in Live-Demos gezeigt, in denen der Roboter binnen 1-3 Minuten seine Bewegungen lernt. Unter Anderem haben wir dies live auf der Automatica 2012 in München gezeigt, auf der das Live-Lernen mit dem Roboter und dem Objekt-Tracking aus dem Video vier Tage lang jeweils acht Stunden lief.

Die gute Nachricht lautet also: es funktioniert! Und es funktioniert robust!

Festos Bionic Handling Assistant ist ein großartiger, spannender Roboter. Er ist nicht nur ein Hingucker durch seine Ähnlichkeit mit dem Elefantenrüssel, sondern seine Struktur macht auch den Umgang und die Interaktion mit ihm natürlich und sicher. Um ihn allerdings auf ähnliche Art und Weise kontrollieren zu können, wie wir es mit anderen Robotern tun, mussten wir einige Hürden überwinden: Ausgangspunkt war ein Roboter ganz ohne Modell und nur mit einfacher Druckregelung. Stück für Stück haben wir ein Vorwärtsmodell der Kinematik, Simulation und Längenregelung hinzugefügt. Der entscheidende Punkt war allerdings, maschinelles Lernen, vor Allem das durch Beobachtung von Babys inspirierte Goal Babbling einzusetzen, das erstaunlich schnell lernt, den Roboter zu kontrollieren.

Jetzt, da wir den Rüssel kontrollieren können, um Objekte zu greifen und zu bewegen: Für welche Aufgaben sollten wir ihn jetzt unbedingt einsetzen?

Kontakt:

Dr.-Ing. Matthias Rolf, CoR-Lab – Bielefeld University, mrolf@cor-lab.uni-bielefeld.de, Emergent Robotics Lab, Osaka University

Prof. Jochen Steil, CoR-Lab – Bielefeld University, jsteil@cor-lab.uni-bielefeld.de

Elastische Roboterarmkörper – Fluch oder Segen?

Posted on 10. Februar 201327. Januar 2020 by Jörn

(this article is also available in English)

Die Vermeidung unerwünschter elastischer Effekte stellt eine große Herausforderung bei der Konstruktion von Robotern dar. Sie erschweren die präzise Positionierung des Roboterarms aufgrund statischer lastabhängiger Verbiegungen und schwingen nach jeder Bewegung nach. Vergleichbare Beispiele, bei denen Elastizitäten meist unerwünscht sind, finden wir fernab der Robotik bei Baumaschinen, wie Auto-Betonpumpen, Hubwagen aber auch Feuerwehrdrehleitern.

Wie wäre es, wenn auf die Steifigkeit bei der Auslegung einer Maschine weniger Wert gelegt werden müsste, da den damit einhergehenden unerwünschten Effekten mit regelungstechnischem Mitteln begegnet werden kann? Mechanische Strukturen könnten mit schlicht weniger Material leichter gebaut werden. Infolge dessen ließen sich Antriebe kleiner dimensionieren und hätten einen geringeren Energiebedarf.

Dieser Gedanke ist genau die Idee hinter dem Forschungsthema, dass ich bearbeite. Im Rahmen des Forschungsthemas haben wir den nachfolgend dargestellten gliedelastischen Roboterarm TUDOR als Experimentalsystem entwickelt.

/images/blog/TUDORBild.png — Das gliedelastische Experimentalsystem TUDOR

Er wird von drei bürstenlosen Gleichstrommotoren angetrieben und besitzt zwei Federstahlbalken als elastische Armkörper. Bei einer typischen Punkt-zu-Punkt-Bewegung der Antriebe treten Schwingungsamplituden von bis zu 10 cm auf.

Auf den Roboter-Konferenzen dieser Welt werden aktuell viele Beiträge zu Robotern mit elastischen Komponenten vorgestellt. Die elastischen Komponenten werden meist in die Robotergelenke integriert. Ein sehr heißes Thema sind vor allem Gelenke, bei denen sich die elastischen Eigenschaften der Komponenten aktiv variieren lassen. Die Elastizitäten bewirken, dass die aufgrund der hohen Getriebeübersetzung üblicher Roboterarme sehr großen Trägheitsmomente der Antriebe von den Trägheitsmomenten des übrigen Arms entkoppelt werden. Das bedeutet, dass im Falle eines physischen Kontakts mit dem Roboter der Interaktionspartner eine geringere Trägheit des Armes „sieht“. Damit kann beispielsweise eine Verringerung des Gefährdungspotenzials des Roboters erzielt werden. Auf der anderen Seite speichern die Elastizitäten zusätzliche Energie, die im Falle eine Kollision freigesetzt und wiederum ein erhöhtes Gefahrenpotential (Peitscheneffekt) zur Folge haben kann. Häufig werden Elastizitäten eingesetzt, um dem Roboter zu natürlicheren und auch dynamischen Bewegungen zu verhelfen. Es ist festzuhalten, dass durch eine geeignete Regelung gezielt eingesetzte elastische Komponenten zahlreiche Möglichkeiten eröffnen.

Aus regelungstechnischer Sicht sind die elastischen Eigenschaften in den Robotergelenken am einfachsten zu beherrschen. Hier ist die Elastizität entlang der Wirkachse der Antriebe konzentriert. Überwiegt die Elastizität in den Roboter Armkörpern, so sind die elastischen Eigenschaften entlang der Armkörper und senkrecht zur Wirkachse der Antriebe verteilt. Die dadurch entstehenden Laufzeiteffekte erschweren eine Regelung des Roboterarms. Dies mag der Grund sein, aus dem derzeit vorwiegend Arbeiten zu gelenkelastischen Roboterarmen publiziert werden.

Mit TUDOR hat uns zunächst die Frage interessiert, ob wir mit einem gliedelastischen Roboterarm trotz der Schwingungen und last- und konfigurationsabhängigen variablen Verbiegungen eine zielgerichtete Aufgabe präzise in geforderter Zeit erledigen können. Als Demonstration hierzu haben wir uns, wie im nachfolgenden Bild dargestellt, das Fangen eines Balles ausgedacht.

/images/blog/Ballfangen_Szenario.png — Ballfangen-Szenario

Ein menschlicher Werfer wirft den Ball in Richtung des Roboters. Die Flugbahn wird mittels einer Kinect-Kamera ermittelt und der Durchstoßpunkt der Flugbahn mit der Bewegungsebene des Roboters berechnet. Bevor der Ball am Roboter vorbei fliegt, bewegt der Roboter ein am Armende montiertes Netz dorthin und fängt den Ball damit auf. Das Resultat haben wir im nachfolgenden Video zusammengefasst:

A multi-link-flexible robot arm catching thrown softballs.

Sofern die Schwingungen regelungstechnisch unterdrückt und Abweichungen aufgrund statischer Verbiegungen kompensiert werden können, ließen sich in manchen Anwendungen diese elastischen Eigenschaften vielleicht nicht mehr nur als Problem verstehen. Vielmehr könnten elastische Eigenschaften vielleicht auch ausgenutzt werden, um beispielsweise Kontaktsituationen zu erkennen und darauf zu reagieren. Mit aktiv geregelten moderat gelenkelastischen Roboterarmen wurde dies ja bereits eindrucksvoll gezeigt.

Bezüglich gliedelastischer Roboter ist die Dämpfung auftretender Schwingungen bislang noch das dominierende Thema in Publikationen.

In den vergangenen Tagen konnten wir hier womöglich einen ersten Schritt über die reine Schwingungsdämpfung hinaus machen. Basierend auf einer Kraftregelung ist es uns gelungen ein Regelungskonzept zu entwickeln, bei dem wir die Schwingungen der mechanischen Struktur eines Roboterarms unterdrücken und zugleich die Nachgiebigkeit aktiv beeinflussen können. Einige Experimente dazu haben wir in nachfolgendem Video festgehalten:

Video zur Kraftregelung eines gliedelastischen Roboterarms

In dem Regelungskonzept wird die Information über die auf die Robterarme einwirkenden Kräfte mittels Dehnungsmessstreifen erfasst und individuell auf die Antriebsregler zurückgeführt. Auf diese Weise werden Schwingungen in der Armstruktur unterdrückt obgleich sie von der Gelenkbewegung oder der Interaktion mit der Umgebung herrühren. Zusätzlich lässt sich die Nachgiebigkeit des Roboterarms derart beeinflussen, dass wir mit sehr wenig Kraft den Roboterarm aus seiner aktuellen Position schieben können und die Wahrscheinlichkeit fragile Objekte bei einer unvorhergesehnen Kollision zu zerbrechen deutlich reduziert wird.

Also: elastische Roboterarmkörper – Fluch oder Segen? Trotz dieser Experimente sind noch zahlreiche Herausforderungen zu meistern und fragen zu beantworten. Dennoch scheint es mir, als schlummertem in den Elastizitäten der Armkörper nicht nur Probleme, sondern auch Potenziale.

Ich freue mich darauf zu sehen, wo die Reise noch hinführen wird.

Simulation des Bionischen Handling-Assistenten

Posted on 17. April 201227. Januar 2020 by Arne

(this article is also available in English)

Im April 2010 wurde der Bionische Handling-Assistent (BHA) von Festo auf der Hannover Messe der Öffentlichkeit vorgestellt. In den folgenden Monaten sah dieser biologisch inspirierte Roboterarm zu recht eine große Medienpräsenz und wurde mit zahlreichen Preisen, unter anderem dem Deutschen Forschungspreis 2010, ausgezeichnet. Im Februar 2011 bekamen wir dann unseren eigenen BHA, voller Vorfreude, denn wir wussten, dass niemand bislang mit dem BHA tun konnte, was wir mit ihm vorhatten: ihn zu kontrollieren. ¹

Die Struktur und Funktionsweise des BHA ist inspiriert von einem Elefantenrüssel, wie in folgender Abbildung unschwer zu erkennen ist. Der Arm wird im Sinne des Rapid Prototypings im 3D-Drucker gedruckt. Als Material wird Polyamid verwendet, wodurch der gesamte Arm leicht-gewichtig und durchgängig verformbar wird: Im Wesentlichen besteht der BHA also aus Plastik und einer Menge Luft. Bewegt wird der Arm von dreizehn pneumatischen Ventilen, die die dreizehn Kammern des Roboters mit Luft füllen oder entleeren. Dies wiederum verbiegt, beugt und streckt die komplette Struktur.

Festo hat mit dem BHA die Vision eines leichten, freibeweglichen Dritte-Hand-Systems, das den Menschen bei seiner Arbeit unterstützen kann. Dank seiner strukturellen Nachgiebigkeit (Compliance) ist der Arm im Kontakt mit Menschen und seiner Umgebung naturgemäß sicher, was die Möglichkeiten von direkter Zusammenarbeit von Mensch und Roboter eröffnet. In industriellem Kontext kann der BHA in Fertigungsprozessen eingesetzt werden, z.B. um mit empfindlichen Gütern wie z.B. Lebensmitteln zu arbeiten.

Als wir uns entschlossen haben, Festos Bionischen Handling-Assistenten zu erwerben, wussten wir, dass wenige der klassischen und bekannten Verfahren mit diesem Roboter funktionieren würden. Trotzdem war überraschend, dass der Roboter ohne jegliche Software ausgeliefert wurde.

Keine Software.

Nichts.

Noch bis vor einem Jahr konnten wir mit dem BHA nicht viel mehr tun, als von Hand die pneumatischen Ventile zu öffnen und zu schließen, um damit entweder vollen Druck oder gar keinen Druck in die Kammern zu geben. Auch damit waren die Bewegungen des Roboters absolut faszinierend und wir hatten großen Spaß, aber ernsthafte Anwendungen waren damit natürlich noch nicht möglich. Wie von Festo zugesagt, bekamen wir dann vor fast genau einem Jahr elektronische Ventile, mit denen wir (mehr oder weniger präzise) den Druck in den Kammern automatisch vorgeben konnten. Nicht mehr und nicht weniger: den Druck kontrollieren.

Um es einmal vorsichtig zu sagen: Der Schritt von dieser Druckregelung zu einer ernsthaften Anwendung mit dem BHA ist groß!

Das tatsächliche Werkzeug, dass man mit dem BHA kontrollieren will, ist der sogenannte Fin Gripper am Ende des Arms. Diesen Greifer zu allerdings genau zu positionieren setzt zuallererst voraus, die Postur des Arms präzise bestimmen zu können. Den Druck in den einzelnen Kammern zu kennen, reicht dafür bei weitem nicht aus; dass dies zum Scheitern verurteilt sein würde, diese Erfahrung hatten wir bereits mir anderen Robotikplattformen gemacht: Zehn Mal den gleichen Druck auf einen pneumatischen Roboter zu geben, ergibt im Regelfall zehn verschiedene Posturen des Roboters. Reibung, Reibung, Hysterese-Effekte und Nicht-Stationaritäten verändern das Ergebnis von Mal zu Mal.

/images/blog/bha-marked.jpeg — Die kinematische Struktur des BHA

Um diesen Problemen zu begegnen, besitzt der BHA Längensensoren (Kabel-Potentiometer), um an der Außenseite des Arms die Streckung der einzelnen Kammern zu messen (siehe obige Abbildung). Natürlich wollten wir diese Länge nicht nur kennen, sondern auch kontrollieren können. Das ist theoretisch mit klassischer (PID-)Regeltechnik möglich, aber funktioniert auf diese Weise nur sehr schlecht. Um dieses Verhalten zu verbessern, könnte man nun versuchen, all das Wissen über den BHA in eine ausgefeiltere Regelungstechnik zu stecken. Wenn man dieses Wissen bloß hätte …

Eine kurze Liste von Dingen, die man über den BHA nicht weiß:

Das präzise Verhältnis zwischen Druck in den Kammern und der geometrischen Postur im Ruhepunkt (im Equilibrium)

Jegliche Art von Dynamik (nicht nur der Pneumatik selbst, sondern auch des sehr viel langsameren Zusammenspiels zwischen der Pneumatik und Geometrie)

Welche Länge des Arms bzw. der einzelnen Kammern ist überhaupt möglich? Wo liegen die Grenzen?

Und nicht zuletzt: Wie genau ist das Zusammenspiel der obigen Aspekte zwischen den einzelnen Kammern. Denn: Es besteht ein starker Zusammenhang!

Alles zusammen eine große Herausforderung … aber nicht unmöglich. Angenommen also, die Länge des Aktuators lässt sich messen und kontrollieren. Um nun die Endeffektor-Position (die Position des Greifers) zu kontrollieren … muss man die aktuelle Endeffektor-Position kennen!

Die Endeffektor-Position anhand der Geometrie des Roboters und der Stellung der Aktuatoren zu errechnen, nennt sich Vorwärts-Kinematik und ist für handelsübliche Roboter kein großes Problem, sondern einfache Trigonometrie. Der BHA gehört allerdings zu einer anderen Klasse von Morphologien, genannt Continuum Kinematics (also in etwa: kontinuierliche Kinematik). Dank seiner mechanischen Flexibilität besitzt dieser Roboterarm unendlich viele Freiheitsgrade, da jeder Bereich des Roboters unterschiedlich gebogen und gestreckt sein kann. Unendlich viele Freiheitsgrade können weder mit Sensoren gemessen noch berechnet werden.

Als wir unsere Arbeit mit dem BHA begonnen haben, planten wir nicht, die komplizierte Kinematik des BHA zu simulieren. Da wir uns im Kontext des BHA hauptsächlich mit Maschinellem Lernen beschäftigen, wollten wir die Endeffektor-Position schlicht messen, um sie benutzen zu können (tun wir auch). Dass wir trotzdem eine Simulation benötigen würden, stellte sich heraus, als wir Schwierigkeiten in der Visualisierung bekamen. Wir wollten nämlich darstellen, wie die räumlichen Koordinaten mit den Bewegungen des BHA zusammenhängen.

Da Visualisierung Kenntnis der Kinematik voraussetzt, begannen wir, sie anzunähern. Selbst wenn sich die Beugung und Streckung von unendlich vielen Freiheitsgraden nicht berechnen lässt, so lassen sich doch durch die Längensensoren einige Annahmen zur Beugung des Arms treffen. Die einfachste Art der Beugung ist eine kreisförmige; im drei-dimensionalen Fall entspricht dies einem Torus:

/images/blog/torus-model.jpg — Torus-Modell zur Annäherung der Beugung des BHA

Das Bild zeigt, wie sich ein Segment mit drei Aktuatoren (in der Abbildung als graue Röhren dargestellt) entlang eines Torus verbiegt. Diese Geometrie kann mit drei Parametern beschrieben werden: zwei Winkel (in der Abbildung blau dargestellt) und der Radius des Torus (in der Abbildung rot). Diese drei Parameter können anhand der gemessenen Längen an der Außenseite der BHA-Segmente rekonstruiert werden. Sobald diese Parameter bestimmt sind, ist das Berechnen der Vorwärtskinematik und damit die Bestimmung der Endeffektor-Position (also der Position des Greifers) einfach. Ein Problem tritt lediglich im Grenzfall auf, wenn alle Längen gleich sind, wenn also alle Kammern gleich gestreckt sind. Diese Verformung kann durch einen Torus nicht dargestellt werden, obwohl der BHA zu solch einer Bewegung in der Lage ist. Auch für dieses Problem ließ sich allerdings eine einfache, numerisch stabile Lösung finden. Der BHA lässt sich somit durch Aufeinandersetzen dreier solcher Segmente darstellen und simulieren.

Die gezeigten Torusdeformationen sind sehr einfache Annäherungen des Arms im Vergleich zu komplexen Physik des Verformungs-Problems. Üblicherweise ist diese Art von Annäherung daher nicht hinreichend für diese Art von Robotern (siehe z.B. Trivedi 2008 ² ). Nicht jedoch für den BHA: Hier funktioniert die beschriebene Lösung sehr gut, in unseren Tests sehen wir einen durchschnittlichen Fehler von 1cm auf einer Länge von 1m. Nicht perfekt, aber absolut ausreichend für unsere Zwecke und außerdem durchaus konkurrenzfähig zu Lösungen in der Literatur.

Das folgende Video zeigt das simulierte Modell und unseren BHA:

BHA-Simulation

Der große Vorteil des benutzten einfachen Torus-Modells ist seine Geschwindigkeit in der Berechnung. Unsere Software-Bibliothek ist auf Basis dieses Modells in der Lage, die Vorwärtskinematik des BHA auf einem einzelnen CPU-Kern mehrere zehntausend Mal in der Sekunde zu berechnen. Auch wenn wir diese Simulation ursprünglich nicht geplant hatten, ist sie damit mittlerweile eine essentielles Werkzeug bei unserer Arbeit mit dem BHA geworden. Die interessanten Dinge machen wir weiterhin auch auf der echten Hardware, aber parallel lassen sich nun viele Dinge bequem vorberechnen und darstellen.

Die Kinematik-Simulation ist in C++ implementiert und als Open-Source-Bibliothek verfügbar. Über die folgende Seite kann sie heruntergeladen werden und enthält sowohl die Vorwärtskinematik als auch die gezeigte OpenGL-basierte 3D-Visualisierung: http://www.cor-lab.de/software-continuum-kinematics-simulation Wir freuen uns über Benutzer und Erfahrungsberichte.

Der folgende einfache Code-Schnipsel berechnet zum Beispiel die Vorwärtskinematik des BHA:

// create robot morphology with segment radii 0.1, 0.09 and 0.08 meters ContinuumRobotKinematics kinematics(RealVector(0.1, 0.09, 0.08));
// specify an end effector offset kinematics.setEndEffectorOffset(RealVector(0.0, 0.0, 0.14));
// this is the forward kinematics function:
Mapping<RealVector,RealVector> fwdKin = kinematics.getForwardPositionKinematics();
// try out some posture (a combination of actuator lengths) RealVector posture = {0.2,0.24,0.24,0.2,0.24,0.24,0.2,0.24,0.24};
// this is the resulting end-effector position RealVector position = fwdKin(posture); // [-0.3808, 0, 0.686287]Neben der in diesem Artikel beschriebenen Kinematik-Berechnung und Simulation des BHA, haben wir in den letzten Monaten noch viele weitere spannende Dinge mit dem BHA gemacht, die wir auf der Automatica-Messe im Mai in München zeigen werden:
Um zu sehen wie wir trotz der zahlreichen obigen Probleme mithilfe maschineller Lernmethoden den Greifer auf dem echten BHA im Arbeitsraum zu kontrollieren gelernt haben, lohnt sich also ein Besuch unseres Standes auf der Automatica in München:
Stand 427 und 429 in Halle B3, vom 22. bis 25. Mai.

Kontakt:

Dipl.-Inform. Matthias Rolf, CoR-Lab – Bielefeld University, mrolf@cor-lab.uni-bielefeld.de

Prof. Jochen Steil, CoR-Lab – Bielefeld University, jsteil@cor-lab.uni-bielefeld.de