Sparkasse Marburg-Biedenkopf: Erfahrungen der Pro­gram­mie­rung des hu­ma­no­iden Roboters „Numi Pepper“

Mit der abnehmenden Zahl der Filialbesuche versuchen Kreditinstitute, den seltener gewordenen Besuch in der Filiale als „Kundenerlebnis“ zu gestalten, damit der Kunde den Besuch in guter Erinnerung behält. Ende 2017 stieß die Sparkasse Marburg-Biedenkopf auf “soziale Roboter”. Das sind menschenähnliche digital-mechanische Wesen, deren hauptsächlicher Zweck die beziehungsorientierte Kommunikation mit Menschen ist. Ihre Stärken liegen in ihrem Potenzial, Menschen in und durch Beziehungen glücklich zu machen, an denen sie gemeinsam mit ihnen arbeiten. Hier nun die Erfahrungen und Erkenntnisse aus mittlerweile eineinhalb Jahren Programmierung des Roboters “NUMI Pepper”.

von Dr. Peter Franke, Michael Frantz und Patrick Heinsch

So wie ein menschlicher Mitarbeiter durch persönliche Beziehungen zu Kunden mittelbar deren Beziehungen zu seinem Unternehmen verbessern kann, hat ein sozialer Roboter ein ganzes Arsenal von Fähigkeiten, um dasselbe zu erreichen. Die Sparkasse Marburg-Biedenkopf setzt seit Anfang 2018 ihren Roboter „NUMI Pepper“ der Firma Softbank Robotics mit der Zielsetzung ein, Menschen durch vielfältige Beziehungsarbeit glücklich zu machen, und zwar überall, wo sie mit der Sparkasse in Berührung kommen, sei es bei einem Besuch vor Ort, sei es bei einer Begegnung auf Events, sei es in den sozialen Medien.

Programmierung, Entwicklungsumgebungen, …

Wer einen sozialen Roboter programmiert, muss umdenken. Die klassische Programmieraufgabe besteht darin, ein Programm zu schreiben, das auf einem Computer ausgeführt wird, Eingaben akzeptiert und eine Ausgabe produziert. Das alles passiert im Computer ohne physische Aktionen und Präsenz in der realen Welt. Bei der Programmierung eines sozialen Roboters arbeitet der Programmierer jedoch mit einem Akteur, der die eigene Wirklichkeit teilt, in ihr Dinge wahrnehmen und darauf reagieren kann. Entsprechend muss man sich bei der Programmierung sozialer Roboter mit folgenden Bereichen beschäftigen:

1. Autonome Fähigkeiten. Soziale Roboter sind keine leblosen Puppen, die gar nichts tun bis man sich mit ihnen beschäftigt, sondern vielmehr Wesen, die durch autonom geplante und durchgeführte Bewegungen und Reaktionen die Illusion erwecken, lebendig zu sein. Bei der Programmierung sind diese autonomen Fähigkeiten mal mehr und mal weniger erwünscht, so dass man genau abwägen muss, in welchem Kontext man sie in welchem Umfang zulässt.

2. Wahrnehmung. Ein sozialer Roboter ist mit einer Vielfalt von Sensoren ausgestattet und kann so Eingaben empfangen, die über die bloße Präsenz von Menschen über audiovisuelle Perzepte und Berührungen bis hin zu Spracheingaben im Rahmen eines Dialogs reichen. Für jede Anwendung muss genau festgelegt werden, welche Eingaben wann zugelassen werden, wie komplex diese Eingaben sein dürfen, und wie der Roboter darauf reagieren soll.

3. Bewegung. Hierzu gehören sowohl Fortbewegung als auch Animationen, die sorgfältig geplant und koordiniert werden müssen, vor allem wenn es um Bewegungsabläufe und Bewegungssequenzen geht. Außerdem spielt das Thema Sicherheit hier eine Rolle, denn es gilt sowohl Kollisionen des Roboters mit seiner Umgebung als auch zwischen dem Roboter und seinen eigenen Extremitäten zu vermeiden.

4. Navigation. Die Aufgabe, sich in einem bestimmten Areal so zurechtzufinden, dass bestimmte Orte zuverlässig angesteuert oder eine bestimmte Route eingehalten werden kann, gehört zu den schwierigeren Problemen der Roboteranwendungsprogrammierung. Für eine Anwendung, die Navigation beinhaltet, muss der Roboter mit Hilfe des Menschen zunächst eine interne Karte des Zielgebiets erstellen, sich anschließend in dieser Karte lokalisieren, um dann schließlich mit Hilfe seiner Sensoren auf Grundlage der Karte und seines Standorts darin, seine Navigationsaufgaben erfüllen zu können.

