Start → Blog → artikel

Blog abonnieren

Artikel

Ab und zu gehen Blogeinträge über den schnellen Einwurf hinaus und werden zu bescheidenen Artikel. Diese Artikel tauchen auch immer im Blog auf, können aber hier auch separat abonniert werden.

• Ursprung der Technik: Roboter

  von Jörn am 29.03.2013 um 16:43 Uhr

  Hier ein Hinweis auf einen Beitrag, den ich heute auf ZDF Info sah. Habe ihn gerade auch auf Youtube gefunden:

  Ursprung der Technik: Roboter

  Für mich bleibt der verwendete Roboter-Begriff immernoch etwas befremdlich und weit gegriffen. Wenngleich mich einige ungenaue und irreführende Formulierungen sowie der übermäßige Gebrauch von Superlativen etwas stört, finde ich in dem Beitrag dennoch eine nette Zusammenstellung über die historischen Anfänge der Automatisierungstechnik. Der Beitrag hat bei mir letzlich ein wenig Appetit geweckt, mich in Zukunft mit der Materie zu befassen.

  zu den Kommentaren
  

• Elastische Roboterarmkörper – Fluch oder Segen?

  von Jörn am 10.02.2013 um 16:57 Uhr

  Die Vermeidung unerwünschter elastischer Effekte stellt eine große Herausforderung bei der Konstruktion von Robotern dar. Sie erschweren die präzise Positionierung des Roboterarms aufgrund statischer lastabhängiger Verbiegungen und schwingen nach jeder Bewegung nach. Vergleichbare Beispiele, bei denen Elastizitäten meist unerwünscht sind, finden wir fernab der Robotik bei Baumaschinen, wie Auto-Betonpumpen, Hubwagen aber auch Feuerwehrdrehleitern.

  Wie wäre es, wenn auf die Steifigkeit bei der Auslegung einer Maschine weniger Wert gelegt werden müsste, da den damit einhergehenden unerwünschten Effekten mit regelungstechnischem Mitteln begegnet werden kann? Mechanische Strukturen könnten mit schlicht weniger Material leichter gebaut werden. Infolge dessen ließen sich Antriebe kleiner dimensionieren und hätten einen geringeren Energiebedarf.

  Dieser Gedanke ist genau die Idee hinter dem Forschungsthema, dass ich bearbeite. Im Rahmen des Forschungsthemas haben wir den nachfolgend dargestellten gliedelastischen Roboterarm TUDOR als Experimentalsystem entwickelt.

  Das gliedelastische Experimentalsystem TUDOR

  Er wird von drei bürstenlosen Gleichstrommotoren angetrieben und besitzt zwei Federstahlbalken als elastische Armkörper. Bei einer typischen Punkt-zu-Punkt-Bewegung der Antriebe treten Schwingungsamplituden von bis zu 10 cm auf.

  Auf den Roboter-Konferenzen dieser Welt werden aktuell viele Beiträge zu Robotern mit elastischen Komponenten vorgestellt. Die elastischen Komponenten werden meist in die Robotergelenke integriert. Ein sehr heißes Thema sind vor allem Gelenke, bei denen sich die elastischen Eigenschaften der Komponenten aktiv variieren lassen. Die Elastizitäten bewirken, dass die aufgrund der hohen Getriebeübersetzung üblicher Roboterarme sehr großen Trägheitsmomente der Antriebe von den Trägheitsmomenten des übrigen Arms entkoppelt werden. Das bedeutet, dass im Falle eines physischen Kontakts mit dem Roboter der Interaktionspartner eine geringere Trägheit des Armes "sieht". Damit kann beispielsweise eine Verringerung des Gefährdungspotenzials des Roboters erzielt werden. Auf der anderen Seite speichern die Elastizitäten zusätzliche Energie, die im Falle eine Kollision freigesetzt und wiederum ein erhöhtes Gefahrenpotential (Peitscheneffekt) zur Folge haben kann. Häufig werden Elastizitäten eingesetzt, um dem Roboter zu natürlicheren und auch dynamischen Bewegungen zu verhelfen. Es ist festzuhalten, dass durch eine geeignete Regelung gezielt eingesetzte elastische Komponenten zahlreiche Möglichkeiten eröffnen.

  Aus regelungstechnischer Sicht sind die elastischen Eigenschaften in den Robotergelenken am einfachsten zu beherrschen. Hier ist die Elastizität entlang der Wirkachse der Antriebe konzentriert. Überwiegt die Elastizität in den Roboter Armkörpern, so sind die elastischen Eigenschaften entlang der Armkörper und senkrecht zur Wirkachse der Antriebe verteilt. Die dadurch entstehenden Laufzeiteffekte erschweren eine Regelung des Roboterarms. Dies mag der Grund sein, aus dem derzeit vorwiegend Arbeiten zu gelenkelastischen Roboterarmen publiziert werden.

  Mit TUDOR hat uns zunächst die Frage interessiert, ob wir mit einem gliedelastischen Roboterarm trotz der Schwingungen und last- und konfigurationsabhängigen variablen Verbiegungen eine zielgerichtete Aufgabe präzise in geforderter Zeit erledigen können. Als Demonstration hierzu haben wir uns, wie im nachfolgenden Bild dargestellt, das Fangen eines Balles ausgedacht.

  Ballfangen-Szenario

  Ein menschlicher Werfer wirft den Ball in Richtung des Roboters. Die Flugbahn wird mittels einer Kinect-Kamera ermittelt und der Durchstoßpunkt der Flugbahn mit der Bewegungsebene des Roboters berechnet. Bevor der Ball am Roboter vorbei fliegt, bewegt der Roboter ein am Armende montiertes Netz dorthin und fängt den Ball damit auf. Das Resultat haben wir im nachfolgenden Video zusammengefasst:

  A multi-link-flexible robot arm catching thrown softballs.

  Sofern die Schwingungen regelungstechnisch unterdrückt und Abweichungen aufgrund statischer Verbiegungen kompensiert werden können, ließen sich in manchen Anwendungen diese elastischen Eigenschaften vielleicht nicht mehr nur als Problem verstehen. Vielmehr könnten elastische Eigenschaften vielleicht auch ausgenutzt werden, um beispielsweise Kontaktsituationen zu erkennen und darauf zu reagieren. Mit aktiv geregelten moderat gelenkelastischen Roboterarmen wurde dies ja bereits eindrucksvoll gezeigt.

  Bezüglich gliedelastischer Roboter ist die Dämpfung auftretender Schwingungen bislang noch das dominierende Thema in Publikationen.

  In den vergangenen Tagen konnten wir hier womöglich einen ersten Schritt über die reine Schwingungsdämpfung hinaus machen. Basierend auf einer Kraftregelung ist es uns gelungen ein Regelungskonzept zu entwickeln, bei dem wir die Schwingungen der mechanischen Struktur eines Roboterarms unterdrücken und zugleich die Nachgiebigkeit aktiv beeinflussen können. Einige Experimente dazu haben wir in nachfolgendem Video festgehalten:

  Video zur Kraftregelung eines gliedelastischen Roboterarms

  In dem Regelungskonzept wird die Information über die auf die Robterarme einwirkenden Kräfte mittels Dehnungsmessstreifen erfasst und individuell auf die Antriebsregler zurückgeführt. Auf diese Weise werden Schwingungen in der Armstruktur unterdrückt obgleich sie von der Gelenkbewegung oder der Interaktion mit der Umgebung herrühren. Zusätzlich lässt sich die Nachgiebigkeit des Roboterarms derart beeinflussen, dass wir mit sehr wenig Kraft den Roboterarm aus seiner aktuellen Position schieben können und die Wahrscheinlichkeit fragile Objekte bei einer unvorhergesehnen Kollision zu zerbrechen deutlich reduziert wird.

  Also: elastische Roboterarmkörper - Fluch oder Segen? Trotz dieser Experimente sind noch zahlreiche Herausforderungen zu meistern und fragen zu beantworten. Dennoch scheint es mir, als schlummertem in den Elastizitäten der Armkörper nicht nur Probleme, sondern auch Potenziale.

  Ich freue mich darauf zu sehen, wo die Reise noch hinführen wird.

  zu den Kommentaren
  

