NEURA Robotics

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.

Robotics for Software Engineers – Interview mit Andreas Bihlmaier

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

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

Andreas Bihlmaier, Chief Software Architect bei ABB

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

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

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

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

Damals warst Du aber ja noch bei robodev.

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

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

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

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

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

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

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

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

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

…und braucht entsprechend viele neue Softwareentwickler:innen.

Absolut! Und das ist die Zielgruppe.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

… und wieviel ist Sonderforschungsbereich125-Andreas?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Heute live: Erweiterung der Produkpalette von Boston Dynamics‘ Spot

Am heutigen Dienstag, den 2. Februar stellt Boston Dynamics um 17 Uhr europäischer Zeit in einem Live-Event die erweiterte Produktlinie ihres Vierbeiners Spot vor. Noch ist nicht viel dazu bekannt. Wer mehr wissen will, sollte sich in das Event einklinken, dass zum genannten Zeitpunkt live bei Youtube übertragen wird. Und zwar hier: Launch Event: Meet Spot’s Expanded Product Line (2. Februar 2021, 17:00 Uhr)

Hier der Tweet mit der Ankündigung und einem gewohnt professionellen Trailer zum Event:

Do You Love Me?

Boston Dynamics ist – natürlich – von Anfang an immer mal wieder in bei uns Thema gewesen: 2009 mit dem abgefahrenen Video von BigDog und ersten Videos vom Zweibeiner PetMan, Anfang dieses Jahres dann mit Gymnastikübungen von dem Humanoiden Atlas, und schließlich im September mit dem Verkaufsstart von Spot.

Was Boston Dynamics heute zeigt ist aber einfach ein Brett und so unfassbar gut! Die Bewegungen der Roboter sind so flüssig und dynamisch, dass ich mich mehrfach während des Videos daran erinnern muss, dass es weder CGI noch ein Mensch in Roboterkostüm ist:

Tanzvideo von Boston Dynamics

I’m back to let you know I can really shake ‚em down

Unglaublich gut!

Weihnachtsparties abgesagt? Nicht für Roboter!

Frohe Weihnachten wünschen die Roboter vom Karlsruher FZI.

Wie in jedem Jahr haben auch in diesem Jahr – trotz der widrigen Umstände – Robotiklabors und -firmen rund um die Welt weihnachtliche Geschichten und Videos mit Robotern produziert. Bei IEEE Spectrum Automaton gibt es eine ansehnliche Sammlung von Videos, hier nur eine kleine Auswahl davon:


Dass Weihnachtsparties in diesem Jahr zuhauf ausfallen, muss Roboter nicht stören, wie das Karlsruher FZI zeigt. Da kümmern sich die Roboter eben selber um die gemütliche und weihnachtliche Stimmung:

Weihnachtsparties abgesagt? Nicht für Roboter!

Ein wiederkehrendes Thema in den Weihnachtsvideos im amerikanischen Raum ist, wie den fleißigen Weihnachtselfen die monotone Arbeit abgenommen oder zumindest erleichtert werden kann:

FANUC erleichtert Weihnachtselfen die Arbeit
Auch Robotiq hilft den Weihnachtselfen

Außerdem hilft ein Spot-Roboter einem einfallsreichen Hund gegen die Langeweile in den Weihnachtstagen:

Spot hilft gegen Langeweile

Und zum Schluss noch eine weihnachtliche Quadrokopter-Choreografie:

Weihnachtliche Quadrokopter-Choreografie

Noch mehr weihnachtliche Videos von und mit Robotern gibt es bei IEEE Spcetrum Automaton.

Frohe Weihnachten und schöne Feiertage!

IROS 2020 wird virtuell und komplett kostenlos

IROS 2020 On-Demand

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.

Gisela im Bikini

