Mensch und Roboter Hand in Hand

Wer hat sich nicht schon einmal einen Roboter gewünscht, der im Haus­halt hilft? Der zum Beispiel schon einmal den Kuchen­teig anrührt, knetet und ausrollt, während man selbst die Glasur vorbereitet, bzw. einem das lästige Gemüse­schnib­beln beim Kochen abnimmt. Oder einen kleinen Roboter­assisten­ten, der einem bei heimischen Bastel­arbei­ten die richtigen Werk­zeuge anreicht, wie man es aus OP-Sälen in Kranken­häusern kennt: „Roboter, Schrauben­zieher!“„Schraubenzieher, und weiter?“„Schraubenzieher, bitte!“

/images/blog/flexirob-hand-in-hand.jpg
Die Vision: Roboter und Mensch arbeiten zusammen [johanneswienke.de]

Zumindest in Industrie­szenarien ist das keine allzu weit entfernte Zukunfts­vision mehr. Flexibel anpassbare Roboter, die autonom oder Hand in Hand mit dem Menschen in einer Werkstatt oder Produktions­strasse arbeiten und diesen bei Fertigungs­auf­gaben unterstützen, sind schon seit geraumer Zeit ein strate­gisches Anliegen europäischer Wissenschaftler und der Robotik­industrie. So führt bereits die im Jahr 2009 ausgerufene europäische Strategic Research Agenda diese beiden Szenarien, den „Robotic Worker“ und den „Robotic Co-Worker“, als Kern­an­wen­dungs­sze­na­rien zukünf­tiger Industrie­robotik mit auf. Dabei geht es nicht um Groß­serien-Voll­auto­matisie­rung wie man sie z. B. aus der Auto­mobil­industrie kennt, in der Roboter an Roboter aufgereiht in Käfigen und – aus Sicher­heits­gründen – abge­schot­tet vom Menschen monatelang exakt die gleiche Aufgabe ausführen:

Vollautmatisierte Montage von Automobilen bei KIA

Es geht vielmehr um die Unter­stützung von Mitarbei­tern in kleinen und mittel­stän­dischen Unter­nehmen, deren Auftrags­lage sich relativ schnell ändern kann. Denkbar ist die Fertigung von Proto­typen, von denen häufig nur geringe, einstel­lige Stück­zahlen gefertigt werden. In diesem Kontext sind zur Zeit Hand­arbeits­plätze immer noch die Regel, d. h. Fachkräfte montieren und bearbeiten Bauteile bzw. bestücken und entladen Maschinen manuell. Häufig sind diese Arbeiten verbunden mit anstren­gender körper­licher Arbeit.

Eine Voll­automatisie­rung im klas­si­schen Sinne, also mit Robotern, die genau auf diesen einen Zweck ausgelegt sind und in aller Regel nicht oder nur sehr aufwendig an neue Fer­ti­gungs­auf­ga­ben angepasst werden können, macht hier allein schon aus ökonomischen Gründen keinen Sinn. Der durch die Einsparung einer Fachkraft gewonnene finan­zielle Vorteil wird sofort wieder zu­nichte gemacht durch den not­wen­digen, häufigen und kosten­inten­siven Einsatz von Experten, die den Roboter bei jeder Änderung im Pro­duk­tions­ablauf wieder an seine neue Aufgabe anpassen und um­program­mieren müssen. Zusätzlich sind viele Teil­aufgaben in solchen Fertigungs­prozessen sehr komplex und wenn überhaupt nur mit enorm hohem technischen Aufwand automatisch zu bewerk­stel­ligen, wie z. B. der berühmte Griff in die Kiste.