5. Dialog. Weil die Interaktion mit Menschen zu den zentralen Aufgaben eines sozialen Roboters gehört, kommt der Entwicklung von Dialogen eine besondere Bedeutung zu. Hierfür muss zunächst der Ablauf des Dialogs mit dem Menschen sorgfältig antizipiert werden, möglichst unter Berücksichtigung aller Varianten und Verzweigungen. Außerdem ist auf die sprachliche Gestaltung zu achten, damit die Sprache des Roboters möglichst konsistent, angemessen, nicht zu kompliziert und ohne allzu gravierende Ausspracheprobleme ist.

6. Emotionale Intelligenz. In diesem Bereich ist die Frage, ob und inwieweit der Roboter auf wahrgenommene Emotionen seines menschlichen Gegenübers reagieren soll und auch reagieren kann. Zwar besitzen heutige soziale Roboter schon die Fähigkeit, grundlegende Emotionen oder das Lachen eines Menschen zu erkennen, aber die subtileren Aspekte der menschlichen Kommunikation von Emotionen sind ihnen (noch) verborgen. Deswegen muss bei der Programmierung sorgfältig abgewogen werden, inwieweit man sich bei Emotionen und ihrer Interpretation auf die Fähigkeiten des Roboters verlässt.

Die Entwicklungswerkzeuge

Glücklicherweise stellen die Hersteller von sozialen Robotern Programmierschnittstellen, Entwicklungssprachen und Entwicklungsumgebungen zur Verfügung, mit denen sich diese Aspekte und ihr Zusammenspiel im Rahmen der Anwendungsentwicklung realisieren lassen. Im Folgenden werden beispielhaft die Werkzeuge beschrieben, die für die Entwicklung von Anwendungen für das Robotermodell Pepper von Softbank Robotics in der Sparkasse eingesetzt werden.

Die Plattform, auf der die für Pepper entwickelten Anwendungen laufen, besteht aus zwei Komponenten, dem Roboter und seinem Tablet. In früheren Versionen des Roboterbetriebssystems NaoQi (bis 2.5.10) war das Tablet, obwohl ein eigenständiger Computer, nicht mehr als ein Touchscreen, über den man mit gezeigten Elementen der Anwendung interagieren konnte. Die Hauptlast der Anwendungsausführung lag beim Roboter, der dies zusätzlich zu seinen eigenen Aufgaben leisten musste.

Programmiert wurden Anwendungen in der Sprache Python unter Zuhilfenahme einer von Softbank Robotics zur Verfügung gestellten grafischen Entwicklungsumgebung namens Choregraphe, mit der man einfache Anwendungen durch Verknüpfung von grafisch dargestellten modularen Code-Blöcken realisieren konnte. Außerdem besaß Choregraphe integrierte Editoren für Animationen und Bewegungspfade. Für die Programmierung von Inhalten für das Tablet musste man HTML, CSS und JavaScript beherrschen, denn auf dem Tablet lief lediglich ein Webbrowser und die in diesem Browser gezeigte Webseite war die grafische Benutzerschnittstelle der Roboteranwendung. Dialoge wurden in einer weiteren Sprache namens QiChat geschrieben, mit der man Dialogthemen erstellte, die aus ineinander verschachtelten Regeln für die Behandlung von natürlichsprachlichen Benutzereingaben sowie “Vorschlägen” für sprachliche Beiträge des Roboters zum Dialog bestanden. Die Koordination von Roboterverhalten, Tablet-Interaktion und Dialog in dieser Umgebung war eine echte Herausforderung für den Programmierer und erforderte es, dass sich Roboter, Dialog und Tablet die Bälle immer richtig zuspielen mussten.

Mit der aktuellen NaoQi-Version 2.9 hat Softbank Robotics einen radikalen Schnitt in der Entwicklung von Anwendungen für Pepper vollzogen. So gut wie alles, was im vorigen Abschnitt gesagt wurde, gilt für Version 2.9 nicht mehr. Zwar besteht die Plattform immer noch aus Roboter und Tablet, aber jetzt werden alle Anwendungen für das Tablet entwickelt und auch dort installiert. Während zuvor das Tablet im Wesentlichen ein Anhängsel des Roboters war, ist es seit Version 2.9 genau umgekehrt.

