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

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?

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!

Der Beitrag Robotics for Software Engineers – Interview mit Andreas Bihlmaier erschien zuerst auf botzeit.

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.

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.

Meine Idee zu dem Interview mit Dir oder Euch ist aus meinem Eindruck entstanden, dass die Robotik als zu positiv und zu leistungsfähig dargestellt wird. Wenn ich das bei Dir richtig heraushöre, dann siehst Du aber häufiger, dass die Robotik als zu gewalttätig oder zu brutal dargestellt wird?

Nein, das war nur der eine Aspekt: der Terminator sozusagen in seiner Schrecklichkeit visualisiert.

Der zweite Aspekt ist natürlich das viel zu positive und viel zu fortgeschrittene Roboterbild. Da geht es auch vor allem immer darum, dass Roboter als humanoide Serviceroboter dargestellt werden. Das geht soweit, dass auch Artikel zu künstlicher Intelligenz (Artificial Intelligence, AI) so bebildert werden. Wenn es also im Moment zum Beispiel darum geht, dass AI im Kampf gegen das neuartige Coronavirus helfen soll, dann sitzt da in den Abbildungen ein humanoider Roboter mit filigranen Händen und benutzt gerne sogar noch menschliche Technologie.

Stimmt, sitzt am Computer zum Beispiel…

Der helle Wahnsinn, wenn man sich das ansieht. Zu der Science-Fiction-Horrorerwartung kommt also noch diese Humanoide-Leistungsfähigkeits-Erwartung, nämlich dass wir demnächst solche Roboter haben, wie sie auf den Bildern zu sehen sind: schlanke, sehr menschenähnliche Roboter, bei denen die Menschlichkeit nur noch dadurch kaschiert wird, dass weiße Plastikabdeckungen auf menschlichen Körperteilen sind. Das schürt eine völlig falsche Erwartung an den Stand der Robotik und was gerade die Forschungsrichtung ist.

Da geht’s auch um die Menschenähnlichkeit, die natürlich selbst auch Erwartungen schürt. Dafür muss man nicht einmal die Agenturbildern von diesen weißen, glatten Humanoiden hernehmen, sondern muss sich nur den Roboter Pepper ansehen. Der ist gerade das absolute Synonym dafür, was von humanoiden Robotern erwartet wird und was sie aber eigentlich gar nicht leisten können.

Du hast jetzt mehrfach AI erwähnt. Nimmt das NotMyRobots-Problem Deiner Wahrnehmung nach durch den aktuellen AI-Trend zu?

Ja, absolut. Es ist natürlich auch schwierig, AI zu bebildern, das muss man dazusagen. Was wir seit zwei Jahren ganz vermehrt beobachten ist, dass der Dialog sich etwas von der Robotik abgewendet hat und es heißt, die AI wird das jetzt tun. Wenn es allerdings Artikel dazu gibt, dass AI uns dabei hilft, ein bestimmtes Problem zu lösen, ist das Bild dazu meistens ein Roboter. Das ist eine Merkwürdigkeit, da sie eine verkörperte künstliche Intelligenz in Form von Robotern zeigt, die weder den Stand der Technik in irgendeiner Weise darstellt, noch potentiellen Entwicklungen der Robotik oder der AI in irgendeiner Weise gerecht wird.

Ich komm jetzt nochmal darauf zurück, wie Euer Projekt NotMyRobots angefangen hat. Du hast gesagt, Ihr hattet alle aus Eurem wissenschaftlichen Hintergrund schon angefangen, diese Beispiel zu sammeln. Gab es denn irgendeinen konkreten Anlass?

Ich glaube, vor Allem das Entsetzen!

Es gibt einfach Bilder, wenn man die sieht, bleibt einem nichts weiter als sie staunend zu speichern und in die Giftkiste zu packen. Die fürchterlichsten sind glaube ich eigentlich die, in denen Roboter auf einmal ge-gendert werden. Der kompetente Roboter ist gerne ein sehr männlicher Roboter, mit männlichen Gesichtszügen. Noch viel schlimmer finde ich aber, wenn es eine unnötige Weiblichkeit der Roboter gibt. Das sind meistens die Roboterdarstellungen mit Brüsten, die ja keinerlei technologische Wirklichkeit darstellen und auf sexistische Kategorien abzielen.

Das ist natürlich gerade für uns Soziologen schrecklich, da Roboter und Cyborgs durchaus auch ein Versprechen einer Welt in sich tragen, die zum Beispiel Gender-Stereotype challengen könnte. Da sind gerade Humanoide natürlich immer sehr stark in einem Spannungsfeld von Geschlechtlichkeit und geschlechtlichen Stereotypen. Der männlich-starke, heroische Roboter auf der einen Seite. Der Terminator wird ja nicht umsonst von Arnold Schwarzenegger, als Klischeebild der Männlichkeit, verkörpert.

Auf der anderen Seite finden wir ganz viele Service-Stereotypen wieder. Da kommt es nicht von ungefähr, dass man auf ganz vielen Präsentationsfolien in der Mensch-Roboter-Interaktion Rosie von den Jetsons findet. Gerade bei Haushaltsrobotern und Pflegerobotern werden die Weiblichkeitsbilder, die wir in Care-Berufen kennen, auf die Roboter projiziert. Und dann finden wir plötzlich Bilder von Haushaltsrobotern, die Haushaltsmädchen-Schürzen tragen und deren Posen auch ganz klar mit der Verrichtung von Servicetätigkeiten assoziiert sind.

Das ist einerseits schade, weil Robotik eine Technologie ist, die Entitäten anders denken könnte, also zum Beispiel postgeschlechts-Identitäten. Das ist sicherlich kein zentrales Anliegen aktueller Robotikentwicklung, aber für uns ist das schon interessant. Pepper zum Beispiel hat mindestens im Deutschen und Englischen auch Antworten auf die Frage einprogrammiert, ob es ein Mädchen oder ein Junge ist. Das scheint also eine unmittelbare Frage zu sein, die Pepper triggert. Ich finde es zum Beispiel interessant, dass wir offenbar diesem technischen Objekt eine Geschlechtlichkeit beigeben müssen, sonst haben wir keine Kategorie, mit der wir darüber reden können, aber Pepper schlägt offenbar in dieser Kategorisierung fehl.

Das ist natürlich spannend: dass die humanoide Robotik solche Kategorien auch mal in Frage stellen kann und uns zum Nachdenken anregen kann. Wenn wir dann aber solche Bilder haben, wie die der robotischen Putzfrau oder die robotische Haushälterin oder das Sexobjekt Roboter in absolut nicht sexuellen Kontexten, dann ist das zu kritisieren. Das hat dann nämlich auch Implikationen für den Umgang mit Technik auf Dauer. Wenn wir Roboter als uns untergestellte Technologie empfinden, dann impliziert das häufig einen ganz merkwürdigen Umgang mit Technologie. Gerade vor dem Hintergrund, dass eigentlich alle robotische Technologie darauf angewiesen ist, ein eher partnerschaftliches Verhältnis mit uns einzugehen. Im Moment sehen wir zum Beispiel, dass das eigentliche Anpassungsfeld noch die menschliche Seite ist: wenn Roboter funktionieren sollen, muss die Umgebung strukturiert und robotisiert werden, muss unser Umgang mit ihnen robotisiert werden. Auch Reparatur ist im Moment immer auf der menschlichen Seite. Da schürt es natürlich falsche Erwartungen, wenn wir in der Darstellung Roboter sehen, die perfekte Hausmädchen sind.