Die Idee ist vielmehr, den Menschen zu unterstützen, indem man ihm diejenigen Arbeiten überlässt, die er z. B. auf Grund besserer visueller Wahrnehmung und guten Finger­fertig­keiten kompetenter und schneller durchführen kann als jede Maschine, ihn aber durch den Roboter­assisten­ten von körperlich belas­ten­den Arbeiten zu befreien … der Roboter als dritte Hand. Damit jedoch beide, Roboter und Mensch, an einem Arbeits­platz gemeinsam sinnvoll zusam­men­arbeiten können, sind einige Heraus­forderun­gen zu bewältigen. Ein bisschen Buzzword-Bingo:

Flexibilität: Um sich den ständig wechselnden Aufgaben anpassen zu können und in beliebigen (engen, eingeschränkten) Arbeits­räumen mit dem Menschen zusammen zu arbeiten, ist im Vergleich zu her­kömmlichen Industrie­robotern zusätzliche Flexi­bi­li­tät nötig. Diese erhält man z. B. durch zusätzliche Bewegungs­achsen: übliche Industrie­roboter verfügen über bis zu sechs Achsen, ab sieben Achsen erhält man durch Redundanz zusätzliche Flexi­bi­lität.

Interaktion: Um teures und zeit­auf­wen­diges Um­program­mieren der Roboter durch Experten zu umgehen, muss der Mit­arbeiter vor Ort in der Lage sein, durch einfache, direkte Interaktion den Roboter an seine neuen Aufgaben und Arbeits­bedin­gun­gen anzupassen und ihn den eigenen Bedürf­nissen entsprechend zu programmieren.

Sicherheit: Die direkte physische Ko­operation zwischen Mensch und Maschine erfordert andere Sicher­heits­mecha­nis­men als Zäune und strikte Arbeits­raum­tren­nung, um die Sicherheit für den Menschen dennoch zu gewähr­leisten.

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

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

Auch moderne Roboter sind nicht leicht zu bedienen.

Die Aufgabe für die Probanden bestand im Prinzip aus einer Art Heißer-Draht-Spiel:
Der vorn am Roboter montierte Greifer sollte möglichst genau an dem Styropor-Parcours entlang geführt werden, während­dessen natürlich jede Kollision sowohl vorne am Greifer als auch am Rest des Roboter­körpers mit den Umgebungs­objekten vermieden werden sollte. Der Hintergrund: Genau durch diese Art des Führens (englisch: Kinesthetic Teaching) können dem Roboter Aufgaben beigebracht werden. Die in der Inter­aktion ent­stan­denen Bewe­gun­gen werden auf­gezeich­net und können auf Befehl schneller, langsamer oder leicht verändert wieder abgespielt werden. Der Fachbegriff hierfür lautet Teach-In und bezeichnet das aktuell übliche Verfahren, um Roboter „anzulernen“.

Wie man in dem Video sieht, geht das zum Teil gehörig schief! Die Versuchs­personen scheinen (trotz einer vorherigen Eingewöhungs­phase mit dem Roboter) überfordert von der Aufgabe, dem LBR den Parcours kollisions­frei bei­zu­bringen. Das liegt nicht an der Komplexität der Aufgabe: Eine einfache vorgegebene drei­dimensionale Bewegung wie die des Parcours aus der Studie nachzufahren, ist für uns Menschen typischer­weise zu bewältigen und wie wir später sehen werden auch in Verbindung mit einem Roboter leicht möglich. Der Grund ist die durch jahrelange Ingenieurs­kunst geschaffene, komplizierte Technik des LBR, die technische Vorteile, aber auch erhöhte Komplexität mit sich bringt. Denn hinter dem einen „I“ des Wortes „Interaktion“ verstecken sich noch zwei weitere: intuitiv und intelligent. Einem Roboterarm mit sieben Gelenken eine bestimmte drei­dimensio­nale Bewegung beizubringen und dabei gleichzeitig darauf achten zu müssen, dass er mit seinen sieben Achsen nicht mit Hinder­nissen im Arbeits­raum kollidiert, ist nicht intuitiv. Und eine vorgemachte Bewegung abspeichern und wieder abspielen zu können, ist nicht sonderlich intelligent.