Dem Tablet kommt bei der Anwendungsentwicklung die zentrale Rolle zu, der Roboter ist nur noch Erfüllungsgehilfe. Das hat den großen Vorteil einer Umverteilung der Arbeitslast bei der Anwendungsausführung.”

Unter NaoQi 2.5.10 wurden die Verarbeitungskapazitäten des Tablets nur rudimentär ausgenutzt, während der Roboter neben seinem eigenen Betrieb auch noch die Anwendung verwalten musste. Mit Version 2.9 laufen die Anwendungen auf dem Tablet und der Roboter wird nur noch tätig, wenn er im Zuge einer Anwendung gebraucht wird.

Ebenfalls komplett anders ist die Software-Umgebung für Roboteranwendungen. Anwendungen für 2.9 werden ausschließlich als Applikationen für Googles Android entwickelt und in Java programmiert.”

Python, HTML, CSS und JavaScript sind dagegen Schnee von gestern. Dasselbe gilt für Choregraphe, das durch Android Studio mit einem Plug-In zur Interaktion mit Pepper sowie mit integrierten Werkzeugen für die Erstellung von Animationen, Dialogen und Bewegungspfaden ersetzt wurde.

Der große Vorteil des radikalen Schnitts ist, dass Programmierer mit einer ausgereiften Plattform, Sprache und Entwicklungsumgebung arbeiten können und sich mit sehr viel weniger Entwicklungssprachen als bisher herumschlagen müssen. Der große Nachteil für all diejenigen, die schon einen Katalog an Choregraphe/Python-Anwendungen haben, ist jedoch, dass sie alle Anwendungen noch einmal für Android neu entwickeln müssen, denn NaoQi 2.9 ist nicht abwärtskompatibel, d.h. sämtliche Choregraphe/Python-Anwendungen laufen nicht mehr. Werk­zeu­ge, die die Mi­gra­ti­on er­leich­tern, exis­tie­ren lei­der nicht. Au­ßer­dem müs­sen Cho­re­gra­phe/Py­thon-Ent­wick­ler oh­ne An­dro­id-Hin­ter­grund mit ei­ner ge­wis­sen Lern­kur­ve rech­nen, bis sie die neue Ent­wick­lungs­um­ge­bung be­herr­schen. Zu­sätz­lich wird mit 2.9 die Lat­te für die Ent­wick­lung von Ro­bo­ter-An­wen­dun­gen noch ein­mal hö­her ge­legt, denn mit An­dro­id Stu­dio las­sen sich An­wen­dun­gen nicht mal eben schnell durch das Ver­knüp­fen von gra­fi­schen Blö­cken ent­wi­ckeln, so wie in Choregraphe.

Zwar existiert die Sprache QiChat für die Dialogerstellung noch, jedoch hat sich auch hier die Syntax in etlichen Bereichen verändert. Außerdem sind Elemente weggefallen, die bis 2.5.10 noch zur Verfügung standen.

Das vereinfacht zwar das Erlernen der Sprache, engt aber auch den Spielraum des Entwicklers ein, weil einige liebgewordene Helferlein unter 2.9 nicht mehr zur Verfügung stehen.”

Dasselbe gilt übrigens auch für QiSDK, die Programmierschnittstelle zu Pepper, im Allgemeinen. Auch hier wurde der Funktionsumfang gegenüber 2.5.10 eingedampft. Dieser Maßnahme sind vor allem etliche Low-Level-Funktionen zum Opfer gefallen, die in der täglichen Programmierpraxis durchaus nützlich waren. Der Vorteil ist jedoch, dass die Programmierschnittstelle deutlich übersichtlicher geworden ist.

Insgesamt lässt sich aus der praktischen Erfahrung mit beiden NaoQi-Varianten, der auf Python und der auf Android basierenden, heraus sagen, dass die aktuelle Version 2.9 eindeutig die bessere Plattform ist. Stabilität, Robustheit und Sicherheit sind gegenüber 2.5.10 deutlich verbessert, wenn auch noch nicht optimal, und Android Studio ist vom Funktionsumfang und Entwicklungskomfort her im Vergleich zu Choregraphe ein Quantensprung so wie von Microsoft Paint auf Adobe Photoshop, wenngleich man dies mit einer gewissen Lernkurve bei der Bedienung erkauft. Und Softbank Robotics entwickelt NaoQi 2.9 weiter, wohingegen die Unterstützung für die Version 2.5.10 wohl spätestens ab 2020 langsam ihrem Ende zugehen wird.Dr. Peter Franke, Michael Frantz und Patrick Heinsch