Spannend! Ich hätte nicht gedacht, dass ich mal so intensiv in der Robotik auf Sexismus und post-gender stoße. Das begegnet mir sonst in der Robotik als Ingenieurswissenschaft nicht so viel. Sollte es aber vielleicht.

Das ist aber auch legitim. Ich bin halt Sozialwissenschaftler und ich weiß, dass unsere Ingenieure meist ganz andere Sorgen haben als wir. Die Sorgen um diese Bilder treffen sich aber trotzdem auf einer gewissen Ebene. Die Sorge darum, was Technik kann und wie die Technik dargestellt wird, die finde ich auch bei unseren Robotikern sofort wieder.

Absolut! Bei Dir und Euch von NotMyRobots hat das ja durchaus auch einen wissenschaftlichen Hintergrund, oder? Also zum Beispiel im Kontext Deiner Dissertation?

Bei Lisa und Laura liegt das sicher im Kontext der Dissertation, ja. In meiner Dissertation geht es eher um Robotik als Wissenschaft und vor Allem darum, wie robotische Wettkämpfe dabei eine Rolle spielen.

Also ist das für Dich eher ein Hobby?

Letztendlich denken wir darüber natürlich schon auf eine wissenschaftliche Art und Weise nach. Wir waren zum Beispiel schon eingeladen, einen Vortrag zu dem Open Lab zu halten, das wir bei MTI-engAge haben. Die Idee, ein solches Open Lab zu starten, ist natürlich aus genau solchen Überlegungen entstanden: dass die Robotik damit kämpft, diejenige Disziplin zu sein, die entweder den Terminator baut oder Menschen ihre Jobs wegnimmt. Das ist eine Hypothek, die man mit jedem robotischen Projekt mitnimmt.

In dem Projekt stand deswegen einmal im Monat unser Labor jedem offen. Das ist sehr gut angenommen worden und die Leute sind durchaus auch mit der Erwartung aus genau solchen Visualisierungen zu uns gekommen: Roboter zu sehen, die alles können. Die waren dann natürlich enttäuscht, dass Pepper zwar im Eingang stand und versucht hat, Hallo zu sagen, aber dann doch sehr wenig konnte und nicht die Hüfte geschüttelt hat. Da ergibt sich dieses sehr schöne Spannungsfeld von einerseits wahnsinniger Erwartung daran, was der Roboter kann und andererseits gibt es dann unseren Franka Emika, der Bälle übergibt, was auf erster Ebene erstmal wahnsinnig unspektakulär ist.

Da gibt es dann auch noch eine Differenz zwischen Pepper, den eigentlich keiner im Labor so richtig mag, auf dem kann man halt ein bisschen rumstreicheln. Und dann haben wir da diese tolle Maschine, die wahnsinnig viel kann und in die wahnsinnig viel Hirnschmalz geflossen ist. Die nimmt einen Ball vom Tisch und übergibt die an den Menschen und das ist dann erstmal eine Enttäuschung dieser Erwartungen.

Aber dann gibt es eine zweite Ebene, nämlich, darüber nachzudenken, was ist überhaupt kompliziert in der Robotik und was ist überhaupt auch an solchen trivialen Aufgaben für die aktuelle Robotik so spannend. Da gibt es meistens so einen Effekt, dass Leute überhaupt erstmal realisieren, wie schwierig es ist, Roboter zu bauen. Wenn man in einem Labor ist und sich die Bewegungen anguckt und was der Roboter überhaupt kann und was Stand der Technik ist, funktioniert das wahnsinnig gut. Danach sind die meisten Leute tatsächlich auch wieder begeistert. Das gibt so eine schöne Kurve der Robotikbegeisterung.

Das konnten wir uns natürlich nur leisten, weil wir ein großzügiges Labor hatten, viele Roboter und Leute, die überhaupt daran interessiert waren, diesen Dialog mit der Öffentlichkeit zu führen. Und solche Dialoge sind doch eher selten. Es gibt sonst natürlich Messen und Tage der offenen Tür als mögliche Berührungspunkte, aber da kommen – das haben wir auch gemessen – eher diejenigen, die ohnehin schon Enthusiasten sind und sich dafür begeistern.

Also, es ist schon irgendwie ein Hobby, aber es war auch Teil unserer beruflichen Realität, genau mit diesen Erwartungen konfrontiert zu werden. Für uns ist eben immer noch interessant, einen Umgang damit zu finden. Wir haben aber auch in zwei Fällen mal Redakteure angeschrieben und – da sind wir auch stolz drauf – haben geschafft, dass die die Symbolbilder in ihren Artikeln geändert haben.

Oh, cool!

Das ist natürlich toll. Und als Soziologen kritisieren wir natürlich immer gerne, aber viel schwieriger ist, Alternativen zu benennen. Das fällt uns immer noch schwer. Wir hatten einen Kollegen, der eine Ausstellung und ein Kunstobjekt dazu plant, wie man Robotik anders und besser bebildern kann. Das liegt Corona-bedingt gerade etwas auf Eis. Die nächste Stufe wäre aber natürlich, darüber nachzudenken, welche Bilder wir schaffen können, die der Technologie und der tatsächlichen Richtung der Technologie gerechter werden.

An der Stelle grätsche ich mal rein. Als Robotikingenieur müsste ich selbst es ja dann eigentlich besser machen können. Das bezieht sich sowohl auf botzeit, natürlich, als auch auf den Wikipedia-Artikel ‚Robotik‚, guck Dir den mal schnell an. Das dortige Titelbild, die Shadow-Hand oben rechts im Artikel, habe ich dort vor Jahren mal reingesetzt. Was hältst Du davon?

Naja, die Abbildung zeigt zumindest schon einmal einen technologischen Stand der Dinge, sie zeigt zumindest mal Aktuatoren und Muskeln. Ich bin mir allerdings nicht sicher, ob die Hand in ihrer Bewegung die Glühbirne tatsächlich greifen könnte. Ich wage, das zu bezweifeln.

Demnach wäre das also auch wieder eine Abbildung, die den Stand der Robotik nicht korrekt und nicht übermäßig realistisch darstellt?

Ich finde das Bild tatsächlich nicht so schlimm. Man sieht schon eine Arbeit am biologischen Menschen und sie sieht sehr filigran aus. Aber mit einer menschlichen Hand zu greifen ist natürlich schon etwas, worüber die Robotik im Moment tatsächlich redet und reden muss. Man sieht hier auch immerhin eine relativ offene Technik an der Hand und sie wirkt immerhin noch sehr technologisch. Ich finde das Bild nicht so schlimm an der Stelle.

Okay, dann bin ich beruhigt.