• Simulation des Bionischen Handling-Assistenten

  von Arne am 17.04.2012 um 11:27 Uhr

  Im April 2010 wurde der Bionische Handling-Assistent (BHA) von Festo auf der Hannover Messe der Öffent­lich­keit vorgestellt. In den fol­gen­den Mona­ten sah dieser bio­lo­gisch inspirierte Roboter­arm zu recht eine große Medien­präsenz und wurde mit zahl­reichen Prei­sen, unter anderem dem Deutschen Forschungspreis 2010, aus­ge­zeich­net. Im Februar 2011 bekamen wir dann unseren eigenen BHA, voller Vor­freude, denn wir wussten, dass niemand bislang mit dem BHA tun konnte, was wir mit ihm vor­hat­ten: ihn zu kon­trol­lieren. [1]

  Die Struktur und Funk­tions­weise des BHA ist inspi­riert von einem Elefan­ten­rüs­sel, wie in fol­gen­der Ab­bildung un­schwer zu erken­nen ist. Der Arm wird im Sinne des Rapid Proto­typings im 3D-Drucker gedruckt. Als Material wird Polyamid ver­wen­det, wodurch der gesamte Arm leicht-gewich­tig und durch­gängig ver­form­bar wird: Im Wesent­lichen besteht der BHA also aus Plastik und einer Menge Luft. Bewegt wird der Arm von drei­zehn pneu­ma­ti­schen Ven­tilen, die die drei­zehn Kammern des Robo­ters mit Luft füllen oder ent­leeren. Dies wiederum verbiegt, beugt und streckt die kom­plet­te Struktur.

  Von einem Elefantenrüssel inspiriert

  Festo hat mit dem BHA die Vision eines leichten, frei­beweg­lichen Dritte-Hand-Systems, das den Men­schen bei seiner Arbeit unter­stützen kann. Dank seiner struk­tu­rel­len Nach­giebig­keit (Compliance) ist der Arm im Kontakt mit Menschen und seiner Umgebung natur­gemäß sicher, was die Mög­lich­keiten von direkter Zu­sam­men­arbeit von Mensch und Roboter eröffnet. In in­dustriel­lem Kontext kann der BHA in Fertigungs­pro­zes­sen ein­ge­setzt werden, z.B. um mit empfind­lichen Gütern wie z.B. Lebens­mit­teln zu arbeiten.

  Als wir uns ent­schlos­sen haben, Festos Bio­nischen Handling-Assisten­ten zu erwer­ben, wussten wir, dass wenige der klas­si­schen und bekannten Ver­fahren mit diesem Roboter funktio­nie­ren würden. Trotz­dem war über­raschend, dass der Roboter ohne jeg­liche Software aus­ge­lie­fert wurde.

  Keine Software.

  Nichts.

  Noch bis vor einem Jahr konnten wir mit dem BHA nicht viel mehr tun, als von Hand die pneu­ma­ti­schen Ven­tile zu öffnen und zu schließen, um damit entweder vol­len Druck oder gar keinen Druck in die Kam­mern zu geben. Auch damit waren die Be­we­gun­gen des Robo­ters absolut fas­zi­nie­rend und wir hatten großen Spaß, aber ernst­hafte An­wen­dungen waren damit natür­lich noch nicht möglich. Wie von Festo zugesagt, bekamen wir dann vor fast genau einem Jahr elektro­nische Ventile, mit denen wir (mehr oder weniger präzise) den Druck in den Kammern auto­ma­tisch vor­geben konnten. Nicht mehr und nicht weniger: den Druck kon­trol­lie­ren.

  Um es einmal vorsichtig zu sagen: Der Schritt von dieser Druck­re­ge­lung zu einer ernst­haften An­wendung mit dem BHA ist groß!

  Das tat­säch­liche Werkzeug, dass man mit dem BHA kon­trol­lieren will, ist der so­ge­nan­nte Fin Gripper am Ende des Arms. Diesen Greifer zu al­ler­dings genau zu po­si­tio­nie­ren setzt zu­al­ler­erst voraus, die Postur des Arms prä­zise bestimmen zu können. Den Druck in den ein­zel­nen Kam­mern zu kennen, reicht dafür bei weitem nicht aus; dass dies zum Scheitern ver­ur­teilt sein würde, diese Er­fah­rung hatten wir bereits mir anderen Robo­tik­platt­for­men gemacht: Zehn Mal den gleichen Druck auf einen pneu­ma­ti­schen Roboter zu geben, ergibt im Regel­fall zehn ver­schie­dene Posturen des Robo­ters. Reibung, Reibung, Hyste­rese-Effekte und Nicht-Stationaritäten ver­ändern das Ergeb­nis von Mal zu Mal.

  Die kinematische Struktur des BHA

  Um diesen Problemen zu begegnen, besitzt der BHA Längen­sen­soren (Kabel-Poten­tio­meter), um an der Außen­seite des Arms die Streckung der einzel­nen Kam­mern zu messen (siehe obige Abbildung). Natür­lich wollten wir diese Länge nicht nur kennen, sondern auch kontrol­lieren können. Das ist theore­tisch mit klas­si­scher (PID-)Regel­technik möglich, aber funktio­niert auf diese Weise nur sehr schlecht. Um dieses Ver­hal­ten zu verbes­sern, könnte man nun ver­suchen, all das Wissen über den BHA in eine aus­ge­feil­tere Regelungs­technik zu stecken. Wenn man dieses Wissen bloß hätte …

  Eine kurze Liste von Dingen, die man über den BHA nicht weiß:

  1. Das präzise Verhältnis zwischen Druck in den Kammern und der geo­me­trischen Postur im Ruhe­punkt (im Equi­li­brium)

  2. Jegliche Art von Dynamik (nicht nur der Pneu­ma­tik selbst, sondern auch des sehr viel lang­sa­me­ren Zusam­men­spiels zwischen der Pneu­matik und Geo­me­trie)

  3. Welche Länge des Arms bzw. der einzelnen Kam­mern ist über­haupt mög­lich? Wo liegen die Gren­zen?

  4. Und nicht zuletzt: Wie genau ist das Zusam­men­spiel der obigen Aspekte zwi­schen den einzel­nen Kam­mern. Denn: Es be­steht ein starker Zusam­men­hang!

  Alles zusammen eine große Heraus­for­de­rung … aber nicht un­mög­lich. An­ge­nom­men also, die Länge des Aktu­a­tors lässt sich mes­sen und kontrol­lieren. Um nun die End­ef­fektor-Posi­tion (die Posi­tion des Greifers) zu kon­trol­lieren … muss man die aktu­el­le End­ef­fek­tor-Posi­tion kennen!

  Die Endeffektor-Position anhand der Geo­metrie des Robo­ters und der Stel­lung der Aktua­toren zu er­rech­nen, nennt sich Vor­wärts-Kine­ma­tik und ist für handels­übliche Robo­ter kein großes Pro­blem, son­dern ein­fache Tri­go­no­metrie. Der BHA gehört allerdings zu einer anderen Klasse von Morpho­lo­gien, genannt Conti­nuum Kine­ma­tics (also in etwa: konti­nu­ier­liche Kine­ma­tik). Dank seiner mecha­ni­schen Flexi­bi­li­tät besitzt dieser Robo­ter­arm unend­lich viele Frei­heits­grade, da jeder Bereich des Robo­ters unter­schied­lich gebo­gen und ge­streckt sein kann. Unend­lich viele Frei­heits­grade kön­nen weder mit Sen­so­ren ge­mes­sen noch berech­net werden.

  Als wir unsere Arbeit mit dem BHA be­gon­nen haben, planten wir nicht, die kom­pli­zier­te Kine­ma­tik des BHA zu simu­lie­ren. Da wir uns im Kontext des BHA haupt­säch­lich mit Maschi­nel­lem Ler­nen be­schäfti­gen, wollten wir die End­ef­fek­tor-Posi­tion schlicht messen, um sie be­nut­zen zu können (tun wir auch). Dass wir trotzdem eine Simu­la­tion benö­ti­gen würden, stellte sich heraus, als wir Schwierig­kei­ten in der Vi­suali­sie­rung bekamen. Wir wollten nämlich dar­stel­len, wie die räum­lichen Koor­di­na­ten mit den Be­we­gun­gen des BHA zu­sam­men­hän­gen.

  Da Visualisierung Kenntnis der Kinematik voraus­setzt, began­nen wir, sie an­zu­nähern. Selbst wenn sich die Beugung und Streckung von unend­lich vielen Frei­heits­graden nicht berech­nen lässt, so lassen sich doch durch die Längen­senso­ren einige An­nah­men zur Beugung des Arms tref­fen. Die einfach­ste Art der Beugung ist eine kreis­förmige; im drei-dimen­sio­nalen Fall ent­spricht dies einem Torus:

  Torus-Modell zur Annäherung der Beugung des BHA

  Das Bild zeigt, wie sich ein Segment mit drei Aktua­toren (in der Ab­bil­dung als graue Röhren dar­ge­stellt) entlang eines Torus verbiegt. Diese Geometrie kann mit drei Parametern beschrieben werden: zwei Winkel (in der Abbildung blau dargestellt) und der Radius des Torus (in der Abbildung rot). Diese drei Parameter können anhand der gemessenen Längen an der Außenseite der BHA-Segmente rekonstruiert werden. Sobald diese Parameter bestimmt sind, ist das Berechnen der Vorwärtskinematik und damit die Bestimmung der Endeffektor-Position (also der Position des Greifers) einfach. Ein Problem tritt lediglich im Grenzfall auf, wenn alle Längen gleich sind, wenn also alle Kammern gleich gestreckt sind. Diese Verformung kann durch einen Torus nicht dargestellt werden, obwohl der BHA zu solch einer Bewegung in der Lage ist. Auch für dieses Problem ließ sich allerdings eine einfache, numerisch stabile Lösung finden. Der BHA lässt sich somit durch Aufeinandersetzen dreier solcher Segmente darstellen und simulieren.

  Die gezeigten Torusdeformationen sind sehr einfache Annäherungen des Arms im Vergleich zu kom­plexen Physik des Ver­for­mungs-Pro­blems. Üblicherweise ist diese Art von Annäherung daher nicht hinreichend für diese Art von Robotern (siehe z.B. Trivedi 2008 [2] ). Nicht jedoch für den BHA: Hier funktioniert die beschriebene Lösung sehr gut, in unseren Tests sehen wir einen durchschnittlichen Fehler von 1cm auf einer Länge von 1m. Nicht perfekt, aber absolut ausreichend für unsere Zwecke und außerdem durchaus konkurrenzfähig zu Lösungen in der Literatur.

  Das folgende Video zeigt das simulierte Modell und unseren BHA:

  BHA-Simulation

  Der große Vorteil des benutzten einfachen Torus-Modells ist seine Geschwindigkeit in der Berechnung. Unsere Software-Bibliothek ist auf Basis dieses Modells in der Lage, die Vorwärtskinematik des BHA auf einem einzelnen CPU-Kern mehrere zehntausend Mal in der Sekunde zu berechnen. Auch wenn wir diese Simulation ursprünglich nicht geplant hatten, ist sie damit mittlerweile eine essentielles Werkzeug bei unserer Arbeit mit dem BHA geworden. Die interessanten Dinge machen wir weiterhin auch auf der echten Hardware, aber parallel lassen sich nun viele Dinge bequem vorberechnen und darstellen.

  Die Kinematik-Simulation ist in C++ implementiert und als Open-Source-Bibliothek verfügbar. Über die folgende Seite kann sie heruntergeladen werden und enthält sowohl die Vorwärtskinematik als auch die gezeigte OpenGL-basierte 3D-Visualisierung: http://www.cor-lab.de/software-continuum-kinematics-simulation Wir freuen uns über Benutzer und Erfahrungsberichte.

  Der folgende einfache Code-Schnipsel berechnet zum Beispiel die Vorwärtskinematik des BHA:

  // create robot morphology with segment radii 0.1, 0.09 and 0.08 meters ContinuumRobotKinematics kinematics(RealVector(0.1, 0.09, 0.08)); // specify an end effector offset kinematics.setEndEffectorOffset(RealVector(0.0, 0.0, 0.14)); // this is the forward kinematics function: Mapping<RealVector,RealVector> fwdKin = kinematics.getForwardPositionKinematics(); // try out some posture (a combination of actuator lengths) RealVector posture = {0.2,0.24,0.24,0.2,0.24,0.24,0.2,0.24,0.24}; // this is the resulting end-effector position RealVector position = fwdKin(posture); // [-0.3808, 0, 0.686287]

  Neben der in diesem Artikel beschriebenen Kinematik-Berechnung und Simulation des BHA, haben wir in den letzten Monaten noch viele weitere spannende Dinge mit dem BHA gemacht, die wir auf der Automatica-Messe im Mai in München zeigen werden: Um zu sehen wie wir trotz der zahlreichen obigen Probleme mithilfe maschineller Lernmethoden den Greifer auf dem echten BHA im Arbeitsraum zu kontrollieren gelernt haben, lohnt sich also ein Besuch unseres Standes auf der Automatica in München: Stand 427 und 429 in Halle B3, vom 22. bis 25. Mai.

  Kontakt:

  • Dipl.-Inform. Matthias Rolf, CoR-Lab - Bielefeld University, mrolf@cor-lab.uni-bielefeld.de

  • Prof. Jochen Steil, CoR-Lab - Bielefeld University, jsteil@cor-lab.uni-bielefeld.de

  1

  „Kontrollieren“ im regelungstechnischen Sinne. Hier also gemeint: Regeln der Endeffektor-Position.

  2

  Geometrically Exact Models for Soft Robotic Manipulators

  Matthias Rolf ist Wissenschaftler am Re­search In­sti­tute for Cog­nition and Ro­bo­tics an der Universität Bielefeld. Sein Hauptinteresse in der Forschung ist *Motor Learn­ing in Develop­men­tal Robotics.

  zu den Kommentaren
  

