Ein Beitrag in eigener Sache: Mitte Mai diesen Jahres – heute vor genau 3 Monaten – bin ich als Head of Engineering zu NEURA Robotics gewechselt. NEURA ist ein noch recht junges deutsches Robotik-Startup, das spätestens seit dem öffentlichkeitswirksamen Zugang von Till Reuter für mächtig Aufmerksamkeit sorgt … und noch weiter sorgen wird. Wohl aufgrund der hohen Dynamik und Geschwindigkeit im Unternehmen fühlt es sich mittlerweile tatsächlich schon nach mehr als 3 Monaten an.
Head of Software im Vordergrund, ich im Hintergrund, MAiRA dazwischen.
Als Head of Engineering hab ich dort Verantwortung über die Engineering-Departments, sowohl Software als auch Hardware (Mechanik, Elektronik, Mechatronik). Damit darf ich neue Entwicklungen koordinieren und unterstützen und überall dort mitmischen, wo es interessant ist. Meiner Meinung nach ist nämlich genau diese Wechselwirkung zwischen Software, Hardware und KI das, was Robotik so spannend macht und in der noch so viel Potential liegt.
KI ist dabei bei NEURA nämlich von Anfang an direkt mit und in den Roboter integriert. Neben der beeindruckenden Performance der Roboter-Hardware an sich ist NEURA Robotics nämlich stolz darauf, den ersten kommerziell verfügbaren kognitiven Roboter der Welt zu bauen. Kognitive Roboter sind dabei eine Roboterklasse, die erst von NEURA so richtig geschaffen wurde. Sie meint kollaborative Roboter, die über zusätzliche kognitive Fähigkeiten verfügen, um noch flexibler einsetzbar zu sein und natürlich(er) mit Menschen zu interagieren.
Neben der Head of Engineering-Stelle an sich hat mich genau der Teil überzeugt, den sicheren Schoß der Bosch Forschung zu verlassen. Seit meinem ersten Kontakt mit NEURA bin ich nämlich von der Tatsache fasziniert, jetzt die Art Roboter Wirklichkeit werden zu lassen, an denen ich schon zu meiner Promotionszeit – damals allerdings noch unter Laborbedingungen – geforscht habe und von denen wir uns damals ausgemalt haben, dass es sie vielleicht eines Tages auch außerhalb des Labors im kommerziellen Einsatz geben wird. Die Zukunft ist da!
Disclaimer: Der Autor dieses Beitrags ist Mitarbeiter der NEURA Robotics GmbH. Die Inhalte des Blogs vertreten ausschließlich Meinungen und Ansichten des Blog-Betreibers und sind nicht als Unternehmensmeinung zu verstehen. Der offizieller Blog von NEURA findet sich hier.
Mitte Mai habe mich mit Andreas Bihlmaier unterhalten, mittlerweile Chief Software Architect bei ABB. Ich kenne Andreas schon länger und er schreibt aktuell an dem Buch „Robotics for Software Engineers“, von dem man schon erste Leseproben und Kapitel lesen kann.
Worum es in dem Buch geht und wie es dazu kam, habe ich mit ihm besprochen.
Andreas Bihlmaier, Chief Software Architect bei ABB
Ich: Andreas, woher und wie lange kennen wir uns eigentlich?
Andreas Bihlmaier: Wir sind uns glaube ich im ERF-Universum (European Robotics Forum) immer wieder über den Weg gelaufen. Das Thema Software Engineering for Robotics liegt mir ja schon länger sehr am Herzen und da warst Du ja schon deutlich aktiver als ich, z.B. in der Topicgroup. Ich glaube, das waren die ersten Überschneidungen. Vermutlich haben wir uns auch 2014 auf de SIMPAR in Bergamo in Italien gesehen.
Das stimmt! Da haben wir uns bestimmt gesehen, da war ich auf jeden Fall auch für den DSLRob-Workshop.
Genau! Beziehungsweise ganz am Anfang war ich noch am Lehrstuhl. Dann habe ich noch einen kleinen Abstecher zu Google Research gemacht, Ende 2015 meine Dissertation fertig geschrieben und dann im April 2016 robodev gründet. Unter der Flagge war ich dann seither auf den ERFs unterwegs.
Unser gemeinsames Thema war allerdings immer schon Softwareengineering und Robotik, darum dreht sich ja auch in diesem Gespräch. Da ist noch viel zu tun und da ist das letzte Wort definitiv auch noch nicht gesprochen.
Aber Du hast ein Wort gesprochen! Du hast ja nämlich ein Buch darüber geschrieben: Robotics for Software Engineers. Darauf bin ich via LinkedIn aufmerksam geworden, habe die schon verfügbaren Kapitel gelesen und darüber möchte ich heute mit Dir sprechen. Kannst Du für all diejenigen, die das Buch noch nicht gelesen haben kurz zusammenfassen, worum es geht?
Inhaltsverzeichnis zum Zeitpunkt des Interviews, mit den ersten 4 Kapiteln schon online verfügbar (mittlerweile sind es schon mehr).
Ja, gerne! Das Buch kam dadurch zustande, dass mich jemand vom Manning-Verlag angeschrieben hat, ob ich eine Idee für ein Buch hätte. Meine erste Reaktion war: „Nein, das Schreiben der Dissertation hat mir genügt.“
Dann habe ich aber überlegt, was mir denn eigentlich noch fehlt. Es gibt ja schließlich schon zig Bücher über Robotik: das Springer Handbook of Robotics, Modern Robotics, Klassiker wie Probabilistic Robotics und A Modern Approach, Understanding Intelligence, etc. Wahnsinnig viele Robotikbücher, zum Teil sehr angewandt – wie programmiere ich Roboter mit ROS – zum Teil sehr akademisch oder forschungsorientiert; da übersteht man dann die ersten drei Seiten nicht ohne Lie-Gruppen und irgendwelche Exponential Maps. Und dann gibt es noch eine dritte Kategorie der Art „so bau ich mir einen Roboter“. Da geht es dann zu achtzig Prozent darum, wie ich einen DC-Motor anlöte und um den Mikrocontroller, um so ein bisschen Linien zu folgen. Und dann gibt es natürlich auch Bücher zum Programmierenlernen, die lediglich einen Roboter als Beispiel nutzen.
Das ist ja eigentlich wunderbar, aber irgendetwas fehlte mir. Nämlich ein Buch, das ich neu eingestellten Softwareentwickler:innen in die Hand drücken kann, die nicht per se Robotiker:innen sind. Das können Embedded-Software-Entwickler:innen sein, Cloud-Fullstack-Entwickler:innen, C++-Pogrammierer:innen und so weiter sein. Viel Softwareentwicklung für die Robotik ist ja nicht Hardcore-Regelungstechnik, oder Algorithmus-Engineering, sondern häufig ganz normales (embedded) Software Engineering. Ob ich das in Automotive mache oder für einen Roboter oder für eine Waschmaschine oder ein IoT device … ich brauche nicht immer extrem viel Domänenwissen.
Was mir immer gefehlt hat, ist ein Buch, das ich Personen in die Hand geben kann, die Software in einer einigermaßen modernen Sprache schreiben können – Python, C++, von mir aus auch Javascript – von Robotik aber noch nicht viel gehört haben – abseits vielleicht vom Terminator, Nummer 5 lebt!, und ein paar Boston-Dynamics-Videos. So fange ich dann bezogen auf die Robotik wirklich bei Adam und Eva an, aber ich muss nichts über grundlegende Programmstruktur erklären. So ein Buch habe ich tatsächlich nicht gefunden.
Aber die Robotik wächst ja auch als Feld. Es gibt ja sehr viele Bereiche um die Kernrobotik herum, sei es Serviceroboter, autonome Fahrzeuge, Drohnen, etc. Das ja ein breites Feld und es passiert extrem viel…
…und braucht entsprechend viele neue Softwareentwickler:innen.
Absolut! Und das ist die Zielgruppe.
Du hast erklärt, wie es zu der Kernidee und dem Titel des Buches gekommen ist und tatsächlich bin ich immer wieder über den Titel gestolpert. Irgendwie habe ich unbewusst immer wieder ein Buch zu „Softwareengineering in der Robotik“ erwartet, aber das ist es ja gerade nicht. Du willst ja stattdessen Softwareentwickler:innen und Programmierer:innen befähigen, zu verstehen, was eigentlich Softwareengineering für Roboter ausmacht und wie sie von Software in verwandten Disziplinen unterscheidet.
Genau! Es wird natürlich auch ein Kapitel dazu geben, worauf ich umgekehrt achten sollte, wenn ich Robotiksoftware schreiben will – im Sinne von Software Best Practices: welche Patterns sollte ich vielleicht nutzen oder wiedererkennen. Aber der Hauptteil ist wirklich wie du sagst: „ich bin schon Programmierer:in, jetzt möchte in der Robotik erfolgreich arbeiten können“.
Es ist also nicht das Buch, das ich Robotiker:innen gebe, die aus der Regelungstechnik kommen und Dynamikgleichungen ohne zu zögern an die Tafel schreiben, aber eben auch genauso ihren Code schreiben würden: also unwartbar und unverständlich.
Denn eigentlich ist ja Programmieren in der Robotik nicht so anders als in anderen Domänen: wenn ich ein Ziel habe, sammele ich mir die benötigten Softwarebibliotheken zusammen. Möchte ich einen Roboter bewegen, lade ich mir z.B. Bibliotheken herunter, die mir Kinematik machen. In diversen ROS-Büchern, z.B. Programming Robots with ROS von Quigley und Gerkey und Co. sehe ich aber, dass man als Robotik-Neuling dann mitunter ROS mit Robotik verwechselt. ROS ist so dominant, dass man dann z.B. denkt, der tf-Baum sei das fundamentale Konzept und nicht verteilte Koordinatensysteme oder wie ich diese repräsentiere. Das möchte ich anders handhaben und bringe erst einmal Grundlagen bei. Allerdings ohne Beweise und immer in der Robotik angewendet. Das ist natürlich ein schmaler Grat zwischen einfachen Kochrezepten und einem Buch über Mathematikgrundlagen.
Was ist denn Deiner Meinung nach der Vorteil davon, nicht tf zu lernen, sondern zu verstehen, warum verteilte Koordinatensystem in der Robotik so essentiell sind?
Ich denke, das ist eine grundlegende Herangehensweise: erst das Konzept, dann die Implementierung, nicht umgekehrt. Denn die Implementierung ist ja häufig willkürlich: warum ich mich für die eine konkrete Ausprägung der API entschieden habe und wie sich die Software genau sich verhält. Es ist also eher ein pädagogisches Grundkonzept, vor der spezifischen tf-API z.B. erst einmal zu verstehen, wie ich die Bewegung von Körpern im Raum relativ zueinander beschreiben kann.
Neben dem persönlichen Vorgeschmack für diesen Aufbau spricht aber auch die bessere Übertragbarkeit. Die großen Roboterhersteller – für einen davon arbeite ich ja seit einiger Zeit – haben ja ihre eigenen proprietären Robotik-Softwarestacks. Das heißt, wenn ich mich dann extrem gut mit ROS auskenne, aber das Konzept nicht verstanden habe, kann ich das schwer auf andere Implementierung übertragen und stehe auf verlorenem Posten. Ich glaube tatsächlich, dass es möglich ist, einen ROS Nav-Stack für mein mobilen Roboter aufzusetzen oder MoveIt zum Laufen zu bekommen ohne eigentlich Ahnung davon zu haben, was ich tue. Das ist aber natürlich kein robotik-spezifisches Problem…
… und erst einmal ja auch nicht schlimm, sondern auch eine Stärke von ROS, die wichtig für die Robotik war. Dadurch finden Leute einen Einstieg, die sich so irgendwann mal für Bücher wie Deines interessieren, aber ohne ROS erst einmal vor eine Wand gerannt wären – und vielleicht abgebrochen hätten.
Absolut! Ich werde auch nach den ersten paar Kapiteln, in denen ich noch gar keine Implementierung brauche, auf ROS 2 und Gazebo eingehen und Beispiele dann damit zeigen. Mit was denn auch sonst?! Ich konstruiere ja nicht extra irgendein Spielzeug-Robotikframework nur für ein Buch. Das hat dann vielleicht eine schöne und saubere API, aber ich kann halt nichts real damit tun. Ich erkläre den Lesern lieber, wie ich grundsätzlich z.B. inverse Kinematik mache und wie ich das beispielhaft mit RVIZ und URDF umsetze und mit Code, der gegen ROS linkt.
Das ist natürlich ein Spagat: ich habe ja selbst auch viele Jahre sehr intensiv mit ROS gearbeitet, so dass ich da nicht auch selber in die Falle tappen will. Ich verwechsle dann selbst auch schonmal den Namen des ROS-Pakets mit dem eigentlichen Problem, das ich lösen will.
Das ist natürlich auch schwer, weil es ja schon eine Art Best Practice gibt, Robotiksysteme zu bauen. Und viele dieser Methoden und Best Practices sind ja auch in ROS bzw. ROS 2 umgesetzt. Wenn man deswegen ROS-artig über Systeme nachdenkt, ist man meines Erachtens ja häufig auch nicht ganz weit davon entfernt, insgesamt eine plausible Sicht auf Robotersysteme zu haben. Das macht es natürlich umso schwieriger, die Teile zu erkennen, in denen ROS eine sehr spezifische Implementierung gewählt hat – zum Beispiel vielleicht tf – die vielleicht nicht immer auch gleichzeitig die Nützlichste ist. Sondern dann wieder zur abstrahieren: was ist eigentlich das zugrundeliegende Problem und was sind dann mögliche Lösungen?
Genau. Um eben auch sicherzustellen, dass die Leute verstehen, was hinter den Kulissen passiert. Ich will zumindest versuchen zu erklären, dass man inverse Kinematik nutzt, wenn man zum Beispiel von MoveIt eine Gelenkposition für eine kartesische Pose anfragt. Und dass ich das auf diese und jene Art angehen kann, dass die praktische Realisierung aber meistens eine numerische Lösung ist, usw. Die Leser:innen sollen zumindest verstehen, was dort im Hintergrund abläuft und ein Gefühl dafür bekommen, was passiert.
Best Practice versuche ich, vom Anfang an zu vermitteln. Also, kein Mensch würde seine Datenbank oder Webapplikationen so programmieren, dass er im Webserver mit dem Treiber der Festplatte redet, sondern da sind diverse Abstraktionsschichten zwischen. Und in der Robotik, gerade im Hobbybereich (manchmal auch von Leuten, die es an der Uni so betrieben haben) findet man zum Teil Systeme komplett ohne alle Abstraktionen. Da wird ein digitaler Eingang alle Ebenen hochgereicht. Da gibt es dann zwar eine ROS-Nachricht für, aber keine sinnvolle Semantik mehr.
Gerade in Robotiksystemen, weil sie oft komplex und vielfältig sind, muss ich mir von Anfang über die Architektur Gedanken machen, z.B. wie ich konzeptionell in verschiedene Belange aufteilen kann, die von verschiedenen Leuten bearbeitet werden können. Es muss dann ja auch nicht alles hardcore embedded Software sein. Es gibt einfach vielfach dieses Vorurteil, um überhaupt was mit Robotik machen zu können, müsse man sich erst einmal Mathematik reinziehen und dann quasi tief in den Registern herumstochern. Das schreckt viele ab.
Interessant! Diesem Vorurteil bin ich noch nicht begegnet. Ich habe manchmal den gegenteiligen Eindruck: dass viele Leute sehr hemdsärmlig herangehen, sich einen best effort ROS-Grafen zusammenhauen und sich um ganz viele Control- und Realtime-Aspekte gar nicht kümmern. Wenn das irgendwie läuft, ist das Robotik.
Es funktioniert ja beides leider nicht. Es geht nicht, nur mit Registern und Signalen zu arbeiten, dann habe ich schnell ein unwartbares System, das wahrscheinlich auch von Anfang an nicht das tut, was es tun soll. Aber das Gegenteil funktioniert auch nicht. Ich kann mir das, was sich vielleicht Webapplikationen, die vielleicht noch in einer Cloud laufen, leisten können, in der Robotik nicht leisten. Nämlich, dass ich mir alles in aller Schönheit abstrahieren und verteile. Sonst gehen mir die ganzen Regelkreise auf die Bretter, die vielleicht auch noch Realtime sein müssen.
Ich brauche halt eine Organisation von all diesen Aspekten. Denn wir haben ja mittlerweile in der Robotik auch Aspekte, die mitunter in der Cloud laufen müssen: Fleet Management, Deep Learning, Object Detection, und so weiter … aber in der Robotik muss es dann trotzdem am Ende irgendwie – im zweifel safety-kritisch, realtime, sehr verstanden und vorhersagbar – irgendwo in schnellen Regelkreisen enden.
Genau! Und da kommen wir zu der Frage, was denn der Kern der Robotik ist. Je nachdem, von welcher Richtung in der Robotik man blickt, sind es ganz unterschiedliche Dinge. Die einen sagen, alles oberhalb der Roboter-Dynamik ist nur Beiwerk. Die anderen sehen den Roboter als reines Positionier-Eisen und das wirklich spannende heutzutage liefe in der KI, der Bildverarbeitung, in Wissensmodellierung. Aber wie du sagst, spielt das alles mit.
Wenn jemand sich 15 Jahre um Echtzeit-Embeddedsysteme gekümmert hat und dann anfängt, Cloud-Systeme zu entwickeln, dann geht das schief. Und das Gegenteil habe ich auch schon gesehen: wenn Leute, die bisher skalierbare Softwarelösungen für Onlinedienste entwickelt haben, plötzlich Embedded-Robotiksoftware entwickeln, dabei aber alles erst einmal durch fünf Versionen von Memcashed und Redis schieben, kommt dabei auch nichts Gutes raus.
Es ist eben das Spannende an der Robotik, dass all diese Aspekte eine Rolle spielen. Das möchte ich mit dem Buch anreißen, um einfach den Lesern auch zu zeigen: hey, wenn du keinen Bock auf Regelungstechnik hast, aber trotzdem Robotik geil findest, dann gibt es für dich immer noch die anderen 90% dessen, was es braucht, um eine Robotikanwendung in die echte Welt zu bringen. Je nachdem, was ich eben mag: mag ich Mikrocontroller, mag ich Clouddienste, mag ich Echtzeit, mag ich Regelungstechnik, mag ich Algorithmik, mag ich Physiksimulation … da muss für jede:n Softwareentwickler:in was dabei sein.
Wir kreisen gerade um eine Frage herum, die ich mir auch schon gestellt habe. Gibt es eine Kernaussage, einen Kerngedanken, den Du mit diesem Buch transportieren möchtest? Der der besonders wichtig ist, weil es den so deutlich noch nicht gibt? Oder würdest du sagen, dass ist eher ein strukturiertes Zusammentragen von bekanntem Wissen der Robotik-Software-Community ist?
Ich würde nicht behaupten, dass ich mit diesem Buch jetzt etwas dem Robotics Body of Knowledge hinzufüge. Ich hab jetzt allerdings mehrere Wochenenden damit zugebracht, zu versuchen, mal nur für dieses Buch eine einheitliche Notation zu finden, die nicht nur für Manipulatoren passt oder nur für mobile Roboter. Daran bin ich fast verzweifelt. Du nimmst drei Bücher zur Hand und findest mindestens fünf Notationen. Aber man wird ja ein Buch sofort wegwerfen, wenn die Notation zwischen den Kapiteln über Kinematik von Manipulatoren und dem über mobile Roboter plötzlich inkonsistent ist. Das ist vielleicht so ein kleiner Beitrag, aber auch da orientiere ich mich natürlich an den großen Werken und erfinde nichts komplett Neues.
Ansonsten ist es eine einheitliche Darstellungen auf einem zugänglichen Niveau, würde ich sagen. Meine Kernbotschaft ist, was ich auch auf einer der ersten Seiten schreibe, dass für mich die Robotik das Feld ist, das sich damit beschäftigt, wie ich aus der virtuellen Welt in die reale Welt hinausreichen kann, und aus der realen Welt wieder zurück in die virtuelle Welt. Jedes Smartphone hat natürlich irgendwie einen Vibrationsalarm, ein Display und eine Kamera, aber in der Robotik ist es ja weit mehr. Die Frage, wie ich das, was ich in Software ausdrücken kann, in eine Manipulation oder Einflussnahme der echten Welt umsetzen kann. Das finde ich faszinierend!
Was wäre denn zum Beispiel das Robotik-Äquivalent zur universellen Turingmaschine. Also: wir wollen ein Mapping haben von dem, was wir in Software frei und flexibel ausdrücken können in die echte Welt. Es ist ja wirklich fast schon Magie: ich schreib hier in irgendwelchen arkanen Sprachen Symbole hin und dadurch teleportiert sich irgendwie der Kaffee von der Kaffeemaschine auf meinen Tisch. Nur dass die Teleportation momentan noch etwas kompliziert über ein mobilen Roboter erledigt wird, aber hey … es ist nah dran.
Dann jetzt ein Sprung zurück zum Buch selbst. Als ich die ersten Kapitel gelesen habe, die ich übrigens echt gerne gelesen habe, ist mir aufgefallen, dass es eine erstaunliche Zahl Vorwärtsreferenzen gibt. Die versucht man ja typischerweise beim Schreiben von wissenschaftlichen Arbeiten zu vermeiden. Als ich die so las, habe ich mich gefragt, ob das Dein Schreibstil ist, oder vielleicht ein Kernproblem der Robotik. Dass so viele Dinge so eng verzahnt sind, dass ich die gar nicht nicht systematisch oder chronologisch aufbauen kann.
Wenn man ein Buch oder Kapitel konzipiert, fragt man sich natürlich immer, von welcher Seite man den Gaul jetzt aufsattelt. Was ich auf jeden Fall vermeiden wollte, ist eine systematische Einführung. Also: erst einmal kommen zwei Kapitel Mathematik, dann x Kapitel Geometrie, etc. … und ganz am Ende vom Buch rede ich mal über Anwendungen in der Robotik. Das wäre zwar eine akademisch saubere Struktur, aber ich würde da viele Leser einfach früh verlieren. Das ist also der Mission des Buches geschuldet.
Das andere ist aber auch: es hängt natürlich vieles miteinander zusammen, wie Du gesagt hast. Nehmen wir z.B. Regelkreise: ich möchte den Lesern am Anfang über Vorwärtsreferenzen als Motivation direkt mitgeben, dass das noch an mehreren Stellen auftauchen wird. Relativ früh, wie ich den einzelnen Motor auf Geschwindigkeit oder auf Position bringen kann. Bei mobilen Robotern brauch ich dann irgendeine Rückmeldung aus der Umgebung, via LIDAR, Taster, und so weiter… ich möchte da früh die Augen öffnen: das kommt jetzt über den Rest des Buchs verteilt vor und taucht noch in der Sensordatenverarbeitung, der Bildverarbeitung etc. vor.
Das ist dann ja auch der direkte Anschluss zum Software Engineering: ich kann das ja auch abstrahieren und im Einzelfall ignorieren, dass ich keine perfekte Positionsregelung habe und das natürlich auch nicht instantan passiert. Aber ich ziehe bewusst eine Abstraktionsebene ein, ab der es nur noch um Positionen geht und alle Dynamik darunter ignoriere ich. Das kann eine gute oder eine sehr schlechte Idee sein. In der Robotik ist es glaube ich schwer, diese guten Ebenen zu finden. Denn es hängt auch vom Robotertyp und der Anwendung ab. Wenn ich mit einem normalen Industrieroboter eine einfache Anwendung mit niedrigen Geschwindigkeiten habe, arbeite ich mit Positionen. Wenn ich dann aber Anspruchsvolleres als z.B. Pick & Place will, dann wird es plötzlich extrem wichtig, auf diese Ebenen doch noch runter zu schauen. Diese natürliche Abstraktionsebenen wie zum Beispiel das Betriebsystemlevel in der IT gibt es in der Robotik noch nicht. Und diese Suche nach nützlichen Abstraktion zieht sich durch das gesamte Buch.
Es kommen ja noch ziemlich viele coole Kapitel, die hast Du jetzt zum Teil schon angedeutet. Zum Beispiel Simulation, KI, etc. Was erwartet uns denn sonst noch, zum Beispiel im Kapitel 23: „More awesome Robotics“?
Da gehe ich zum Einen auf neue Robotertypen ein, also Schwarmroboter, selbst-rekonfigurierende Roboter, modulare Roboter, humanoide Roboter, Soft Robotics, Bionik, etc. … jedes natürlich für sich selbst nochmal mindestens ein weiteres Buch wert. Damit möchte ich das Feld weiten, um zu zeigen: das gibt es auch noch alles und Du verstehst jetzt vielleicht schon 80% davon. Das mache ich ja auch in jedem Kapitel klar: das lernst Du, das hast Du jetzt verstanden, und das kannst Du damit schon schon anfangen. Auch wenn das konkrete Beispiel gerade vielleicht ein Last Mile Delivery Robot ist und Du eigentlich einen stationären Roboter programmieren willst, der Fritten zubereitet … das Grundwissen ist in beiden Anwendungen relevant und übertragbar. Das versuche ich zu zeigen mit dem Buch: das autonome Auto hat deutlich mehr mit einem humanoiden Roboter zu tun oder mit meinem klassischen Industrieroboter, als auf den ersten Blick ersichtlich.
Ich selbst habe mich ja in der Diplomarbeit mit selbstkonfigurierenden modularen Robotern beschäftigt, danach dann eine Promotion im Bereich Chirurgierobotik, dann ein Unternehmen im Bereich modulare Robotik für Industrieanwendungen gegründet, und bin jetzt in eine Unternehmen für Industrieroboter und mobile Roboter. Das geht ja nur, weil man nicht alles wieder von vorne lernen muss, sondern weil sich halt unglaublich viel übertragen lässt an Herangehensweisen, Grundlagen, Konzepten, bis hin zu Algorithmen und Implementierungen.
Das ist eine perfekte Überleitung zu meiner wahrscheinlich ungefähr letzten Frage: wie viel von diesem Buch ist robodev-Andreas und wie viel ist ABB-Andreas?
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!
Elon Musk hat auf dem Tesla „AI Day“ den Tesla Bot angekündigt: einen Humanoiden mit einer Größe von knapp 1,80 m. Er soll zukünftig „gefährliche, sich wiederholende oder langweilige Aufgaben“ für den Menschen übernehmen können.
So stellt sich Elon Musk den Tesla Bot vor. NotMyRobots, *zwinker, zwinker*
Elon Musk hat mit Tesla und SpaceX durchaus gezeigt, dass er gewisse Disziplinen (Elektromobilität, Raumfahrt) kräftig aufräumen kann, aber diese Ankündigung wirkt doch nochmal ein gutes Stück verwegener. Die Reaktionen reichen daher bislang auch eher von„AI Day, und damit auch dieser Roboter, ist eher Marketinginstrument beim Buhlen um Mitarbeiter“ bis zu „Elon Musk hat noch nicht verstanden, was ein humanoider Roboter eigentlich überhaupt ist und was man dafür benötigt“:
For anyone wondering why I Tweeted "Elon Musk has no idea what getting humanoid robots to do useful stuff actually involves," here's why. https://t.co/Ekjg9Y3j89
Elon Musk behauptet in seinem Auftritt jedenfalls, dass Tesla mit seinen Autos praktisch schon alle Komponenten für einen intelligenten, autonomen Humanoiden besitzt und beherrscht. Dass die Ankündigung, anders als Ankündigungen etwa von neuen Auto-Modellen, allerdings ohne Prototyp auskommt, sondern stattdessen einen Roboterdarsteller nutzt, ist sicher kein Zufall:
Elon Musks Ankündigung des Tesla Bot beim Tesla AI Day
Spannend finde ich bei der Ankündigung, dass Elon Musk – bislang eher als Turbo-Kapitalist aufgefallen – die Notwendigkeit von allgemeinem Grundeinkommen anspricht. Ob das Thema langsam gesellschaftsfähig(er) wird? Eine breitere Diskussion und größere Bühne ist bei zunehmender Automatisierung zumindest sicher nicht schädlich.
Übrigens: Hat Elon Musk nicht noch kürzlich vor intelligenten Robotern gewarnt und gefordert, per Gesetz KI und selbstständige Roboter zu beschränken, weil sie uns alle töten werden?
Eigentlich sollte die IROS, neben der ICRA die wohl wichtigste Robotik-Konferenz, in diesem Jahr im Oktober in Las Vegas stattfinden. Eigentlich. Natürlich macht der neuartige Coronavirus diesem Plan einen Strich durch die Rechnung, wie zuletzt schon der ICRA und auch der ROSCon und vielen anderen Konferenzen weltweit.
Die gute Nachricht ist aber: sie findet virtuell statt, als IROS 2020 On-Demand. Und noch besser: sie ist komplett kostenlos.
Mit der kostenlosen Registrierung gibt es Zugang zu allen technischen Vorträgen, Panel-Diskussionen, Keynotes, Workshops, Tutorials, etc. Wenn ich es richtig verstehe, gibt es damit auch kostenlosen Zugriff auf die Proceedings bei IEEE und damit auf alle Konferenzbeiträge in schriftlicher Form.
Es lohnt also, sich zu registrieren und zwar hier: IROS 2020 Sign-Up. Am 25. Oktober 2020 geht’s los und geht bis zum 25. November.
Eigentlich sollte im Oktober diesen Jahres die alljährliche ROSCon, eine Konferenz rund um ROS, das Robot Operating System, in New Orleans stattfinden. Vernünftigerweise passiert das wegen der COVID-Pandemie natürlich und leider nicht. Stattdessen findet in diesem Jahr als Ersatz zum ersten Mal überhaupt ein ROS World statt.
Die ROS World 2020 wird eine virtuelle 1-Tages-Konferenz am 12. November, die die ROSCon ersetzt und der ROS-Community einen Ausgleich geben soll, sich trotzdem auszutauschen und vernetzen zu können. Wie bei einer ROSCon wird es natürlich auch bei der ROS World viele Vorträge aus der Community geben, die im Live Stream übertragen werden. Dazu kommen Diskussionsforen, 1-zu-1-Videochats zwischen Teilnehmer:innen und Interaktionsmöglichkeiten während des Vortrags zum Fragenstellen und Abstimmen über Themen.
Ich habe mich auf jeden Fall schon als Teilnehmer registriert, vielleicht werde ich mich auch noch an einem Beitrag beteiligen (etwa zu micro-ROS). Die Registrierung zum Event scheint erstmal kostenlos zu sein, zumindest noch bis zum 5. Oktober. Hier geht’s zur Registrierung!
Die nächste ROSCon gibt es dann voraussichtlich vom 21. – 22. Oktober, natürlich in New Orleans.
Eine dringende Frage der Community wurde auch schon beantwortet: Ja, es gibt T-Shirts! 😉
Zum tatsächlichen Einsatz von Robotern im Kampf gegen das Coronavirus, über den wir schon geschrieben haben, kann Prof. Dr. Murphy aus Texas etwas konkreter berichten und tat dies bei IEEE Spectrum. Murphy ist Professorin an der Texas A&M University, sowie Direktorin des Center for Robot-Assisted Search and Rescue (CRASAR). Sie kennt sich mit Robotern im Einsatz bei Katastrophen also durchaus aus.
Im nachfolgenden Bild ist eine interessante Übersicht zu sehen, in wie vielen Ländern denn nun wirklich schon Roboter für welche Zwecke eingesetzt werden. Roboter sind dabei in fünf Anwendungsbereiche eingeteilt, deren konkrete Aufgaben jeweils in der Spalte von oben nach unten in absteigender Häufigkeit einsortiert sind.
Tatsächlicher Einsatz von Robotern im Kampf gegen COVID-19 in fünf Kategorien, jeweils von oben nach unten in abnehmender Häufigkeit. [R. Murphy, V. Gandudi/Texas A&M; J. Adams/Center for Robot-Assisted Search and Rescue]
Erstaunlicherweise sind in den meisten Ländern (in insgesamt 16) Roboter im Einsatz, die sich im öffentlichen Raum bewegen und dort zum Beispiel helfen, Quarantäne-Maßnahmen durchzusetzen (am häufigsten) oder öffentliche Plätze zu desinfizieren. Das finde ich in sofern erstaunlich, dass a) der öffentliche Raum für Roboter potentiell die komplizierteste und unsicherste Umgebung ist und b) mir in Deutschland diese Vorstellung doch im Moment noch eher fremd erscheint.
In der nächst-häufigen Kategorie, klinische Pflege, sind auch Roboter zum desinfizieren verbreitet sowie – wie wir schon orakelt haben – Telepräsenzroboter. Eine weitere stark vertretene Klasse von Robotern, die gleich in drei Anwendungsfällen (die drei rechten Spalten in der Grafik) vertreten ist: Lieferroboter.
Unabhängig von dem tatsächlichen Einsatz des Roboters merkt Dr. Murphy allerdings noch an, dass die unmittelbar nützlichsten Roboter ohnehin einfach diejenigen sind, die es schon gibt und an deren Nutzung sich die Menschen schon gewöhnt haben.
The most effective robots right now, she adds, are the robots that already exist, that people are already comfortable using, that have low activation energy, and that can scale up to be immediately useful.
Nein, gemeint ist hier nicht der Holzmichl, sondern mein erster Staubsaugerroboter. Am 7. August 2009 habe ich meinen Roomba 580 gekauft. Damit war ich schneller als Arne, was auf botzeit gut dokumentiert ist, und er tut heute noch seinen Dienst. Wie in jeder Beziehung hat auch meine Geschichte mit Roomba Höhen und Tiefen erfahren.
Wie man sieht, hat dieser 580 so einige Duelle mit meinen Fußleisten und Möbeln ausgefochten.
Anfängliche Wutanfälle
Bis sich der neue Roboter an seine neue Umgebung gewöhnt hat, dauert es eine Weile. Das kann dazu führen, dass ein nicht kompatibler Teppich unweigerlich die Wohngemeinschaft verlässt, nachdem er von Roomba spontan zerpflückt worden ist. Einen ähnlichen Fall hat Arne ja beispielsweise hier dokumentiert. Aber diese Phase ging bei uns schnell vorbei und es kehrte bald Harmonie ein.
Der Akku – Plötzliche Appetitlosigkeit
Etwa alle anderthalb Jahre verliert der kleine seinen Appetit und wirkt etwas launisch und kraftlos. Das heißt, Roomba lädt nicht mehr richtig und saugt auch nicht mehr die ganze Wohnung. Das ist dann für mich das Zeichen, wieder einmal einen neuen Akku zu kaufen. Den gibt es bei einem wohlbekannten börsennotierten Onlineversandhändler mit einer breit gefächerten Produktpalette. Diverse Anbieter verkaufen Nachbauten um etwa 30 €. Originale gibt es für etwas mehr Geld. Bisher habe ich noch nie ein Problem mit den Nachbauten gehabt.
„Fehler 9“ – Das verflixte siebte Jahr
Unsere schwerste Krise hatten wir — ganz klassisch — im verflixten siebten Jahr. Urplötzlich drehte Roomba buchstäblich am Rad und bewegte sich nur noch im Kreis. Es stellte sich heraus, dass es an einer altersschwachen Infrarot-Diode und / oder einem altersschwachen Fototransistor lag. Die Diode und der Transistor bilden das Herzstück der Bumper. Sie lassen Roomba erkennen, dass er gegen ein Hindernis gefahren ist. Die besagte Symptomatik ist auch als „Fehler 9“ bekannt. Es kann mit etwas handwerklichem Geschick, etwas Zeit, einem Schraubendreher und einem heißen Lötkolben für unter 5 € behoben werden. Also habe ich mir eine Flasche Bier aufgemacht und meinen Roomba damals nach der Reparaturanleitung von Andy Dunkel (vielen Dank!) kuriert:
Wer schon einmal bei einem Neuwagen nach ersten paar tausend Kilometern ein Abblendlicht gewechselt hat, der ahnt was jetzt kommt. Richtig, weniger als ein Jahr später hat Roomba einen Rückfall. Die gleiche Symptomatik, mit anderer Drehrichtung… Als ich den kleinen aufgeschraubt und bis auf seine intimsten Platinen zerlegt hatte, hätte ich gleich auch den anderen Bumper reparieren sollen. Glücklicherweise hatte ich ein paar Dioden und Fototransistoren extra gekauft. Bier war auch noch im Kühlschrank…
Hat er einen anderen?
Seit dem läuft es eigentlich gut in unserer Beziehung. Wenngleich ich zugeben muss, hin und wieder mal mit meinen Gedanken „bei einem anderen“ zu sein. Beim HiWi Job im Studium durfte ich an Sparse Visual SLAM Algorithmen mit Omnidirektionalen Kameras mitentwickeln. Die habe ich dann auf einem Pioneer Roboter erprobt. Dann habe ich bei einem großen Technologieunternehmen in der Entwicklungsabteilung genau daran weitergearbeitet. Obwohl ich heute in einem etwas anderen Teilgebiet der Robotik unterwegs bin, könnte ich mir einen neuen Staubsaugerroboter kaufen, der das alles mitbringt. Das juckt mich natürlich schon…
Dennoch bleibe ich meinem alten Roboter treu. So lange er noch tut, bleibt er der einzige Staubsaugerroboter in meinem Leben.
Reparier‘ Deinen Staubsaugerroboter
Vielleicht eine gute Beschäftigung an einem langweiligen Abend in Covid-19-Isolation? Wenn Du noch einen alten Roboter rumstehen hast, versuche ihm doch wieder Leben einzuhauchen.
Und wenn er nicht gestorben ist, dann saugt er die Wohnung auch morgen noch…
Ich bin nach wie ganz begeistert von meinem Roomba 560, den ich mir vor etwa anderthalb Jahren zugelegt habe und der ja jetzt auch wieder voll einsatzfähig ist. Welchen Staubsaugerroboter sollte ich mir denn jetzt zulegen, wenn ich mir einen neuen kaufen wollte? Sollte ich beim Roomba bleiben? (mein Modell, den 560, gibt es ja nicht mehr, aber entsprechende Nachfolgermodeller) Oder gibt es mittlerweile bessere Modelle mit ähnlichem Preis-/Leistungs-Verhältnis?
Ich frage nicht (primär) für mich, sondern für ein Freundin, die mich danach gefragt hat.
Also: Gibt es gute Alternativen zum Roomba? Ich bin für alle Tipps, Erfahrungsberichte und Kommentare dankbar. Welche Modelle kommen in Frage?
PS: Die Kommentarfunktion ist im Moment offenbar defekt. Ich arbeite dran. Bis dahin Kommentare auch einfach per mail anbotzeit@ohmpage.org
Lange habe ich keine Linksammlung mehr eingestellt, dafür kommen hier aber ein paar wirklich tolle Artikel der letzten zwei Monate: Ein Interview, religiöse Robotik und ein Staubsaugerroboter in der echten Welt …
Tauchroboter „Ferngesteuerte Roboter […] können zur Erschließung neuer Ölfelder vor den Küsten eingesetzt werden“. Ein Beitrag im aktuellen Kontext der Ölkatastrophe im Golf von Mexiko zum Einsatz von Tauchrobotern, die zwar Vorteile bieten und tiefer tauchen können als Menschen, aber zum Teil auch achtköpfige Bedienungsmannschaften erfordern.Baumarkt in der Tiefe(Süddeutsche, Alexander Stirn, 19. Juni 2010)
Robotik als Religion In der New York Times schreibt Jaron Lanier von der University of Southern California einen Artikel unter dem bezeichnenden Titel The First Church of Robotics, die erste Kirche der Robotik. „The influential Silicon Valley institution preaches a story that goes like this: one day in the not-so-distant future, the Internet will suddenly coalesce into a super-intelligent A.I. […] it will become alive in the blink of an eye, and take over the world before humans even realize what’s happening.“The First Church of Robotics(New York Times, englisch, Jaron Lanier, 9. August 2010)
Haushaltshilfe Für Welt-Online macht Familienvater Clemens Wergin den Test, einen Staubsaugerroboter in die Familie und den Haushalt einzuführen. Ausgesucht hat er sich einen von Samsung, weil dieser der Intelligenteste sei, mit seinem „Visionary Mapping System“ und der „beeindruckende[n] Zahl von Sensoren“. Der Test ist interessant zu lesen, weil er zeigt, wo Roboter nach wie vor scheitern: In der echten Welt, in der Kabel und andere Gegenstände rumliegen und in der der Roboter von Menschen bedient wird, die nicht an der Programmierung beteiligt waren oder geschult wurden. Unterhaltsam zu lesen.Saugroboter – im Bewährungstest knapp gescheitert(Welt Online, Clemens Wergin, 27. Juni 2010)
Interview Der US-Politologe Peter W. Singer (siehe Buch-Review Wired for War) sieht in Militärrobotern eine ähnlich große Veränderung für die Kriegsführung – und eine ähnlich unkalkulierbares Risiko – wie durch die Atombombe. Matthias Kolb führt mit ihm für die Süddeutsche ein Interview.Wenn Roboter das Schlachtfeld übernehmen(Süddeutsche, Matthias Kolb, 12. August 2010)
Google hat die deutsche Firma Microdrones gekauft, die zivile ferngelenkte Drohnen entwickelt. Die Spekulationen schießen seitdem – gerade im Zusammenhang mit der aktuellen StreetView-Debatte – aus dem Boden. Spekuliert wird unter anderem über detailliertere Aufnahmen oder sogar Live-Aufnahmen von wichtigen Plätzen.Google dementiert Berichte über geplanten Drohnen-Einsatz(Spiegel Online, Frank Patalong, 9. August 2010)
Über Hinweise zu lesenswerten Artikeln freue ich mich jederzeit. Entweder per Kommentar oder per E-Mail anbotzeit@ohmpage.org
Ein weiterer Schritt in Richtung Haushalts-Wäsche-Bügelroboter, dem vermutlich meistgewünschten Roboter, ist jetzt der University of California in Berkeley und Willow Garage gelungen. Das folgende Video zeigt den Roboter PR2, wie er Wäsche aufnimmt und sie anschließend ordentlich faltet und zusammenlegt:
PR2 faltet Handtücher
Die Aufgabe, die der PR2 dort erfüllt, ist dabei alles andere als trivial. Wie im Zeitraffer zu sehen, muss der Roboter nach dem Aufhaben eines Handtuchs erst einmal die Geometrie des Stoffstückes verstehen. Der Roboter hat kein Modell des Handtuchs, sondern lernt es durch Betrachtung, durch Drehen und Wenden. Anschließend setzt er dies in entsprechend Schritte zum Falten und Stapeln des Handtuchs um und streicht es zum Schluss noch liebevoll glatt. Der PR2 ist dabei erstaunlich robust und zuverlässig:
The reliability and robustness of our algorithm enables for the first time a robot with general purpose manipulators to reliably and fully-autonomously fold previously unseen towels, demonstrating success on all 50 out of 50 single-towel trials as well as on a pile of 5 towels.