Das ist jetzt ein sehr guter Bogen zu meiner eigentlichen Kernfrage, die Auslöser für dieses Interview mit Dir ist. Mit NotMyRobots legt Ihr ja den Finger in die Wunde der Journalisten und Redaktionen, die diese falschen Symbolbilder nutzen. In dem Artikel, den ich gerade für botzeit vorbereite, geht es aber darum, dass ich finde, dass das Problem in großen Teilen aber auch ein hausgemachtes ist. Dass also die Robotikwissenschaft dieses Zerrbild auch selbst mit verursacht und befeuert. Siehst Du das auch so?

Vielleicht liegt es daran, dass unser Robotiklabor in diesem Bezug relativ woke ist und regelmäßig sogar explizit Sachen abgebrochen worden sind, wenn der Eindruck entstand, dass der Roboter etwas kann, was er tatsächlich aber nicht kann. Das wird aber wahrscheinlich bei uns so gemacht, weil es an ganz vielen anderen Stellen nicht gemacht wird.

In der Robotik selber ist mir das Problem nicht so sehr untergekommen. Vielleicht bin ich da selber blind, deswegen bin ich sehr gespannt auf Deinen Artikel. In der Robotik, an der ich direkt beteiligt war wurde darauf geachtet, dass viel kommuniziert wird, was getan wird. Es wird ja auch oft ein Video zu den Veröffentlichungen beigelegt, in dem versucht wird, ganz klar zu machen, was getan wird. Ich hab dann auch gelernt, dass es in Videos Zeichen, an denen man erkennen kann, ob das Video manipuliert wird oder nicht. Also klassischerweise zum Beispiel eine Person im Hintergrund des Videos, an der sich gut sehen lässt, ob das Video vorgespult wird oder unterbrochen wurde.

Wo es aber meines Erachtens ganz klar auftaucht ist in der Mensch-Roboter-Interaktion als Disziplin und da ist auch unser Lab dann etwas schuldig. Da werden ganz viele der Experimente in der Wizard-of-Oz-Variante durchgeführt. Wizard-of-Oz ist nunmal, wenn man so will, fake. Wenn ich Dialoge eintippe, wenn ich Bewegungen steuere, dann kaschiert das natürlich den tatsächlichen Stand der Technik und ist ein Euphemismus dafür, was man tatsächlich kann.

Ich hab das kürzlich auch bei der langen Nacht der Wissenschaft gesehen. Da werden Übergaben zwischen Roboter und Mensch gemacht und behauptet, der Roboter würde das erkennen können. Es wird sogar was über die Sensoren erzählt. In Wirklichkeit sitzt aber im Nebenraum der Operator und steuert den Roboter über eine Kamera. Das ist natürlich schlechte wissenschaftliche Praxis.

Das liegt aber genau an der falschen Erwartungshaltung und daran, dass der aktuelle Stand der Robotik häufig zu unspektakulär ist. Die Dinge, die aus Ingenieurssicht interessant sind, sind von der Außenperspektive häufig einfach nicht besonders sichtbar oder spektakulär. Wenn man beeindrucken will oder Fördergelder haben will, nötigt das einen manchmal dazu, solche Kompromisse in der Darstellung einzugehen.

Aus meiner Wahrnehmung gibt es da aber eine gewisse Differenz zwischen populär-wissenschaftlicher Aufarbeitung, die ganz fürchterlich ist und semi-wissenschaftlicher Aufarbeitung, die etwas weniger fürchterlich ist. Ich hab aber selten in der Robotik wirklich wissenschaftliches Fehlverhalten unter Kollegen erlebt.

Finde ich gut, dass Du das so positiv siehst. Ich glaube, ich bin da nicht ganz so positiv. Was ich nämlich dazu zählen würde – das ist vielleicht kein Betrug, aber Beschönigung mindestens – sind viele Videos der Robotik. Ich versuche eine Sache 50 Mal und lade dann das eine erfolgreiche Mal auf YouTube hoch. Darüber spreche ich dann und schreibe darüber vielleicht sogar noch eine wissenschaftliche Veröffentlichung. Das begegnet uns glaube ich auch in der Robotikwissenschaft und ist für mich eine ähnliche Praxis.

Ja. Das finde ich wahnsinnig spannend, denn darüber schreibe ich tatsächlich in meiner Dissertation. Das wird wahrscheinlich mein Projekt für die Zukunft werden: die epistemische Frage – da kommt jetzt wieder der Soziologe, sorry – wie wissenschaftliche Evidenz in Disziplinen erzeugt wird, die an der Schnittstelle zwischen Science und Engineering stehen. Das ist glaube ich wissenschafts-theoretisch noch nicht gut beschrieben. Das wahnsinnig Interessante in der Robotik für einen Soziologen ist ja, dass man während der Forschung den Gegenstand seiner eigenen Forschung erst kreiert.

Oh, ja stimmt. Interessant!

Das ist etwas, das absolut unüblich ist in den meisten wissenschaftlichen Disziplinen. Es gibt natürlich ähnliche Beispiele: Wissenschaftler, die das Elektronenmikroskop bauen, aus der Notwendigkeit heraus, Ihre Forschung an Atomen zu machen. Dort hat aber ganz klar der gebaute Gegenstand Instrument-Charakter.

Der Roboter, den wir bauen, ist aber ja mehr als ein Instrument für weitere Forschung. Deswegen ist es eben wahnsinnig interessant, wie dort Evidenzen kreiert werden. Da sehe ich das Video auch ganz klar als neues Medium und so kenne ich das aus keiner anderen Wissenschaft. Man sieht häufig bei Robotik-Papern, dass auf der Homepage der Link zum IEEE-Paper zu finden ist, das mein YouTube-Video verlinkt. In dem Video lasse ich meinen Roboter dreimal fahren, vielleicht kann man auch noch die Kurven der Bewegung sehen. Das ist wahnsinnig interessant, weil es eine neue Art und Weise ist, Evidenzen zu schaffen und Wissenschaft zu kommunizieren. Da ist natürlich genau dieser Effekt interessant, dass einmaliges Funktionieren häufig als eine Art Proof of Concept ausreicht. Das widerspricht in eigentlich allen anderen Wissenschaften dem Prinzip der wissenschaftlichen Wiederholbarkeit. Das liegt aber natürlich auch daran, dass das Setup der Experimente häufig von einer derart hohen Komplexität ist, dass das einmalige Funktionieren in einer nachweisbaren Form – und das ist zum Beispiel das Video – reicht, um Proof of Conept zu sein.

Ich bin mir noch nicht sicher, ob es schlicht nicht-wissenschaftlich ist oder ob es wissenschaftliches Fehlverhalten ist oder ob es einfach dem Stand der Robotik als Wissenschaft geschuldet ist.