• Der RoboCup kommt

  von Arne am 02.07.2011 um 11:53 Uhr

  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.

  zu den Kommentaren
  

• Robuste Roboterhand vom DLR

  von Arne am 10.02.2011 um 17:01 Uhr

  Einen Vorgeschmack zur weiteren Entwicklung in der Robotik hat das Deutsche Zentrum für Luft- und Raumfahrt (DLR) in den letzten Tagen geliefert: Angetriggert von einem Artikel in der IEEE Spektrum, wie ich annehme, berichteten in den letzten Tagen allerhand englischsprachige Robotik-Blogs (z.B.) über die neue Roboterhand, die das DLR vorgestellt hat.

  Leichtbau-Hand des DLR

  Die Hand sieht nicht nur spektakulär aus, ihre wahre Sensation liegt zum einen in ihrer Ähnlichkeit zur menschlichen Hand und vor allem in ihrer Robustheit. Die Ähnlichkeit zur menschlichen Hand liegt maßgeblich im (technische) Design begründet, das dem Bewegungsapparat der menschlichen Hand sehr Nahe kommt. Dass die Hand in den Blogs dieser Welt unter Bezeichnungen wie Super Robust Robot Hand geführt wird, ist darin begründet, dass das DLR zeigen kann, dass diese Hand selbst mehrere Schläge mit einem Hammer überlebt; mit nahezu allen bisherigen Robotik-Bauteilen absolut undenkbar. Vor allem, wenn sie dafür nicht in eine Schutzhülle eingepackt sein müssen und sich dabei noch so präzise bewegen können.

  Hier im Video ist die Hand zu sehen und wie mit ihr umgegangen wird:

  Leichtbau-Hand des DLR in Bewegung und grob behandelt

  Schon auf der Automatica im letzten Jahr zeigte das DLR die Hand plus angeschlossenem Unterarm und zog damals schon viele Blicke auf sich. Dass die Robotik-Abteilung des DLR um Hirzinger plant, sozusagen als nächsten großen Wurf, dieses Designprinzip innerhalb der nächsten fünf Jahr in einen Vollkörper-Humanoiden fließen zu lassen, stimmt mich äußerst erwartungsvoll. Der Plan ist, so hört man aus eingeweihten Kreisen, innerhalb der nächsten fünf Jahre die Hardware des Roboter fertigzuhaben und in weiteren fünf Jahren den Roboter vollständig zu beherrschen, so dass er rennen und Treppen rauf- und runterspringen kann. Und wem ist das mehr zuzutrauen, als dem DLR, nachdem die Robotik-Abteilung zuletzt mit dem Leichtbau-Industriearm gezeigt hat, zu welchen technologischen Sätzen man dort in den Lage ist.

  Was diese Hand so besonders robust macht, ist ihr durchdachtes Design, moderne Materialien, aber vor allem die Verwendung von künstlichen Sehnen zur Bewegung der Finger. Diese erlauben es, plötzlich auftretenden Kräften nachzugeben (wie zum Beispiel bei einem Aufprall), so dass die Struktur der Hand und die Elektronik von diesen Kräften nicht verletzt wird. Weiterhin wurden die Sehnen in einer Art und Weise verbaut, die es erlauben, ihre Steifigkeit zu verändern. Also etwa steife Sehnen für einen möglichst präzisen Griff und weniger steife Sehnen, wenn es darum geht, unbekannte Gegenstände zu ertasten, oder empfindliche Objekte sanft zu greifen.

  Mit insgesamt 19 Freiheitsgraden ist die Hand außerdem ähnlich bewegungsfähig wie unsere Hand (die gerade einmal einen Freiheitsgrad mehr hat). Bei der Konstruktion haben die Bauer darauf achtgegeben, dass die Bewegungsabläufe der Finger denen menschlicher Finger sehr nahe kommen, was diese Hand insgesamt mit all den obigen Faktoren zur aktuell wahrscheinlich coolsten Roboterhand für Humanoide macht. Der Konferenzbeitrag [1] zu der Hand und diesem Arm wurde auf der HUMANOIDS-Konferenz im Dezember in Nashville folgerichtig mit dem Best Paper Award ausgezeichnet. Dort zeigte der Vortragende Grebenstein im Video, wie mit einem Baseball-Schläger auf den Arm eingeschlagen wird, ohne dass dieser Schaden nimmt. Und das – das macht es so beeindruckend – nicht etwa mit ausgeschalteten Motoren und schlaff herumhängend, sondern in voller Positionsregelung. Ein gehöriger Unterschied, muss man doch bislang mit Robotern jede Bewegung im Vorhinein in Simulation ausführen, um jede Kollision mit eigenen Körperteilen oder anderen Objekten und eine damit einhergehende Beschädigung des Roboters auszuschließen.

  Auf den Humanoiden des DLR in diesem Design kann man nur gespannt sein. Mehr und mehr beeindruckende Humanoide hat man in den letzten zwei Jahren die Weltbühne betreten sehen. Aber ein Leichtbau-Roboter, der in jedem Detail so durchdacht und so technologisch fortgeschritten ist, wie es uns mit der DLR-Hand gezeigt wurde, dürfte ein neues Niveau erreichen.

  1

  Markus Grebenstein, Maxime Chalon, Gerd Hirzinger, Roland Siegwart: Antagonistically Driven Finger Design for the Anthropomorphic DLR Hand Arm System, HUMANOIDS 2010. (Abstract, Full Paper)

  zu den Kommentaren
  