Dieses Beispiel zeigt, dass in der Praxis mehr notwendig ist als nur die tech­nischen Möglichkeiten zu schaffen. Der Schlüssel, davon sind wir überzeugt, liegt in einer syste­ma­tischen Inte­gration von Hoch­techno­logie, maschi­nel­lem Lernen und einfacher Inter­aktion. Um ein solches Robotik­system für den Arbeiter vor Ort bedienbar zu machen, muss die eigent­liche techno­lo­gische Komplexi­tät im besten Fall hinter intuitiven Benutzer­schnitt­stellen und schritt­weiser Inter­aktion versteckt werden. Am Forschungsinstitut für Kognition und Robotik (CoR-Lab) der Univer­sität Biele­feld beschäftigen wir uns seit Jahren genau damit. Das Roboter­system, das oben im Video zu sehen war und auf einem KUKA LBR IV aufbaut, ist unsere Forschungs­plattform FlexIRob: ein Beispiel­szenario, bei dem wir diese Art von Integration untersuchen. Um die obige Aufgabe zu erleichtern, haben wir einen Ansatz entwickelt, mit dem jeder einen solchen Roboter an neue Umgebungen und Aufgaben anpassen kann. Die Idee ist im Prinzip einfach und beruht darauf, die komplexe Aufgabe in zwei Teil­schritte zu unter­teilen. Dass das funktioniert, ist im folgenden Video zu sehen:

Erleichterung der Interaktion durch Aufteilung in explizite Konfigurations- und assistierte Programmierphase (ab ca 1:15)

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

Im nächsten Schritt, geht es nun darum, ihm die eigentliche Aufgabe beizubringen. Das kann z. B. eine Schweiß- oder Klebenaht sein und auf verschie­denen Wegen passieren, z. B. erneut mit Hilfe von Kinesthetic Teaching, also dem direkten Führen des Roboters. Da dieser sich aber in seiner Umgebung nun schon zu bewegen weiß, braucht der Nutzer nicht mehr alle Gelenke gleichzeitig zu kontrollieren. Es reicht, dass er ihn vorn am Greifer entlang der spezifischen Aufgabe führt und der Roboter assistiert ihm dabei sozusagen bei der Hindernis­vermei­dung, wie in dem Video ab Minute 2:10 zu sehen ist. Diese Phase nennen wir deshalb Assisted Program­ming.

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

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

Christian Emmerich und Arne Nordmann sind Doktoranden am Forschungs­institut für Kognition und Robotik der Universität Bielefeld und beschäftigen sich mit lernenden, interaktiven Robotik­systemen.

Der RoboCup kommt

/images/blog/robocup-istanbul.png
RoboCup 2011 in Istanbul

In knapp drei Tagen, am kom­men­den Dienstag startet in Istanbul an der Grenze zwi­schen Eu­ro­pa und Asien die RoboCup-Welt­mei­ster­schaft 2011. Auch ein Team aus Bie­le­feld, ToBi (Team of Bielefeld) ist wie­der in der RoboCup@Home-Liga da­bei.

Ich habe deswegen die Gelegenheit des letzten Robotik-Stammtischs genutzt, um mit Frederic Siepmann, dem Verantwortlichen für das Bielefelder Team, ein wenig über den RoboCup und die Vorbereitungen dafür zu sprechen:

Ich: Hey Frederic. Ihr habt ja im letzten Jahr in Singapur den siebten Platz gemacht. Welche Unterschiede und Verbesserungen in diesem Jahr an Eurem System gibt es im Vergleich zum Vorjahr. Und sind überhaupt die Aufgaben wieder die gleichen?