Ich muss zur Ehrenrettung der Robotik anmerken, dass mittlerweile einige Journals und Konferenzen dieses Problem auch erkannt haben. Deswegen wird immer mehr gefordert, auch eine gewisse Reproduzierbarkeit der Experimente zu ermöglichen. Zum Beispiel indem ich die Software ausliefern muss oder die gesamte ROS-Installation als virtuelle Maschine mitliefern muss. Das ist aufgrund der von Dir genannten Komplexität natürlich immer noch ein Problem. Es kann sich zum Beispiel nicht jeder den Roboter kaufen, um die Experimente zu reproduzieren. Zum Teil sind die Systeme auch einfach so komplex, dass es nicht mit vertretbarem Aufwand möglich ist. Aber dieses Problem wird glaube ich immer mehr gesehen und daran wird gearbeitet. Zum Beispiel mit Robotik-Wettkämpfen, in dem man das dann live zeigen muss, das ist dann ja auch wieder Dein Thema.

Das ist tatsächlich eines meiner Kapitel, ja: der Wettkampf und die Live-Demonstration als Experiment-Status. Da schlagen wir dann auch wieder den Bogen zu NotMyRobots und der Öffentlichkeit. Wenn wir nämlich öffentliche Live-Demos vom Status der Robotik haben, ist das natürlich extrem nützlich zur Kommunikation. Das ist etwas, das zurückgeht auf sehr alte Formen der Technikdemonstration, die wir im 19. Jahrhundert und Anfang des 20. Jahrhunderts hatten. Zum Beispiel Lindberg, der vor den Augen der Pariser Öffentlichkeit demonstriert hat, was sein Flugzeug kann. Auch da verstehen natürlich nicht alle das Flugzeug als wahnsinnig komplexes System. Ähnlich ist das in der Robotik. Wir haben dort einen wahnsinnigen Haufen an Disziplinen. Selbst die Leute, die letztendlich das Verhalten implementieren, können nicht das gesamte System verstehen.

Diese Art von Demonstrationen in der Robotik sehe ich zum Beispiel beim RoboCup. Wenn ich da hin gehe und die Roboter Fußballspielen sehe, dient das natürlich auch dem Zweck, zu sehen: diese Roboter sind keine Terminatoren. Wahrscheinlich sind deswegen die Naos auch viel beliebter als die Roboter der Middle Size League. Gerade die Naos zeigen gut den Stand der Technik und wie viel Arbeit es ist, etwas für den Menschen so triviales zu machen wie einen Ball zu finden, ein Tor zu finden, und den Ball dann ins Tor zu schießen. Solche Dinge kann man beim RoboCup erleben. Damit sind diese Veranstaltungen gut geeignet, um eine Verbindung zwischen wissenschaftlich Interessierten und der Robotik herzustellen.

Für mich als Robotiker sind diese Videos vom RoboCup oftmals furchtbar frustrierend. Wenn man vom RoboCup@Home zum Beispiel das x-te Mal sieht, wie eine fahrende Tonne ganz langsam an einen Tisch heran fährt, um eine einzelne Cola-Dose zu greifen, dann frustriert mich das ungemein und ich denke: irgendwie bleibt die Robotik seit Jahren stehen. Aber aus Sicht der Wissenschaftskommunikation ist das natürlich genau richtig, um ein realistischeres Bild zu vermitteln. Diese Szenen zeigen, dass selbst scheinbar trivialen Aufgaben, die von einem Menschen mit geschlossenen Augen nebenbei erledigt werden können, unglaublich komplex sind. Und da stehen wir eben noch in der Robotik: selbst in einer strukturierten Umgebung einfache Aufgaben zu erfüllen ist immer noch knüppelhart.

So, wir haben jetzt doch ganz schön große Bögen geschlagen in diesem Interview. Ich habe jetzt noch zwei, drei Fragen zum Schluss, die sich nicht perfekt anschließen.

Genau so sollte das sein mit den letzten Fragen eines Interviews.

Dieses Problem, das ihr mit NotMyRobots aufzeigt, falsche Symbolbilder, hat ja nicht nur die Robotik. Man denke zum Beispiel an die klassischen Symbolbilder von Hackern in Hoodies. Wahrscheinlich gilt das in ähnlicher Form für fast alle Disziplinen. Wenn man sich auskennt und darin arbeiten, dann schlägt man wahrscheinlich auch da die Hände über dem Kopf zusammen. Müsste es neben NotMyRobots also auch NotMyHacker und NotMyX… geben?

Ich glaube, bei NotMyHacker gibt es so etwas schon, also Leute, die den klassischen Kaputzenpulli-Hacker ironisieren und darstellen. Aus meiner Perspektive kenne ich aber zum Beispiel keine Bilder, die die Soziologie darstellen. Vielleicht sind wir einfach auch weniger in derartigen Artikeln vertreten.

Da ist noch etwas, das wir auch in der Robotik machen könnten ist. Wenn zum Beispiel Armin Nassehi in der FAZ interviewt wird, dann ist ein Bild von Armin Nassehi abgebildet, und kein Symbolbild wie in der Robotik. Das wäre vielleicht auch in der Robotik nicht verkehrt, dass die Gesichter hinter der Technik gezeigt werden, die gerade dargestellt wird. Ich denke, dass BiologInnen in ihren Artikeln ähnliches finden.

Ich glaube aber, dass dieser merkwürdige Science-Fiction-Realismus in der Robotik das größere Problem hat, weil die Robotik seit jeher mit Science Fiction assoziiert ist. Wenn man über Roboter und Robotik redet, dauert es häufig keine drei Sätze bis jemand Asimov erwähnt – das Godwin’s Law der Robotik sozusagen. Das heißt, die Science-Fiction-Elemente sind in der Robotik viel deutlicher als in anderen Wissenschaften. Das ist diese Merkwürdigkeit von Fantasie und sehr konkreter Darstellung, die die Robotik einzigartig macht. Ich glaube, in keiner anderen Disziplin existiert dieses Bild so stark. Wenn wir humanoide Roboter sehen, dann haben wir eine Vorstellung davon, die pop-kulturell geprägt ist. Humanoide sind sehr präsent in unserer pop-kulturellen Fantasie und in unserem pop-kulturellen Gedächtnis. Zumindest in einem westlichen Kontext sind die glaube ich viel stärker als in anderen Disziplinen. Wenn man Stock Photos googelt – und das werde ich als Experiment nachher wahrscheinlich mal ausprobieren – ist wahrscheinlich Robotik diejenige Disziplin, bei der die meisten fürchterlichen Stock Photos gefunden werden.

Das kann gut sein.

Dann schließe ich mal ab mit einer Frage, die Du schon zwei, drei Mal angeschnitten hast. Was sollte ich als Blogger, Journalist, Redakteur denn in Zukunft besser machen oder beachten?

Es sollte sozusagen einen Giftschrank geben von grafischen Robotikvisualisierungen, die nicht mehr benutzt werden. Also zum Beispiel Terminator und HAL. Die fliegen raus! Die werden einfach nicht mehr benutzt, es sei denn, es geht im Text tatsächlich um den Terminator oder HAL. Außerdem alles, was stark geschlechtlich ist und – das ist glaube ich mit das Fürchterlichste – dieser weiße Roboter, bei dem auch diese merkwürdige Reinheit/Weißheit (sic!) vorkommt. Die fliegen auch alle raus! Das ist glaube ich das beliebteste Stock Photo und der Designer ist wahrscheinlich mit seinem White Robot Guy ziemlich reich geworden, wenn die Bilder nicht piratisiert werden. Der kommt auch weg!