• Die neuen Beine des iCub

  von Arne am 03.11.2010 um 14:34 Uhr

  In der letzten Zeit habe ich einige Male über den iCub geschrieben. Das liegt zum Einen daran, dass ich bekennender iCub-Fan bin und zum Anderen daran, dass ich in letzter Zeit immer häufiger von Arbeitswegen mit ihm in Berührung komme. Endlich finde ich nun die Zeit, mal über eine neue Entwicklung des iCub zu schreiben, die ich schon seit einigen Monaten mit Spannung verfolge und zu der ich jetzt auch Bilder und Videos aus erster Hand zeigen kann: Die neuen Beine des iCub.

  Der iCub ist im Rahmen des RobotCub-Projekts seit 2004 entstanden und wird seitdem kontinuierlich weiterentwickelt. Hauptsächlich bezog sich dies in den letzten Jahren auf Weiterentwicklung der Firmware und der iCub-Softwareumgebung, um die vorhandene Hardware immer besser, effektiver und einfacher nutzen zu können. Da der iCub als humanoide Forschungsplattform aber so erfolgreich ist, wird er konsequenterweise auch in Sachen Hardware weiterentwickelt. Kopf, Hände, Arme, Beine … für nahezu alle Teile existieren mehr oder weniger fortgeschrittene Pläne und Ansätze zur Weiterentwicklung.

  Am CoR-Lab arbeiten wir zur Zeit noch mit der ersten Version des iCub, auf der Summer School jedoch durfte ich schon mit einer weiterentwickelten Version des iCub arbeiten, die über Kraftsensorik in Armen und Beinen verfügt. Diese Kraftsensoren können (noch relativ grob) Kontaktkräfte messen, die auf Arme und Beine einwirken. So erlaubt diese iCub-Version zum Beispiel, dass man den iCub bei der Hand nimmt und seinen Arm führt; ein bedeutender Fortschritt in der Interaktion von Mensch und Roboter, wenn man ihn anfassen und führen kann. Eine weitere faszinierende Möglichkeit ist, den Roboter in einen Nachgiebigkeits-Modus zu schalten. In diesem Modus reagiert der Roboter auf die Kräfte, die auf ihn wirken, auf die gleiche Art, wie es eine Feder tun würde: Bei kleiner Krafteinwirkung gibt der Roboter ein wenig nach, bei größerer Krafteinwirkung gibt der Roboter deutlicher nach. Der Roboter fühlt sich dadurch sanft und weich an. Dieser Modus, diese Art der Regelung, nennt sich Active Compliance (aktive Nachgiebigkeit). Ein Video mit dieser iCub-Version zeigt, wie Ugo diese Eigenschaften nutzt, um den iCub mit Spielzeug vertraut zu machen:

  Der iCub wird geführt und kann Objekte ertasten

  Bei meinem Besuch am IIT (Italien Institute of Technology in Genua) an einem Tag während der Summer School habe ich eine iCub-Version kennengelernt, die für das AMARSi-Projekt entwickelt wird und dieses Konzept noch weiter treibt. Dieser iCub (der vielleicht irgendwann einmal auf den Namen cCub, Compliant iCub, hören wird), hat nicht nur wie sein Vorgänger in Armen und Beinen jeweils einen Kraftsensor, sondern er verfügt über neue Gelenke, die jeweils sowohl weitere Kraftsensorik als auch echte mechanische Federn integrieren. Was diese integrierten Gelenk-Module in dem Betrachter auszulösen vermögen, wenn sich der iCub damit bewegt, ist eine der faszinierendsten Dinge, die ich in letzter Zeit in der Robotik gesehen habe. Die Kombination aus Active Compliance, also der durch Sensorik und Regelung simulierten Nachgiebigkeit, mit der realen Nachgiebigkeit der eingebauten mechanischen Fähigkeiten (Passive Compliance), bewirkt eine Natürlichkeit der Bewegung des Roboters, die im ersten Moment irritierend bis verstörend wirken kann.

  Active Compliance allein macht die Interaktion mit dem Roboter schon deutlich natürlicher, und Bewegungen sehen weicher, runder und natürlicher aus. Nichtsdestotrotz bleibt der Eindruck beim Betrachter, dass es sich – tatsächlich – nach wie vor um eine Maschine handelt. Und genau dieser Eindruck scheint in dem Moment zu verschwinden, in dem zu der aktiven Nachgiebigkeit die echte (passive) Nachgiebigkeit der mechanischen Federung hinzukommt. Der Roboter bewegt sich damit offenbar in einer Art und Weise mit unterbewusst wahrgenommenen Schwingungen, die im menschlichen Hirn den Eindruck erwecken, hier würde sich ein biologisches Körperteil bewegen. Die mechanische Federung scheint ein ähnliches Muster aus Schwingungen und Oberschwingungen zu erzeugen, wie es menschliche Muskeln und Sehnen tun. Für mich war dies ein faszinierender, erschreckender Moment – als Robotiker allerdings positiv, was vermutlich nicht jedem Betrachter so ergeht. Nikos Tsagarakis, dessen Gruppe am IIT diese integrierten nachgiebigen Gelenke des iCub entwickelt, hat mir Fotos und Videos zugesandt und mir erlaubt, diese hier im Blog zu veröffentlichen. Zu sehen sind im folgenden Video die neuen Beine (noch ohne Oberkörper), wie sie balancieren und kleine Schritte tun. Ich weiß nicht, wie gut der beschriebene Effekt im Video erkennbar ist, wenn man ihn nicht live erlebt, aber dies ist der Versuch:

  Die neuen Beine des iCub in Bewegung

  Wer dies im Video nicht zu erkennen vermag, erfreut sich vielleicht an der Vorstellung des vergangenen AMARSi-Projekttreffens, als bei der Live-Demo dieser Beine grob geschätzt 40 Wissenschaftler, die in ihrem Leben schon hunderte Roboter gesehen haben, schweigend und mit großen Augen minutenlang diesen Beinen bei ihrer einfachen Bewegung zusahen.

  Und hier die Beine nochmal in der Großaufnahme:

  Die neuen Beine des iCub (Foto: IIT)

  Technisch Interessierte finden eine detailliertere Beschreibung dieser integrierten Aktuatoren in der Konferenzbeitrag zur ICRA 2009: A Compact Soft Actuator Unit for Small Scale Human Friendly Robots (kostenpflichtiger Zugriff via IEEE). Die weitere Entwicklung dieser iCub-Version wird weiterhin auf der Website des AMARSi-Projekts dokumentiert.

  zu den Kommentaren
  