Frederic: In diesem Jahr ist im Prinzip der selbe Funktionumfang wie im letzten Jahr gefordert. Es gibt immer einige kleine Änderungen an Aufgaben, in denen sich im vergangenen Jahr Probleme herausgestellt haben oder die Regeln nicht klar genug formuliert waren. Es hat sich auch ein bisschen etwas an der Punktevergabe geändert, aber im Prinzip sind es die selben Aufgaben.

Daher ist der Unterschied bei uns zum letzten Jahr vor allem, dass damals viele Sachen einfach mit der heißen Nadel gestrickt waren. Das konnten wir jetzt mal etwas intensiver testen und stabilisieren. Im Rahmen der @­Home-­Liga gibt es auch immer die sogenannte Demo Challenge. Dafür wird immer ein Thema vorgegeben und dort kann man dann im Prinzip tun, was man will. Es muss nur irgendwie in dieses Demo-Konzept passen. In Singapur im letzten Jahr war ein Restaurant-Kontext vorgegeben. Das heißt, wir haben zum Beispiel viel gesehen, dass der Roboter Bestellungen entgegennimmt und den Leuten Getränke bringt; wie man sich das eben von einen Roboter im Restaurant vorstellt. In diesem Jahr ist das Thema Household Cleaning vorgegeben. Da haben wir jetzt bei den German Open noch nicht so sehr viel gesehen, aber man sah, dass viele Roboter versuchen, Gegenstände vom Boden aufzusammeln und in den Müll zu schmeißen …

Ich: Ich glaube, ich habe auch gesehen, wie einer der Roboter versucht hat, mit einem Lappen einen Tisch sauberzumachen …

Frederic: Ja, genau. Das waren wir.

Ich: Ach, das wart Ihr. Und das werdet Ihr auch in Istanbul zeigen?

Frederic: Ja, wir werden mit Sicherheit wieder Tischsäubern zeigen. Wie Du ja weißt, ist die Plattform bei uns ja etwas eingeschränkt, da der Arm nicht soweit herauskommt. Aber wir haben jetzt noch ein paar Extra-Gimmicks eingebaut, zum Beispiel dass der Roboter jetzt dynamisch die Flächen erkennen kann und man dem Roboter zeigen kann, wo er reinigen soll. Es ist für den Roboter natürlich schwierig zu erkennen, wie schmutzig eine Fläche ist. Wenn da Konfetti liegen ist das noch okay, aber bei Staub wird es schon schwierig. Man muss da noch etwas sehen, welche Szenarien da denkbar sind, aber im Prinzip passt das.

Ich: Ihr wart ja im April bei den German Open und habt glaube ich den dritten Platz gemacht …

Frederic: Nee, nach der Vorrunde waren wir zwar auf dem dritten Platz, sind dann im Finale aber noch von den b-it-bots abgefangen worden.

Ich: Ein vierter Platz, mit dem Ihr zufrieden wart?

Frederic: Ja, auf jeden Fall.

Ich: Ich nehme aber an, dass Ihr auch von dort noch Dinge mitgenommen habt, die noch zu verbessern sind?

Frederic: Ja. Die German Open – und vermutlich alle nationalen Vorentscheide – sind immer so ein bisschen ein erster Test Case. Da hat man dann normalerweise zum ersten Mal on site wirklich Zeit, das System intensiv zu testen. Die Studenten bekommen dann auch zum ersten Mal wirklich mit, wie das ist: Wenn es dann wirklich auf Kommando losgehen soll, hektisch ist und die Hardware überall herumfliegt usw. … von daher ist das ein super Testszenario, das würde ich auch nicht missen wollen.

Ich: Zum ersten Mal auch unter den echten Wettkampfbedingungen …

Frederic: Richtig! Man muss dann auch zum ersten Mal richtig in die Arena hereinfahren und dann stehen dort Objekte und Möbel herum, die man nicht erkennen kann. Man kann sich dann auch wirklich intensiv und mit viel Zeit um den Roboter kümmern, da ja dann auch das gesamte Team da ist. In der Uni mischen sich dann ja auch immer viele andere Dinge dazu. Das hat uns auch wieder ziemlich viel gebracht in diesem Jahr. Wir konnten viele Dinge für die weitere Arbeit in unserem Wiki festhalten: Dinge, die gut und Dinge, die nicht so gut gelaufen sind und die wir noch verbessern wollen.