Wenn wir AI illustrieren, dann muss klar werden, AI ist nicht ein nachdenkender Roboter. Generell sollten AI-Artikel nicht mit Robotern bebildert werden, es sei denn die künstliche Intelligenz ist tatsächlich in robotischen Systemen verkörpert.

Ich würde raten, Bilder von den robotischen Systemen zu verwenden, über die man schreibt. Die haben nämlich meistens Bilder. Wir haben es irgendwann so gemacht, dass wir unserer Presseabteilung gesagt haben, dass sie bei uns im Lab vorbei kommen sollen, wenn sie Bilder haben wollen. Die haben dann Bilder von den tatsächlichen Robotern gemacht. Die stellen dann häufig trotzdem noch Dinge dar, die sie nicht wirklich können. Aber immerhin ist es ein existierender Roboter mit dem tatsächlich die Forschung gemacht wird, über die geschrieben wird.

Wenn die Teaser der Artikel schön aussehen sollen, gibt es auch jede Menge Bilder, die abstrakt sind. Roboter in Form von abstrakter Kunst finde ich weniger schlimm als die Bilder, die konkrete aber falsche Visualisierungen zeigen.

Abschließend würde ich sagen, ein Artikel zur AI braucht kein Roboterbild, und ein Roboter muss nicht immer ein Humanoider sein. Viel wäre schon geholfen, wenn Robotik als Technik gezeigt wird. Deswegen finde ich Deine Abbildung in der Wikipedia auch nicht so schlimm. Wenn keine Verblendungen da sind, sondern wenn Aktuatoren gezeigt werden, wenn Mechanismen gezeigt werden, wenn die technische Entität von Robotik wieder da ist, ist das glaube ich schon sehr hilfreich

Okay, Arne. Dann an dieser Stelle vielen Dank. Wir haben jetzt fast eine Stunde geredet. Das hätte ich im Vorfeld gar nicht gedacht, aber wir haben auch über viele Aspekte geredet, die ich nicht erwartet hatte. Nicht nur Sexismus in der Robotik, sondern sogar auch noch Andeutungen von Rassismus in der Robotik.

Ja, ich glaube gerade dieser weiße Roboter ist aus dieser Perspektive absolut nicht harmlos.

Aber das kommt natürlich davon, wenn man mit SozialwissenschaftlerInnen redet. Das sind die Themen, über die wir dauernd reden und das ist auch irgendwie unsere Hausaufgabe. Das machen wir natürlich auch, um unsere eigene wissenschaftliche Legitimität in die Form unserer Kritik einzubringen.

Ich bin daher sehr gespannt und aus wissenschaftlicher Perspektive sehr interessiert, das auch nochmal aus der robotischen Perspektive zu lesen. Ich warte also gespannt auf Deinen Artikel.

Der Beitrag NotMyRobots – Interview mit Arne Maibaum erschien zuerst auf botzeit.

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

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

Der Beitrag DRC Wettkampftage erschien zuerst auf botzeit.

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 erst­malig in Betrieb genommen. Als ich im Januar in Genua ankam, steckten die extern gefer­tig­ten Teile noch in der Zoll­ab­fer­tigung fest…

Als schließlich alle Teile im Institut ange­kom­men waren, wurde der Roboter binnen zwei Wochen zusammen­ge­baut und in Betrieb genommen. Zu diesem Zeit­punkt blieb uns für die Fertig­stel­lung der Quali­fi­ka­tions­videos für die DRC Finals dann noch ein knapper Monat Zeit.

Auch nach der Quali­fi­ka­tion blieb nicht viel Zeit zum Durch­atmen. Während der Qualifika­tions­experi­men­te hatten sich ein paar Tücken sowohl in der Hardware, wie auch in der Soft­ware offenbart. Alles andere wäre vermut­lich auch sehr über­raschend gewesen…

Am vergangenen Samstag sind wir schließlich hier in Pomona nahe Los Angeles ange­kom­men und berei­ten uns seither auf den Wett­kampf vor.

Eine Art Tagebuch

Sonntag: Registrierung, Begrüßung und Instruktionen

Der Sonntag Vormittag dient im Wesent­lichen der Orientie­rung hier vor Ort. Es ist das einzige Zeit­fenster, in dem wir einen kurzen Blick auf die Gegend um Los Angeles erhaschen und einige wenige Sehens­würdig­keiten besuchen können. Nach der Registrie­rung am Nach­mit­tag findet dann die offizielle Be­grüßung und Auftakt­ver­anstal­tung statt. Ein kurzer Überblick über die Daten und Fakten zum Event: es sind etwa 600 Team-Mitglieder angereist, betreut wird die Veranstal­tung von 300 frei­wil­ligen DARPA-Mitarbei­tern. Zahlreiche inter­nationa­le Pres­se­vertre­ter haben sich ange­kü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 Werk­statt, den Roboter und eine kleine Trainings­umgebung aufbauen.

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

Für die meisten endet dieser erste Tag etwa um Mit­ter­nacht mit dem Rückweg zum Hotel.

Dienstag: Modultest

Um 09:00 Uhr geht es für mich weiter. An diesem Tag steht Loko­motion im Forder­­grund. Wir sind unsicher, wie Walkman mit dem un­ebenen Wett­kampf­gelände und vorhandenen Stei­gungen zurecht kommen wird. Ent­sprechend werden nach dem Transport einige Modell­para­me­ter überprüft und re­kali­briert sowie Regler­einstel­lungen verfeinert.

Am Nach­mit­tag können wir erstmalig den Roboter in eines der von der DARPA für den Wett­kampf zur Verfügung gestellten Autos setzen und unsere Fahrzeug­modi­fi­ka­tionen für diese Aufgabe testen.

Anschließend haben sowohl Roboter als auchTeam einen offi­ziel­len Foto­termin.

Am Abend geht es weiter mit Lokomotion. Eine Holz­platte und ein paar Balken dienen dienen als Test­platt­form. Wir testen das Stehen, Laufen und Drehen auf der Stelle auf der hölzer­nen Ebene mit bis zu 8° Grad Neigung. Der Roboter meistert die Tests und wir beenden unsere Arbeit sehr zufrie­den um 03:00 Uhr am Morgen. Wir werden von den Jungs abgelöst, die nun das Auto­fahren testen werden. Die Kollegen vom IHMC haben uns freund­licher­weise zu diesem Zweck bis 11:00 Uhr ihren Polaris Ranger überlassen. Mille mille grazie dafür!

Mittwoch: Manipulation Day Öffnen und Durch­schreiten der Tür, Ventil-Aufgabe

Heute steht Manipulation auf der Tages­ordnung. Im speziellen das Öffnen und Durch­schreiten einer Tür, sowie das Drehen eines Industrie­ventils. Bei den Arbeiten bereitet uns das linke Knie­gelenk Probleme. Einer der Magnet­encoder versagt den Dienst. Am Morgen war bereits ein Fehler in der Leistungs­elektronik auf­ge­tre­ten. 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 Aus­fall festzustellen…

