Schlagwort: interview

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.

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!