Ich: Seit wievielen Jahren seit Ihr jetzt mit Eurem System beim RoboCup@Home vertreten?

Frederic: Tatsächlich erst seit 2009. Damals sind wir aus dem Stand auf den achten Platz gekommen, was ziemlich gut war. Im letzten Jahr sind wir dann wie gesagt Siebter geworden, dieses Jahr werden wir sehen, was passiert.

Ich: War das damals die gleiche Plattform wie in diesem Jahr?

Frederic: Ja gut, wir haben die seitdem natürlich etwas modifiziert, aber die Basis ist die gleiche geblieben. Wir hatten damals die neue Plattform bekommen und in dem Rahmen beschlossen, dass die Teilnahme an der @Home-Liga eine brauchbare Sache wäre. Diese Liga hat eben Anforderungen, die unserer sonstigen Forschung insgesamt schon recht ähnlich sind. Das erste Team hat natürlich erst einmal die meiste Arbeit, weil einige der Basiskomponenten einfach noch nicht für die Plattform zur Verfügung standen. SLAM zum Beispiel musste erst einmal darauf gebracht werden. Oder Objekterkennung. Das war zwar schon vorhanden, aber eben noch nicht auf dieses Robotersystem portiert. Das war viel Arbeit zu Beginn.

Ich: Kommen bei Euch denn jetzt eigentlich auch im Vergleich zur German Open noch weitere Features dazu?

Frederic: Stabilität ist natürlich auch ein Feature. (lacht) Wir haben aber tatsächlich auch noch ein wenig grundlegend an der Software gearbeitet. Zum Beispiel die Ansteuerung des Arms und die Objekterkennung verbessert. Das heißt, da können wir jetzt auch noch etwas mehr als bei den German Open.

Das klassiche Problem ist ja zum Beispiel, dass wenn man ein Objekt erkannt hat, man den Roboter erst einmal so positionieren muss, dass der Arm das Objekt überhaupt greifen kann. Das stellt sich im Moment noch etwas als Schwierigkeit heraus. Die Software haben wir schon, sie ist aktuell aber einfach noch nicht vollständig ins System integriert.

Ich: Also Frederic, ich nehme an, Deine letzten Wochen waren deutlich von der Arbeit für den RoboCup bestimmt?

Frederic: Das würde ich sofort unterschreiben, ja!

Ich: Das kostet ja insgesamt schon ziemlich viel Zeit, insbesondere natürlich in der Vorbereitung eines Turniers. Inwiefern, würdest Du sagen, profitiert da ein Institut oder vielleicht sogar Du als Wissenschaftler von?

Frederic: Super Frage! Also bei uns ist es ja tatsächlich so, dass ca. 90 Prozent der Teammitglieder jedes Jahr wechseln. Da kommen also jedes Jahr frische, neue Studenten, die an dem Roboter arbeiten wollen. Das ist mit Sicherheit auch etwas Besonderes von dem Bielefelder Team, was natürlich auch besondere Anforderungen an die Entwicklungsumgebung stellt. Wir machen das aber natürlich sehr gerne, weil wir dadurch sehr früh die Studenten mitnehmen können. Von der universitären Seite ist natürlich sehr spannend, dass wir die Studenten so sehr früh in unsere Software einführen können. Die können dann damit wirklich coole Sachen machen, wir haben zum Beispiel unheimlich viele studentische Abschlussarbeiten im Rahmen unserer RoboCup-Teilnahme. Außerdem kommen so auch immer wieder Studenten als Hilfswissenschaftler zu uns. Davon kann natürlich die Universität und das Institut ganz enorm profitieren. Einfach auch weil wir damit natürlich auch viel Manpower dazugewinnen.