Die Atmosphäre in der Garage:

Insgesamt ist die Atmosphäre sehr angenehm. Insbesondere das Mit­einander mit den übrigen Teams empfinde ich als sehr angenehm. Die Halle hier ist voll von Menschen, die mit großer Be­geisterung an ihren Robotern arbeiten. Bis auf ein einzi­ges Team hängt in jeder Garage ein grünes Schild, dass die Aufnahme von Fotos und Videos ausdrücklich erlaubt. Die Wissen­schaftler und Techniker laufen von Garage zu Garage und informieren sich wiss­begie­rig über die Kon­struk­tion, 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:

Insgesamt gehen alle Teams sehr hilfs­bereit mitein­ander um. Man leiht sich gegen­seitig Ersatz­teile und Werk­zeug. Gegen Abend zeigt sich dann, welche Teams schon lange dabei sind und ent­sprechend eine aus­ge­reifte Hard- und Software vor­weisen können. Diese Teams verlassen ihre Garage am Abend und genießen ein wenig Frei­zeit. Andere Teams, die noch jung im Rennen sind und meist ihre Roboter voll­ständig selbst gebaut haben, bleiben bis in die Nacht hinein. Viele arbeiten im Schicht­betrieb – so wie wir.

Turniamo a’lavoro!

Der Beitrag Ein paar Eindrücke von den DRC Finals erschien zuerst auf botzeit.

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:

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.

Der Beitrag Alles Fake – Ein trauriger Monat für die Robotik erschien zuerst auf botzeit.

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.

Der Beitrag Elastische Roboterarmkörper: Fluch oder Segen? (Teil 2) erschien zuerst auf botzeit.

Zumindest in Industrie­szenarien ist das keine allzu weit entfernte Zukunfts­vision mehr. Flexibel anpassbare Roboter, die autonom oder Hand in Hand mit dem Menschen in einer Werkstatt oder Produktions­strasse arbeiten und diesen bei Fertigungs­auf­gaben unterstützen, sind schon seit geraumer Zeit ein strate­gisches Anliegen europäischer Wissenschaftler und der Robotik­industrie. 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 Kern­an­wen­dungs­sze­na­rien zukünf­tiger Industrie­robotik mit auf. Dabei geht es nicht um Groß­serien-Voll­auto­matisie­rung wie man sie z. B. aus der Auto­mobil­industrie kennt, in der Roboter an Roboter aufgereiht in Käfigen und – aus Sicher­heits­gründen – abge­schot­tet vom Menschen monatelang exakt die gleiche Aufgabe ausführen:

Es geht vielmehr um die Unter­stützung von Mitarbei­tern in kleinen und mittel­stän­dischen Unter­nehmen, deren Auftrags­lage sich relativ schnell ändern kann. Denkbar ist die Fertigung von Proto­typen, von denen häufig nur geringe, einstel­lige Stück­zahlen gefertigt werden. In diesem Kontext sind zur Zeit Hand­arbeits­plä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 anstren­gender körper­licher Arbeit.

Eine Voll­automatisie­rung im klas­si­schen Sinne, also mit Robotern, die genau auf diesen einen Zweck ausgelegt sind und in aller Regel nicht oder nur sehr aufwendig an neue Fer­ti­gungs­auf­ga­ben angepasst werden können, macht hier allein schon aus ökonomischen Gründen keinen Sinn. Der durch die Einsparung einer Fachkraft gewonnene finan­zielle Vorteil wird sofort wieder zu­nichte gemacht durch den not­wen­digen, häufigen und kosten­inten­siven Einsatz von Experten, die den Roboter bei jeder Änderung im Pro­duk­tions­ablauf wieder an seine neue Aufgabe anpassen und um­program­mieren müssen. Zusätzlich sind viele Teil­aufgaben in solchen Fertigungs­prozessen sehr komplex und wenn überhaupt nur mit enorm hohem technischen Aufwand automatisch zu bewerk­stel­ligen, 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 Finger­fertig­keiten kompetenter und schneller durchführen kann als jede Maschine, ihn aber durch den Roboter­assisten­ten von körperlich belas­ten­den Arbeiten zu befreien … der Roboter als dritte Hand. Damit jedoch beide, Roboter und Mensch, an einem Arbeits­platz gemeinsam sinnvoll zusam­men­arbeiten können, sind einige Heraus­forderun­gen 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) Arbeits­räumen mit dem Menschen zusammen zu arbeiten, ist im Vergleich zu her­kömmlichen Industrie­robotern zusätzliche Flexi­bi­li­tät nötig. Diese erhält man z. B. durch zusätzliche Bewegungs­achsen: übliche Industrie­roboter verfügen über bis zu sechs Achsen, ab sieben Achsen erhält man durch Redundanz zusätzliche Flexi­bi­lität.

Technisch gesehen scheinen obige Herausforderungen so gut wie gelöst. Der vom Deutschen Luft- und Raumfahrtszentrum und KUKA gemeinsam entwickelten Leicht­bau­roboter IV (LBR IV), dessen serien­reifer Nachfolger KUKA LBR iiwa auf der diesjährigen Hannover Messe erstmals vorgestellt wurde, ist ein Beispiel. Das geringe Gewicht, Kraft­sensoren zur Kollisions­erkennung und eine sehr schnelle Regelung sind gute Voraus­setzun­gen für eine sichere Interaktion mit dem Menschen. Außerdem ist der LBR mit seinen sieben Bewegungs­achsen redundant, bietet also genügend Flexi­bi­li­tät, um um Hinder­nisse herum­zu­greifen oder Aufgaben auf mehr als nur eine Art zu erledigen.

Dass trotzdem nun nicht jeder sofort einem solchen Roboter Aufgaben bei­bringen kann, sieht man im folgenden Video, welches im Verlaufe einer umfang­reichen Feld­studie ¹ mit Mit­arbei­tern der Firma Harting entstand:

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ährend­dessen natürlich jede Kollision sowohl vorne am Greifer als auch am Rest des Roboter­körpers mit den Umgebungs­objekten 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 Inter­aktion ent­stan­denen Bewe­gun­gen werden auf­gezeich­net 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 Versuchs­personen scheinen (trotz einer vorherigen Eingewöhungs­phase mit dem Roboter) überfordert von der Aufgabe, dem LBR den Parcours kollisions­frei bei­zu­bringen. Das liegt nicht an der Komplexität der Aufgabe: Eine einfache vorgegebene drei­dimensionale Bewegung wie die des Parcours aus der Studie nachzufahren, ist für uns Menschen typischer­weise 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 Ingenieurs­kunst 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 drei­dimensio­nale Bewegung beizubringen und dabei gleichzeitig darauf achten zu müssen, dass er mit seinen sieben Achsen nicht mit Hinder­nissen im Arbeits­raum 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 tech­nischen Möglichkeiten zu schaffen. Der Schlüssel, davon sind wir überzeugt, liegt in einer syste­ma­tischen Inte­gration von Hoch­techno­logie, maschi­nel­lem Lernen und einfacher Inter­aktion. Um ein solches Robotik­system für den Arbeiter vor Ort bedienbar zu machen, muss die eigent­liche techno­lo­gische Komplexi­tät im besten Fall hinter intuitiven Benutzer­schnitt­stellen und schritt­weiser Inter­aktion versteckt werden. Am Forschungsinstitut für Kognition und Robotik (CoR-Lab) der Univer­sität Biele­feld beschäftigen wir uns seit Jahren genau damit. Das Roboter­system, das oben im Video zu sehen war und auf einem KUKA LBR IV aufbaut, ist unsere Forschungs­plattform FlexIRob: ein Beispiel­szenario, 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 Teil­schritte zu unter­teilen. Dass das funktioniert, ist im folgenden Video zu sehen:

Der erste Teil­schritt der Aufgabe heißt Konfigurations­phase und ist unabhängig von der Aufgabe, die der Roboter­arm später ausführen soll. In dieser Phase bringt der Nutzer bzw. der Mit­arbeiter dem Roboter seine neue Umgebung bei, d. h. eventuelle dauerhafte Hindernisse, welche in seinem Arbeits­bereich platziert sind, wie z. B. herum­liegende Objekte, Säulen oder Regale. Als Mensch hat er dabei ein intuitives Verständnis der Szenerie: Er sieht die Hinder­nisse, er weiß, dass und wie man um sie herumgreifen muss und ist deswegen instinktiv in der Lage, den LBR dabei in aus­gesuchte Regionen zu führen und dort mit ihm zusammen einige Beispiel­bewegungen durch­zu­führen, ohne mit den Hinder­nissen zu kollidieren. Von diesen Beispiel­bewegungen kann nun der Roboterarm lernen, wie er sich in seinem Arbeits­bereich zu bewegen und wie er die Hinder­nisse im Zweifel zu umgreifen hat. Die Methoden zum Lernen, die dabei verwendet werden, gehen über simples Aufnehmen und Re­pro­du­zieren hinaus. Mit Hilfe von künst­lichen neuro­nalen Netzen ist das System nämlich nicht nur in der Lage sich innerhalb der trainier­ten Bereiche zu bewegen, sondern auch zwischen diesen hin- und her zu manö­vrieren und kollisions­freie Bewegungen für den Arm zu wählen. Diese Eigenschaft von Lern­verfahren nennt man Genera­lisierungs­fähigkeit und beschreibt die Fähigkeit, von wenigen Beispiel­daten ein generel­les Verhalten zu erlernen und dieses auf unbekannte Daten zu übertragen. In unserem Fall sind die Beispiel­daten die Trainings­daten, 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 Ziel­positionen anzufahren, ohne dabei mit den Hinder­nissen zu kollidieren. Und das nicht nur in den Trainings­berei­chen, 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 verschie­denen 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 Hindernis­vermei­dung, wie in dem Video ab Minute 2:10 zu sehen ist. Diese Phase nennen wir deshalb Assisted Program­ming.

Der Knackpunkt zur Verein­fachung dieser Inter­aktion liegt also in der Auf­teilung der Gesamt­aufgabe in zwei oder mehr aufeinander aufbauende Teil­schritte, um den Nutzer bzw. Mitarbeiter des Roboters nicht zu überfordern. Im letzten Jahr haben wir mit Unter­stützung der Firma Harting oben genannte Pilot­studie zum Thema Kinesthetic Teaching durchgeführt und die beschriebene Idee evaluiert. Dabei haben 48 Mitarbeiter, unterteilt in zwei Versuchs­grup­pen, mit dem System inter­agiert und versucht, dem Roboter obigen Parcours beizubringen. Die Ergeb­nisse der einen Gruppe waren bereits im ersten Video zu sehen. Von 24 Versuchs­teil­nehmern, haben es gerade einmal zwei Probanden geschafft, den Parcours kollisions­frei abzufahren; eine Probandin brach ihren Versuch nach einiger Zeit frustriert ab. Die zweite Versuchs­gruppe hingegen benutzte den assistier­ten Modus und zeigte signi­fi­kant bessere Ergebnisse. Diese Teilnehmer benötigten im Schnitt weniger als die Hälfte der Zeit, um den Roboter anzulernen, die bei­gebrach­ten Bewegungen waren signifikant näher an der Vorgabe und wesent­lich ruckel­freier.

Unsere Experimente und Studien legen nahe, dass moderne Robotik­systeme durchaus über die Flexi­bi­li­tät verfügen, regelmäßig und vor Ort an wechselnde Aufgaben angepasst zu werden, wie es zum Beispiel für Klein­serien­ferti­gung oder Pro­to­typen­bau notwendig ist. Dazu reicht die rein technische Flexi­bi­li­tät allerdings nicht aus, denn sie erfordert immer noch lange Einarbei­tung und Robotik­exper­ten. Erst in der Kombi­nation mit lernenden Systemen und einfachen Inter­aktions­schnitt­stel­len spielen solche Systeme ihr volles Potential aus.

Der Beitrag Mensch und Roboter Hand in Hand erschien zuerst auf botzeit.

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.

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:

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.

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

Der Beitrag Ein Roboter-Rüssel lernt wie ein Baby erschien zuerst auf botzeit.

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.

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.

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:

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:

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.

Der Beitrag Elastische Roboterarmkörper – Fluch oder Segen? erschien zuerst auf botzeit.

Im April 2010 wurde der Bionische Handling-Assistent (BHA) von Festo auf der Hannover Messe der Öffent­lich­keit vorgestellt. In den fol­gen­den Mona­ten sah dieser bio­lo­gisch inspirierte Roboter­arm zu recht eine große Medien­präsenz und wurde mit zahl­reichen Prei­sen, unter anderem dem Deutschen Forschungspreis 2010, aus­ge­zeich­net. Im Februar 2011 bekamen wir dann unseren eigenen BHA, voller Vor­freude, denn wir wussten, dass niemand bislang mit dem BHA tun konnte, was wir mit ihm vor­hat­ten: ihn zu kon­trol­lieren. ¹

Die Struktur und Funk­tions­weise des BHA ist inspi­riert von einem Elefan­ten­rüs­sel, wie in fol­gen­der Ab­bildung un­schwer zu erken­nen ist. Der Arm wird im Sinne des Rapid Proto­typings im 3D-Drucker gedruckt. Als Material wird Polyamid ver­wen­det, wodurch der gesamte Arm leicht-gewich­tig und durch­gängig ver­form­bar wird: Im Wesent­lichen besteht der BHA also aus Plastik und einer Menge Luft. Bewegt wird der Arm von drei­zehn pneu­ma­ti­schen Ven­tilen, die die drei­zehn Kammern des Robo­ters mit Luft füllen oder ent­leeren. Dies wiederum verbiegt, beugt und streckt die kom­plet­te Struktur.