Dieser Artikel wird weniger schlüpfrig als es der Titel verspricht. Gisela ist nämlich ein Roboter und mit Bikini ist das Bikini Berlin gemeint, also ein Einkaufszentrum. Dort steht, wie mich eine Freundin vor einigen Tagen aufmerksam gemacht hat, ein Roboter, der Spielzeugroboter zusammensteckt und verkauft.

Der sogenannte Workerbot hat zwei 85 cm langen Arme, dem Anschein nach zwei Universal Robots, und eine Größe von 2,10 m. Gebaut wurde er von der Berliner Firma pi4. Seinen Namen, Gisela, hat der Roboter von der Mutter des Erfinders und Firmenchefs, Matthias Krinke.

Interessierte können Gisela im Erdgeschoss des Einkaufszentrums Bikini Berlin bestaunen. Gegen 6 Euro baut der sogenannte Workerbot innerhalb von sechs Minuten einen kleinen Papp-Roboter aus 14 Teilen zusammen. Elf Stunden am Tag, ohne Pause. Wenn ich nächstes Mal in Berlin bin, will ich die 6 Euro auf jeden Fall investieren.

Lustig ist auch die Schlagzeile, die die Berliner Zeitung titelt: Gisela ist die erste Berliner Verkäuferin, die immer nett ist.

ROS World 2020 ersetzt ROSCon 2020

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! 😉

European Robotics Forum 2020 – ausgedünnt

Seit Freitag bin ich zurück vom European Robotics Forum 2020. Auf dem Hinweg hatte ich noch gerätselt, ob wohl die Auswirkungen des Coronavirus‘ zu bemerken sein würden. Jetzt kann ich sagen: ja, waren sie. Corona war gefühlt neben der Strategic Research Agenda für das kommende Forschungsrahmenprogramm Horizon Europe und künstlicher Intelligenz das vorherrschende Thema.

Direkt zu Beginn wurde erstens klar, dass die EU-Kommission wegen Reisebeschränkungen ausnahmsweise dem ERF komplett fernbleiben würde. Zweitens galt während des gesamten Events striktes Handschüttelverbot (das wird uns in nächster Zeit wohl noch häufiger begegnen). Und drittens wurden jeden Tag am Eingang des Veranstaltungsortes bei allen Teilnehmern die Temperatur gemessen. Ob wirklich jemand nach Hause geschickt wurde, weiß ich nicht, die Atmosphäre hat es aber natürlich trotzdem beeinflusst. Mein Husten und Schnupfen wurde während der Veranstaltung auch regelmäßig äußerst skeptisch beäugt.

Händeschütteln verboten beim ERF 2020
Händeschütteln verboten beim ERF 2020

Exhibition

Die Ausstellungsfläche, auf der beim ERF traditionell in den Mittags- und Kaffee-Pausen Roboter und Robotikprojekte gezeigt werden, war auch dementsprechend ausgedünnt. Unter Anderem fehlte der Hauptsponsor des Events, ABB. ABB hätte dort sonst wahrscheinlich einen größeren Stand mit mehreren Robotern gezeigt.

Ausgedünnte Ausstellungsfläche beim ERF
Viele offene Flächen, wo eigentlich Roboter stehen sollten

Unserem Stand, vom micro-ROS-Projekt, tat dieser Umstand allerdings keinen Abbruch. Wir hatten über alle Tage viele interessierte Besucher, die unsere Demo gesehen und mit uns über ROS auf Mikrocontrollern diskutiert haben. Überraschenderweise schienen die Besucher des ERF ähnlich viele Unklarheiten und Fragen zu dem – theoretisch verbreiteten und schon über zwei Jahre alten – ROS-NachfolgerROS 2‚ zu haben wie zu unserem vergleichsweise kleinen Projekt. Da hat ROS 2 wohl noch Nachholbedarf in der Dokumentation und Kommunikation.

micro-ROS-Stand beim ERF 2020
Viel Diskussion am micro-ROS-Stand

Workshops