Das System als solches, das wir in dem Rahmen entwickeln, und die Entwicklung, die man in der Kürze der Zeit damit macht, würde man wahrscheinlich sonst auch in der Form nicht hinbekommen.

Ich: … wegen der fokussierten Arbeit an einer lauffähigen und stabilen Version …

Frederic: Genau! Also, man mag mir da widersprechen, aber es ist sonst im universitären Umfeld auch nicht so häufig, dass so stark in Richtung eines Systems gearbeitet wird, das wirklich stabil auf einer Plattform läuft.

In wissenschlaftlicher Hinsicht ist der RoboCup immer durchaus zwiespältig diskutiert. Einige sagen, dass die Verfahren einfach schon seit Jahren bekannt sind und es im Prinzip nur darum geht, die schnellere Hardware zu haben. Zum Teil ist das sicherlich auch berechtigt und mag stimmen. Gerade beim Roboterfußball hört man das häufig.

Bei der @Home-Liga trifft das sicherlich nicht so sehr zu. Da lässt sich durch schnellere Hardware nicht so viel wettmachen, weil viele Probleme hier einfach auch noch nicht gelöst sind.

Ich: In der @Home-Liga passiert also auch noch mehr Forschung, würdest Du sagen? Weil es da auch konzeptionell noch mangelt?

Frederic: Die @Home-Liga ist auch einfach noch eine der jüngsten Ligen des RoboCup, ich glaube erst 2005 gegründet worden, und seitdem die am stärksten wachsende Liga. Und die Teilnehmer, ob jetzt Georgia Tech, University of Tokio, Osaka University, Bielefeld und einige andere … das sind Namen, die man durchaus auch im Forschungsumfeld viel hört.

Es sind einfach auch viele Probleme wirklich noch ungelöst. Daher würde ich schon sagen, dass wenn man Forschung in diesem Bereich macht – was Grundvoraussetzung ist – kann man da durchaus von profitieren. Auch, da man dadurch ja Systeme bekommt, mit denen man dann empirische Daten aufnehmen kann. Häufig hat man eben in der Robotik einzelne Komponenten, aber ohne lauffähiges Gesamtsystem kann man keine vernünftigen Tests machen. Das Problem haben wir nicht.

Ich: Du würdest also sagen, dass Du auch als Wissenschaftler davon profitierst?

Frederic: Vielleicht nicht so viel wie ich könnte, aber im Prinzip auf jeden Fall, ja.

Ich: Und ich nehme an, du würdest Studenten in der Robotik auch jederzeit empfehlen, an solchen Wettbewerben teilzunehmen, sofern die Möglichkeit an der Universität oder dem Institut besteht?

Frederic: In meinen Augen ist das das beste, was man machen kann. Das ist das echte Entwicklerleben und nicht die berühmte trockene Theorie, die einem ja sonst häufig in der Informatik vorgeworfen wird. Das einmal mitgemacht zu haben, ist auch wirklich ein Erlebnis. Kann natürlich auch sehr frustrieren sein, wenn es nicht funktioniert. Aber wenn man dann dazu beigetragen hat, einen Platz XY bei der Weltmeisterschaft zu machen und Sachen, die man selbst programmiert hat vor einem Publikum präsentieren kann und der Roboter räumt dann richtig ab … das ist einfach nur genial!

Ich: Okay, Frederic. Danke vielmals für den ausführlichen Einblick und viel Erfolg mit Team ToBi in Istanbul!

Frederic: Danke.

Das Team ToBi bloggt übrigens auch fleißig über den Turnierverlauf und die Vorbereitungen. Frederic Siepmann ist Diplom-Informatiker am Center of Excellence Cognitive Interaction Technology (CITEC) in Bielefeld und seit 2008 Teamlader des Team ToBi.