• Compliance

  von Arne am 03.11.2010 um 14:34 Uhr

  Traditionell ist die Interaktion mit Robotern darauf beschränkt, dass dem Roboter Kommandos zugesandt werden (in der Regel als textuelle Kommandos, seltener per Sprache) und der Roboter über geeignete Sensorik (Kameras, Mikrofone, Laserscanner, …) seine Umgebung wahrzunehmen versucht. Was dabei in der Interaktion mit Menschen entsteht, ist allerdings häufig eine holprige, wenig natürliche und dadurch für Menschen oft anstrengende Interaktion. Dass man auf diese Art und Weise auch Menschen mit Robotern interagieren lässt, die nicht an der Entwicklung beteiligt waren und dadurch nicht Verständnis für diese Schwierigkeiten aufbringen, passiert daher eher selten.

  Eine Form der Interaktion, die sehr viel natürlicher ist, weil sie durch die physische Rückkopplung sehr viel direkter ist, ist die direkte Berührung und damit das Führen des Roboters. Der Mensch fasst den Roboter an der Hand (sofern er eine solche besitzt) und leitet den Roboter an. In der Robotik ist dies ein relativ aktueller Zweig der sogenannten Mensch-Maschine-Interaktion (MMI, Human Machine Interaction – HMI). Im Umfeld der industriellen Robotik sind ähnliche Techniken unter den Begriffen Teach-In und Kinestethic Teaching zu finden.

  Es gibt mehrere Möglichkeiten, einen Roboter für diese Form der Interaktion auszustatten. Eine Möglichkeit ist es, die Hardware des Roboters bewusst so zu konstruieren, etwa durch die Integration von mechanischen Federn in Struktur des Roboters, dass dieser nachgiebig ist. Diese Art der Nachgiebigkeit wird in der Robotik bzw. Regelungstechnik als Passive Nachgiebigkeit (engl.: Passive Compliance) bezeichnet, da sie – einmal verbaut – das System ohne weiteres Zutun dauerhaft nachgiebig gestaltet.

  Eine aufwendigere, aber dafür auch flexiblere Möglichkeit ist die Aktive Nachgiebigkeit (engl.: Active Compliance). Hierbei kann die Roboterhardware mechanisch völlig steif sein; die Nachgiebigkeit des Systems wird durch eine entsprechende Ansteuerung der Motoren simuliert. Dafür ist der Roboter mit Kraftsensorik ausgerüstet, die dem System konstant die auf den Roboter einwirkenden externen Kräfte meldet. Eine geschickte Regelung (Wikipedia) lässt den Roboter dann auf diese Kräfte auf die gleiche Art und Weise reagieren, wie es eine reale Feder tun würde: Bei kleiner Krafteinwirkung gibt der Roboter mit einer kleinen Bewegung nach, bei größerer Krafteinwirkung reagiert der Roboter mit einer deutlicheren Ausweichbewegung. Nicht, weil die Motoren nicht kräftig genug wären, den Kräften entgegenzuhalten, sondern weil dieses Verhalten den Eindruck eines weichen, nachgiebigen Systems erweckt und erwecken soll. Wie so eine Interaktion aussehen kann, zeigt das folgende Video:

  Der iCub wird geführt und kann Objekte ertasten

  Nachgiebigkeit ist dabei allerdings nicht allein für Interaktion eingesetzt; es ist auch ein enormer Sicherheitsaspekt. Ein Roboter, der mit seiner Umgebung (im schlimmsten Fall dem Menschen) kollidiert, weil er sie nicht richtig erkannt hat, richtet potentiell deutlich weniger Schaden an, wenn er nachgiebig ist; Schaden an sich und der Umwelt. Dies gilt für passive Nachgiebigkeit, genauso wie für aktive Nachgiebigkeit, wie das Deutsche Luft- und Raumfahrtzentrum im folgenden Video eindrücklich und mit offenbar ausreichend Vertrauen in die Technik beweist; am Ende des Videos mit Messer und einem menschlichen Probanden:

  KUKA Lightweight Robot IV mit Kollisionserkennung
  zu den Kommentaren
  