Abseits der Ausstellungsfläche haben in den Workshops meinem Eindruck nach zwei Themen dominiert: künstliche Intelligenz (AI) und die Strategic Research and Innovation Agenda (SRIA) für Horizon Europe. Dies betrifft zumindest die Workshops, die auch tatsächlich stattgefunden haben. Mehrere der ursprünglich geplanten Workshops und Vorträge fielen nämlich aus oder wurden spontan von anderen Teilnehmern vertreten.

Die SRIA war so präsent, da sie beeinflusst, zu welchen Themen die EU-Kommission in den Jahren 2021–2027 ca. 100 Milliarden Euro Forschungsgelder zur Verfügung stellen wird (nicht ausschließlich für die Robotik, selbstverständlich). Dass AI so im Fokus des ERF stand liegt daran, wie die EU-Kommission das Verhältnis von AI und Robotik sieht bzw. – besser gesagt – definiert. Sie hat nämlich erklärt, dass sie Robotik als Teil von AI versteht und nur in dem Rahmen fördern wird. Die Robotik-Community sieht das natürlich anders, nämlich dass AI und Robotik zwei separate Disziplinen mit einigen Überschneidung sind. Will man sich allerdings mit der EU-Kommission vertragen, muss man diese Sichtweise zähneknirschend tolerieren.

In diesem Rahmen habe ich während der Veranstaltung auch gelernt, dass ich in diesem Jahr wohl noch ein bis zwei Male in Brüssel sein werde. Als Koordinatoren einer der euRobotics-Topicgroups werde ich dort wohl am Input für die SRIA mitarbeiten. Wahrscheinlich geht’s damit schon im Mai los.

Abseits davon hat mich persönlich gefreut, dass auch das Thema Sicherheit (sowohl im Sinne von Safety als auch von Security) beim ERF präsenter wird. So habe ich drei gute Workshops zum Thema Safety besucht, unter anderem in der Industrierobotik, in dem ich auch selbst vorgetragen habe. Ich hoffe, das bleibt so, denn dieses Thema schien mir in den letzten Jahren bei euRobotics deutlich unterrepräsentiert.

Insgesamt also ein ausgedünntes European Robotics Forum in diesem Jahr, mit trotzdem einigen interessanten Themen, aber leider wenigen Robotern. Im nächsten Jahr hoffentlich dann wieder mit vollem Schwung, dann geht’s zum ERF 2021 nach Rotterdam!

Auf dem Weg zum European Robotics Forum 2020

Auf dem Weg zum ERF 2020 nach Málaga, trotz Coronavirus! Ich weiß schon von mehreren Teilnehmern, die ihre Reise zum European Robotics Forum in diesem Jahr aus diesem Grunde ganz kurzfristig gecancelt haben. Ich halte mich allerdings an die von den Organisatoren extra eingerichtete Seite Coronavirus Policy for ERF2020, die sich recht informiert und pragmatisch gibt und aktuell (Stand 28. Februar) keinen Grund zur Absage sieht.

Ich bin aber gespannt, ob sich vor Ort eine Ausdünnung im Vergleich zu den letzten Jahren erkennen lässt.

Ich bin schon heute unterwegs, da a) Eurowings nur Sonntags, Mittwochs und Freitags zwischen Stuttgart und Málaga direktfliegt und b) da ich morgen am Tag vor dem ERF schon ein Projekttreffen mit dem micro-ROS-Projekt (OFERA) habe. Zusammen mit dem MROS-Projekttreffen auch im Rahmen des ERF ist der CO²-Ausstoß des Flugs (der von meinem Arbeitgeber kompensiert wird) zumindest effektiv genutzt.

Wie immer gilt: Ich freue mich über jeden Leser, der auch beim ERF ist, mich anspricht und mit mir tagsüber einen Kaffee trinkt oder abends beim Social Event mit mir anstößt. Ich bin wahrscheinlich in den Pausen auch regelmäßig an Stand 27 zu finden.

Hier geht’s zum diesjährigen European Robotics Forum 2020#erf2020