Festo hat mit dem BHA die Vision eines leichten, frei­beweg­lichen Dritte-Hand-Systems, das den Men­schen bei seiner Arbeit unter­stützen kann. Dank seiner struk­tu­rel­len Nach­giebig­keit (Compliance) ist der Arm im Kontakt mit Menschen und seiner Umgebung natur­gemäß sicher, was die Mög­lich­keiten von direkter Zu­sam­men­arbeit von Mensch und Roboter eröffnet. In in­dustriel­lem Kontext kann der BHA in Fertigungs­pro­zes­sen ein­ge­setzt werden, z.B. um mit empfind­lichen Gütern wie z.B. Lebens­mit­teln zu arbeiten.

Als wir uns ent­schlos­sen haben, Festos Bio­nischen Handling-Assisten­ten zu erwer­ben, wussten wir, dass wenige der klas­si­schen und bekannten Ver­fahren mit diesem Roboter funktio­nie­ren würden. Trotz­dem war über­raschend, dass der Roboter ohne jeg­liche Software aus­ge­lie­fert wurde.

Keine Software.

Nichts.

Noch bis vor einem Jahr konnten wir mit dem BHA nicht viel mehr tun, als von Hand die pneu­ma­ti­schen Ven­tile zu öffnen und zu schließen, um damit entweder vol­len Druck oder gar keinen Druck in die Kam­mern zu geben. Auch damit waren die Be­we­gun­gen des Robo­ters absolut fas­zi­nie­rend und wir hatten großen Spaß, aber ernst­hafte An­wen­dungen waren damit natür­lich noch nicht möglich. Wie von Festo zugesagt, bekamen wir dann vor fast genau einem Jahr elektro­nische Ventile, mit denen wir (mehr oder weniger präzise) den Druck in den Kammern auto­ma­tisch vor­geben konnten. Nicht mehr und nicht weniger: den Druck kon­trol­lie­ren.

Um es einmal vorsichtig zu sagen: Der Schritt von dieser Druck­re­ge­lung zu einer ernst­haften An­wendung mit dem BHA ist groß!

Das tat­säch­liche Werkzeug, dass man mit dem BHA kon­trol­lieren will, ist der so­ge­nan­nte Fin Gripper am Ende des Arms. Diesen Greifer zu al­ler­dings genau zu po­si­tio­nie­ren setzt zu­al­ler­erst voraus, die Postur des Arms prä­zise bestimmen zu können. Den Druck in den ein­zel­nen Kam­mern zu kennen, reicht dafür bei weitem nicht aus; dass dies zum Scheitern ver­ur­teilt sein würde, diese Er­fah­rung hatten wir bereits mir anderen Robo­tik­platt­for­men gemacht: Zehn Mal den gleichen Druck auf einen pneu­ma­ti­schen Roboter zu geben, ergibt im Regel­fall zehn ver­schie­dene Posturen des Robo­ters. Reibung, Reibung, Hyste­rese-Effekte und Nicht-Stationaritäten ver­ändern das Ergeb­nis von Mal zu Mal.

Um diesen Problemen zu begegnen, besitzt der BHA Längen­sen­soren (Kabel-Poten­tio­meter), um an der Außen­seite des Arms die Streckung der einzel­nen Kam­mern zu messen (siehe obige Abbildung). Natür­lich wollten wir diese Länge nicht nur kennen, sondern auch kontrol­lieren können. Das ist theore­tisch mit klas­si­scher (PID-)Regel­technik möglich, aber funktio­niert auf diese Weise nur sehr schlecht. Um dieses Ver­hal­ten zu verbes­sern, könnte man nun ver­suchen, all das Wissen über den BHA in eine aus­ge­feil­tere Regelungs­technik 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 geo­me­trischen Postur im Ruhe­punkt (im Equi­li­brium)

Jegliche Art von Dynamik (nicht nur der Pneu­ma­tik selbst, sondern auch des sehr viel lang­sa­me­ren Zusam­men­spiels zwischen der Pneu­matik und Geo­me­trie)

Welche Länge des Arms bzw. der einzelnen Kam­mern ist über­haupt mög­lich? Wo liegen die Gren­zen?

Und nicht zuletzt: Wie genau ist das Zusam­men­spiel der obigen Aspekte zwi­schen den einzel­nen Kam­mern. Denn: Es be­steht ein starker Zusam­men­hang!

Alles zusammen eine große Heraus­for­de­rung … aber nicht un­mög­lich. An­ge­nom­men also, die Länge des Aktu­a­tors lässt sich mes­sen und kontrol­lieren. Um nun die End­ef­fektor-Posi­tion (die Posi­tion des Greifers) zu kon­trol­lieren … muss man die aktu­el­le End­ef­fek­tor-Posi­tion kennen!

Die Endeffektor-Position anhand der Geo­metrie des Robo­ters und der Stel­lung der Aktua­toren zu er­rech­nen, nennt sich Vor­wärts-Kine­ma­tik und ist für handels­übliche Robo­ter kein großes Pro­blem, son­dern ein­fache Tri­go­no­metrie. Der BHA gehört allerdings zu einer anderen Klasse von Morpho­lo­gien, genannt Conti­nuum Kine­ma­tics (also in etwa: konti­nu­ier­liche Kine­ma­tik). Dank seiner mecha­ni­schen Flexi­bi­li­tät besitzt dieser Robo­ter­arm unend­lich viele Frei­heits­grade, da jeder Bereich des Robo­ters unter­schied­lich gebo­gen und ge­streckt sein kann. Unend­lich viele Frei­heits­grade kön­nen weder mit Sen­so­ren ge­mes­sen noch berech­net werden.

Als wir unsere Arbeit mit dem BHA be­gon­nen haben, planten wir nicht, die kom­pli­zier­te Kine­ma­tik des BHA zu simu­lie­ren. Da wir uns im Kontext des BHA haupt­säch­lich mit Maschi­nel­lem Ler­nen be­schäfti­gen, wollten wir die End­ef­fek­tor-Posi­tion schlicht messen, um sie be­nut­zen zu können (tun wir auch). Dass wir trotzdem eine Simu­la­tion benö­ti­gen würden, stellte sich heraus, als wir Schwierig­kei­ten in der Vi­suali­sie­rung bekamen. Wir wollten nämlich dar­stel­len, wie die räum­lichen Koor­di­na­ten mit den Be­we­gun­gen des BHA zu­sam­men­hän­gen.

Da Visualisierung Kenntnis der Kinematik voraus­setzt, began­nen wir, sie an­zu­nähern. Selbst wenn sich die Beugung und Streckung von unend­lich vielen Frei­heits­graden nicht berech­nen lässt, so lassen sich doch durch die Längen­senso­ren einige An­nah­men zur Beugung des Arms tref­fen. Die einfach­ste Art der Beugung ist eine kreis­förmige; im drei-dimen­sio­nalen Fall ent­spricht dies einem Torus:

Das Bild zeigt, wie sich ein Segment mit drei Aktua­toren (in der Ab­bil­dung als graue Röhren dar­ge­stellt) 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 kom­plexen Physik des Ver­for­mungs-Pro­blems. Ü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:

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

Der Beitrag Simulation des Bionischen Handling-Assistenten erschien zuerst auf botzeit.