• Roboter: iCub

  von Arne am 07.08.2010 um 22:25 Uhr

  Der iCub (Foto von LV, robotcub.org)

  Der iCub ist ein waschechter europäischer Roboter-Spross. Die Vision zu diesem Roboter hatte Giorgio Metta vom IIT (Italien Institute of Technology), der an seinem Institut zusammen mit vielen anderen europäischen Forschungsinstituten im fünf­jäh­ri­gen RobotCub-Projekt das Roboterkind entwickelte.

  Die Kleinkind-Gestalt des iCub kommt nicht von Ungefähr. Mit dieser Gestalt trickst man die Kommunikationspartner – den menschlichen Gegenüber des iCub – aus. Zum einen erwarten Menschen instinktiv von einem Kind nicht so viele, komplexe und entwickelte Fähigkeiten wie von einem Erwachsenen. Entsprechend verzeihen wir einem kindlichen Roboter eher die Fehler, die jeder Roboter heutzutage nun einmal noch zuhauf und ständig begeht: Sie verstehen uns nicht, erkennen Objekte in ihrer Umgebung nicht und greifen daneben, wenn sie diese greifen sollen.

  Zum anderen bietet die kindliche Gestalt große Vorteile für den Roboter, wenn es darum geht, Fähigkeiten vom Menschen zu lernen. Unbewusst ändern Menschen ihre Sprache, Gestik und Mimik gegenüber Kleinkindern. Sprechen wir mit Kindern, sprechen wir sehr deutlich und sehr betont. Wir achten darauf, Bewegungen langsam und deutlich auszuführen und synchron mit der Stimme auszuführen die gerade die Bewegung oder deren Zweck beschreibt. Und wir zeigen mit unserem Blick ganz deutlich, wo auch das Kind gerade hinsehen sollte, um die Aufgabe zu verstehen. Diesen Effekt, mit dem normalerweise Eltern und Erwachsene Kleinkindern beim Lernen und Verstehen der Welt helfen, macht man sich so zunutze. Ein Vorteil bei der Kommunikation zwischen Roboter und Mensch, den man zumindest heute mit besserer Sensorik und besserer Technik des Roboters noch nicht ausgleichen kann.

  Ursprünglich war der iCub nach der Vorlage eines noch kleineren Kindes geplant, herausgekommen ist ein Roboter, der in der Einschätzung zwischen zwei- und dreijährig rangiert. Der Grund ist, dass es Motoren und Getriebe in der Größe und gleichzeitig Leistungsfähigkeit, um den iCub zu tragen, damals noch nicht gab, weswegen man die Größenvorstellung anpassen musste.

  Doch auch mit diesem Kompromiss ist der iCub ein wunderbarer Roboter geworden, der im besten Sinne ein langfristiges, europäisches Projekt ist. Die Robotik-Welt beneidet Europa um die langfristige, klare Strategie in der Robotik und der iCub zeigt, warum. Das Projekt lief fünf Jahre und ist seit nunmehr einem Jahr vorüber, aber der iCub macht munter weiter. Überall auf der Welt ist er im Einsatz, wie stetig neue Videos auf Youtube beweisen. Neben den einzelnen Experimenten der (hauptsächlich europäischen) Forschungsinstitute, laufen über die nächsten Jahre weitere große Projekte, die den iCub nutzen und weiterentwickeln: iTALK, Robotdoc, AMARSi, … um nur drei der großen aktuellen Projekte zu nennen.

  Bericht über den iCub
  zu den Kommentaren