Evaluierung und Implementierung eines Konzeptes für die autonome Orientierung eines humanoiden Roboters. Masterarbeit Christian A.

Transkript

1 Technische Hochschule Nürnberg Georg-Simon-Ohm Fakultät Informatik Wintersemester 2012/13 Evaluierung und Implementierung eines Konzeptes für die autonome Orientierung eines humanoiden Roboters anhand potentieller Warnzeichen oder Gefahrensituationen Masterarbeit Christian A. Ullrich Erstkorrektor Prof. Dr.-Ing. Florian Gallwitz Zweitkorrektor Prof. Dr. Rainer Rieckeheer Technische Hochschule Nürnberg Georg-Simon-Ohm 15. April 2013

2 II

3 Eigenständigkeitserklärung Ich versichere hiermit, dass ich die vorliegende Abschlussarbeit selbstständig verfasst, nicht anderweitig für Prüfungszwecke vorgelegt und keine anderen als die angegebenen Hilfsmittel und Quellen benutzt habe. Die Stellen, die anderen Werken dem Wortlaut oder dem Sinn nach entnommen wurden, habe ich in jedem einzelnen Fall durch die Angabe der Quelle, auch der benutzten Sekundärliteratur, als Entlehnung kenntlich gemacht. Christian Ullrich Ort, Datum III

4 IV

5 Vorwort Diese Arbeit befasst sich mit einer Studie im Bereich der humanoiden Robotertechnologie. Es wird ein Konzept und eine prototypische Implementierung entworfen um einen Roboter der NAO-Serie durch eigenständige Analyse der Umwelt zu steuern und ihn dabei autonom nach möglichen Gefahrenquellen wie etwa Schildern oder Warnzeichen suchen zu lassen. Hierbei wird vor allem auf die verschiedenen komplexen Teilaspekte einer solchen Problemstellung eingegangen. So spielen unter anderem Inhalte aus der Optik, Kinetik als auch der menschlich-maschinellen Interaktion eine wesentliche Rolle in einem derartigen Konzept. Die Konstruktion eines theoretischen Modells wird zunächst dabei helfen, potentielle Probleme aus den genannten Bereichen zu identifizieren und eine grundlegende Struktur für deren Lösung und Implementierung zu schaffen. Es werden auch mögliche technische Grenzen analysiert. Darüber hinaus wird eine anschließende Evaluation des Software Development Kit des NAO- Roboters aufzeigen, inwieweit sich der gefundene Lösungsansatz in diesem reflektiert. Es wird sich zeigen, ob gegebenenfalls weitere Software benötigt wird. Eine prototypische Implementierung des Konzeptes wird dessen Umsetzbarkeit an einem echten Roboter testen. Dabei wird von mehreren realistischen Szenarien ausgegangen, mit denen das System konfrontiert wird. Das Ziel dieser Arbeit ist es, neben einem funktional korrekten Konzept bzw. der prototypischen Implementierung auch die Komplexität des Modellierungsprozesses eines derartigen Projektes herauszuarbeiten und aufzuzeigen. Weiterhin soll die Frage beantwortet werden, inwieweit die Ergebnisse in den Rahmen bisheriger Theorien in der Robotik eingebettet werden können. Als Vorwissen dienen Lerninhalte sowohl aus dem Bachelor- als auch dem Masterstudiengang Informatik. Insbesondere wird auf Konzepte der Fächer Grundlagen multimedialer Systeme, Digitale Bildverarbeitung und Mustererkennung zurückgegriffen. Darüber hinaus sind selbstverständlich die allgemein gültigen Grundlagen aus den Kursen Programmieren 1 und 2, Softwarearchitektur und Software Engineering für diese Arbeit maßgebliche Voraussetzungen. Der Besitz von Kenntnissen über die Kreation von und dem Umgang mit humanoiden Robotersystemen ist für den Leser hilfreich, aber nicht zwingend erforderlich. Alle in dieser Arbeit verwendeten Tabellen, Abbildungen, Codelistings und Abkürzungen sind in individuellen Verzeichnissen am Ende der Arbeit zur besseren Übersicht aufgelistet. Begriffsdefinitionen und Anmerkungen sind soweit notwendig in den Fußnoten angegeben. Wörtliche Zitate werden durch Anführungszeichen, Kursivschrift und einer Fußnote mit Quellenangabe kenntlich gemacht. Sinngemäß übertragene Inhalte wie beispielsweise Abbildungen oder Denkansätze sind ebenfalls mit Fußnoten und Quellenangaben gekennzeichnet. In dieser Arbeit genannte Personen bzw. Typen (z.b. der Leser) sind zumeist im generischen Maskulinum gehalten. Dies soll keine sprachliche Diskriminierung, sondern lediglich einem vereinfachten Sprachverständnis dienen. Die gesamte in der Arbeit verwendete Literatur, Dokumentation und Referenzwerke sind in einem entsprechenden Verzeichnis am Ende dieser Arbeit angegeben. V

6 VI

7 Danksagung Der Autor bedankt sich bei den Supportmitarbeitern von Aldebaran Labs., Inc. für die Antwort auf technische Fragen, der Technischen Hochschule Nürnberg Georg-Simon-Ohm, für die Bereitstellung des Nao-Roboters und den Professoren Prof. Dr. Ing. Florian Gallwitz und Prof. Dr. Rainer Rieckeheer für die fachliche Betreuung während der Bearbeitungszeit. VII

8 VIII

9 Inhaltsverzeichnis 1. Einleitung Ziel der Arbeit Motivation Aufbau Grundlagen zum Aldebaran NAO-Roboter Idee und Basiskonzeption Konzeptanalyse Lösungen des theoretischen Modells Prototypische Implementierung Systemtest Ausblick Zusammenfassung Grundlagen zum Aldebaran NAO-Roboter Geschichte der Robotik: Ein Überblick Ursprung moderner Roboter Telemanipulatoren Industrieroboter Forschungsroboter Moderne Robotik im digitalen Zeitalter Technische Spezifikation der Nao-Plattform Überblick Maße und Gewicht Kinematik Motorik Sensorik System Stromversorgung Einsatzgebiete und bisherige Projekte Offizielle Projekte Projekte der Technischen Hochschule Nürnberg Fazit und Position dieser Arbeit Idee und Basiskonzeption Hintergrund und Idee Zielspezifikation Umfang Suchen und Extrahieren von Bedrohungen in der Umgebung Erkennen der Bedeutung Lokalisation der Bedrohung Navigation Interaktion Fazit IX

10 Inhaltsverzeichnis 3.3. Einsatzszenarien Szenario R: Realität Szenario N: Nao Bedienungsphilosophie Sprachsynthese Spracherkennung Vorführung des Pfades Haptische Bedienelemente und visuelle Signale Körperhaltung Visualisierung durch Software Fazit Konzeptanalyse Wissenschaftliche Aspekte des Konzeptes Suchen und Extrahieren von Bedrohungen in der Umgebung Erkennen ihrer Bedeutung Lokalisation der Bedrohung Navigation Interaktion Evaluation der Problemgebiete Physik Mathematik Psychologie Kartografie Linguistik Konstruktion des theoretischen Modells Lösungen des theoretischen Modells Lösungen aus der Informatik Optik und Informatik Akustik und Informatik Kinematik und Informatik Künstliche Intelligenz und Informatik Lösungen aus der Robotik Steuerungskonzepte Datenstrukturen für Lokalisation und Navigation Referenzarchitekturen Grenzbetrachtung: Aldebaran Nao Rechenleistung Optik Kinematik Akustik Fazit: Machbarkeit Prototypische Implementierung Evaluation des NaoQI-SDK Aufbau und Nutzung Referenzmodule für Implementierung Zusatzsoftware und Lücken Softwaremodell Modulimplementierung und Abläufe ClientBroker X

11 Inhaltsverzeichnis Missionplanner Cartographer Navigator/NavNode Pilot VisionReactor Movement CUSURFDetector CUSonar Deployment in NaoQI Sensorik (C++) Steuerungssystem (Python) Systemtest Test am Aldebaran Nao Aufbau Ablauf Probleme Test durch Simulation Aufbau Ablauf Ausblick Zusammenfassung 165 Abbildungsverzeichnis XII Tabellenverzeichnis XVI Listings XVIII Abkürzungsverzeichnis XXI Literaturverzeichnis XXII A. Anhang XXIX XI

12

13 1. Einleitung Seit der tschechische Schriftsteller Karel Čapek mit seinem Theaterstück Rossums Universal-Robots im Jahre 1920 den heutzutage viel genutzten Terminus Roboter prägte, sind zunehmend immer mehr Menschen an deren Technologie und Fähigkeiten interessiert. Kein Wunder, versprechen doch diese seit der Verbreitung des Personal Computer in den späten siebziger Jahren der nächste logische Schritt in der menschlich-maschinellen Interaktion zu sein. Denn obwohl traditionelle Computer aus dem heutigen Alltag praktisch nicht mehr wegzudenken sind, ist die Interaktion mit ihnen nicht besonders effizient. Die Eingabe von Informationen über externe Peripherie wie Maus und Tastatur ist nämlich für den Menschen zumeist anfangs ungewohnt, da dieser in der Realität primär das Sprechen bzw. non-verbale Kommunikation (Gestik bzw. Mimik) hierfür nutzt. Jene Kommunikationsformen, die er über Jahrtausende hinweg entwickelt hat. Selbst mit gezieltem Training ist es bei der Nutzung von Hardware nicht möglich, eine vergleichbare Geschwindigkeit und Informationsdichte wie durch die natürlichen Verständigungsarten zu erreichen. Abbildung 1.1.: Roboter aus R.U.R. 1 Wie verlockend der Gedanke ist, Computern eine menschliche Gestalt und entsprechende Fähigkeiten zu verleihen, lässt sich allein schon an der Tatsache erkennen, dass sie unbestritten eine größere Menge an (abstrakten) Informationen als wir in einem bestimmten Zeitintervall verarbeiten können. Diese Eigenschaft haben sie durch das ursprüngliche Anwendungsgebiet ihrer Vorgänger den Rechenmaschinen erhalten. Deshalb haben sich im Laufe der Zeit eine Vielzahl an Forschern und Ingenieuren verschiedenster Fachrichtungen an der Realisierung eines Konzeptes versucht, welches diesen nächsten Schritt in der menschlich-maschinellen Interaktion ermöglichen soll. Hierbei ist vor allem eines deutlich geworden: Die Interpretation und Nachahmung von menschlichem Verhalten ist ein sehr komplexes Problem, welches bis heute nur in Teilen und für bestimmte Szenarien gelöst werden kann Ziel der Arbeit Aus diesem Grund setzt sich diese Arbeit mit einem Konzept für ein Szenario auseinander, welches sich auch auf ein solches Zusammenspiel von Mensch und Maschine fokussiert. Dabei soll ein humanoider Roboter der Aldebaran NAO-Serie stellvertretend für einen Menschen einen Raum autonom nach potentiellen Gefahrenquellen durchsuchen und anschließend davon berichten bzw. einen Pfad aufzeigen. 1 Abbildung aus [45], Abschnitt What is a robot? 1

14 1. Einleitung Das Ziel dieser Arbeit ist es, ein Konzept, aus diesem ein theoretisches Modell, eine prototypische Implementierung und deren Schaffungsprozess entsprechend zu dieser Idee zu verwirklichen und darzustellen. Darüber hinaus sollen die Ergebnisse anhand von Szenarien getestet werden. Als Endprodukt dient nicht nur das Konzept bzw. die prototypische Implementierung selbst, sondern auch die Erkenntnis, wie ein derartiges System korrekt modelliert und in den Rahmen bisheriger Theorien in der Robotik eingebettet werden kann Motivation Die wesentliche Motivation hinter dieser Arbeit besteht insbesondere aus reiner Neugier: Nämlich bzgl. der Frage inwieweit derzeitige Robotersysteme in der Lage sind Menschen in komplexen (Alltags-)Situationen zu helfen. Auch der Aspekt, wie man grundsätzlich ein solches System modelliert, implementiert und testet, macht einen großen Anreiz aus. Die einfache Verfügbarkeit repräsentativer humanoider Roboterplattformen ist ein weiteres Argument. Ausserdem begründet sich ein weiterer Anstoß für die Bearbeitung dieses Themas in der persönlichen Interesse des Autors. Er hat sich im Laufe seines Studiums mit verschiedenen Themen befasst, welche immer eine gewisse Teilmenge der zu bearbeitenden Problemstellung beinhalteten. Die Idee an einem humanioden Roboter zu arbeiten, soll die angesammelten Kenntnisse im Bereich der Grafikverarbeitung, der Entwicklung auf mobilen Plattformen sowie der Etablierung neuartiger Bedienkonzepte vertiefen und festigen Aufbau Der Aufbau der Arbeit orientiert sich nach typischen Meilensteinen eines derartigen Projektes. Hierbei wird je Kapitel ein Teilschritt behandelt, um den Leser schrittweise in die Thematik einzuführen und an den weiterführenden Denkprozessen im Laufe der Ausarbeitung teilhaben zu lassen. Sie reflektieren die Vorgehensweise, die auch bei der Durchführung des Projektes genutzt wurde. Diese Teilschritte lassen sich dabei wie folgt auflisten: 1. Grundlagen zum Aldebaran NAO-Roboter 2. Idee und Basiskonzeption 3. Konzeptanalyse 4. Lösungen des theoretischen Modells 5. Prototypische Implementierung 6. Systemtest Ihre Struktur, sowie ihr jeweiliger Sinn und Zweck werden im Folgenden nun kurz erläutert Grundlagen zum Aldebaran NAO-Roboter Zuerst wird ab Seite 7 eine Einführung über die in dieser Arbeit genutzten Hardwareplattform gegeben dem Aldebaran Nao-Roboter. 2

15 1.3. Aufbau Hierbei werden grundsätzliche Elemente, wie sowohl dessen Herkunft und Geschichte im Kontext der Robotik, als auch die Hardwarespezifikation selbst dargestellt. Aspekte seiner Systemsoftware werden bewusst nur im notwendigen Rahmen erwähnt, da diese später im Zuge der prototypischen Implementierung genauer vorgestellt und auf ihre Brauchbarkeit hin untersucht werden. Eine Betrachtung der Einsatzgebiete und Projekte, welche sich bisher mit dem Nao-Robotersystem befassten, rundet dieses Kapitel ab. Dabei werden internationale Forschungsprojekte und Arbeiten der Technischen Hochschule Nürnberg Georg-Simon-Ohm gleichermaßen erwähnt. Neben dem Ziel, dem Leser die Einarbeitung in das Nao-Robotersystem weitestgehend zu ersparen, soll das Kapitel dem Zweck dienen, die Position dieser Arbeit in der bisherigen Forschung in der Robotik grundsätzlich festzulegen Idee und Basiskonzeption Im anschliessenden Kapitel 3 (ab Seite 19) wird die eigentliche Idee und das Konzept des Projektes dieser Arbeit ausführlich vorgestellt bzw. letzteres aus ihr abgeleitet. Die Festlegung einer Zielspezifikation (ab Seite 20) wird dabei die wesentlichen Merkmale des avisierten Robotersystems präzisieren. Hierbei werden einerseits (Teil-)Ziele und Bedingungen aber auch Einschränkungen festgesetzt. Kurz gesagt: Es wird definiert, was der Roboter am Ende dieser Arbeit können soll und was nicht. Weiterhin folgt eine genauere Beschreibung von verschiedenen Einsatzszenarien (Seite 22). Es wird die Frage beantwortet, wie eine der Idee entsprechenden Umwelt beschaffen sein müsste und inwiefern eine solche für den Nao-Roboter bezüglich der Umsetzung modelliert werden kann. Ausserdem ermöglichen sie eine Prüfung, ob die einzelnen Punkte der Zielspezifikation auch wirklich anwendbar sind. Hierzu werden Konzeptzeichnungen zur besseren Veranschaulichung genutzt. Abschliessend wird ab Seite 26 der Aspekt der Benutzerinteraktion beleuchtet. An dieser Stelle erfolgt die Suche nach einer Bedienungsphilosophie, welche einerseits möglichst intuitiv für den späteren Benutzer, andererseits jedoch adäquat zur Idee ist. Sie vervollständigt den Entwurf. Dieses Kapitel hat die Intention, dem Leser die Idee und das daraus entstehende Grundkonzept vorzustellen und zu vermitteln. Weiterhin lernt er die wesentlichen Faktoren, welche allgemeingültig bei der Modellierung von derartigen Systemen mit einzubeziehen sind, kennen Konzeptanalyse In Kapitel 4 wird das zuvor aufgestellte Konzept aus verschiedenen Perspektiven kritisch betrachtet und auf die Möglichkeit überprüft, ob mit Hinblick auf die prototypische Implementierung ein theoretisches Modell geschaffen werden kann. Ab Seite 31 findet dies zunächst durch eine Betrachtung aus einer gesamtwissenschaftlichen Sichtweise statt. Das Konzept wird hierbei nach elementaren Teilproblemen aus unterschiedlichen Wissenschaften untersucht, für welche im weiteren Verlauf der Arbeit Lösungen zu finden sind. Diese werden im Abschnitt 4.2 (S. 37 ff.) mit Fokus auf ihre Signifikanz und geschätzten Komplexität beurteilt, geordnet und priorisiert. Als Referenz hierfür werden Erfahrungen des Autors und verschiedene wissenschaftliche Publikationen herangezogen. 3

16 1. Einleitung Schlussendlich wird auf Basis dieser Evaluation die Konstruktion eines theoretischen Modells (ab Seite 45) vorangetrieben. Es dient fortan als Richtlinie für die weitere Bearbeitung des Themas. Der Teilschritt der Methodik, der sich in diesem Kapitel reflektiert, hat den Anspruch die Denkprozesse, welche für eine erfolgreiche Erweiterung des Grundkonzeptes zu einem realisierbaren Ansatz notwendig sind, darzustellen. Wie dabei ersichtlich werden wird, orientieren sie sich hierfür an der Lösungstechnik des divide-and-conquer. Somit wird auch dessen Praktikabilität für die Modellierung von Robotersystemen visualisiert Lösungen des theoretischen Modells Kapitel 5 (ab Seite 47) befasst sich anschliessend mit dem zuvor erzeugten Modell. Hierbei steht besonders eine Suche nach passenden Lösungen zu den höchst prioritären Teilproblemen aus der Wissenschaft durch Konzepte aus der Informatik und Robotik im Brennpunkt. In Abschnitt 5.1 (S. 47 ff.) findet dies zunächst anhand von adäquaten Lösungskonzepten bzw. -methodiken aus der Informatik statt. Eine Betrachtung passender Mittel und architektonischen Referenzmodelle aus der Robotik für die Kreation eines künstlich intelligenten Robotersystems wird anschließend in Abschnitt 5.2 (ab S. 63) vorgenommen. Die in Abschnitt 5.3 (Seite 74) durchgeführte Grenzbetrachtung setzt sich im Kontext dieser Betrachtungen intensiv mit der technischen Machbarkeit der Aufgabenstellung am Aldebaran Nao-Roboter auseinander. Unter Berücksichtigung der Hardwarespezifikation aus Abschnitt 2.2 wird dabei untersucht, inwiefern Einschränkungen und Schwierigkeiten bei der Implementierung des Projektes auftreten könnten und Kompromisslösungen notwendig sind. Dieser Teil der Arbeit erläutert den Prozess der Konkretisierung einzelner Bausteine aus dem theoretischen Systemmodell und vermittelt dem Leser zusätzlich das nötige Wissen, um alle wesentlichen Elemente für die Schaffung eines zum Konzept passenden Lösungsansatzes prinzipiell zu verstehen Prototypische Implementierung Die konkrete Umsetzung eines solchen Lösungsansatzes bzw. dessen Teilprobleme und Architektur ist der Schwerpunkt des folgenden Kapitels (ab Seite 81). Es dient somit dem Zweck, dem Leser am eigentlichen Verwirklichungsprozess teilhaben zu lassen. Hierfür wird zunächst in Abschnitt 6.1 (S. 81) eine umfassende Einführung in das NaoQI- Framework gegeben, dem Entwicklungswerkzeug des Aldebaran Nao-Roboters. Grundsätzliche Kernaspekte wie dessen Hintergrund, Umfang und Aufbau, aber auch einfache Programmierbeispiele, an welchen seine Nutzung verdeutlicht werden kann, sind hier zentrale Themen. Im selben Zuge werden die in dem SDK enthaltenen Module bezüglich ihres Funktionsumfangs und vorgesehenen Anwendungsgebiets auf ihre Brauchbarkeit im Kontext des Projektes untersucht. Diese Evaluation (ab Seite 93) verfolgt sowohl das Ziel der Erarbeitung möglicher Anschlusspunkte für die Implementierung als auch eine Suche nach Lücken. Alternativen für letztere werden anschliessend ab Seite 95 vorgestellt. Abschnitt 6.2 (S. 96 ff.) behandelt die Transformation aller zu diesem Zeitpunkt gesammelten Erkenntnisse, Anforderungen und der vielversprechendsten Lösungsmuster in ein umfassendes Softwaremodell, welches in das NaoQI-System eingebettet werden kann, um das Konzept mit diesem zu realisieren. Das dadurch entstehende Ergebnis ist ungefähr einem Pflichtenheft gleichzusetzen. 4

17 1.3. Aufbau Abschnitt 6.3 (ab S. 101) stellt wesentliche Inhalte, Arbeitsprozesse und Schwierigkeiten bei der Implementierung der einzelnen Softwarekomponenten vor. Eine Darstellung der anschliessenden Schritte für das Deployment des auf diese Art und Weise entstandenen Systems (Abschnitt 6.4, S. 153) vervollständigt dieses Kapitel Systemtest Der letzte Schritt der Methodik ist der Test des geschaffenen Gesamtsystems. Hierbei soll die grundsätzliche Funktion und Richtigkeit des Konzeptes sowie der prototypischen Implementierung exemplarisch visualisiert und bewiesen werden. Zunächst wird dabei das Verhalten des Systems unter realen Bedingungen getestet. Dazu befasst sich Abschnitt 7.1 mit einem entsprechenden Szenario. Sein Aufbau wird daher ab Seite 156 zunächst detailliert beschrieben. Abschnitt setzt sich dann direkt mit dem Verhalten der prototypischen Implementierung in diesem auseinander. Hierfür werden die wichtigsten Aspekte aus den damit verbundenen Testläufen herangezogen. Anschliessend wird ab Seite 158 auf die dabei am häufigst aufgetretenen Probleme eingegangen. Das hat den Zweck, jene Faktoren herauszuarbeiten, welche nicht von den Inhalten dieser Arbeit her stammen, aber dennoch einen Beweis ihrer Richtigkeit/Funktion stark verzerren. Deshalb wird weiterhin in Abschnitt 7.2 (S. 159 ff.) ein Test des Systems durch Simulation vorgenommen. Da hier von einer gänzlich störungsfreien Umgebung ausgegangen werden kann, ist die Verwendung noch komplexerer Szenarien im Rahmen der Evaluation möglich. Entsprechend beschäftigt sich Abschnitt zunächst mit dem Aufbau eines solchen und führt dieses ein. Abschliessend rundet eine Darstellung der bei der Simulation beobachteten Ergebnisse die Evaluation sowie dieses Kapitel ab (vgl. Seite 160 f.). Sie ergeben somit den Beweis der Richtigkeit/Funktion des Konzeptes/der prototypischen Implementierung dieser Arbeit Ausblick Ab Seite 163 zeigt der Ausblick, inwiefern die Ergebnisse der Arbeit in naher Zukunft noch verbessert werden könnten. Dazu werden die wichtigsten Überlegungen hierfür kurz vorgestellt, welche entsprechende Änderungen am Konzept bzw. der prototypischen Implementierung skizzieren. Da ihre Umsetzung jedoch den Rahmen dieser Arbeit sprengen würde, stellen sie daher allesamt eine Grundlage für weitere Forschungsarbeiten zu diesem Thema dar Zusammenfassung Diese Arbeit schliesst mit einer Zusammenfassung über die Inhalte der einzelnen Kapitel und des Ausblicks ab (S. 165). Entsprechend werden an dieser Stelle noch einmal alle Schritte der Methodik kurz betrachtet und ihr individueller Beitrag, sowie ihre wichtigsten Ergebnisse, dargelegt. 5

18

19 2. Grundlagen zum Aldebaran NAO-Roboter Bevor sich die Arbeit der eigentlichen Problemstellung bzw. der Bearbeitung der Idee zuwendet, wird in diesem Kapitel eine Einführung über die dafür erforderlichen Grundlagen gegeben. Da der Aldebaran Nao das Ergebnis eines langen und komplizierten Evolutionsprozesses in der Robotik ist, werden zunächst die wichtigsten historischen Stationen und Entwicklungsschritte letzterer beleuchtet. Hierbei wird insbesondere bei der Beschreibung moderner Ausprägungen dieses Forschungsgebiets vor allem ein Fokus auf die Herkunftsgeschichte von Robotersystemen gelegt, welche humanoide Eigenschaften als Grundlage benutzen. Sie stellen die unmittelbaren Vorfahren des Nao dar, welcher als Referenzplattform für die prototypische Implementierung des Konzeptes dieser Arbeit verwendet wird. Auf Basis dieser Hintergrundinformationen kann somit eine Vorstellung der technischen Spezifikation den Leser dann mit den genauen Details dieser Plattform vertraut machen. Abschliessend werden exemplarische Einsatzgebiete sowie bisherige Projekte des Nao-Roboters präsentiert um das Gesamtbild abzurunden und die Nische für diese Arbeit aufzuzeigen Geschichte der Robotik: Ein Überblick Wie bereits in der Einleitung erwähnt, prägte Čapek 1920 den Begriff des Roboters. Was er jedoch nicht vorausahnen konnte ist, was für Auswirkungen diese Bezeichnung auf die technische Entwicklung der darauf folgenden Jahrzehnte haben würde. Fakt ist, Roboter sind aus der heutigen Zeit nicht mehr wegzudenken. Wenn man von den Schätzungen des Institute of Electrical and Electronics Engineers ausgeht, so waren im April 2010 mehr als 8,6 Millionen Roboter weltweit im Einsatz. 1 Zahlreiche Meilensteine wurden bis zu dieser Entwicklung durchlaufen. Die wichtigsten davon sollen hier als Überblick dienen und den Evolutionsprozess hinter modernen humanoiden Robotern wie dem Aldebaran Nao stichpunktartig visualisieren Ursprung moderner Roboter Die Faktoren für die eigentliche Entstehung von Robotern waren nach Murphy vielfältig. 2 Relativ sicher ist jedoch, dass sie anfangs zumeist für das Durchführen von Aufgaben erfunden wurden, welche mindestens einem der sog. 3D-Kriterien 3 entsprachen. Sie sollten also Čapek s ursprünglicher Idee treu bleibend dem Menschen als Arbeiter dienen. Der maßgebliche Anlass für die Entwicklung von Robotern begründet sich weiterhin bei verschiedenen Quellen aus den Gefahren, welche sich bei dem Umgang mit nuklearen Materialien im Rahmen des zweiten Weltkriegs ergaben. 4 1 vgl. [26] 2 vgl. [42], S dirty, dull, or dangerous, zu deutsch: schmutzig, abgestumpft oder gefährlich; vgl. [42], S vgl. beispielsweise [30], S. 6 7

20 2. Grundlagen zum Aldebaran NAO-Roboter Telemanipulatoren Da es mit steigender Radioaktivität immer schwieriger wurde, entsprechende Materialien zum Schutz des Menschen herzustellen, konstruierte man mechanische Arbeitsvorrichtungen um einen direkten Kontakt zu vermeiden. Diese sog. Telemanipulatoren können dabei als die früheste Erscheinungsform von Robotern gewertet werden. Obwohl sie keinesfalls mit jedweder Technologie ausgestattet waren (keine Motoren/Computer), folgen die heutigen Roboter noch immer den gleichen Prinzipien z. B. bei der Festlegung ihrer Freiheitsgrade. Telemanipulatoren waren jedoch sehr schwer zu bedienen, was weiteren Entwicklungsbedarf nach sich zog. Die Erschaffung erster richtiger Roboter war die Folge. Abbildung 2.1.: Ein Telemanipulator Industrieroboter Mit dem Ende des zweiten Weltkriegs bot sich die Möglichkeit, die Ergebnisse aus dieser Entwicklung auch auf andere Gebiete zu übertragen. Jedoch dauerte es bis ca. in die späten 50er Jahre bis einfache Roboterarme für die Durchführung von simplen Aufgaben einsetzbar waren. Industriemanipulatoren und AGVs 7 waren die am weitest verbreiteten Systeme dieser Zeit. Erstere gelten dabei als die unmittelbaren Vorgänger der heutigen Industrieroboter, welche beispielsweise in der Automobilbranche eingesetzt werden. AGVs hingegen waren u. a. die Vorreiter heutiger Logistiksysteme. Abbildung 2.2.: Ein früher Industriepulator 6 Beide Ansätze hatten das Ziel, den Einsatz von menschlichen Arbeitskräften für einfache Transportbzw. Montageaufgaben überflüssig zu machen. Ein Vorhaben, welches unter gewissen Rahmenbedingungen auch erreicht wurde. Probleme stellten sich damals nämlich spätestens dann ein, wenn entweder unvorhersehbare Faktoren aus der Umwelt oder schlicht die Komplexität der gestellten Aufgabe zu groß wurde. Diese hätten nur durch die Implementierung einer Art Bewusstsein gelöst werden können, welche zu diesem Zeitpunkt noch nicht existierte Forschungsroboter Diese spezifische Problematik beschäftigte im Lauf der darauf folgenden Jahrzehnte zahlreiche Forschungsgruppen. Als sicherlich bekannteste davon gilt die amerikanische Luft- und Raumfahrtbehörde NASA (National Aeronautics and Space Administration), welche sich im Zuge des kalten Krieges mit der Sowjetunion ein Wettrennen um die Erforschung des Weltalls lieferte. Da es dem Menschen aufgrund der im All fehlenden Gravitation sehr schwer fällt trotz Schutzanzug körperliche Arbeiten zu verrichten, wurde auch hier an den Einsatz von Robotern gedacht. Jene sollten in diesem Falle aber dann auch über eine gewisse Selbstständigkeit verfügen, da ein korrigierender Eingriff seitens des Menschen im Fehlerfall u. U. sehr lange dauern kann oder gar nicht mehr möglich ist. 5 Abbildung aus [42], S Abbildung aus [42], S Automated Guided Vehicle: Ein sich selbst steuerndes Fahrzeug, welches einer bestimmten optischen oder magnetischen Markierung auf dem Boden folgt. 8

21 2.1. Geschichte der Robotik: Ein Überblick Abbildung 2.3.: Der NASA Curiosity Roboter 8 So sollte beispielsweise ein Forschungsroboter auf einem anderen Planeten (vgl. Abbildung 2.3) über autonomes Verhalten zur Kollisionsvermeidung verfügen, da ein entsprechendes Steuersignal im schlechtesten Falle mehrere Minuten von der Erde aus benötigen kann (oder niemals ankommt). Die Komplexität derartiger Einsatzszenarien ist nicht von der Hand zu weisen. Auf Basis dieser Überlegungen entstanden im Verlauf der 70er und 80er Jahre zahlreiche Architekturen und Lösungsansätze, welche die Robotik bis heute entscheidend prägten. Diese lassen sich dabei grob in planungsorientierte und verhaltensorientierte Varianten kategorisieren. Einzelheiten jener Lösungsmuster werden im Laufe dieser Arbeit, insbesondere bei der Modellierung und Umsetzung, eine wichtige Rolle spielen (vgl. dazu Abschnitt 5.2.1, S. 64 ff.). Trotz der wichtigen Erkenntnisse, die in diesem Zeitraum gewonnen werden konnten, wurde der Fortschritt in der Robotik entscheidend gebremst. Die für die Umsetzung notwendige Technologie war damals zumeist sehr teuer und/oder nicht portabel genug um sinnvoll für die breite Masse nutzbar zu sein Moderne Robotik im digitalen Zeitalter Dieser Umstand änderte sich im Verlauf der letzten 23 Jahre deutlich. Dafür waren neben einer zunehmenden Verbreitung von Personal Computern in den 90er Jahren auch die in letzter Zeit stattfindende Reorientierung des IT-Sektors maßgebliche Faktoren. Beide führten zu zahlreichen Fortschritten in der damit verbundenen Technologie, welche beispielsweise effizientere und minimalistischere Fertigungsprozesse bei Chips erlaubten. Selbstverständlich profitierte davon auch die Robotik. Mit der Möglichkeit, komplexe Algorithmen auf stromsparenden Prozessorarchitekturen (z. B. ARM) zu realisieren, sind mittlerweile eine Vielzahl der damaligen Lösungsgedanken praktisch für jedermann umsetzbar. In der Tat ist man dabei sogar nach Murphy zu Modellen gekommen, welche planungs- und verhaltensorientierte Aspekte hybridisieren. 9 Entsprechend zu dieser Entwicklung wurden auch insbesondere im letzten Jahrzehnt verschiedene Roboterplattformen entwickelt, welche sowohl in der Forschung als auch in der Praxis 8 Abbildung aus [41] 9 vgl. [42], S. 9 9

22 2. Grundlagen zum Aldebaran NAO-Roboter zum Einsatz kommen. Im Sinne dieser Arbeit werden jedoch nur moderne, humanoide Robotersysteme weiter betrachtet. Abbildung 2.4.: Der Honda ASIMO als erster humanoider Roboter 10 Den Grundstein zu einem ersten derartigen System legte der japanische Konzern Honda. Dieser entwickelte bereits zu Beginn der 90er Jahre an verschiedenen Prototypen auf Basis der menschlichen Anatomie. Kopf, Torso, Arme und Beine sollten der Vorlage entsprechend groß, bewegbar und das Gesamtsystem zu eigenständigem Laufen fähig sein. Letztendlich kulminierte dies im Honda ASIMO, welcher im November 2000 der Öffentlichkeit vorgestellt wurde und als erster humanoider Roboter in die Geschichte einging. 11 (a) Sony Aibo (b) Sony Qrio Abbildung 2.5.: Robotermodelle von Sony 12 Gleichermaßen führte das ebenfalls japanische Unternehmen Sony eigene Studien in der Robotik durch. Schon 1999 folgte dann die Vorstellung des Sony Aibo, dem ersten für den Heimeinsatz 10 Abbildung aus [52] 11 mehr dazu unter [32] 12 Abbildung des Aibo aus [22], Abbildung des Qrio aus [61] 10

23 2.2. Technische Spezifikation der Nao-Plattform gedachten Spielzeugroboter. Als logische Weiterentwicklung wird der Sony Qrio gesehen, welcher ab 2002 erhältlich war und als eine vereinfachte, kleinere und vor allem billigere Version des ASI- MO gesehen werden kann. Beide Modelle fanden vor allem im universitären Umfeld vielseitige Verwendung. 13 Als Sony jedoch im Zuge einer konzernweiten Restrukturierung 2006 das Ende von Aibo und Qrio bekannt gab, war die Zukunft humanoider Kleinroboter zunächst ungewiss. Als Lösung stellte das französische Unternehmen Aldebaran Robotics noch im selben Jahr den Nao-Roboter vor, der sich seit 2004 in der Entwicklung befand. Er stellt zum Stand dieser Arbeit die momentane Evolutionsstufe humanoider Robotik dar. Innerhalb eines Jahres löste er den Sony Aibo als Standardplattform des RoboCup ab und ist entsprechend auch weit verbreitet als Referenz vorzufinden. 15 Der Nao selbst, welcher seitdem kontinuierlich weiterentwickelt und verbessert wird, ist immer noch ein Prototyp. Er kann auf Anfrage zu einem Preis von ca Euro erworben werden. Die aktuelle Version Nao Next-Gen ist seit Dezember 2011 verfügbar. Abbildung 2.6.: Nao Robocup Edition (2008) 14 In Anbetracht der stetigen Weiterentwicklung in der Technologie, insbesondere in der Mikroelektronik, wird die Robotik in der Zukunft immer weiter ihre Grenzen erweitern können. Man kann davon ausgehen, dass sie im Verlauf dieses Jahrhunderts durchaus ihren bisherigen Rahmen aus spezifischen Einsatzszenarien sprengt und eine Art von künstlichen Lebewesen hervorbringt Technische Spezifikation der Nao-Plattform Überblick Die Nao-Roboterplattform, welche ab 2004 im Zuge des Project Nao von Bruno Maisonnier und seinem Unternehmen Aldebaran Robotics entwickelt wurde, liegt mittlerweile (Stand: Ende 2012) in verschiedensten Variationen vor. Hierbei sind neben den vier Hauptmodellen (H25/H21, T14 & T2) auch unterschiedliche Versionen des Körperaufbaus (V4, V3.3, V3.2 & V3+) verfügbar. Weiterhin existieren sechs Prototypen, welche zwischen 2005 und 2007 angefertigt wurden. (a) Schema des Nao T2 (b) Schema des Nao T14 Abbildung 2.7.: Modelle der T-Serie vgl. [22] 14 Abbildung aus [31] 15 vgl. [48] 16 Abbildungen aus [5], Abschnitt Nao, NAO Hardware, Product Range 11

24 2. Grundlagen zum Aldebaran NAO-Roboter Die Modelle der T-Serie sind keine eigentlichen humanoiden Roboter im herkömmlichen Sinne, da sie nur stationär genutzt werden können. Sie bestehen an sich nur aus dem Nao-Torso entweder ohne (T2) oder mit Armen (T14). Jedoch sind die verwendeten Sensoren identisch mit denen der vollständigen Systeme. Sie werden hauptsächlich für Entwicklungs- bzw. Einsatzzwecke genutzt, welche nur sehr wenige Freiheitsgrade benötigen. Ausserdem eignen sie sich ob ihres geringen Preises auch zum Einstieg in die Entwicklung auf der Nao-Plattform. Abbildung 2.8.: Schema des Nao H25/H21 17 Modelle der H-Serie (Abbildung 2.8) verkörpern im Gegensatz dazu vollständige humanoide Roboter. So sind, wie auch beim Honda ASIMO bzw. Sony Qrio Kopf, Arme, Beine sowie Torso vorhanden und mit entsprechenden Gelenken versehen. Auch Hände mit einzeln bewegbaren Fingern sind vorhanden. Darüber hinaus sind eine Vielzahl von Sensoren installiert, welche individuell genutzt werden können. Zusätzlich verfügen die Modelle der Serie H über eine eigene Stromquelle, wodurch sie in der Lage sind, für einen begrenzten Zeitraum lang autonom zu funktionieren. Eine nähere Vorstellung der Subsysteme und Eigenschaften findet auf den Seiten 14, 15 sowie 16 statt. Sie sind die typischen Nao-Modelle, mit denen man am häufigsten konfrontiert wird. Innerhalb dieser Klasse gibt es verschiedene Spezialausgaben für bestimmte Einsatzzwecke. Dies trifft beispielsweise bei der RoboCup-Edition (H21), bei der im Vergleich zur Academics Edition weder die Hände bewegt werden können noch bestimmte Sensoren verbaut sind, zu. So wird beim Spielen von Roboterfußball eine höhere Stabilität erzielt. 17 Abbildung aus [5], Abschnitt Nao, NAO Hardware, Product Range 12

25 2.2. Technische Spezifikation der Nao-Plattform Die bereits angesprochenen Versionen kategorisieren verschiedene Maße und Gewichte bezüglich des Gesamtsystems. Diese sind innerhalb der Versionen 3 und 4 geringfügig unterschiedlich, untereinander jedoch stark verändert. Abbildung 2.9.: Nao der Fakultät Informatik/TH Nürnberg Da die Arbeit an einem Nao Academics Edition H25, V3.3 implementiert wird (Abbildung 2.9), soll im Folgenden nur auf die Aspekte dieser spezifischen Version eingegangen werden Maße und Gewicht In der sogenannten Zero-Position (vgl. Abbildung 2.10), welche die simpelste Basiskonfiguration in dessen Entwicklungssoftware Choregraphe darstellt, ist der NAO AE H25 V3.3 57,3cm hoch, 27,5cm breit und benötigt einen Raum von mindestens 31,1 cm Tiefe. Abbildung 2.10.: Maße des Nao H25 V3.3 (in mm) 19 Bei der Stand-Position, bei welcher sich die Arme am Torso befinden, bestimmen die Füße des Nao die notwendige Tiefe. Sie liegt dann bei ca. 16 Zentimetern. 18 Anm. Die hier dargestellten Inhalte wurden dabei direkt aus der Dokumentation des Aldebaran Nao entnommen, welche unter [3] bzw. [5] genauer eingesehen werden kann. 19 Abbildung aus [3], Abschnitt Hardware, Overview 13

26 2. Grundlagen zum Aldebaran NAO-Roboter Ohne Batterie wiegt ein Nao H25 ca. 5 Kilogramm. Mit der vollständigen Systemkonfiguration ergibt sich ein Gesamtgewicht von ungefähr 5750 Gramm Kinematik Derartige Nao-Roboter besitzen einen hoch komplexen Bewegungsapparat mit bis zu 25 Freiheitsgraden. Sie stellen sich beim Modell H25 folgendermaßen dar: 20 Abbildung 2.11.: Freiheitsgrade des Nao H25 V3.3 Aus dieser Abbildung lassen sie sich wie folgt ablesen. Körperelement Anzahl Freiheitsgrade Bewegungsmöglichkeiten Kopf 2 Neigung und Drehung (Yaw & Pitch) Arme je 5 je Bewegung & Drehung an der Schulter bzw. dem Ellenbogengelenk, Drehung des Handgelenks Becken 1 Vor- und Rückbewegung der Beine Beine je 5 je Bewegung & Drehung an der Hüfte bzw. dem Fußgelenk, Beugung des Kniegelenks Hände je 1 Öffnen und Schließen der Finger Tabelle 2.1.: Auflistung der Freiheitsgrade des Nao H25 Eine gezielte, naturgemäße Bewegbarkeit von Armen und Beinen beansprucht hierbei den überwiegenden Teil der Freiheitsgrade. Selbstverständlich sind sie dem humanoiden Vorbild nach auf das Körpermodell des Nao adaptiert und daraufhin angepasst worden. Die Abbildungen 2.12 (a) und (b) verdeutlichen dies exemplarisch für die linke Körperhälfte. 20 vgl. dazu [4] 14

27 2.2. Technische Spezifikation der Nao-Plattform (a) Winkelmaße des linken Arms (b) Winkelmaße des linken Beins Abbildung 2.12.: Winkelmaße des H25 21 Die entsprechenden Beschränkungen gelten mit leichten Abweichungen auch für die rechte Körperhälfte Motorik Die Bewegungen der Gelenke werden mit Elektromotoren umgesetzt. Insgesamt handelt es sich hierbei um 26 einzelne Miniaturmotoren, welche sich in zwei verschiedene Typen mit unterschiedlichen Beschleunigungs- und Bremseinstellungen je nach Verwendungszweck aufgliedern. Erwähnenswert ist, dass für die Steuerung des Hüftelements (vgl. Abbildung 2.11, HipYawPitch) nur ein Motor für beide Beine genutzt wird Sensorik Der Aldebaran Nao Academics Edition H25 V3.3 verfügt über eine Vielzahl verschiedener Sensoren, mit denen er sowohl seine eigene Umwelt als auch seinen eigenen Zustand erfassen kann. Zusätzlich wurden berührungsempfindliche Bedienungselemente zur freien Nutzung durch den Anwender verbaut. Im Kopf befinden sich zwei baugleiche Kameras, welche kontinuierlich Bilder beispielsweise für eine Objekt- oder Gesichtserkennung aufnehmen können. Sie liefern dabei eine maximale Auflösung von 640 mal 480 Bildpunkten (VGA-Auflösung) bei 30 Bildern pro Sekunde. Abbildung 2.13 zeigt die Position und den jeweiligen Blickwinkel der Kameras auf. 21 Abbildungen aus [3], Abschnitt Hardware, Kinematics 3.3, Joints Information 22 Anm. Dabei handelt es sich um geringfügige graduelle Versätze insbesondere bei den einzelnen Gelenken der Beine. Ansonsten ist der Großteil des Nao symmetrisch angelegt. 15

28 2. Grundlagen zum Aldebaran NAO-Roboter Abbildung 2.13.: Kameras des Nao H25 V Sie können ein Sichtfeld von 58 Grad (diagonal) ab einem Abstand von ca. 30 cm scharf sehen. Ihr ursprüngliches Ausgabeformat ist hierbei nicht RGB, sondern YUV422. Werden Bilddaten im RGB-Format benötigt, so ist es notwendig, diese zuvor aus den YUV-Daten zu konvertieren. Weiterhin wurde ein Sonarsubsystem in den Roboter eingebaut. Dieses kann sowohl für die Erkennung von Hindernissen und Wänden, als auch für die Abstandsmessung zu selbigen verwendet werden. Es besteht aus einer Anordnung von jeweils einem Transmitter und einem Receiver auf der linken bzw. rechten Hälfte im Zentrum des Torsos (siehe Abbildung 2.14). Obwohl in der Spezifikation die Reichweite der Erkennung auf 70cm festgelegt wurde, kann man in der Praxis noch zuverlässige Daten bei einem Abstand von ca. 2 Metern erhalten. Unter 15cm lässt sich jedoch nur noch die Existenz eines Hindernisses ausmachen. Abbildung 2.14.: Sonarsystem des Nao H25 24 Zur Verarbeitung und Wiedergabe von Audiodaten kann das Soundsubsystem des Nao genutzt werden. Hierfür sind zwei Lautsprecher und vier verschiedene Mikrofone am Kopf des Roboters verteilt und installiert worden. Sie können zum Beispiel für Anwendungsgebiete wie die Spracherkennung oder die Positionsbestimmung von Tonquellen genutzt werden. Seinen eigenen Zustand, wie beispielsweise seine derzeitige Haltung oder die momentane Krafteinwirkung auf bestimmte Körperelemente, überwacht der Nao durch mehrere Gyrometer, Beschleunigungs- und Drucksensoren. Mit diesen ist es möglich, auf ungewöhnliche Bewegungen von aussen zu reagieren, sowie das Laufverhalten und dessen Stabilität aufrecht zu erhalten und zu analysieren. Das Gros der dafür notwendigen Technik befindet sich von einer eigenen CPU überwacht in seiner Brust. Abbildung 2.15 zeigt die typische Konfiguration der Drucksensoren in den Füßen des Nao. Abbildung 2.15.: Fußsensoren des Nao H System Das Computersystem des verwendeten Nao AE H25 V3.3 basiert auf einem AMD GEODE x86 Prozessor, welcher mit 500 MHz getaktet ist. Für das Linux-Betriebssystem, der Steuerungssoftware NaoQI und eigenen Projekten in C++ oder Python stehen 256MB SDRAM als 23 Abbildung aus [3], Abschnitt Hardware, Sensors and Transmitters, Video Camera 24 Abbildung aus [3], Abschnitt Hardware, Sensors and Transmitters, Sonars 25 Abbildung aus [3], Abschnitt Hardware, Sensors and Transmitters, Force Sensitive Resistors (FSRs) 16

29 2.3. Einsatzgebiete und bisherige Projekte Arbeitsspeicher und ein USB-Stick mit 2 Gigabyte Kapazität als Festplatte zur Verfügung. Zugriff auf das System erhält man entweder über den RJ-45 Ethernet-Port oder wahlweise auch über WLAN. Hierbei stehen Dienste wie eine Web-Oberfläche, SSH oder FTP zur Verfügung. Das Gesamtsystem befindet sich im Kopf des Nao-Roboters. Die Steuerungssoftware NaoQI ist nach den Prinzipien eines Enterprise Service Bus (ESB) aufgebaut. Eigene Programmmodule und Funktionen müssen eindeutig deklariert und an einen lokalen oder entfernten Kommunikationspartner angeschlossen werden. Das schliesst ebenfalls auch die mitgelieferten Programmbibliotheken mit ein. Im Zuge der Implementierung wird genauer auf den Aufbau des Softwaresystems eingegangen (vgl. dazu Abschnitt 6.1, ab Seite 81) Stromversorgung Zur Stromversorgung kann entweder das mitgelieferte Netzteil oder ein Akku genutzt werden. Letzterer ist insbesondere für den Test eines autonomen Programms von Vorteil. Nach einer Ladezeit von ca. 5 Stunden kann der Roboter etwa 90 Minuten im Normalbetrieb bzw. 60 Minuten im Vollbetrieb ohne externe Stromquelle betrieben werden. Die Batterie wird am Rücken des Roboters angeschlossen Einsatzgebiete und bisherige Projekte Seit seiner Veröffentlichung genießt die Nao-Reihe eine große Beliebtheit in verschiedensten Einsatzszenarien und Projekten. Im Folgenden werden einige hiervon exemplarisch dargestellt. Sie runden die Vorstellung des Nao ab und erlauben, diese Arbeit im Rahmen der bisherigen Forschung genauer zu positionieren Offizielle Projekte Es existieren unzählige derartige Projekte, welche beispielsweise den Nao schlicht als Zielplattform oder auch als Referenz für zukünftige humanoide Roboter nutzen. Als erstes ist hierbei der bereits erwähnte RoboCup zu nennen, durch den der Nao auch ursprünglich bekannt wurde. Es handelt sich hierbei um ein Projekt, welches sich als Ziel gesetzt hat, bis 2050 menschliche Spieler im Fußball zu besiegen. Primär geht es dabei natürlich nicht um das Fußball spielen an sich, sondern viel mehr um Fortschritte in Forschungsbereichen der Robotik wie u. a. der Sensorik, Kinetik oder auch der Bildung kollektiver Intelligenz. Neben dem Nao werden dort aber auch andere (nichthumanoide) Roboter eingesetzt. 26 Ein weiteres, andersartiges Einsatzszenario des Nao steht hinter dem sog. KSERA Project. 27 Es dient dem Zweck der Erschaffung von Knowledgeable SErvice Robots for Aging, also von Assistenzrobotern für ältere Menschen. Sie sollen insbesondere letzteren helfen, wenn diese auf eigenen Wunsch hin so lange wie möglich zu Hause leben möchten. An dem Projekt, welches Februar 2010 initiiert wurde, sind verschiedenste Universitäten und Abbildung 2.16.: Robocup 2009 Abbildung 2.17.: Arbeit des KSERA Project 26 Abbildung und Hintergrundinformationen vgl. [47] 27 Abbildung und Hintergrundinformationen vgl. [46] 17

30 2. Grundlagen zum Aldebaran NAO-Roboter auch die Europäische Kommission beteiligt, welche die Nützlichkeit von humanoiden Robotern im Zuge der Altersverschiebung eruieren will. Weiterhin befasst sich das Unternehmen Aldebaran Robotics selbst mit dem Problem der zunehmenden Rate von Autismus bei Kindern. Hierfür pflegen sie eine Partnerschaft mit Ärzten, Therapeuten, Schulen und Universitäten, um den Nao auch hier als helfendes Element einzusetzen. 28 Erste Versuche an entsprechenden Schulen zeigen nach aktuellen Medienberichten bereits erste Erfolge. Den Kindern fällt es dabei leichter, mit dem vorhersehbaren Verhalten der Roboter umzugehen. 29 Man kann davon ausgehen, dass diese Forschungsbemühungen fortgesetzt werden Projekte der Technischen Hochschule Nürnberg Im Rahmen der Anschaffung des Nao AE H25V33 im Sommer 2011 sind an der Technischen Hochschule Nürnberg Georg-Simon-Ohm bereits einige Projekte und Abschlussarbeiten auf Basis dieser Roboterplattform entstanden. So setzte sich u. a. eine Abschlussarbeit bereits mit der Thematik auseinander, inwiefern der Nao zur eigenständigen Erkennung von Objekten im Raum bzw. deren Transport in der Lage ist. Ein anderer Ansatz implementierte die Imitation menschlicher Bewegungen durch den Roboter auf Basis der Microsoft Kinect. Auch das Spielen von Minigolf war bereits ein Thema Fazit und Position dieser Arbeit Die hoch entwickelte Technologie des Aldebaran Nao ist eine Folge der zahlreichen Forschungen in der Robotik. Seine Einsatzgebiete sind mehr als nur vielfältig. Sie bedienen Themen aus Gebieten wie der menschlich-maschinellen Interaktion oder auch der Autonomie von Lebensformen gleichermaßen. In diese Reihe der bis dorthin unternommenen Bemühungen wird sich diese Arbeit mit dem Konzept, auf Basis eigenständiger Forschung einen Raum nach Gefahrenquellen zu analysieren, zu umgehen und zu kartografieren, nahtlos eingliedern. Sie verbindet dazu Teilkonzepte (z. B. Bildverarbeitung und Kinetik) zu einem neuen komplexen Konstrukt auf Basis künstlich intelligenter Robotik. Ein derartiger Ansatz hat so als Arbeit an der Technischen Hochschule Nürnberg Georg-Simon-Ohm bislang noch nicht existiert. 28 vgl. [6], Abschnitt News 29 vgl. [13] 18

31 3. Idee und Basiskonzeption Mit dem Hintergrundwissen aus der Robotik bzw. zu der Aldebaran Nao-Roboterplattform ist es nun möglich, sich der Problemstellung dieser Arbeit zuzuwenden. Im Zuge dessen wird zunächst die eigentliche Idee vorgestellt. Aus diesem Ansatz heraus werden im Folgenden Ziele für eine Spezifikation abgeleitet, welche als Basiskonzept maßgeblich für die Bearbeitung des Themas sein wird. Ebenfalls werden typische Einsatzszenarien betrachtet, um dem Leser Beispiele und Anwendungsgebiete für das Thema und die Praktikabilität der einzelnen Komponenten des Entwurfs aufzuzeigen. Eine Evaluation der Bedienungsphilosophie vervollständigt die Einführung in das Gesamtkonzept und rundet das Kapitel ab Hintergrund und Idee Die technische Entwicklung hat innerhalb des letzten Jahrzehnts neben dem Nao noch eine Vielzahl weiterer Erfindungen hervorgebracht. Hierzu zählen beispielsweise intelligente elektronische Assistenten wie das Apple Siri-System (vgl. Abbildung 3.1a) oder auch schon die nächste Generation von humanoiden Robotern (vgl. Abbildung 3.1b). Letztere ist für Ende 2012 im Rahmen des Project Romeo, an dem auch Aldebaran Robotics beteiligt ist, angekündigt. (a) Apple Siri (b) Aldebaran Romeo Abbildung 3.1.: Technologiefragmente des digitalen Zeitalters im Jahre Wie in Abschnitt 2.3.1, S. 17 erwähnt, finden zur Zeit viele unterschiedliche Bemühungen statt um die Integration von Robotern in den Alltag der Menschen voranzutreiben. Um dieses Ziel zu erreichen, verschmelzen sie Aspekte zuvor getrennter Systeme. So ist es durchaus möglich, dass bald für derartige Vorhaben ein Roboter mit Siri-artigen Funktionen existiert. Bisweilen haben solche Projekte aber auch immer nur eine festgelegte Zielgruppe, wie z. B. im Falle des KSERA-Projektes Menschen mit chronisch obstruktiven Lungenerkrankungen. 1 Abbildungen aus [7] und [6], Abschnitt Pressroom, About, Romeo 19

32 3. Idee und Basiskonzeption Ein ähnlicher Gedanke führte zu der initialen Idee hinter dieser Arbeit: Lassen sich humanoide Roboter und die gegenwärtige Technologie auch zur Assistenz von Menschen mit Sehbeeinträchtigungen nutzen? Falls ja, wie schafft man ein solches System und welche Probleme gibt es? Im Verlauf der darauf folgenden Tage durchlief diese Idee mehrere Iterationsschritte. Hauptsächlich wurden dabei Überlegungen angestellt, auf welche Art und Weise eine solche Assistenz eigentlich nützlich und machbar sein könnte. Jener Gedankengang führte letztendlich zum Thema dieser Arbeit. Die Idee ist, einen humanoiden Roboter potentielle Gefahrenquellen in seinem Umfeld eigenständig erkennen zu lassen, um sie zu navigieren und gleichzeitig den Sehbehinderten vor den gefundenen Hindernissen zu warnen und ihn somit anzuleiten. Gefahrenquellen sollen hierbei entweder durch Schilder (vgl. Abbildung 3.2) oder einfache Hürden, wie beispielsweise nahe vor dem Roboter kreuzende Objekte, gegeben sein. Ein derartiges System implementiert quasi eine elektronische Form eines Suchtieres beispielsweise eines Blindenhundes und wäre somit tatsächlich nützlich. Zudem würde es einen weiteren kleinen Fortschritt in der humanoiden Robotik bedeuten. Abbildung 3.2.: Gefahren durch Schilder Zielspezifikation Natürlich ist es zunächst einfach die Idee als solche darzustellen und sich selbst als Leser ein Bild hiervon zu machen. Mit etwas Fantasie lassen sich hierbei bereits einige Szenarien, in denen ein solches System zum Einsatz kommen könnte, ersinnen. Jedoch ist einem auf diese Art und Weise zunächst unklar, welche komplexen Teilschritte und - lösungen hinter einem derartigen Konzept stecken können. Bevor wir uns also mit exemplarischen Einsatzszenarien befassen (s. Seite 22), wird in diesem Abschnitt eine genauere Zielspezifikation auf Basis der Idee erarbeitet. Abbildung 3.3.: Entwicklungsmodell für reaktive Robotersysteme nach Murphy 3 2 Abbildung aus [40] 3 Abbildung aus [42], S

33 3.2. Zielspezifikation Um hierbei sinnvoll Vorzugehen, orientiert sich die Methodik in ihren Grundzügen nach dem Entwicklungsmodell für reaktive Robotersysteme nach Murphy. 4 Auch wenn später ersichtlich werden wird, dass derlei Systeme für die Implementierung nicht ausreichen (vgl. S. 96 ff.), so sind doch die Schritte 1-3 in Abbildung 3.3 durchaus nützlich. Diese sehen vor, für eine gute Spezifikation zunächst die Aufgabe, den Roboter und die Umgebungsbedingungen des Systems zu beschreiben bzw. festzulegen. In Abschnitt 2.2 (ab Seite 11) wurde die für die Implementierung genutzte Roboterplattform bereits ausführlich vorgestellt. Punkt 2 ist somit bereits erfüllt. Da in Abschnitt 3.3 die Umgebung das zentrale Thema darstellt, verbleibt für eine vollständige Zielspezifikation nach Murphy die genaue Beschreibung der Aufgabe. Hierfür wird die Idee aus Abschnitt 3.1 weiter analysiert und spezifiziert. Insbesondere müssen Teilkomponenten identifiziert und anschließend definiert werden. Das Ergebnis, welches die Idee somit auch präzisiert, klärt die Frage was der Roboter nach Abschluss des Projektes können soll und was nicht Umfang Bei genauerer Überlegung bedingt das eigenständige Erkennen von potentiellen Gefahrensituationen und ein intelligentes Verhalten bei deren Vermeidung bzw. der Nutzerinteraktion die Funktion verschiedener Teilschritte. Sie können als Komponenten der Zielspezifikation, ihrem logischen Ablauf nach, wie folgt aufgelistet werden: Suchen und Extrahieren von Bedrohungen in der Umgebung Erkennen ihrer Bedeutung Lokalisation der Bedrohung bzgl. des Roboters Navigation Interaktion Dabei wäre pro Element jeweils der nachstehende, abstrakte Funktionsumfang wünschenswert um die Idee dieser Arbeit bestmöglich zu realisieren Suchen und Extrahieren von Bedrohungen in der Umgebung Der Roboter muss jederzeit zum Suchen und Extrahieren von möglichen Gefahrensituationen bzw. Warnzeichen in dem von ihm gerade wahrnehmbaren Ausschnitt der Umwelt befähigt sein. Hierfür hat er auf zuverlässige Sensorik und Referenzdaten zurück zu greifen. Insbesondere ist eine Art Bewusstsein notwendig, welche während des Betriebs kontinuierlich alle gesammelten Daten speichert und für eine weitere, kontextsensitive Analyse nutzt. Es darf keine Gefahrensituation mehrfach erkannt werden. Da dieser Prozess (der Suchprozess in einer Szene an sich) während der gesamten Laufzeit stets aus der Ich-Perspektive des Roboters stattfindet, muss letzterer auch seine Position erkennen können. Es sollten dabei möglichst viele Bedrohungen in der Umwelt des Roboters auch wirklich gefunden bzw. ihre Existenz erkannt werden. Ein Anspruch auf Vollständigkeit ist jedoch nicht gegeben. 4 vgl. [42], S

34 3. Idee und Basiskonzeption Erkennen der Bedeutung Eine gefundene Bedrohung muss anschließend auf ihre Bedeutung hin vom Roboter eigenständig untersucht werden. Hierzu hat er die Beobachtungen einerseits mit einer Art Bibliothek von repräsentativen Mustern, andererseits jedoch auch untereinander, zu vergleichen. Bis zu einer bestimmten Grenze darf die Erkennung keine falschen Klassifikationen zu den Beobachtungen liefern. Eine Einschränkung stellt die Erkennung von Gefahren auf Basis unzureichender Sensordaten dar (Objekt zu schnell/zu komplex) Lokalisation der Bedrohung Nach der Klassifikation muss die Bedrohung bezüglich der Position/Orientierung des Roboters bzw. dessen Benutzers von ersterem lokalisiert und in einer Art Karte vermerkt werden. Auch hierbei spielen bereits genannte Aspekte wie die Technologie hinter der Sensorik eine entscheidende Rolle. Es sollte möglichst vermieden werden, dass falsche Messdaten die Karte verfälschen Navigation Auf Basis der Daten in der Karte muss der Roboter befähigt sein einen Weg, welcher möglichst alle erkannten Hindernisse vermeidet, eigenständig zu ermitteln. Es ist dabei jedoch auch durchaus möglich, dass kein Weg für eine bestimmte Situation existiert. Weiterhin soll nicht der Anspruch gelten, dass der gefundene Pfad effizient ist bzw. der kürzesten Variante entspricht Interaktion Das System muss in der Lage sein, seinen Zustand sowie die gefundenen potentiellen Gefahrenquellen und den dazu passenden Lösungsweg dem Benutzer mitzuteilen. Ausserdem werden Bedienkonzepte benötigt, welche den Suchablauf intuitiv beeinflussen. Ein einfaches Starten und Stoppen seitens des Nutzers sollte hierbei die größte Priorität besitzen Fazit Summiert man die Spezifikationen dieser Teilkomponenten auf, wird sehr schnell die Komplexität der einst so einfachen Idee deutlich. Die daraus entstehende Zielspezifikation bildet im Folgenden eine wesentliche Richtlinie für die Bearbeitung des Themas und die Verwirklichung der Idee. Es wird im weiteren Verlauf der Arbeit eruiert, ob der gesamte avisierte Funktionsumfang auch wirklich implementiert werden kann Einsatzszenarien Da nun die Idee und die dafür notwendigen Teilzeile gegeben sind, ist es möglich anhand von exemplarischen Einsatzszenarien das Gesamtkonzept noch besser zu verdeutlichen und dessen Anwendbarkeit aufzuzeigen. Hierfür wird zwecks der besseren Vorstellbarkeit zunächst ein praktisches Beispiel aus dem Alltag genutzt. Die Teilkomponenten aus der Zielspezifikation (vgl. S. 21 f.) werden dabei sukzessive angewendet. Weiterhin wird auch eine mögliche Variation des Szenarios speziell für den 22

35 3.3. Einsatzszenarien Aldebaran Nao-Roboter generiert. Auf diese Art und Weise erfolgt eine Modellierung der Umwelt des Robotersystems, um so eine vollständige Zielspezifikation nach Murphy zu erhalten (vgl. Punkt 3 in Abbildung 3.3, S. 20) Szenario R: Realität Eines der am leichtesten vorstellbaren Einsatzgebiete der Idee könnte beispielsweise aus dem folgenden Szenario bestehen: Eine ältere Frau, welche nicht mehr gut sehen kann, möchte eine Strasse überqueren. Da, gerade in der heutigen Zeit, ein immer stärker werdendes Verkehrsaufkommen und eine zunehmende Anzahl von Schildern dieses Unterfangen nicht gerade vereinfachen, wäre Hilfe in Form einer leitenden Hand sehr nützlich. Der Sachverhalt erinnert einen sehr stark an die gute Tat eines Pfadfinders (siehe Abbildung 3.4), der in früheren Zeiten genau die passende Antwort auf derartige Problemstellungen war. Abbildung 3.4.: Gute Tat eines Pfadfinders 5 Gerade im Winter könnte eine hierfür entsprechende Umwelt nach Abbildung 3.5 modelliert werden. Das Ziel wäre es in diesem Falle, die ältere Frau anzuleiten, die Strasse weder bei der Baustelle noch bei potentiell glatten Verhältnissen zu überqueren. Tatsächlich sollte der geringe Umweg über den Fußgängerübergang eingeschlagen werden. Da dessen Kennzeichen möglicherweise ausserhalb des Sichtfelds der Dame ist, nimmt sie diesen zunächst nicht wahr. Auch auf das heranfahrende Auto muss Rücksicht genommen werden. Ziel Frau P.finder Start Abbildung 3.5.: Aufbau Szenario R Um diese komplexe Problemstellung zu lösen, müsste der Pfadfinder bzw. ein humanoider Hilfsroboter zunächst die Aufgabe in einzelne Teile zerlegen. Eine sukzessive Anwendung der Teilkomponenten der Zielspezifikation würde dabei folgendes Ergebnis liefern: Suchen und Extrahieren von Bedrohungen in der Umgebung Der Pfadfinder würde selbstverständlich zuerst seine Umgebung genau betrachten. Bei der Suche kämen wahrscheinlich zunächst nur visuelle Eindrücke in Frage, da damit die wesentlichsten Bedrohungen einfach und schnell gefunden werden können. Natürlich nimmt er ein Schild nicht mehrfach wahr und er kennt normalerweise auch seine eigene Position relativ zur Umwelt. Falls 5 Abbildung aus [16] 23

36 3. Idee und Basiskonzeption er sorgfältig ist, wird er mit der Betrachtung nicht eher aufhören, bis er alles notwenige wahrgenommen hat. Auf diese Art und Weise gelingt es dem Pfadfinder, die drei potentiellen Gefahren zu identifizieren und in die Wegplanung einzubeziehen. Erkennen ihrer Bedeutung Da der Pfadfinder über das notwendige Hintergrundwissen verfügt, fällt es ihm sehr leicht die erkannten Gefahrenquellen zu klassifizieren. Die Bedeutung der einzelnen Verkehrsschilder und das heranfahrende Auto sind ihm innerhalb weniger Sekunden bewusst und er ist in der Lage diese sinnvoll zu priorisieren. Fehlinterpretationen kommen praktisch nicht vor. Lokalisation der Bedrohung(en) Dank seines Orientierungssinnes und der räumlichen Wahrnehmung kann der Pfadfinder ohne weiteres die relativen Positionen der einzelnen Gefahrenquellen ausmachen. Diese fügt er sehr einfach seiner Beobachtung hinzu, wodurch er im Kopf somit eine Karte der Umgebung geschaffen hat. Navigation Anhand der gesammelten Erkenntnisse plant der Pfadfinder nun einen gefahrenfreien Weg. Da er die Bedeutung eines Fußgängerübergangs kennt, wird er natürlich diesen auch nutzen. Interaktion Schlussendlich kann der Pfadfinder von den Gefahren berichten bzw. den Weg verkünden oder die ältere Dame einfach an die Hand nehmen und sie auf die andere Strassenseite führen. Fazit Die Teilkomponenten der Zielspezifikation lösen also in der Tat die Problemstellung. Gleichermaßen kann man aus diesem Ansatz eine Variante für den Aldebaran Nao-Roboter ableiten, welche im weiteren Verlauf dieser Arbeit als Vorlage für die Implementierung der Idee gilt Szenario N: Nao Obwohl der Aldebaran Nao-Roboter durchaus humanoide Eigenschaften besitzt, ist er dennoch bei weitem nicht mit einem richtigen Menschen zu vergleichen. Dies liegt nicht nur zuletzt daran, dass er wesentlich kleiner ist als seine realen Kollegen, sondern auch an der Tatsache, dass ihm durch die Grenzen der verbauten Technologie Beschränkungen auferlegt sind. Fakt ist, der Nao ist derzeitig nicht in einem realen Kontext wie in Szenario R (ab Seite 23) beschrieben, einsetzbar. Da mit der fortschreitenden Entwicklung diese Hürden mit Sicherheit bald der Vergangenheit angehören werden (vgl. Abbildung 3.1b, Seite 19), kann er aber trotzdem als Grundlage für eine Studie zur Lösung derartiger Probleme durch humanoide Roboter dienen. 24

37 3.3. Einsatzszenarien Labor/Testraum Bezugsraum Hindernis Ziel Nao Start Abbildung 3.6.: Aufbau Szenario N Hierfür muss natürlich die Umwelt für eine entsprechende Realisierbarkeit angepasst werden. Abbildung 3.6 zeigt eine mögliche Variante eines angemessenen Einsatzszenarios. Statt auf offener Strasse wird dabei ein identisches Konzept innerhalb eines Raums aufgebaut. Schilder dienen weiterhin als Warnzeichen und sich möglicherweise bewegende Hindernisse (das Auto in Szenario R) werden nun durch leicht verschiebbare Gegenstände wie beispielsweise Bürostühle repräsentiert. Obwohl sich somit alles nur noch in einem minimalistischem Bezugsraum abspielt, bleibt die grundsätzliche Idee jedoch von der Transformation unberührt. So ist es weiterhin die Aufgabe des Nao, ein solches Areal nach potentiellen Gefahrenquellen zu durchsuchen, sie zu erkennen und um sie zu navigieren. Im Falle dieses Szenarios wäre also das Ziel, dass der Nao-Roboter vom Startpunkt aus eigenständig seinen Bestimmungsort erreicht, ohne dabei die gegebenen Gefahren(-situationen) zu missachten. Tatsächlich wäre auch die Erstellung einer Karte und deren Wiedergabe nach einem Suchlauf wünschenswert. Auch der ermittelte Pfad ist ein Ausgabekriterium. Durch die neue Umgebung ist auch der Nao in der Lage die Idee umzusetzen. Hierfür nutzt er die gleiche Zerlegung wie der Pfadfinder, ob seiner Natur jedoch modifiziert um einen technologiebasierten Standpunkt. Suchen und Extrahieren von Bedrohungen in der Umgebung Auch der Nao-Roboter muss zuerst die von ihm gerade wahrnehmbare Umgebung genau betrachten. Hierfür ist es erforderlich, dass er auf verschiedene Fähigkeiten seiner Sensorik zurückgreift, wie beispielsweise auf die Kameras oder sein Sonarsystem. Um Fehl- bzw. Mehrfacherkennungen auszuschließen, muss er über eine wachsende Datenstruktur verfügen, welche sowohl aus grundsätzlichen Parametern (Was ist ein Schild oder eine Gefahrensituation aus der Sicht der Sensorik eigentlich?) aber auch aus der Vergangenheit (Was habe ich schon gefunden?) besteht. Dies erfordert auch, dass der Nao seine Position im Bezugsraum durch seine Sensorik bzw. auf Basis der gesammelten Daten wahrnehmen kann. Auch er sollte die Existenz von so vielen Bedrohungen wie möglich aus den visuellen bzw. akustischen Daten erkennen. Es ist jedoch klar, dass dies möglicherweise nicht vollständig und/oder in einem engen Zeitfenster garantiert werden kann. 25

38 3. Idee und Basiskonzeption Erkennen ihrer Bedeutung Die gesichteten potentiellen Gefahren müssen anschließend vom Nao eigenständig interpretiert werden. Im Falle der visuellen Daten geschieht das hauptsächlich über Klassifikation zu Referenzmustern, während bei den Abstandsdaten hingegen ein robustes Vergleichsmaß notwendig ist. Bis zu einer bestimmten Grenze darf die Erkennung keine falschen Klassifikationen zu den Beobachtungen liefern. Eine zu schnelle Änderung der Umgebung bzw. zu komplexe Objekte können jedoch nicht in die Erkennung mit einbezogen werden. Lokalisation der Bedrohung Der Nao muss die Position der klassifizierten Gefahrenquellen bzw. -zeichen aus seinem derzeitigen Standort ermitteln können. Hierfür wird weiterhin auch ein Abstandsmaß für die visuellen Eindrücke benötigt, um deren ungefähre Lage und Distanz zu errechnen. Zusätzlich muss eine Karte, welche die gegenwärtige Stellung bzw. Orientierung des Roboters im Bezugsraum, die Position der Hindernisse sowie die Grenzen des Raums enthält, angefertigt werden. Navigation Auf Basis der Daten hat der Nao einen Weg durch die Gefahrensituationen eigenständig zu finden. Zu diesem Zweck muss ein geeigneter Suchalgorithmus die Karte untersuchen und ggfs. auch die Möglichkeit, dass kein Pfad gefunden werden kann, berücksichtigen. Der Fokus liegt dabei klar auf der Findung irgendeines Wegs. Dieser muss weder effizient noch der kürzest mögliche sein. Interaktion Der Nao sollte über einfache Bedienelemente steuerbar sein. Um den Suchprozess zu starten, könnte ein einfaches Kommando über einen Knopfdruck oder ein Sprachbefehl abgegeben werden. Dasselbe gilt für die vorzeitige Beendigung des Suchlaufs. Weiterhin wird der gefundene Pfad und die Karte über die Software ausgegeben. Eine genauere Spezifikation dazu ist in Abschnitt 3.4 (S. 26 ff.) vorzufinden. Fazit Somit ist neben den Zielen auch die Umwelt des zu implementierenden Robotersystems nach dem Modell von Murphy (vgl. Punkt 3 in Abbildung 3.3, Seite 20) festgelegt. Ausserdem ist ganz exemplarisch die Praktikabilität aller Komponenten der Zielspezifikation verdeutlicht worden Bedienungsphilosophie Ohne eine möglichst intuitive und einfache Benutzerinteraktion wäre ein derartiges System leider aber nur bedingt einsetzbar. Aus diesem Grund muss man gerade über den letzten Punkt der Zielspezifikation die Interaktion weiterführende Gedanken über deren Ausgestaltung und Umfang anstellen. 26

39 3.4. Bedienungsphilosophie Hierbei muss ein Konzept gefunden werden, welches einerseits zur Idee passt, andererseits jedoch auch gut auf Roboter wie den Aldebaran Nao anwendbar ist. Da die Assistenz von Menschen einen wesentlichen Aspekt des Gesamtkonzeptes darstellt, sollte sich diese Teilkomponente deshalb an den Grundprinzipien humanoider Kommunikation bzw. Interaktion orientieren. Wie zu Beginn dieser Arbeit bereits erwähnt, manifestieren sie sich aus Komponenten wie Gestik, Mimik und dem Sprechen. Eine Betrachtung der technischen Möglichkeiten des Nao unter dem Kontext der Nachahmung von menschlichem Verhalten ließe dabei ein Konzept aus den folgenden Systemen zu: Sprachsynthese Spracherkennung Vorführung des Pfades haptische Bedienelemente & visuelle Signale (optional) Körperhaltung Visualisierung durch Software Zur Vervollständigung der Zielspezifikation werden die dazu passenden Ideen bzw. Ansätze jeweils kurz erläutert Sprachsynthese Eine Benutzung von Sprache würde es ermöglichen, dem Nutzer des Roboters sehr schnell Informationen zu vermitteln und ihn über den Zustand des Systems aufzuklären. Das auf Seite 16 vorgestellte Soundsubsystem des Nao könnte eine solche Funktion gewährleisten, da es auch genutzt werden kann um im Voraus definierte Sprachelemente mittels Wortsynthese wiederzugeben. Im Hinblick auf eine intuitive Bedienbarkeit wäre ein möglichst unmissverständlicher und einfacher Wortschatz erforderlich. Dieser könnte nach Tabelle 3.1 folgendermaßen beschrieben werden. Ausgabe durch Nao Hello, i am ready Starting search Sign detected Obstacle detected Stopping search Finished Error Battery low Left/Right & Forward/Backward Bedeutung System bereit Start des Systems Schild erkannt (bspw. Stop-Schild) Hindernis erkannt Stop des Systems Suchlauf beendet Fehler Nutzereingriff nötig Batterie ist fast leer Richtungsangaben Tabelle 3.1.: Vokabular für Sprachsynthese Ein derartiger Wortbestand ist für den Rahmen einer prototypischen Implementierung ausreichend. 27

40 3. Idee und Basiskonzeption Spracherkennung Neben dem Verstehen von Sprache nutzt der Mensch sie auch selbst, um beispielsweise seinem Gegenüber Wünsche effizient auszudrücken. Da das Soundsubsystem des Nao auch über mehrere Mikrofone verfügt, könnte mit diesen eine ähnliche Interaktion ermöglicht werden. Hierfür wird die Stimme des Nutzers aufgezeichnet und die Aufnahme nach Hinweisen auf verbale Befehle analysiert. Befehl Start search! Abort search! Tell path! Tell obstacle! Bedeutung Starte mit Suche Beende die Suche Pfad wiedergeben Hindernisse wiedergeben Tabelle 3.2.: Vokabular für Spracherkennung Auch hier ist ein eingeschränkter Wortschatz von Vorteil (vgl. Tabelle 3.2). Die resultierende Lernkurve des Nutzers ist minimal und das Gesamtsystem wird durch die technischen Einschränkungen der Spracherkennung kaum beeinflusst Vorführung des Pfades Eine weitere Art eine Assistenz von Menschen zu realisieren besteht neben der Nutzung von Sprache in dem Prinzip der Nachahmung. In diesem Fall wäre es sinnvoll, wenn der Roboter den gefundenen Pfad anleitend selbstständig abläuft und optional hierzu weiterhin Elemente der Sprachausgabe nutzt um sein Vorgehen zu erläutern. Somit könnte ein Mensch, der beispielsweise hinter dem Roboter steht, die Verhaltensweise des Roboters kopieren und so selbst an den Gefahrenquellen vorbei kommen Haptische Bedienelemente und visuelle Signale Aufgrund der Tatsache, dass der Nao weder über Haut noch über eine Gesichtsmuskulatur verfügt, können Aspekte der Mimik im Sinne der Benutzerinteraktion nur über alternative Wege realisiert werden. Hierfür bieten sich die LEDs, sowie die haptischen Bedienelemente des Roboters an. Beide sind über seinen gesamten Körper verteilt und können vollständig mit eigenen Funktionen programmiert werden. So wäre es beispielsweise möglich, unmittelbar nach der Erkennung eines Hindernisses die Farbe der Augen zu verändern. Weiterhin ist auch eine Signalisierung des Suchfortschritts vorstellbar. Da Grundfunktionen wie Start und Stop immer verfügbar sein sollen, können sie auf zwei der drei berührungssensitiven Sensoren am Kopf des Nao gelegt werden. Ausserdem ist eine Aufnahmetaste für die Spracherkennung sinnvoll, damit diese nicht permanent aktiviert bleibt und unnötig Rechenleistung beansprucht Körperhaltung Es wäre durchaus möglich, Elemente der Gestik für die Benutzeraktion in das System mit einzubeziehen. Die Handlungen des Roboters würden somit noch menschlicher erscheinen. 28

41 3.4. Bedienungsphilosophie Beispielsweise wäre ein Erschrecken des Nao bei plötzlichem Auftauchen eines Hindernisses in seinem Weg mit Sicherheit machbar. Auch dass er mit einem Finger auf ein mögliches Hindernis deutet ist eine weitere Option. Aus Vereinfachungsgründen wird diese Idee jedoch nicht dem Bedienkonzept hinzugefügt Visualisierung durch Software Auch wenn eine externe Visualisierung in Form einer GUI-Oberfläche kaum im Sinne einer humanoid-orientierten Kommunikation mit dem Benutzer gesehen werden kann, so ist sie für die Entwicklung und Test des Systems extrem hilfreich. Abbildung 3.7 zeigt einen ersten Entwurf, wie eine solche Software aussehen könnte. RobotSurveillanceApp #Zyklen Karte Suche Start Suche Stop Abbildung 3.7.: Mock-up der Überwachungssoftware Sie bietet hierbei Einblick in den Zustand des Systems (bspw. der internen Kartenstruktur) und erlaubt dessen Fernsteuerung über eine Netzwerkverbindung. Auf diese Art und Weise könnte somit eine ständige Präsenz neben dem Roboter vermieden werden Fazit Die aus all diesen Teilsystemen entstehende Benutzerinteraktion orientiert sich, getreu den technischen Möglichkeiten des Nao, an humanoiden Grundelementen. Es erweitert die Zielspezifikation nach Abschnitt 3.2 und vervollständigt sie zu einem Basiskonzept. 29

42

43 4. Konzeptanalyse Das Konzept bzw. die damit verbundene Zielspezifikation sind so natürlich noch lange nicht einfach so umsetzbar. Hierfür sind deren Komponenten noch zu idealistisch formuliert und in ihren Teilproblemen zu unklar. Eine Implementierung wäre an dieser Stelle deswegen noch sehr schwierig. Um derartige Probleme zu lösen, hat sich in der Informatik der Ansatz, zuerst ein System vernünftig zu modellieren, durchgesetzt. Auch in anderen Wissenschaften geht man genauso vor, man nutzt dabei häufig das Prinzip des divide-and-conquer. 1 Bevor man also überhaupt an die Realisierung eines Systems denkt, ist es sinnvoll, im Voraus möglichst alle Teilelemente jeder einzelnen Anforderung zu erkennen und sie sukzessive zu lösen. Analog zu dieser weit verbreiteten Vorgehensweise wird in diesem Kapitel eine weiterführende Analyse der Zielspezifikation bzw. des Basiskonzeptes vorgenommen. Das Ziel ist es, ein theoretisches Modell aller für eine prototypische Implementierung notwendigen Aspekte aus verschiedenen Gebieten der Wissenschaft zu finden. Würde ein solches vorliegen, so könnte man aus diesem dann durch Benutzung von Lösungsansätzen aus der Informatik bzw. Robotik eine besser umsetzbare Spezifikation erzeugen Wissenschaftliche Aspekte des Konzeptes Wenn man einen Schritt zurück tritt und vergleichbare Systeme wie das KSERA-Projekt (vgl. Abschnitt 2.3.1, Seite 17) betrachtet, so fällt auf, dass insbesondere die humanoide Robotik scheinbar aus Erkenntnissen vieler unterschiedlicher Wissensgebiete der Forschung schöpft. So werden oft Lösungsmuster aus der Mathematik, Physik und der Informatik mit Elementen aus der Psychologie vermischt. Die Robotik könnte also als eine Art Königsdisziplin der derzeitigen Wissenschaft gesehen werden. Um also tatsächlich lösbare, elementare Teilprobleme aus den Komponenten der Spezifikation abzuleiten, müssen sie eine entsprechende Basis in den genannten Wissensbereichen finden. Aus diesem Grund wird bei der Konzeptanalyse zunächst aus einer gesamtwissenschaftlichen Perspektive vorgegangen. Die einzelnen Ziele werden dabei jeweils auf diesbezügliche Überschneidungen untersucht Suchen und Extrahieren von Bedrohungen in der Umgebung Das Suchen und Erkennen der Existenz einer oder mehrerer Bedrohungen nach dem ersten Punkt der Zielspezifikation muss hierbei eindeutig Problemlösungen aus der Physik und der Psychologie nutzen. Wie in Abbildung 4.1 angegeben, benötigt man zunächst eine Lösung um optische und akustische Daten aus dem jeweils gerade wahrnehmbaren Ausschnitt der Umgebung zu erhalten. Hierfür helfen Erkenntnisse aus der Physik, welche die Erfindung von Kameras und Mikrofonen zur Folge hatte. Ausserdem ist ein optischer Algorithmus notwendig, um eindeutige Merkmale 1 zu deutsch: teile und herrsche - eine Problemlösungstechnik, bei der ein komplexer Sachverhalt solange in elementar zu lösende Bruchstücke zerlegt wird, bis deren Zusammensetzung schließlich diesen effizient lösen 31

44 4. Konzeptanalyse Perzeption Optik künstliche Intelligenz(KI) Reflexion Suchen und Extrahieren von Bedrohungen in der Umgebung Physik Akustik Abbildung 4.1.: Gebiete der Wissenschaft im Suchen und Extrahieren-Ziel von Bedrohungen aus dem Bild bzw. den akustischen Daten heraus zu rechnen. Die bloße, jedoch nicht weiter verarbeitete, Wahrnehmung von Dingen entspricht dabei dem psychologischen Konzept der Perzeption, welche nach Guilford eine Operation von Intelligenz ist. 2 Da dieser Prozess später den wesentlichen Input darstellt, lässt sich bereits hier die Notwendigkeit eines Systems erahnen, welches eine Art künstliche Intelligenz bzw. Bewusstsein realisiert. Um schon bei der reinen Feststellung von Bedrohungen wie beispielsweise von Verkehrsschildern Fehler durch unterschiedliche Perspektiven zu unterbinden, ist ein solches ebenfalls erforderlich. Die Stichwörter für eine mögliche Lösung lauten dazu Gedächtnis und Reflexion. Derartige Lösungsmuster würden helfen, in der Vergangenheit bereits gefundene Gefahrenquellen als solche zu identifizieren und diese zu ignorieren. Also benötigt man neben einer Datenbank auch Funktionen, welche deren Konsistenz zur Laufzeit überwachen. Weil dafür jedoch auch der Roboter die bereits durchlaufenen Positionen kennen muss, ist es notwendig, dass er sich seiner Taten bewusst ist. Somit wird die Signifikanz eines entsprechend intelligenten Systemaufbaus bekräftigt Erkennen ihrer Bedeutung Nach der einfachen Wahrnehmung der Existenz von Bedrohungen müssen laut Spezifikation diese weiter verarbeitet und ihre individuelle Bedeutung interpretiert werden. Da hierfür verstärkt kontextsensitives Wissen notwendig ist, ist es erforderlich, die künstliche Intelligenz des Roboters durch weitere psychologische Prinzipien zu ergänzen. So bestimmen neben einer kontinuierlichen Perzeption auch Evaluation und eine erweiterte Reflexion weiterhin die Funktion des Systems (vgl. Abbildung 4.2). Es erhält dadurch kognitive Eigenschaften. Der Begriff Kognition ist dabei in der deutschen Sprache genauer als Gesamtheit aller Prozesse, die mit dem Wahrnehmen und Erkennen zusammenhängen 3 definiert. Wichtig ist hierbei insbesondere der zuletzt genannte Aspekt des Erkennens. Da das System in der Lage sein muss, eigenständig aus den optischen Eindrücken auch deren Inhalt effizient zu extrahieren, ist dieser ein entscheidender Faktor. Wie in Abbildung 4.2 angegeben, verlangt Kognition ein komplexes Zusammenspiel von verschiedenen Operationen innerhalb einer (künstlichen) Intelligenz. Vorraussetzung für eine zuverlässige Erkennung ist natürlich eine kontinuierliche Perzeption der Umgebung. Da es jedoch nun nicht mehr um die binäre Wahrnehmung der Existenz einer Gefahr geht, sind weitere Schritte erforderlich, um einen zielorientierten Suchprozess zu ermöglichen. Ganz so wie beim Menschen, der auf 2 vgl. [55], [25] 3 vgl. [11] 32

45 4.1. Wissenschaftliche Aspekte des Konzeptes künstliche Intelligenz(KI) Kognition Perzeption Evaluation Reflexion Erkennen der Bedeutung Optik Physik Abbildung 4.2.: Gebiete der Wissenschaft im Erkennen-Ziel Basis seiner Sichtung beispielsweise auch Referenzwissen nutzt, wenn er nach einem bestimmten Gegenstand sucht. Hierzu helfen einerseits die Erkenntnisse der reflexiven Eigenschaften. Zusätzlich zu den bereits durchlaufenen Orten wäre es sinnvoll, die gesammelten Daten aus dem Gedächtnis zu nutzen um das Erkennen zu erleichtern. Sind z. B. in einem bestimmten Eck viele Gefahren zu finden, schliesst man am besten gleich das ganze Teilstück aus der Umgebung aus. Für das Herauslesen der Bedeutung muss eine künstliche Intelligenz andererseits das Prinzip der Evaluation beherrschen. Es geht dabei um eine weiterführende Bewertung der Daten nach ihrer kontextsensitiven Bedeutung. Durch diese Fähigkeit entscheidet sich, was für ein Schild beispielsweise vorliegt und inwiefern es für den weiteren Ablauf somit eine Rolle spielt. Ein im Vorfeld durchgeführter Lernprozess ist dafür eine wichtige Grundlage. Es ist auffällig, dass dieses Ziel nahezu ausschließlich mit rein psychologischen Komponenten definiert werden kann. Jedoch wird deutlich, dass entsprechend intelligente Teillösungen im späteren Gesamtsystem eine Notwendigkeit darstellen Lokalisation der Bedrohung Ist die Bedeutung einer potentiellen Bedrohung bzw. Gefahrensituation bekannt, ist ein weiterführendes Ziel die Lokalisation derselbigen. Zu diesem Zweck war spezifiziert, anhand geeigneter Mittel den gegenwärtigen Standort des Roboters, der Gefahren und die jeweilige Distanz zu diesen zu berechnen bzw. abschätzen zu können (vgl. Abschnitt 3.2.4, S. 22). Ein derartiges Ziel berührt Aspekte einer Vielzahl von verschiedenen Wissenschaften (siehe Abbildung 4.3). So werden einerseits Erkenntnisse aus der Physik und der Mathematik benötigt, um ein adäquates, kartografisches Modell der Umgebung zu generieren. Dies gelingt andererseits jedoch nur auf Basis der zuvor gesammelten Daten aus den Komponenten der künstlichen Intelligenz. Lösungsmuster aus der Kartografie stellen für dieses Ziel eine fundierte und praktisch orientierte Vorlage. Das Erstellen einer Karte orientiert sich klar an menschlichem Verhalten. Möchte dieser sich dauerhaft in einem unbekannten Terrain orientieren, so wird er sich zwangsläufig genau dieser Wissenschaft bedienen. Hierfür nutzt er häufig seine gesammelten Beobachtungen 33

46 4. Konzeptanalyse künstliche Intelligenz(KI) Kognition Physik Reflexion Kartografie Metrik Optik Evaluation Perzeption Lokalisation der Bedrohung Mathematik Geometrie Abbildung 4.3.: Gebiete der Wissenschaft im Lokalisieren-Ziel als Referenz, welche anschliessend weiterverarbeitet und in einer einheitlichen Repräsentation verallgemeinert werden. Um diesen Prozess in einem künstlichen System nachzubilden, werden hierzu passende Teillösungen benötigt. Für die Berechnung von Distanzen und relativen Positionen sind eindeutig Erkenntnisse aus der Geometrie, der Optik sowie eine Einführung einer angemessenen physikalischen Metrik ausschlaggebend. Somit können Anforderungen wie ein robustes Abstandsmaß, die Lokalisation und die Schaffung einer repräsentativen Datenstruktur erfüllt werden. Da der Roboter über keine bewusste Wahrnehmung der Umgebung verfügt, sind somit zusätzlich die bisher eingeführten Komponenten der Kognition zur Realisierung dieses Ziels erforderlich. Sie modellieren einerseits die Datenquelle für die Lokalisation (bzw. sie zeigen die Topologie der Umgebung auf, welche Schilder und Gefahren vorliegen etc.) und versuchen andererseits Mehrfachmessungen und Messfehler im Vorfeld zu vermeiden. Es ist jedoch klar, dass sich die beiden Ziele im realen Falle gegenseitig bedingen. Schließlich muss eine Referenz auf mögliche Duplikate auch irgendwo hinterlegt werden. Aufgrund der Tatsache, dass dieses Ziel Kernelemente aus ihren beiden Vorgängern nutzt bzw. ihre Funktion sicherstellt, wird zunehmend klar, dass einheitliche Schnittstellen zwischen den verschiedenen Problemlösungen notwendig sind Navigation Die Navigation um alle potentiellen Gefahrensituationen ist für eine Realisierung der Idee hinter dieser Arbeit essentiell. Hierfür muss zuerst auf Basis des zuvor generierten Kartenmodells überprüft werden, inwiefern entsprechende Wege möglich sind. Sollte es dabei mindestens eine Möglichkeit geben, ist es nach Definition (vgl. Abschnitt 3.2.5, S. 22) erforderlich, diese weiter zu verfolgen und ihre Struktur repräsentativ aufzuzeigen. Das daraus resultierende Problemgebiet ist bei weitem nicht nur auf die Robotik beschränkt. Es stellt viel mehr ein weit verbreitetes Problem in der Wissenschaft dar und kommt daher in einer Vielzahl anderer Systeme vor, wie beispielsweise in GPS-basierten Navigationssystemen für Automobile. Trotz der vielen spezifischen Anwendungsszenarien haben derartige Konzepte jedoch grundsätzlich eine identische Vorgehensweise. Sie nutzen Erkenntnisse aus der Mathematik und der Physik um auf einem kartografischen Modell die Problemstellung zu lösen. Diese sind für die Analyse dieses Ziels daher von entscheidender Bedeutung. 34

47 4.1. Wissenschaftliche Aspekte des Konzeptes Um den Aspekt der Wegfindung abzubilden, werden hierfür aus der Mathematik Suchalgorithmen genutzt. Am häufigsten sind dazu Lösungsmuster aus der Graphentheorie vorzufinden. Sie arbeiten zumeist auf abstrakten Datenstrukturen und gewährleisten durch verschiedene geometrische Ansätze effiziente Routenplanung. Da an solche Algorithmen jedoch oftmals weitere Bedingungen gestellt werden, wie beispielsweise die Findung des kürzesten Weges, gibt es eine Vielzahl von Varianten und Abarten von ihnen. Aufgrund der individuellen Charakteristika eines jeden Vehikels (z. B. durch unterschiedliche Fahrzeugtypen) muss bei der Wegberechnung auch die Physik berücksichtigt werden. Dabei ist insbesondere die Kinematik bzw. deren Metrik des zu navigierenden Geräts wesentlich. Schließlich ist es nicht zielführend, wenn ein Weg nicht oder nur falsch beschritten werden kann, weil beispielsweise Faktoren wie der Wendekreis nicht berücksichtigt wurden. künstliche Intelligenz(KI) Konvergenz Kognition Kinematik Physik Metrik Reflexion Mathematik Geometrie Evaluation Navigation Perzeption Graphentheorie Kartografie Abbildung 4.4.: Gebiete der Wissenschaft im Navigieren-Ziel Wenn man diese Erkenntnisse auf den Kontext der Navigation eines Roboters überträgt, wird somit ein Zusammenhang von Mathematik, Physik, Kartografie und künstlicher Intelligenz erkennbar (vgl. Abbildung 4.4). Hierbei gilt, dass für die angeführten Lösungsmuster aus der Mathematik und Physik entsprechende Äquivalente gefunden werden müssen. So sind ein passender Suchalgorithmus und ein adäquates kinematisches Modell der Roboterplattform unabdingbar. Eine gute Kartografie ist auch in diesem Fall für die Navigation ausschlaggebend. Im Falle des Roboters entsteht diese wie bereits im vorausgehenden Abschnitt erwähnt aus kognitiven Prozessen und der Berechnung optischer und akustischer Daten. Demnach ist es also wirklich erforderlich, einheitliche Schnittstellen zwischen diesen Ebenen zu etablieren. Die eigenständige Navigation erweitert zudem die Anforderungen an die künstliche Intelligenz des Systems. Da dieses nun in der Lage ist Informationen zielorientiert, regelgeleitet und lösungsorientiert 4 zu sehen, erhält es konvergente Eigenschaften. Somit kann es selbstständig bei Gefahrensituationen geeignete Maßnahmen ergreifen. Jedoch sind hierzu Lösungsmuster und zusätzliche Schnittstellen notwendig, um die Ergebnisse effizient weiter verarbeiten zu können. Schließlich muss ja die Möglichkeit bestehen, einen Pfad auch durch Funktionen in der realen Welt zu beschreiten. Auch der Eintritt plötzlicher Hindernisse seitens der kognitiven Routinen wäre denkbar, was eine Neueinschätzung des Pfades bedeuten müsste. 4 vgl. [55] 35

48 4. Konzeptanalyse Interaktion Die Interaktion des Roboters mit der Umwelt vervollständigte als letzter Punkt die Zielspezifikation. Da er die eigentliche Schnittstelle zur Aussenwelt für eine menschlich-maschinelle Kooperation darstellt, wurde dieser entsprechend sorgfältig modelliert (vgl. Abschnitt 3.4, Seite 26 ff.). Dabei dienten Grundlagen und Konzepte humanoider Kommunikation als Orientierung. Physik künstliche Intelligenz(KI) Kinematik Metrik Akustik Elektrik Konvergenz Kognition Reflexion Interaktion Mathematik Wahrscheinlichkeitsmodelle Transformationen Evaluation Linguistik Perzeption Phonetik Abbildung 4.5.: Gebiete der Wissenschaft im Interagieren-Ziel Bei einer weiterführenden Betrachtung des vorgestellten Entwurfs fällt jedoch auf, dass er prinzipiell zwei verschiedene Aspekte des Gesamtsystems beinhaltet. So erfolgt neben der Festlegung der grundsätzlichen Bedienung durch einen Menschen des Weiteren eine Beschreibung, inwiefern die berechneten Ergebnisse physikalisch in der realen Welt präsentiert werden. Beide Aspekte stützen sich hierfür ebenfalls auf eine Vielzahl von Lösungen, welche unterschiedliche wissenschaftliche Fundamente besitzen. So soll nach der Spezifikation ein möglicher Pfad, welcher Gefahrensituationen bewusst vermeidet, selbstständig vom Roboter physikalisch beschritten werden. Um eine solche Funktion zu realisieren, sind nach Abbildung 4.5 Lösungsmuster und Erkenntnisse aus der künstlichen Intelligenz (bzw. Psychologie), Physik und der Mathematik notwendig. Die Beteiligung von Elementen der künstlichen Intelligenz wurde bereits bei der Analyse des Ziels der Navigation eingeführt (ab S. 34). Im Falle der Interaktion müssen die dadurch gewonnenen Erkenntnisse weiter verarbeitet und in Bewegungen in der realen Welt transformiert werden. Somit sind die Ergebnisse des konvergenten Teils die wesentliche Grundlage und die Notwendigkeit entsprechender Algorithmen zur Konversion ist aus dieser Erkenntnis ableitbar. Liegt ein Plan über die auszuführenden Bewegungen vor, kann dessen Umsetzung stattfinden. Dazu müssen die einzelnen Motoren und Gelenke des Roboters gezielt angesteuert und bewegt werden. Da der Nao-Roboter den aufrechten Gang des Menschen als Vorbild nutzt, sind aufgrund dessen Komplexität Erkenntnisse aus der Physik und Mathematik unabdingbar. So werden Methoden benötigt, welche anhand eines kinematischen Modells das Laufen an sich an der Hardware direkt realisieren. Weiterhin ist eine Metrik erforderlich, welche die Stabilität des Roboters beim Laufen analysiert. Daraus ergibt sich auch die Notwendigkeit hierzu passender Korrekturfunktionen im Fehlerfall. 36

49 4.2. Evaluation der Problemgebiete Die grundsätzliche Bedienung und sonstige Ausgabe ist weiterhin durch die Verwendung von Spracherkennung, Sprachsynthese, LEDs und haptischen Bedienelementen spezifiziert. Selbstverständlich sind diese ebenfalls stark von wissenschaftlichen Faktoren beeinflusst. Erstere (Sprachsynthese, Spracherkennung) sind für sich komplexe Disziplinen der Wissenschaft, welche in vielen modernen Systemen genutzt werden. Wenn man sich mit ihnen ein wenig befasst, so kann man erkennen dass diese auf Elementen der Physik, Linguistik und Mathematik aufgebaut sind. Parallel zu der Bildverarbeitung bei der Erkennung von Schildern ist jedoch dafür zunächst eine funktionierende, bewusste Wahrnehmung (vgl. Kognition in Abbildung 4.5) von Audiosignalen notwendig. Bei der Spracherkennung ist es anschliessend erforderlich, die dabei entstandenen Aufnahmen zu filtern, ehe sie weiterverarbeitet werden. Hierfür kommen mathematische Methoden zum Einsatz, welche die physikalischen bzw. akustischen Eigenschaften des menschlichen Hörapparates simulieren. Somit werden einzelne Buchstaben anhand von Referenzdatenbanken klassifiziert. Durch eine mathematisch fundierte Wahrscheinlichkeitsbewertung können dann anhand linguistischer Erkenntnisse ganze Wörter erkannt werden. Bei ähnlicher Prozess findet in umgekehrter Reihenfolge auch bei der Sprachsynthese statt. Da das System den Umgang mit Sprache beherrschen soll, müssen zu diesen Prozess Äquivalenzen gefunden werden. Sie sind, analog dazu, in Abbildung 4.5 vermerkt. Schlussendlich verbleibt noch die Nutzung der LEDs und der haptischen Bedienelemente. Diese sind einfache elektrische Komponenten, die auf physikalischen Grundprinzipien aufbauen. Eine Erläuterung ihres grundsätzlichen Aufbaus würde jedoch den Rahmen dieser Arbeit sprengen, weshalb darauf verzichtet wird. Grundsätzlich stellen sie jedoch weitere perzeptible Elemente da, die die Handlung der künstlichen Intelligenz entscheidend beeinflussen können. Da das System auf Wunsch beispielsweise jederzeit gestoppt werden soll, sind passende Methoden notwendig, um ein solches Verhalten zu realisieren. Da ansonsten keine weiteren Ziele vorliegen, wäre damit die Analyse des Basiskonzeptes aus gesamtwissenschaftlicher Sicht abgeschlossen Evaluation der Problemgebiete Im Kontext der Implementierung der Ziele an einem repräsentativen Robotersystem müssen nun die zuvor identifizierten Teilprobleme aus den Wissenschaften weiter strukturiert und zu einem Referenzmodell zusammengefügt werden. Es wäre sinnvoll, hierbei gleichzeitig eine Priorisierung der einzelnen Aspekte vorzunehmen, sodass deren Umsetzung später in iterativen Schritten erfolgen kann. Somit ist es notwendig, die in Abschnitt 4.1 gewonnenen Erkenntnisse weiter zu verarbeiten. Eine Evaluation, welche sie nach ihrer Komplexität und Signifikanz für das Projekt beurteilt, dient hierfür als Werkzeug. Dabei wird jede Wissenschaft individuell in einer Tabelle betrachtet, welche aus den identifizierten Teilproblemen und einer Wertung besteht. Als Maßstab für letztere gelten Erkenntnisse aus wissenschaftlichen Referenzen und den persönlichen Erfahrungen des Autors. Das Wertungssystem unterscheidet dabei vier Stufen, welche sich von komplex bzw. hoch signifikant (Symbol: +++), dem Mittelmaß (Symbol: ++), bis einfach bzw. niedrig signifikant (Symbol: +) erstrecken. Ihre Kombination lässt auf die Priorität der einzelnen Ziele im Zuge der Implementierung schliessen. Nicht einschätzbare Elemente erhalten ein?. 37

50 4. Konzeptanalyse Physik Wenn man aus der gesamtwissenschaftlichen Analyse der Zielspezifikation alle Aspekte, welche eine Beteiligung von Erkenntnissen aus der Physik erfordern, extrahiert, verbleiben die in Tabelle 4.1 aufgelisteten Ziele. Diese spezifizieren Anforderungen, welche für eine Funktion des Systems absolut erforderlich sind. Ohne sie wäre es nämlich unmöglich, die Daten der Aussenwelt zu verarbeiten bzw. sich in ihr zu bewegen. Ziel Komp. Sig. Prio Erhalten von optischen und akustischen Daten Algorithmus für Perzeption (Existenz d. Gefahr) Algorithmus für Erkennung (Bedeutung d. Gefahr) optisches Modell und Metrik zur Bildverarbeitung Kinematisches Modell und Metrik d. Bewegungsapparats Wahrnehmung/Wiedergabe digitaler Impulse Umsetzung/Überwachung des Laufens mit kinemat. Modell Tabelle 4.1.: Priorisierung der Ziele aus der Physik Das Erhalten von optischen und akustischen Daten stellt hierbei klar die am leichtesten zu realisierende Anforderung dar. Durch die hohe Verbreitung von digitalen Lösungen sowohl zur Bilderzeugung als auch im Rahmen der Sonartechnik sind mittlerweile eine Vielzahl von einfachen Lösungsmustern für dieses Problem verfügbar. Deswegen macht es Sinn, sich anfangs mit derartigen Ansätzen zu befassen und den geeignetsten davon auszuwählen. Ausserdem stellt dieser Aspekt die wesentliche Grundlage für alle anderen Teilkomponenten dar. Demzufolge ist es sinnvoll ihm eine sehr hohe Priorität zuzuweisen. Um die Existenz von Gefahren zu finden, sind nach Abschnitt (S. 31 ff.) perzeptible Prozesse künstlich zu imitieren. Dies erfordert seitens der Physik, dass sinnvolle Merkmale aus den digitalisierten Bilddaten gewonnen werden müssen. Hierfür wäre prinzipiell die Nutzung derartig einfach messbarer Eigenschaften, wie Größe und Farbe einzelner Objekte in ihnen, möglich. Erfahrungsgemäß ist jedoch diese Problemstellung auf sehr viele verschiedene Arten und Weisen lösbar, da es eine wachsende Anzahl von komplexen Bildverarbeitungsalgorithmen für unterschiedliche Anwendungszwecke gibt. Das spiegelt sich auch in der Menge an wissenschaftlichen Publikationen zu diesem Thema wieder. So sind allein [14], [10], [53], [38] Referenzen und entsprechend umfangreich. Ihr grundsätzlicher Inhalt wird in Abschnitt (ab S. 48) weiter betrachtet. Da die Entscheidung über die Existenz einer Gefahr somit nicht ohne weitere Evaluation solcher Ansätze einfach getroffen werden kann, aber wesentlich für den Erfolg des Projektes ist, erhält dieses Ziel die zweithöchste Priorität. Die Interpretation der Bedeutung einer Gefahrenquelle hat ebenfalls einen größeren Stellenwert. Diese Annahme entsteht aus dem Schluss, dass sie unmittelbar alle Erkenntnisse der anderen beiden hoch prioritären Anforderungen als Grundlage erfordert. Aus Perspektive der Physik müsste hierzu ein für diese Wissenschaft typischer erkenntnisgewinnender Prozess durch empirische Messung und Vergleich der gesammelten Daten erfolgen. Wie aber an den Publikationen [53] bzw. [38] sichtbar ist, existieren dazu schon eine Vielzahl an Vorgehensweisen zur Lösung derartiger Probleme. Sie bauen dazu im Wesentlichen auf den Algorithmen zur Erkennung von festgelegten Merkmalen in einem Bild auf, jedoch werden die dabei gewonnenen Daten zusätzlich in einem Erkennungsmodell weiter verarbeitet, um deren Klassifikation zu gewährleisten. Auch hier bestimmen Detailgrad und Zeitaufwand die Auswahl einer richtigen Methodik. So kann man, nicht nur zuletzt aus der persönlichen Erfahrung mit solcherlei Systemen, von einer noch 38

51 4.2. Evaluation der Problemgebiete höheren Komplexität dieser Anforderung ausgehen. Deshalb wäre eine Realisierung an dritter Stelle anzuraten. Weitere Anforderungen resultierten aus der Notwendigkeit physikalischer Modelle für die Notation und Berechnung von optischen und kinematischen Zusammenhängen. Ersteres ergibt sich als Nebenbedingung aller bereits dargestellten Punkte. Ohne Kenntnisse über die zugrundeliegende Optik ist eine langfristige Bewertung der gesammelten Daten nämlich nur schwer bzw. recht unzuverlässig realisierbar. Das ergibt sich aus Eigenschaften heutzutage genutzter Kameras, welche beispielsweise optische Fehler in Kauf nehmen um in der Herstellung günstig bleiben zu können. 5 So sind radiale bzw. tangentiale Verzerrungen die häufigsten Probleme. Für die Erkennung, Lokalisation und Navigation bedeuten sie Störeffekte, welche umfassend korrigiert werden sollten. Andernfalls gibt es Komplikationen, die z. B. eine stabile Distanzberechnung stark erschweren. Laut [12], S. 378 f. stellt hierbei ein physikalisch fundiertes Kameramodell die beste Option zur Beseitigung dieser Effekte dar. Da letztere nahezu von allen digitalen Kamerasystemen erzeugt werden, existieren dazu gute und effiziente Lösungen. Somit ergibt sich zwar eine relativ hohe Priorität (vgl. Ziel 4 in Tabelle 4.1) der jeweiligen Anforderung, ihre Umsetzung sollte jedoch ohne größere Schwierigkeiten zu bewältigen sein. Zweiteres betrifft vor allem die Umsetzung der Teilziele Navigation und Interaktion. Ein kinematisches Modell stellt für sie nach der Meinung verschiedener Veröffentlichungen eine wesentliche Grundlage dar. So ist beispielsweise nach Murphy eine Kenntnis der Eigenschaften des zu steuernden Roboters absolut notwendig. 6 Ausserdem enthalten viele Publikationen (wie zum Beispiel [15]) zumeist immer ein Kapitel bzw. eine Vorarbeit, welche(s) sich mit der Kinematik des jeweiligen Referenzsystems auseinandersetzt. Auch wenn man sich persönlich mit dem Bereich der Navigation befasst, sind systemspezifische Fragen (beispielsweise über die Holonomie 7 des Roboters) oftmals der erste Einstieg. Je nach Art der Fortbewegung (Kettenantrieb, Reifen oder Gehen) fällt die Komplexität des hierbei benötigten Modells unterschiedlich aus. So müssen alle Freiheitsgrade und die daran beteiligten Segmente der Maschine spezifiziert und anhand metrisch definierter Größen beschrieben werden. Da der Aldebaran Nao Grundprinzipien des aufrechten Gangs imitiert, ist ein solches differenziertes Modell zwar durch den Hersteller einfach zu erhalten, jedoch muss es entsprechend auch durch Algorithmen Beachtung finden. Bei der Realisierung sollte möglichst früh daran gedacht werden, da deren Komplexität schwer abzuschätzen ist. Im Zuge dessen kann mit einem solchen Modell auch die eigentliche Fortbewegung des Systems in der realen Welt umgesetzt werden. Bei einem kurzen Studium passender Materialien zu diesem Thema fällt jedoch auf, dass dieses Vorhaben ein nicht-triviales Problem in der heutigen Robotik darstellt. Insbesondere scheint es komplex zu werden, wenn es um das bipedale Laufen geht. So existieren einerseits viele Publikationen, welche sich mit grundlegenden Elementen des Laufens befassen (z.b. [18]). Andererseits sind auch spezielle Themen, wie die Planung der einzelnen Schritte und die Auswirkung von Umgebungsbedingungen auf das Laufmodell (vgl. [33], [39]), zahlreich vertreten. Allein aus dieser Diversität lässt sich schließen, dass eine Umsetzung entsprechender Methoden recht schwierig sein dürfte. Da sie im Sinne der Realisierung des interaktiven Aspekts der Idee jedoch von entscheidender Bedeutung ist, sollte gleich nach der Modellierung der Kinematik des Zielsystems nach angemessenen Lösungen gesucht werden. Schlussendlich ergibt sich die Wahrnehmung und Ausgabe von elektrischen Impulsen durch berührungssensitive Sensoren und LEDs als die niedrigst zu priorisierende Anforderung. Es handelt sich hierbei zwar um wichtige Elemente des (Bedien-)Konzepts, jedoch ist der Aufwand um sol- 5 vgl. [12], S. 375 ff. 6 vgl. [42], S Anm. Als Holonomie bezeichnet man die Fähigkeit eines Robotersystems, sich an Ort und Stelle selbst drehen zu können. vgl. dazu auch [42], S

52 4. Konzeptanalyse che Steuerungsmöglichkeiten zu implementieren als eher gering einzuschätzen. Derlei technische Elemente sind weit verbreitet und gut dokumentiert Mathematik Ein weiteres Ergebnis der Analyse (vgl. Abschnitt 4.1, Seite 31 ff.) ist eine kontinuierlich hohe Beteiligung mathematischer Schemata in allen Komponenten des Konzeptes. Tabelle 4.2 zeigt hierbei eine Übersicht aller dazu passenden Anforderungen. Ziel Komp. Sig. Prio Algebra für perzeptiblen Algorithmus Klassifikator für Kognition von Bedrohungen Geometrie und Metrik für Kartografie Metrik für Navigationsmodelle Suchalgorithmus für Navigation Wahrscheinlichkeitsmodell für Spracherkennung Tabelle 4.2.: Priorisierung der Ziele aus der Mathematik Es ist sofort auffällig, dass sie sich stark in Reihenfolge und Art ihrer Themengebiete an Tabelle 4.1 (Seite 38) orientiert. Dies ist kein Zufall, sondern durch den Fakt begründet, dass in der Tat nahezu alle Lösungsansätze der Physik unmittelbar mathematische Grundlagen benötigen, um überhaupt realisiert werden zu können. Die Perzeption von Gefahren kann man daher also nur durch mathematische Algorithmen auf Basis optischer bzw. akustischer Daten erreichen. Analog dazu finden sich in den in Abschnitt angegebenen Veröffentlichungen ([14], [10], [53], [38]) zahlreiche derartige Definitionen und Berechnungen. Da es, wie bereits erwähnt, eine Vielzahl von anwendungsabhängigen Vorgehensweisen in diesem Bereich der Bildverarbeitung gibt, dienen folglich auch verschiedenste Varianten mathematischer Funktionen bzw. Verfahren zur Gewinnung von Merkmalen. So werden in [14] beispielsweise Kanten anhand mehrfacher numerischer Optimierungsschritte gefunden. [53] hingegen approximiert die Existenz eines Objektes in einem Bild anhand gewichteter Summen bzw. Differenzen von Pixeln bestimmter Teilbereiche. Auch hier resultiert durch die hohe Diversität von möglichen Algorithmen ein schwer abzuschätzender Komplexitätsgrad für eine Implementierung eines entsprechenden Ansatzes. Deswegen sollte man den hierfür notwendigen Evaluationsprozess (vgl. Abschnitt 4.2.1) so früh wie möglich einleiten, um das beste Verfahren zu finden. Eine ähnliche Situation zeigt sich auch bei der Interpretation der so gewonnenen Merkmale. Die in Abschnitt angesprochenen Erkennungsmodelle für deren Klassifikation basieren nämlich auch auf mathematischen Grundsätzen. Entsprechend dazu finden sich in den referenzierten Publikationen ([10], [53], [38]) ebenfalls die notwendigen Definitionen. Besonders häufig treten natürlich in diesem Zusammenhang Klassifikatoren auf, welche ihre Aufgabe möglichst robust und innerhalb eines vertretbaren Zeitraumes bewältigen. Erwartungsgemäß existiert dazu eine Vielzahl an passenden Konzepten in der Mathematik. Die bekanntesten sind mit Sicherheit jedoch der k-nächste-nachbarn-klassifikator und Support Vector Machines, welche beispielsweise auch in [10] bzw. [38] zum Einsatz kommen. Analog zu den perzeptiblen Algorithmen hängen weiterhin derartige Verfahren ebenfalls bekanntermaßen stark von Anwendungsgebiet, Detailgrad und konkreter Laufzeit ab. Da sich somit eine ähnlich hohe Komplexität bei der Implementierung des geeignetsten Kandidaten davon abzeichnet, ergibt sich eine hohe Priorität an zweiter Stelle für die Lösung dieses Teilproblems. 40

53 4.2. Evaluation der Problemgebiete Fundamentale mathematische Erkenntnisse sind auch für die Ziele Lokalisation und Navigation ausschlaggebend. Die für ein Kameramodell notwendigen physikalischen Parameter für die Korrektur des Bildes sind genau genommen durch geometrische Verfahren zu gewinnen. 8 Eine ähnliche Basis erfordert auch die Metrik hinter der Abstands- und Distanzmessung (z.b. für die Kartografie) bzw. des kinematischen Modells (z.b. für die Navigation und Interaktion). Einige Ansätze dafür lassen sich beispielsweise in [35] und [15] finden. Sie basieren im Wesentlichen auf Erkenntnissen und Operationen in planarer bzw. räumlicher Geometrie. Jedoch sind die dabei zu erkennenden Zusammenhänge erfahrungsgemäß nicht unbedingt immer sofort überschaubar und der damit verbundene Aufwand zur Realisierung somit besser nicht zu unterschätzen. Trotzdem soll zunächst eine gemeinsame Priorität für diese Anforderungen ob ihrer gleichen Natur genügen. Weiterhin kann das Ziel der selbstständigen Navigation (vgl. Punkt 4 der Zielspezifikation, Abschnitt 3.2.5, S. 22) bei näherer Betrachtung vollständig durch mathematische Zusammenhänge erfüllt werden. Auf eine ähnliche Schlussfolgerung kommt Murphy, indem er ebenfalls auf die Nutzung entsprechender Verfahren zur Lösung dieses Problems verweist. 9 Hierbei können Suchalgorithmen aus der Graphentheorie den Aspekt der individuellen Wegfindung abstrakt modellieren und anschliessend imitieren. Bei einem Studium passender Referenzwerke ([23], [50]), kommen zu diesem Zweck mehrere Vorgehensweisen in Frage. Die bekanntesten Algorithmen sind dabei der Dijkstra- und der A*- Algorithmus. Allerdings findet man auch weitere Ausprägungen, wie den D*- und den FloodFill- Algorithmus. Alle berechnen, unabhängig von der jeweiligen Variante, zuverlässig einen Weg, falls dieser existiert. Unterschiede bestehen lediglich in der Güte der Ergebnisse. So kann beispielsweise Wert auf die Findung des kürzest möglichen Pfades gelegt werden. Erwiesenermaßen ist die Logik hinter derartigen Algorithmen u. U. komplex und deshalb nicht einfach umzusetzen. Deswegen muss von einer frühestmöglichen Priorität bei der Suche einer angemessenen Lösung ausgegangen werden. Das ist spätestens dann der Fall, wenn eine geeignete Kartografie sowie alle Aspekte der Wahrnehmung etabliert wurden. Aspekte der Mathematik werden zuletzt auch bei der Spracherkennung benötigt (vgl. Bedienungsphilosophie, Abschnitt 3.4.2, S. 28). Bereits in Abschnitt (S. 36 f.) war hierbei von der Notwendigkeit eines mathematisch fundierten Wahrscheinlichkeitsmodells die Rede. Konsultiert man entsprechende Fachliteratur, so werden hierfür einige dazu passende Konzepte aus der Stochastik vorgestellt. Nach [20] besteht ein solches Modell hierbei genauer aus einem Konzept aus sog. Hidden-Markov-Modellen. Sie berechnen auf Basis mehrdimensionaler Merkmalsvektoren die Wahrscheinlichkeit von aneinander folgenden Buchstaben- und Wortketten. Erfahrungsgemäß ist es schwierig, solch eine Anforderung selbst umzusetzen. Da diese jedoch für eine prototypische Implementierung optional ist, erhält sie eine niedrige Priorität. Aspekte der Mathematik spielen also für die Umsetzung des Projektes eine wesentliche Rolle. Es wird daher später notwendig sein, für diese gute Parallelen in der Informatik zu finden (vgl. dazu Abschnitt 5.1, ab Seite 47) Psychologie In der Konzeptanalyse (vgl. Abschnitt 4.1, Seite 31 ff.) wurde zunehmend auch die Notwendigkeit intelligenter Strukturen für die Umsetzung der Zielspezifikation deutlich. Als Referenz dienten Termini aus der Psychologie, welche ursprünglich humanoides Verhalten beschreiben. Nun stellt 8 vgl. [12], S. 379 ff. 9 vgl. [42], S

54 4. Konzeptanalyse sich im Rahmen der Evaluation jedoch die Frage, inwiefern und wann derartige Eigenschaften in ein rein künstlich-erschaffenes System überhaupt eingebracht werden können. Zunächst ist es offensichtlich, dass eine komplette Übereinstimmung von menschlicher und künstlicher Intelligenz bislang technisch vollkommen unmöglich ist. Es existiert bisher nur die Möglichkeit, einige Kernaspekte aus ersterer zu identifizieren und sie mit derzeitigen Mitteln zu imitieren. Das erschwert natürlich die Definition des Begriffs künstliche Intelligenz enorm, da dann nicht mehr von Intelligenz im eigentlichen Sinne gesprochen werden kann. Seine Bedeutung wird somit lediglich auf die Nutzung besserer bzw. kontextsensitiver Methoden reduziert. Ähnlich sieht das auch Murphy: A single, precise definition of AI is not necessary to study AI robotics. AI robotics is the application of AI techniques to robots. More specifically, AI robotics is the consideration of issues traditional covered by AI for application to robotics learning, planning, reasoning, problem solving, knowledge representation, and computer vision. 10 Ziel Komp. Sig. Prio historisch robuste Wahrnehmung von Gefahren? Etablierung kognitiven Verhaltens? Selbstbewusstsein bzgl. Lokation? Etablierung einer konvergenten Sicht? individuelle Problemlösung? Tabelle 4.3.: Priorisierung der Ziele aus der Psychologie Eine Berücksichtigung dieser Definition hat zur Folge, dass die in Tabelle 4.3 dargestellten Ziele in ihren jeweiligen Ausprägungen Äquivalenzen sowohl in allen bisherigen Anforderungen aus der Physik und Mathematik als auch der noch folgenden Kartografie bzw. Linguistik benötigen. So muss beispielsweise der Aspekt der Reflexion bei der Wahrnehmung von Gefahren (vgl. Abschnitt 4.1.1, S. 31) tatsächlich künstlich durch eine Art lernende Speicherstrukturen abgewickelt werden. Nur so wäre es möglich, historisch robuste Daten zu erhalten und wie spezifiziert Mehrfacherkennungen im Vorfeld zu vermeiden. Dies könnte entweder innerhalb der dazu designierten Methoden oder durch Auswertung einer zentralen Kartenstruktur geschehen. Reflexion ist dabei ein vielseitiger Begriff. So spielen nicht nur Mehrfacherkennungen eine Rolle, sondern auch vergangene Aktionen, wie Bewegungen und Störungen. Auch die kontinuierliche (Selbst-)Lokalisation im Bezugsraum zählt dazu. Nimmt man Murphy s Definition als Grundlage, müssen zur Speicherung dieses Wissens also passende Lösungsmuster aus der Informatik bzw. Robotik ausgewählt und evaluiert werden (ab Abschnitt 5.2.2, S. 67 ff.). Für die Etablierung kognitiven Verhaltens im humanoiden Sinne ist die intelligente Perzeption der erste Schritt (vgl. Abschnitt 4.1.2, ab S. 32). Sie muss laut Definition durch abstrakte Operationen auf Daten aus der Sensorik (visuell/akustisch) realisiert werden. Diese Anforderung wird jedoch allein schon durch die Betrachtungen in Abschnitt bzw erfüllt. Die Aufnahme eines Bildes und dessen anschließende Verarbeitung (z. B. die Extraktion von Merkmalen), welche in diesem Fall durch physikalische und mathematische Erkenntnisse schrittweise erzielt werden, gleichen dabei in ihrer Funktion dem menschlichen Sehen. Allerdings sollte es klar sein, dass hierbei nicht ein identischer Umfang realisierbar ist. Schließlich können bei der künstlichen Imitation nur endlich viele Merkmale aus den Daten herangezogen werden. Diesbezüglich effiziente Äquivalenzen sind also auch hier erforderlich und bereits im System abgebildet worden. 10 vgl. [42], S

55 4.2. Evaluation der Problemgebiete Weiterhin setzt eine derartige bewusste Wahrnehmung zugleich auch die Existenz von Kontextwissen voraus. Schließlich kann ein Mensch auch nur die Dinge wieder erkennen, wenn er eine Relation zwischen deren Bedeutung und Erscheinung erlernt bzw. erarbeitet hat. Somit ist es ihm möglich, seine Beobachtungen zu evaluieren. Nach Abschnitt (S. 40 ff.) sind für dieses Verhalten mathematisch fundierte Klassifikatoren eine Möglichkeit für die Nachahmung derlei Prozesse. Auch dieser Aspekt ist somit bereits modelliert. Ein Mensch ist darüber hinaus aber auch in der Lage, seinen Suchprozess beispielsweise anhand gesammelter Beobachtungen zu optimieren. Da somit erneut reflexive Aspekte eine Rolle spielen, müssen daher die Teillösungen zur Perzeption, Reflexion und Evaluation eine Art kognitives Netzwerk mit gegenseitigen Abhängigkeiten ergeben. Dieses formt dann letztendlich eine Art künstliches Selbstbewusstsein. Es ist kaum möglich den Aufwand, um entsprechende Modifikationen für eine solche Vernetzung an den vorhandenen Algorithmen durchzuführen, konkret zu benennen. Deswegen ist eine hohe Priorität dieser Ziele sinnvoll. Weiterhin führte die Analyse der Zielspezifikation zu der Erkenntnis, dass Elemente künstlicher Intelligenz Informationen aus konvergenter Perspektive betrachten und für einen individuellen Problemlösungsprozess zur Wegfindung einsetzen sollen. In Szenario R (vgl. Abschnitt 3.3.1, S. 23 ff.) stellte das für einen Menschen absolut kein Problem dar. Er nimmt Informationen von Natur aus zielgerichtet wahr und erdenkt sich meist spontan eine passende Lösung. Analog zu der Definition von Murphy sind derartige intelligente Prozesse ebenfalls durch angemessene Methoden bzw. Modifikationen zu imitieren. Das spiegelt sich im System bereits in der Nutzung von mathematisch fundierten Navigationsalgorithmen wider (vgl. Abschnitt 4.2.2, ab S. 40). Sie interpretieren Umgebungsdaten zielorientiert und garantieren ein zum natürlichen Denkprozess vergleichbares Ergebnis. Somit sind sie gut als Approximation an den menschlichen Problemlösungsprozess nutzbar. Die dabei verwendeten Informationen müssen im Gegensatz zum Menschen zuvor jedoch als abstrakte Datenstruktur vorliegen. Dies stellt eine zusätzliche Anforderung an das kognitive Netz (s.o.), das als Ergebnis konvergente Beobachtungen produzieren und entsprechende Schnittstellen zu diesen bereitstellen muss. Das Ziel der Erstellung einer virtuellen Karte (siehe dazu den folgenden Abschnitt 4.2.4) ist hierfür bereits eine passende Äquivalenz im System. Besagte effiziente und sinnvoll modellierte Vernetzungspunkte sind ihr jedoch noch hinzuzufügen. Für eine solche Modifikation an den spezifizierten Algorithmen sind auch hierfür Konzepte aus der Informatik/Robotik wichtig und demnach von hoher Priorität. Ihre Komplexität ist im Vorfeld jedoch genauso schwer abzuschätzen. Die Notwendigkeit intelligenter Strukturen im Gesamtsystem wird also hauptsächlich durch die Einführung vernetzter und kontextsensitiver Modifikationen an allen Komponenten des Systems befriedigt. Nach Murphy ist bisweilen nur auf diese Art und Weise ein künstlich intelligentes Robotersystem auf Basis heutiger Technologie zu realisieren Kartografie Auch Ziele, welche Erkenntnisse aus der Kartografie benötigen, sind laut Analyse an der Umsetzung beteiligt. In Tabelle 4.4 sind sie zusammenfassend für alle Ziele der Spezifikation aufgelistet. Vorrangig ist dabei die Findung eines guten Modells bzw. einer passenden Datenstruktur um die Topografie, sowie Hindernisse in der Umgebung effizient aufnehmen zu können. Hierbei sollte man darauf achten, dass diese effizient und möglichst simpel gehalten ist, um den Zugriff nicht weiter zu verzögern bzw. zu verkomplizieren. Gute Anhaltspunkte dazu finden sich in [42] (Seiten ) bzw. [21], welche gleichermaßen wichtige Konzepte für deren technische 43

56 4. Konzeptanalyse Ziel Komp. Sig. Prio Findung eines guten Modells für Topografie Schnittstelle bereitstellen Korrekturmethoden bereitstellen Generierung der Karte aus Beobachtungen Tabelle 4.4.: Priorisierung der Ziele aus der Kartografie Implementierung in einem Robotersystem vorschlagen. Sie haben je nach Anwendungsgebiet einen variablen Komplexitätsgrad. In Abschnitt (ab S. 67) wird auf die einzelnen Modelle näher eingegangen. Weiterhin sind Methoden notwendig, um Umgebungsinformationen in die Karte einzutragen bzw. diese im Fehlerfall aktualisieren zu können. Wünschenswert dazu wäre auch eine standardisierte Schnittstelle, damit sie als zentrale, vernetzte Datenstruktur im System nutzbar ist. Erfahrungsgemäß bieten sich hierfür verschiedene Ansätze an. Beispielsweise könnten einfache Prinzipien objektorientierter Programmiersprachen wie Interfaces aus Java herangezogen werden, um den Zugriff auf eine gemeinsame Klasse bzw. den Datenaustausch zwischen Teilen eines Programms zu spezifizieren. Eine andere Möglichkeit ist die Nutzung von Mitteln zur Interkommunikation auf Betriebssystemebene. So könnten zum Beispiel Message Queues ebenfalls eine solche Kopplung von mehreren getrennt voneinander ablaufenden Programmsegmenten ermöglichen. Als Alternative hierfür wäre denkbar, weiterhin auch asynchrone Events auf Basis eines einheitlichen Messaging-Bus (z. B. XML-Webservices) zu verwenden. All jene Konzepte würden im Zusammenspiel mit passenden Methoden gleichermaßen diese Anforderung beheben. Aus diesem Grund werden sie weiterhin in Abschnitt (ab Seite 61) weiter vorgestellt bzw. evaluiert, um eine angemessene Lösung für die prototypische Implementierung zu finden. Grundsätzlich kann man somit davon ausgehen, dass alle Ziele gut umzusetzen sind. Da sie aufeinander aufbauen, macht es Sinn, sie nach ihrer logisch-sinnvollen Reihenfolge zu priorisieren Linguistik Schlussendlich fehlen für eine komplette Evaluation der Konzeptanalyse alle Ziele, welche linguistischer Natur sind. Tabelle 4.5 zeigt diese auf. Ziel Komp. Sig. Prio Erkennung von Befehlen aus Aufnahme Bewertung d. Bedeutung auf Basis von Kognition Systemverhalten verändern Ausgabe der Ergebnisse/des Systemzustands Tabelle 4.5.: Priorisierung der Ziele aus der Linguistik Ihre jeweilige Priorität orientiert sich dabei nach Erkenntnissen aus [20] bzw. [44], welche bekannte Werke in der Sprachverarbeitung darstellen. So sind insbesondere die notwendigen linguistischen und mathematischen Grundlagen von relativ komplexer Natur und bei einer Implementierung der Prioritäten 1 bzw. 2 deswegen nicht zu unterschätzen. Es müssen dazu, unter anderem, Aspekte der Phonologie, Prosodie und Semantik genau beachtet werden. 11 Ausserdem sind auch erneut Modelle für die Nachbildung kognitiver Prozesse erforderlich. 12 Hier gelten 11 vgl. [44], S. 10, 11, 369 f. 12 vgl. [44], S. 103 f. 44

57 4.3. Konstruktion des theoretischen Modells grundsätzlich die gleichen Überlegungen wie bei der Bildverarbeitung (vgl. Abschnitt 4.2.3, S. 41). Erst wenn zuverlässige Ergebnisse aus den Zielen 1 bzw. 2 verfügbar sind, kann für eine entsprechende Korrespondenz zwischen dem Befehlswortschatz und dem Systemverhalten gesorgt werden. Hierfür braucht man spezielle Schnittstellen, welche möglichst einfach eine Beeinflussung der davon betroffenen Teilkomponenten erlauben. Die Umsetzung solcher Verbindungspunkte kann sich im Wesentlichen in Ausprägung und Komplexität an den in Abschnitt (S. 43) eingeführten Konzepten orientieren. Weiterhin kann die Ausgabe der Ergebnisse bzw. des Systemzustandes eine niedrige Priorität erhalten. Zwar werden für die Realisierung einer Sprachausgabe ebenfalls eine Vielzahl von Kenntnissen in der Linguistik benötigt, jedoch sind derartige Systeme mittlerweile stark verbreitet. Grundsätzlich ist also davon ausgehen, dass eine Umsetzung einfach sein wird Konstruktion des theoretischen Modells Aus den gesammelten Erkenntnissen dieses Kapitels ist es nun möglich, alle notwendigen Teilprobleme und -elemente für eine Implementierung des Konzeptes letztendlich zu identifizieren und sie zu einem Gesamtsystem zu verbinden. Abbildung 4.6 zeigt das theoretische Modell, welches zu diesem Zweck konstruiert wurde. Allen Komponenten der Zielspezifikation (orange) werden hierbei aus den jeweiligen Gebieten der Wissenschaft (lila) jene Anforderungen (grün) zugeordnet, die für ihre individuelle Erfüllung notwendig sind. Zusätzlich sind etwaige Abhängigkeiten zwischen den einzelnen Teillösungen durch Pfeile gekennzeichnet. Gesamtkonzept Ziele Physik Wissenschaften Mathematik Psychologie Kartografie Linguistik 1. Suchen und Extrahieren von Bedrohungen Erhalten von Daten aus Sensorik Analyse dig. Daten nach Gefahren Refmodelle/Metriken (Optik/Akustik) hier: ausführende Wissenschaft Algebra für Merkmalsberechnung Geometrie für korrektur von Fehlern KI Modifikationen Perzeption Reflexion Zugriffsmethoden Historie Bewegungen Umgebungsdaten 2. Erkennen d. Bedeutung Interpretation der Daten aus Sensorik Klassifikation von Merkmalen KI Modifikationen Evaluation Kognition Zugriffs- und Änderungsmethoden Topologie d. Umgebung 3. Lokalisation Analyse der Daten aus Sensorik Ref.modelle/Metriken (Optik/Akustik/ Umgebung/Kinematik) Geometrie für Positionsabschätzung KI Modifikationen Reflexion Zentrale Kartenstruktur etablieren Schnittstelle bereitstellen 4. Navigation Gesezesmäßigkeiten/ Referenzmodelle/ Metriken Suchalgorithmen Graphentheorie Maße und Ordnungen im Koordinatenraum KI Modifikationen Konvergenz Problemlösen Schnittstelle ist Datenquelle 5. Interaktion Umsetzung des Laufens Überwachung des Laufens Kinematik Sensorik Algebra für Berechnung der Bewegungen Wahrscheinlichkeitsbewertungen KI Modifikationen Perzeption Reflexion Evaluation Lageplan Schnittstelle: Laufen Ausgabe SysZustand/ Ergebnisse Spracherkennung Steuerung Abbildung 4.6.: Theoretisches Modell des Gesamtkonzeptes 45

58 4. Konzeptanalyse Die Anordnung der Anforderungen orientiert sich jeweils an den Prioritäten, welche in Abschnitt 4.2 (S. 37 ff.) festgestellt und ausführlich erläutert wurden. Es wird dabei von einer absteigenden Reihenfolge ausgegangen. Somit stehen die höchst prioritären Ziele jeweils immer zuerst im Modell. Ein erstes Studium dieses Modells erlaubt es weiterhin, einige interessante Eigenschaften des Gesamtkonzeptes zu erkennen: Es scheint, dass dessen Komponenten zunächst individuell lösbar wären. Das gilt jedoch nur in ihren Ansätzen, da schon sehr früh starke Abhängigkeiten eintreten. Beispielsweise wird schon beim Suchen von möglichen Gefahrenquellen Referenzwissen aus der Umgebung (und damit z. B. bereits eine Karte) benötigt. Derartige Beziehungen müssen durch eine Art funktionsübergreifende Kommunikation der einzelnen Ziele realisiert werden. Hier kommen Aspekte der künstlichen Intelligenz des Konzeptes ins Spiel. Da nach Murphy eine solche lediglich als eine geschickte Verkettung und Modifikation von vorhandenen Algorithmen erreicht werden kann (vgl. Abschnitt 4.2.3, ab S. 41), spiegelt sich diese Anforderung entsprechend im Modell wider. Sie resultiert in den zahlreichen Verknüpfungen, welche die einzelnen Komponenten miteinander verbinden. Trotz dessen zeichnet sich jedoch weiterhin eine gewisse Modularisierbarkeit des Gesamtkonzeptes ab. Es existiert nämlich auch eine Menge an Verknüpfungen, die jeweils nur Teillösungen innerhalb einer Ebene betreffen. Ein Beispiel hierzu kann man in 4. Navigation (Abbildung 4.6) sehen. So wäre denkbar, zunächst physikalische Modelle und eine Kartenstruktur statisch festzulegen, um verschiedene Navigationsalgorithmen getrennt vom Rest des Systems zu evaluieren. Ausserdem ist klar erkennbar, dass es Sinn macht, das Suchen und Extrahieren (vgl. Ziel 1 in Abbildung 4.6) von Gefahrenquellen als das zuerst zu realisierende Modul festzulegen. Es behandelt und implementiert die Extraktion von Sensordaten aus der Umgebung und stellt somit die wesentliche Informationsquelle dar. Erwartungsgemäß haben alle Aspekte der Interaktion Auswirkungen auf alle anderen Komponenten des Systems. Da als vorrangiges Element dazu die Nutzung von Sprache spezifiziert ist, wurde auf eine Duplikation der hierfür wichtigen Anforderungen in allen Funktionsebenen verzichtet. Wenn man dieses Modell schlussendlich mit der Zielspezifikation (vgl. Abschnitt 3.2, S. 20 ff.) vergleicht, so ist nun definitiv eine bessere Umsetzbarkeit des Basiskonzepts bzw. dessen Komponenten gegeben. Dies ergibt sich durch die Tatsache, dass mit der Nutzung des divideand-conquer Prinzips viele zuvor unklare, jedoch elementare Aspekte bzw. Teilprobleme aus ihm gefunden und spezifiziert werden konnten. Das theoretische Modell ist das Hauptergebnis dieser Analyse, welches somit als Gesamtkonzept eine leitende und helfende Struktur repräsentiert. Deshalb dient es als weitere Referenz für die prototypische Implementierung der Idee dieser Arbeit am Aldebaran Nao. 46

59 5. Lösungen des theoretischen Modells Auf Basis der Zielspezifikation (vgl. Abschnitt 3.2, S. 20 ff.) und des in Kapitel 4 konstruierten theoretischen Modells kann im Folgenden die prototypische Implementierung des Konzepts vorangetrieben werden. Zu diesem Zweck müssen die zuvor gefundenen Anforderungen letztendlich durch passende Lösungsmuster und -ansätze aus der Informatik und Robotik abgedeckt sein. Insbesondere trifft das auf die höchst prioritären Aspekte des theoretischen Modells zu, da sie die wesentlichen Kernfunktionen des Gesamtkonzeptes darstellen bzw. modellieren. Dieser Transferprozess ist der wesentliche Fokus dieses Kapitels. Folglich werden dazu in Abschnitt 5.1 zunächst für alle Bedingungen der Teilziele entsprechende Reflexionen aus dem Sektor der Informatik gesucht und zugleich evaluiert. Weiterhin befasst sich Abschnitt 5.2 (ab S. 63) darüber hinaus mit angemessenen Lösungen aus der Robotik. Sie behandeln zunächst weiterführend Steuerungskonzepte und geeignete Datenstrukturen für die Lokalisation und Navigation. Um Eigenheiten und systemspezifische Bedürfnisse der Robotik zu berücksichtigen, vervollständigt eine Vorstellung typischer Referenzarchitekturen die Betrachtung. Als Anhaltspunkte hierfür dienen wichtige Erkenntnisse aus diesem Fachgebiet. Durch den Transfer wird es möglich, anhand der bisher gesammelten Ergebnisse bereits im Vorfeld einige Probleme abschätzen zu können. Deren Betrachtung würde die Thematik dieses Kapitels abrunden. Die in Abschnitt 5.3 (vgl. Seite 74 ff.) durchgeführte Grenzbetrachtung setzt sich daher intensiv mit der technischen Machbarkeit der Aufgabenstellung am Aldebaran Nao-Roboter auseinander. Unter Berücksichtigung der Hardwarespezifikation aus Abschnitt 2.2 (ab S. 11) wird dabei untersucht, inwiefern Einschränkungen und Schwierigkeiten bei der Implementierung des Projektes auftreten könnten und Kompromisslösungen notwendig sind Lösungen aus der Informatik Betrachtet man die Anforderungen sowohl der Zielspezifikation als auch des theoretischen Modells (vgl. S. 20 ff. / 45 ff.) hinsichtlich einer Implementierung an einem Computersystem, so müssen für viele Aspekte des Gesamtkonzeptes vernünftige Lösungen gefunden werden. Aus der Perspektive der Informatik sind dabei diejenigen Lösungsmuster relevant, welche folgende Teilbereiche mithilfe universeller wissenschaftlicher Erkenntnisse erfassen und bearbeiten: Teilgebiet Optik Akustik Kinematik Psychologie (bzw. ki) Funktion im Roboter Perzeption, Evaluation = Kognition Perzeption, Evaluation, Kognition + Interaktion Interaktion Interkommunikation, Problemlösen Tabelle 5.1.: Teilbereiche mit Lösungen aus der Informatik 47

60 5. Lösungen des theoretischen Modells Im Folgenden werden die dafür relevanten Fragmente aus diesem Teilgebiet der Forschung gesucht, sowie kurz vorgestellt und evaluiert. Um zu verdeutlichen, an welcher Stelle diese in das Gesamtkonzept greifen, wird dabei auf das theoretische Modell zurückgegriffen Optik und Informatik Optische Eindrücke stellen bei der Wahrnehmung von potentiellen Gefahrensituationen naturgemäß zumeist die wichtigste Datenquelle, vor allem wenn man sich an humanoidem Verhalten orientiert (siehe Szenario R, S. 23). Wie Abbildung 5.1 zeigt, ist analog dazu die Notwendigkeit optischer Prozesse im Gesamtsystem entsprechend hoch. Abbildung 5.1.: Notwendigkeit von optisch-orientierten Lösungen aus der Informatik So ist unter anderem spezifiziert, dass Gefahrenzeichen im Bezugsraum gefunden, interpretiert und ihre Position festgestellt werden müssen. Den Betrachtungen in Abschnitt (S. 32 f.) folgend, werden also Äquivalenzen für perzeptible, evaluative und somit kognitive Prozesse aus der Informatik gesucht. Sie berührt wie die Robotik eine Vielzahl von verschiedenen Disziplinen. Als Hinweis für einen erfolgreichen Transfer dienen uns daher die spezifizierten Anforderungen an Physik (Abschnitt 4.2.1, S. 38 ff.) und Mathematik (Abschnitt 4.2.2, S. 40). Sensorik Tabelle 4.1 (S. 38) legte das Erhalten von optischen und akustischen Daten als oberste Priorität fest. Aus der Sichtweise der Informatik würde das bedeuten, u. a. eine digitale Repräsentation der Umgebung auf Basis optischer Daten zu schaffen. Abbildung 5.2 zeigt dafür das wesentlichste technische Element, einen sog. CCD-Chip. Dieser erlaubt es ähnlich wie das menschliche Auge das einfallende Licht in (digitale) Informationen zu verwandeln. Da es derartige Sensoren schon seit ca gibt, verwundert es Abbildung 5.2.: CCD-Chip 1 kaum, dass in der Informatik schon seit langem die Möglichkeit besteht auf die Daten dieser Elemente zuzugreifen und aus ihnen digitale Bilder zu gewinnen. Somit wäre der grundsätzlichste Aspekt der Perzeption, das Sehen an sich, bereits in die Informatik abgebildet. 1 Abbildung aus [58] 48

61 5.1. Lösungen aus der Informatik Merkmalsextraktion Auf Basis der gesammelten Daten soll im Rahmen eines solchen Prozesses anschließend die Existenz von potentiellen Gefahrenquellen eruiert werden. Eine Anforderung war hier die Extraktion von Merkmalen aus einem Bild (vgl. Abschnitt 4.2.1, S. 38 ff.). Wie bereits die Referenz auf die Werke [14], [10], [53], [38] erahnen lässt, sind in der Informatik seit der Erfindung des CCD-Sensors eine große Menge an dazu passenden Lösungsmustern entstanden. Auf die wichtigsten hiervon wird an dieser Stelle kurz eingegangen. Natürlich gelten die zuvor gespeicherten Bilder als Grundlage. Das diesbezüglich wohl bekannteste Schema ist der Canny- Algorithmus, welcher 1986 von John Canny veröffentlicht wurde ([14]) und heutzutage sehr weit verbreitet ist. Er leistet die Extraktion von Kanten aus einem beliebigen Graustufenbild. Im Wesentlichen basiert er auf einer Menge von speziellen, mathematisch fundierten, Faltungs- und Filteroperationen, welche direkt auf den Binärdaten der Bilder operieren. Abbildung 5.3 zeigt beispielhaft das Ergebnis einer solchen Extraktion. In diesem Fall sind z. B. eindeutig die Konturen von verschiedenen mechanischen Teilen bzw. eines Computerchips zu erkennen. Abbildung 5.3.: Extrahierte Kanten 2 Es wäre vorstellbar diesen Algorithmus für die Erkennung von potentiellen Gefahrenquellen einzusetzen. Dafür müssten jedoch zuvor die hierfür signifikanten Konturen im Bild eindeutig gefunden werden. Ein weiterer Ansatz aus der Informatik ist die Nutzung des SIFT- Algorithmus, der erstmals 1999 von David Lowe in seiner Publikation ([37]) vorgestellt wurde. Die Grundidee besteht darin, Merkmalsvektoren aus Strukturen in einem Graubild zu errechnen, welche auf speziellen und markanten Schlüsselpunkten aufbauen. Zur Findung dieser Punkte dienen lokale Maxima und Minima, welche sich durch die gauß sche Glättung des Bildes ergeben. In Abbildung 5.4 ist das Ergebnis bei einer Anwendung verdeutlicht. Es existieren von diesem Algorithmus weitere, weniger rechenintensive Varianten (z. B. SURF, [10]). Abbildung 5.4.: SURF - Deskriptoren 3 Die Merkmale möglicher Gefahrenquellen würden zwar genauso möglicherweise erfasst, jedoch fehlt auch hier zunächst eine eindeutige Zuordnung. Als letztes Beispiel ist der seit 2001 bekannte Viola-Jones- Algorithmus zu nennen ([53]). Dieser errechnet zur Merkmalsextraktion absolute Differenzen und Summen mehrerer Pixelwerte des Bildes. Die hierfür verwendeten Schablonen sind in Abbildung 5.5 exemplarisch dargestellt. Die Summe aller Pixel der jeweilig hellen Bereiche wird dabei von der Summe aller grauen Pixel einer Form abgezogen. Somit lassen sich anhand ähnlicher Felder in verschiedenen Bildern Zusammenhänge über die Existenz eines bestimmten Objektes machen. Abbildung 5.5.: Viola-Jones- Merkmale 4 Auch mit diesem Ansatz wäre die gewünschte Funktion realisierbar. Allerdings ist abzusehen, dass es nicht einfach sein könnte, passende Referenzfelder für jede Gefahr zu generieren, da die 2 Abbildung aus [14] 3 Abbildung aus [10] 4 Abbildung aus [53] 49

62 5. Lösungen des theoretischen Modells Viola-Jones-Merkmale bei einer hohen Auflösung des Bildes sehr klein sind (und deswegen viel Aufwand wegen der daraus resultierenden Menge investiert werden muss). Weitere, jedoch speziellere Algorithmen für die Extraktion von Merkmalen finden sich in [38] und [28]. Darüber hinaus steht es bei der Verwendung jedes Ansatzes frei, weitere Funktionen zur Vorfilterung der Bilddaten voran zu schalten. Beispielsweise ist es üblich, bei der Benutzung des Canny-Algorithmus nicht benötigte Farbbereiche auszuschließen, wenn man Kanten von Objekten bestimmter Farbe finden will. Anhand dieser Beobachtungen kann man folgern, dass alle derartigen perzeptiblen Anforderungen durch Methoden der Informatik abgedeckt werden können. Klassifikation Für die Imitation humanoiden Verhaltens bei der Suche nach Gefahren ist es nach den Erkenntnissen aus Kapitel 4 erforderlich, die extrahierten Merkmale aus den Bildern weiterführend zu evaluieren. Nur so könnten schließlich kognitive Prozesse künstlich abgebildet werden. In Abschnitt (ab S. 40) ist hierzu die Nutzung von mathematisch fundierten Klassifikatoren zur Bewertung von Messdaten spezifiziert worden. Diese ordnen einer Probe (bestehend aus einer endlichen Anzahl an Merkmalen, welche zuvor gewonnen wurden) eine bestimmte Klasse zu und gewährleisten so die gewünschte Funktion. Als Anhaltspunkt dienen dabei die Veröffentlichungen [10] bzw. [38], welche bereits zwei wichtige Algorithmen hierfür erwähnen. Ob ihrer mathematischen Natur sind sie entsprechend gut mit den Möglichkeiten der Informatik technisch umsetzbar. Aus diesem Grund soll auf grundsätzliche Konzepte der vielversprechendsten Kandidaten hierzu kurz eingegangen werden. Ein beliebter und weit verbreiteter Ansatz ist der knn- Klassifikator, der beispielsweise in [10] verwendet wird. Bei diesem findet die Zuordnung einer Probe durch die Betrachtung der k nächsten Nachbarn aus einer zuvor trainierten Lernmenge statt. Hierbei sind Minima geometrischer Abstandsfunktionen (z. B. der euklidische Abstand) der entscheidende Faktor. Eine Klasse gilt hierbei nämlich als gefunden, wenn eine Mehrheit der individuell zu testenden Merkmale einer Probe die geringste Distanz zu dessen Zentrum aufweist. Abbildung 5.6 zeigt eine Visualisierung exemplarischer Klassengrenzen bzw. ihrer Zentren als Voronoi-Diagramm auf. Abbildung 5.6.: knn - Klassifikation 5 Es wäre durchaus möglich, einen solchen Klassifikator zur weiteren Analyse von Merkmalen bei der Implementierung des Projektes zu nutzen. Jedoch muss man beachten, dass dieser im Vergleich zu anderen Algorithmen auch einige Eigenheiten aufweist. So sind erfahrungsgemäß beispielsweise erst gute Werte für k zu finden, welche nach Anwendungsfall variieren können. Weiterhin ist u. U. der Speicherverbrauch nicht optimal, da für eine Klassifikation immer alle Referenzmerkmale im Speicher gehalten werden müssen. 5 Abbildung aus [36] 50

63 5.1. Lösungen aus der Informatik In diesem Zusammenhang wird mehrfach auch die Nutzung von sog. Support Vector Machines nahegelegt (zum Beispiel in [38]). Diese basieren im Wesentlichen auf der Idee, verschiedene Klassen durch Trennebenen im Vektorraum anstelle durch geometrische Abstandsmaße (s.o.), zu definieren. Dadurch ergeben sich eine Reihe von Vorteilen: So müssen beispielsweise je nur die extremen Vektoren einer Klasse beim Lernen berücksichtigt werden. Weiterhin ist es möglich, durch die Einführung weiterer Dimensionen krumme Klassengrenzen zu erhalten. In Abbildung 5.7 ist eine Visualisierung dieses Ansatzes zu finden. Die Klassifikation findet letztendlich einfach durch die Betrachtung der Lage des Merkmalsvektors einer Probe bzgl. den Trennebenen statt. Abbildung 5.7.: Klassifikation durch SVM 6 Eine Support Vector Machine würde sich somit auch für die Interpretation potentieller Gefahrenquellen aus geeigneten Merkmalen der Bilddaten eignen. Allerdings kann eine Implementierung dieses Algorithmus im Vergleich zum knn-klassifikator wesentlich komplexer ausfallen, insbesondere wenn höhere Dimensionen angenommen werden. Es besteht auch die Option, Aspekte der genetischen Programmierung aus der Informatik zu nutzen, um die Klassifikation von Merkmalen zu ermöglichen. Dabei wird in Anlehnung an die natürliche Evolution zunächst von initialen (und somit nicht gut trainierten) Klassifikatoren ausgegangen, welche sich sukzessive im Lauf der Zeit verbessern. Das geschieht durch eine Selektion der besten Algorithmen einer Generation, welche anschließend gegenseitig mutiert und weitergegeben werden. Abbildung 5.8 zeigt diesen Prozess schematisch auf. Die eigentliche Klassifikation findet dann später anhand der besten Methoden statt. Sie arbeiten hierfür zumeist mit Pixelsummen bestimmter Bereiche in einem Bild, in etwa analog zu Viola-Jones-Merkmalen. Abbildung 5.8.: Ablauf genetischer Programmierung 7 Kaskaden (Varianten/Detailgrad) Weiterprüfung absoluter Vergleich F Probe Muster 1 F Muster 2 F T T T Muster 3 Klassifiziert Abbildung 5.9.: Vorgehensweise bei Kaskadierung/Brute-Force Klassifikation Abschliessend wäre noch die simpelste Vorgehensweise in diesem Bereich zu nennen. Sie besteht aus dem Template- bzw. Brute-Force-Matching einer Probe. Hierbei werden alle Merkmale einer Probe strikt gegen alle Referenzmuster bestimmter Objekte verglichen, um somit die Zugehörigkeit zu einer bestimmten Klasse zu ermitteln. In den meisten Fällen wird dabei mehrfach in einer Art Suchkaskade geprüft. Diese enthalten zumeist komplexere Varianten der Referenzmuster 6 Abbildung aus [43] 7 Abbildung aus [17] 51

64 5. Lösungen des theoretischen Modells oder forcieren aggressivere Erkennungsraten. Abbildung 5.9 verdeutlicht diesen Prozess. Auf eine ähnliche Art funktioniert beispielsweise auch die Klassifikation von Viola-Jones-Merkmalen. 8 Dieses Verfahren ließe sich recht simpel mit Werkzeugen der Informatik umsetzen. Allerdings nur unter der Vorraussetzung, dass alle signifikanten Merkmale von Gefahren im Voraus bekannt sind. Eine Einschränkung ergibt sich jedoch aus der Tatsache, dass dies sehr rechenintensiv sein wird. Neben den hier vorgestellten Algorithmen zur Klassifikation existieren zahlreiche weitere, deren Vorstellung den Rahmen dieser Arbeit sprengen würde. Es ist schnell erkennbar, dass somit eine Realisierung des kognitiven Aspekts des Konzeptes mit Mitteln der Informatik gelingt, wenn man sich an gegebenen mathematischen Grundlagen orientiert. Lokalisation Weiterhin muss nach Abbildung 5.1 (S. 48) letztendlich auch die Position potentieller Gefahrenquellen aus den optischen Daten der Umgebung gewonnen werden. Nur damit wäre laut der Analyse aus Abschnitt (S. 33 ff.) eine Kognition, die mit der eines Menschen ansatzweise vergleichbar ist, umsetzbar. In den Abschnitten (S. 38) bzw (S. 40) wurde hierfür jeweils die Notwendigkeit von passenden Metriken und geometrisch-optischen Modellen festgestellt. Somit sind entsprechende Schemata aus der computergestützten Bildverarbeitung zu finden. Als Indiz dafür gelten die Konzepte, die in [12] gegeben werden. Die wichtigsten Aspekte hieraus werden im Folgenden kurz erläutert. Abbildung 5.10.: Pinhole-Kameramodell 9 Eine wesentliche Grundlage hierfür ist demnach die Berücksichtigung des sogenannten Pinhole- Kameramodells (vgl. Abbildung 5.10). Dieses beschreibt den optischen Aufbau der meisten derzeitig verfügbaren Webcams und digitalen Kleinstkameras. Da jene tatsächlich nur einen festen Fokus besitzen und somit eine gleichbleibende Brennweite (f in Abbildung 5.10) bei der Aufnahme von Bildern verwenden, lassen sich die Eigenschaften dieses Modells für Vorhersagen über die ungefähre Position eines Objektes im Bezugsraum und zur Korrektur von optischen Fehlern nutzen. So wäre durchaus denkbar, dass eine heuristische Projektion des Punktes q aus der Bildebene in die reale Welt (Punkt Q in Abbildung 5.10) durchführbar ist. Legt man die Aussagen aus 8 vgl. [53], S. 5 9 Abbildung aus [12], S

65 5.1. Lösungen aus der Informatik [12] zugrunde, so sollte somit auch eine Abschätzung der Distanz (Linie durch 0, q, Q) möglich sein. Durch das Modell sind weiterhin radiale und tangentiale Störungen, an denen ein Großteil derartiger Kameras leidet, leicht zu beheben. 10 Natürlich setzt das eine Kenntnis aller notwendigen Parameter sowie den spezifischen Eigenschaften der verwendeten Kamera (verwendete Linse, Position des CCD-Sensors relativ zu dieser) voraus. Es wird sich herausstellen, ob sie in Erfahrung gebracht werden können. Abbildung 5.11.: Stereoskopisches Kameramodell 11 Dieses Prinzip lässt sich weiterhin nach [12], S. 415 f. auch bei der Nutzung zweier Kameras anwenden. Allerdings nur in erweiterter Form. Abbildung 5.11 zeigt das dabei entstehende Szenario. Die Position (und somit auch der Abstand) eines Objektes könnte hierbei durch eine Triangulation auf Basis der sog. Disparität zwischen den beiden Perspektiven bestimmt werden. Hierfür wäre neben den oben bereits genannten Parametern zusätzlich die Kenntnis zweier korrespondierender Punkte eines Objektes (p l undp r in der Abbildung) notwendig. Zur Veranschaulichung kann daraus ein Disparitätsbild errechnet werden, welches in Abbildung 5.12 exemplarisch dargestellt wird. Nahe Objekte erscheinen hierbei in diesem heller, da sie bei der Berechnung der Unterschiede einen größeren Versatz aufweisen als entfernte Objekte. Abbildung 5.12.: Disparitätsbild als Ergebnis 12 Aus diesen kurzen Betrachtungen kann man schließen, dass es möglich sein sollte, Distanzen zu Objekten unter Verwendung von Konzepten aus der computergestützten Bildverarbeitung zu ermitteln. Allerdings gelingt das nur mit der Kenntnis entsprechender Parameter und der passenden Hardware. 13 Somit wären alle Anforderungen, welche mit der Verarbeitung von optischen Eindrücken zusammenhängen, durch geeignete Lösungskonzepte der Informatik erfolgreich abgedeckt. 10 vgl. [12], S Abbildung aus [12], S Abbildung aus [54] 13 Anm. Für die Nutzung von Stereoskopie ist es natürlich zwingend notwendig, dass sich die Blickfelder der Kameras überschneiden. 53

66 5. Lösungen des theoretischen Modells Akustik und Informatik Bei der Konzeptanalyse in Kapitel 4 ist deutlich geworden, dass neben optischen auch akustische Eindrücke eine wesentliche Datenquelle des Gesamtsystems darstellen. Im Vergleich zu Ersteren müssen diese jedoch neben der Wahrnehmung der Umgebung zusätzlich auch interaktive Aspekte umfassen. Abbildungen 5.13a und 5.13b zeigen jeweils jene Komponenten des theoretischen Modells, welche dafür entsprechende Lösungen benötigen, schematisch auf. (a) Akustische Aspekte bei Ortung (b) Akustische Aspekte bei Interaktion Abbildung 5.13.: Notwendigkeiten von akustisch-orientierten Lösungen aus der Informatik In der Zielspezifikation (vgl. Abschnitt 3.2, S. 20 ff.) war dazu zunächst genauer von einer Ortung möglicher Hindernisse bzw. potentiellen Gefahrensituationen zur Laufzeit der Suche die Rede. Zusätzlich sollte der Roboter weiterhin mithilfe von Sprachbefehlen möglichst intuitiv gesteuert werden können bzw. durch Sprachsynthese selbstständig Aussagen über den Systemzustand treffen (vgl. Abschnitt 3.4, S. 26 ff.). Laut den Betrachtungen in Abschnitt 4.1 ff. sind somit bei einem Transfer dieser Anforderungen Äquivalenzen zu den damit verbundenen kognitiven (Perzeption, Reflexion, Evaluation) und interaktiven Prozessen aus der computergestützten Tonverarbeitung zu finden. Als Indikator für mögliche Lösungsmuster können jene Referenzwerke und Gedanken herangezogen werden, welche in den dazu passenden Abschnitten der Konzeptanalyse erwähnt sind. Analog zur Grafik kommen daher also Ansätze aus der Physik (Abschnitt 4.2.1, S. 38), Mathematik (Abschnitt 4.2.2, S. 40) sowie der Linguistik (Abschnitt 4.2.5, S. 44) in Frage. Sensorik Um akustische Eindrücke überhaupt mit Mitteln der Informatik verarbeiten zu können, ist es zunächst notwendig, eine elektrische Repräsentation von ihnen anzufertigen. Hierfür müssen weiterhin analoge Schallwellen zuerst in eindeutige elektrische Impulse verwandelt werden. Diesen Zweck erfüllen Mikrofone dank vielfältiger Erkenntnisse aus der Physik schon seit mehr als 100 Jahren. Abbildung 5.14 zeigt das Schema der dabei heutzutage am häufigsten genutzten Variante, dem Kondensatormikrofon. Dieses kommt ob seiner gut miniaturisierbaren Bauweise besonders tormikrofon 14 Abbildung 5.14.: Kondensa- häufig in Mobiltelefonen, Notebooks und ähnlichen elektrischen Geräten vor. So ist anzunehmen, 14 Abbildung aus [60] 54

67 5.1. Lösungen aus der Informatik dass auch mobile Roboter wie der Aldebaran Nao derartige Elemente nutzen, um Schallquellen bzw. deren Reflexionen aus der Umgebung wahrzunehmen und elektrisch zu transformieren. Abbildung 5.15.: Wellenform 15 Die anschliessende Überführung der gemessenen Schwingungen in eine entsprechende digitale Darstellung geschieht dann im Wesentlichen durch deren Quantisierung bzw. Sampling. Hierbei wird in festen Zeitintervallen das anliegende Audiosignal gemessen und dessen aktueller Wert in eine Tabelle eingetragen, welche man am Schluss abspeichert. Typischerweise kommen für eine solche Abtastung digitale Signalprozessoren zum Einsatz. Die Genauigkeit bzw. Auflösung hängt dabei von Abtastfrequenz und Bittiefe ab. Erstere legt die Zeitspanne zwischen zwei Messungen fest, während zweitere die Genauigkeit des gemessenen Wertes in der Datenstruktur beschreibt. Abbildung 5.15 zeigt exemplarisch das Ergebnis dieses Prozesses. In diesem Fall sind die ermittelten Werte dem Zeitverlauf nach auf der x-achse angeordnet, welches eine Wellenform ergibt. Demnach sind grundsätzliche perzeptible Aspekte des humanoiden Hörens gut in die Informatik abbildbar. Sie sind sowohl bei der Ortung von Zielen als auch bei der Interaktion gleichermaßen wie beschrieben anzuwenden. Merkmalsextraktion Ähnlich wie bei der Bildverarbeitung ist es erforderlich, die gesammelten Daten weiter auszuwerten, um sowohl die Ortung von Hindernissen als auch die Interpretation von gesprochener Sprache zu ermöglichen. Anforderungen waren hierbei die Erkennung von Befehlen aus Aufnahme (vgl. Tabelle 4.5, S. 44) und die Nutzung von Sonartechnik zur Messung akustischer Abstandsdaten (vgl. Abschnitt 4.2.1, ab S. 38). Hierfür müssen aus den zugrundeliegenden perzeptiblen Daten Eindrücke bzw. Merkmale gewonnen werden. Allein aufgrund der Hinweise in [20], [44], [42] lässt sich von einer hohen Diversität verwertbarer Lösungsmuster in der Informatik ausgehen. Im Sinne der Vorstellung passender Ansätze werden die beiden wichtigsten hiervon kurz vorgestellt. Nach [20], S. 43 f. ist für die computergestützte Spracherkennung die Gewinnung der sog. Mel-Frequenz-Cepstrum-Koeffizienten das zielführendste Schema, um hierfür stabile und sinnvolle Merkmale zu erhalten. Insbesondere können an diesen einzelne, charakteristische Laute einer Sprache anhand ihrer Formanden 17 identifiziert werden. Im Wesentlichen erfolgen dazu unterschiedliche Transformationen an der Wellenform einer Aufnahme (vgl. dazu auch [44], S. 94 f.). Unter anderem umfasst dies eine Überführung des Signals in ein Frequenzspektrum mittels diskreter Fouriertransformation. In Abbildung 5.16 ist das Ergebnis einer solchen quenzspektrum 16 Abbildung 5.16.: Mel Fre- Analyse beispielhaft dargestellt. Die Extraktion dieser Merkmale ist somit für die Erfüllung der oben genannten Anforderung auf jeden Fall ausschlaggebend. Sonarsensoren erhalten die für eine Abstandsmessung notwendigen Merkmale auf eine andere Art und Weise aus ihrer Umgebung. Sie messen hierfür die Zeit zwischen der Aussendung und dem Empfang der Reflexion eines bestimmten akustischen Signals. Unter Berücksichtigung physikalischer Gegebenheiten (Schallgeschwindigkeit) ist somit die Distanz vorausliegender Objekte 15 Abbildung selbst angefertigt aus dem Verarbeitungsprogramm Audacity 16 Abbildung aus [19] 17 Anm. Menge an Cepstrum-Koeffizienten, welche typisch für bestimmte Laute sind 55

68 5. Lösungen des theoretischen Modells einfach abschätzbar. Abbildung 5.17 visualisiert dieses wesentliche Konzept. Aufgrund seiner Simplizität könnte es sehr einfach durch ein Programm umgesetzt werden. Schlussendlich sind dafür nämlich nur bereits vorhandene Fähigkeiten zur Perzeption (s.o.), sowie Methoden für die Zeitmessung erforderlich. Letztere sind mit Sicherheit in jedem Betriebssystem vorhanden. Darüber hinaus ist heutzutage ein derartiges Vorgehen tatsächlich oftmals sogar schon in der Mikroelektronik der meisten Sonarsensoren integriert. In diesem Falle ist es möglich, Abstandswerte direkt über deren (Software-)Schnittstelle bzw. Bibliothek zu erhalten. Abbildung 5.17.: Konzept: Sonar 18 Es existieren neben diesen Ansätzen zahlreiche weitere, auf deren Vorstellung im Rahmen dieser Arbeit jedoch verzichtet wird. Die Gewinnung von Eindrücken und Merkmalen für die Ortung von Hindernissen und die Analyse von Sprache auf Basis gespeicherter Audiodaten ist jedoch schon durch die präsentierten Vorgehensweisen durchaus gut realisierbar. Somit ist davon auszugehen, dass alle perzeptiblen Anforderungen des Gesamtkonzeptes durch passende Lösungsmuster in der Informatik abgedeckt werden. Klassifikation Parallel zu der Verarbeitung optischer Daten aus der Umgebung spielt auch die Evaluation der gewonnenen akustischen Merkmale in diesem Fall eine wichtige Rolle. Kognition wird dabei zunächst durch die Anforderung, dass die Bedeutung eines Befehls anhand einer Bewertung seines akustischen Signals durch Vorgehensweisen aus der Linguistik gefunden werden soll (vgl. Abschnitt 4.2.5, S. 44), benötigt. Daher müssen auch hier entsprechende Ansätze aus der computergestützten Tonverarbeitung betrachtet werden, um die dafür sinnvollsten Lösungskonzepte finden zu können. Der Einblick in die diesbezüglichen Referenzwerke ([20], [44]) führt zu der Erkenntnis, dass sich grundsätzlich in der Spracherkennung dazu erneut mathematisch fundierte Klassifikatoren (vgl. Abschnitt 4.2.2, ab S. 40) benutzen lassen. Diese sind nämlich im Wesentlichen unabhängig vom Verwendungszweck und setzen für eine Funktion lediglich einen ordnungsgemäß definierten Merkmalsraum voraus. Abbildung 5.18.: Hidden-Markov-Modell zur Berechnung von Beobachtungssequenzen 19 Hierbei können nach [44], S. 103 f. einzelne Laute aus einer Probe beispielsweise durch die Nutzung eines knn-klassifikators anhand ihrer minimalen Distanz zu einer Referenzklasse eindeutig zugeordnet werden. Die dabei gewonnenen Erkenntnisse gelten weiterhin dann als Grundlage für 18 Abbildung aus [62] 19 Abbildung aus [44], S

69 5.1. Lösungen aus der Informatik den eigentlichen Erkennungsprozess. Im Wesentlichen ist dafür die Bewertung der Wahrscheinlichkeit einer bestimmten Buchstaben- bzw. Wortkette der zentrale Aspekt. Dies wird nach [20], S. 67 f. vor allem durch den Einsatz von sog. Hidden-Markov-Modellen bewerkstelligt, welche auf Basis bedingter Wahrscheinlichkeiten und Zustandsautomaten operieren. Abbildung 5.18 zeigt ein solches Modell exemplarisch auf. So ist die Wahrscheinlichkeit, dass eine bestimmte Beobachtung b N (x) tatsächlich vorliegt, davon abhängig, ob der jeweils damit verbundene Zustand S N angenommen wird. Das ist wieder herum durch die Folge von Übergangswahrscheinlichkeiten (a x,y) bedingt, welche bis zu diesem Zeitpunkt durch die Abarbeitung der zugrundeliegenden Sequenz entstanden sind. Letztere können eben die Buchstaben einzelner Wörter oder Wörter ganzer Sätze sein. Durch eine Zusammensetzung der Beobachtungen aus dem HMM ist es somit möglich, aus klassifizierten Lautfolgen jeweils das höchst wahrscheinliche, dazugehörige Wort zu bestimmen. Weiterhin könnte es notwendig werden, Aspekte der Kognition auch bei der Weiterverarbeitung der Daten aus den Sonarsensoren realisieren zu müssen. Dazu findet hingegen jedoch keine Klassifikation von Merkmalen statt. Wie später ersichtlich wird, werden stattdessen die dabei gewonnenen Abstandswerte oftmals für die Population von Kartenstrukturen beispielsweise sogenannter Occupancy Grids (vgl. Abschnitt 5.2.2, S. 67) hierfür über die gesamte Laufzeit des Systems gesammelt und ausgewertet. Wenn man die dafür vorgeschlagenen Lösungen betrachtet, so ist diesen ein gewisser kognitiver Aspekt nicht abzuschreiben. Das mit vorrangigste Modell aus der Informatik bzw. Robotik ist nach Murphy der HIMM-Algorithmus, welcher 1992 an der Universität von Michigan, USA entwickelt wurde. 21 Dieser wertet die Distanzdaten eines Sonarsensors kontinuierlich aus und versucht die Wahrscheinlichkeit der Belegung bestimmter Orte im Raum aus der Historie aller gesammelten Daten abzuschätzen. Dazu wird ein gewichtetes Bewertungsmaß eingeführt. Abbildung 5.19 zeigt beispielhaft das hierfür zu nutzende Schema. Demnach findet die Interpretation über die Existenz von Hindernissen nur Abbildung 5.19.: HIMM - in Richtung der akustischen Achse der jeweiligen Sensoren statt. Schema 20 Das Bewertungsmaß wird dabei grundsätzlich durch die folgende einfache Formel berechnet: karte[x][y] = karte[x][y]+i,0 karte[x][y] 15 Wobei I bei Belegung positiv und andernfalls entsprechend negativ ist. Die anschliessende Evaluation geschieht weiterhin durch die Berechnung abhängiger Wahrscheinlichkeiten durch die Formel von Bayes. Dabei wird anhand dieser statistisch fundiert entschieden, ob ein Teilstück der Karte tatsächlich belegt ist oder nicht. Auf die Details kann jedoch verzichtet werden, da es in diesem Abschnitt nur um eine Vorstellung von adäquaten Lösungsansätzen geht. Anhand der Existenz derartiger Konzepte ist jedoch abzuleiten, dass die spezifizierten, kognitiven Aspekte des Gesamtsystems, welche eine weitere Verarbeitung akustischer Reize benötigen, durch Lösungskonzepte der Informatik realisierbar sind. Interaktion durch Imitation Für eine Ausgabe des Systemzustandes (vgl. Abbildung 5.13b, S. 54) ist abschliessend ebenfalls eine gute Äquivalenz aus dem Forschungsbereich der Informatik für die Umsetzung dieser interaktiven Komponente des Gesamtkonzeptes zu finden. 20 Abbildung aus [42], S vgl. [42], S

70 5. Lösungen des theoretischen Modells (a) Transkriptionsstufe (b) Phonoakustische Stufe Abbildung 5.20.: konzeptioneller Ablauf von Sprachsynthese 22 In Anbetracht des derzeitigen Standes computergestützter Tonverarbeitung sind hierfür insbesondere Methoden zur Sprachsynthese besonders gut geeignet. Allein schon bei der Betrachtung von [44] kann man dabei von einer Vielzahl aus verfügbaren Lösungen wählen. Im Wesentlichen arbeiten sie jedoch vom Prinzip her gleich. Wie in Abbildung 5.20 beschrieben, werden zuerst Lautbausteine durch Analyse eines Textbausteines (Transkriptionsstufe, vgl. Abbildung 5.20a) gewonnen und jene anschließend anhand eines akustischen Modells zusammengesetzt (Phonoakustische Stufe, vgl. Abbildung 5.20b). Bei den beliebtesten Lösungen kommen hierfür natürlich vorrangig Konzepte und Grundlagen zum Einsatz, welche eingängig in der Informatik bekannt sind. So wird die Transkriptionsstufe nach [44], S. 215 f. letztendlich durch die Anwendung einer bestimmten Grammatik realisiert, um ähnlich wie bei einem Compiler die Übersetzung von Buchstabenketten zu Lautfolgen zu ermöglichen. Letztere werden dann, oftmals unter Verwendung der bereits aus der Spracherkennung bekannten Formanten (vgl. dazu Abbildung 5.16, S. 55), unter Verwendung von neuronalen Netzen verkettet und durch Synthese der entsprechenden Signale in eine hörbare Form gebracht. 23 Aufgrund der hohen Verfügbarkeit geeigneter Referenzen kann man davon ausgehen, dass die gewünschte interaktive Funktion ohne große Probleme umsetzbar ist. Somit sind für alle akustischen Bedürfnisse des Gesamtkonzeptes Übereinstimmungen aus der Informatik gefunden Kinematik und Informatik Neben der Verarbeitung von Sprache ist insbesondere eine selbstständige Bewegung um potentielle Gefahrenquellen ein wesentlicher interaktiver Bestandteil des zu erzeugenden Robotersystems (vgl. Abschnitt 3.4.3, S. 28 ff.). Im Rahmen der Konzeptanalyse ist klar geworden, dass ohne ein angemessenes kinematisches Modell bzw. dazu passenden Algorithmen eine Umsetzung dieser Eigenschaft nicht realisierbar ist (siehe Abschnitt 4.2.1, ab S. 38). Im theoretischen Modell führt dies letztendlich zu den in Abbildung 5.21 dargestellten Anforderungen, welche ebenfalls durch passende Lösungsmuster aus der Informatik gelöst werden müssen. Da es sich beim Aldebaran Nao um einen Roboter handelt, der das humanoide, bipedale Laufen als Fortbewegungssystem nutzt, beschränkt sich dieser Abschnitt dazu auf eine Vorstellung der Grundlagen des dabei von ihm genutzten Konzepts. Dieses besteht zunächst aus dem linearinversen Pendelmodell, und dessen technischer Umsetzung, einem quadratischen Programm für 22 Abbildungen aus [44], S. 199 f. 23 vgl. dazu [44], Kapitel 9, Seite 237 f. 58

71 5.1. Lösungen aus der Informatik Abbildung 5.21.: Notwendigkeit von kinematisch-orientierten Lösungen aus der Informatik die letztendliche Berechnung der einzelnen Bewegungen durch das Steuerungssystem des Roboters. 24 Linear-inverses Pendelmodell Um ein in puncto Gleichgewicht möglichst stabiles Verhalten im Gang zu ermöglichen, wird im Falle der Nao-Roboterplattform auf ein Bewegungsmodell gesetzt, welches auf dem Prinzip eines linear-inversen Pendels beruht. Die Details dieses Modells sind in [34] zu finden, welches auch als Referenz bei der Entwicklung des Nao genutzt wurde. Anhand Abbildung 5.22 ist die grundsätzliche Idee des Modells relativ einfach zu erklären. Es geht prinzipiell immer darum, ein Fahrzeug, welches sich in einer planaren Ebene bewegt, derartig zu steuern, sodass ein darauf befestigtes, bewegliches Pendel nicht Abbildung 5.22.: Linearinverses Pendel 25 zu Fall gebracht wird. Im Kontext des Nao ist letzteres gleichzusetzen mit der Gerade, welche von den Füßen an mitten durch dessen Beine führt und in seinem Schwerpunkt (welcher in der unteren Hälfte seines Torsos liegt) endet. Aus geometrischer Sicht folgt dabei die Bedingung, den Winkel zwischen dieser und der Normgerade der Basisebene möglichst minimal zu halten. Anders ausgedrückt: Der Schwerpunkt des Roboters darf während des Laufs möglichst nicht von einem voraus berechneten Kurs und der dazu passenden Geschwindigkeit abweichen. Abbildung 5.23.: Laufmuster 26 Im Falle des bipedalen Laufens bedeutet dies weiterhin nach der Arbeit von Wieber ([56]), dass der sog. Center of Pressure 27, also der Punkt des Bodens, an dem nach einem durchgeführten Schritt das Bewegungsmoment des Roboters möglichst gegen Null strebt, in Abhängigkeit zur relativen Position bzw. Balance des Schwerpunktes ideal berechnet und erreicht werden muss. Dazu ist es notwendig, die jeweiligen Stellen, an denen sich die Aufsatzpunkte beider Füße entsprechend befinden sollten, zu bestimmen. Abbildung 5.23 zeigt ein dazu passendes Laufmuster exemplarisch auf. Dabei sind jene Aufsatzpunkte durch die kleinen Kreise gekennzeichnet. Es resultiert durch eine wiederholte Berechnung oben genannter Parameter. Dieses kann dann anhand einiger Transformationen (SE3-Interpolation nach [5]) durch die Hardware des Nao umgesetzt werden. 24 vgl. dazu [5], Abschnitt Reference - NAOqi API, NAOqi Motion, Walk control 25 Abbildung aus [59] 26 Abbildung aus [5], Abschnitt Reference - NAOqi API, NAOqi Motion, Walk control 27 vgl. [56], S. 1 59

72 5. Lösungen des theoretischen Modells Da für diese Methodik verschiedene Faktoren, wie die gegenwärtige horizontale Beschleunigung (ẍ), Position (x) und der Abstand zur Bezugsebene (h) des Schwerpunkts eine wichtige Rolle spielen, wird in [56] grundsätzlich von dem folgenden Zusammenhang ausgegangen: z = x h g ẍ Wobei z die Position des CoP auf der Bezugsebene und g die Gravitationskonstante darstellt. Eine weiterführende Betrachtung von [56] offenbart jedoch letztendlich das fundamentale Problem: Da für seine diskrete Berechnung weiterhin verschiedene, abschnittsweise definierte kubische Funktionen zum Einsatz kommen, müssen dabei dynamisch jene Teilpolynome, welche einen stabilen Kurs des Schwerpunkts garantieren, unter der Bedingung eines minimalen Abstands zu letzterem gefunden werden. Nur so wäre es möglich, die Auftrittspunkte der einzelnen Beine zu bestimmen. Dies ist ein typisches Problem, welches durch quadratische Programmierung und somit auch durch Mittel der Informatik gelöst werden kann. Quadratisches Programmieren Obwohl der Terminus quadratisches Programmieren zunächst auf eine bestimmte Vorgehensweise bei der Realisierung von Computersystemen vermuten lässt, hat er anfangs eigentlich gar nichts damit zu tun. Es handelt sich dabei viel mehr primär um ein Lösungsmuster aus der Mathematik. Quadratische Programme stellen grundsätzlich eine Variante des Optimierungsproblems dar. Hierbei werden Ergebnisse quadratischer Funktionen anhand einer Beschränkung ihrer Variablen minimiert bzw. maximiert. Ein typisches Anwendungsszenario sind Problemstellungen, die wie bei der Berechnung des CoPs eine möglichst effiziente Lösung unter festgelegten Bedingungen/Beschränkungen erfordern. Abbildung 5.24 zeigt das Programm im Falle des Wieber- Problems beispielhaft auf. Abbildung 5.24.: Quadratisches Programm für Errechnung des CoPs 28 Nach [51] können für dessen Lösung prinzipiell sehr viele verschiedene Ansätze zum Einsatz kommen. Die wichtigsten davon können hierbei wie folgt aufgelistet werden: Active Set Methods 29 Interior Point Methods 30 Conjugate Gradient Methods 31 Wie also kann anhand dieser ein Zusammenhang zur Informatik hergestellt werden? Es existieren mehrere Möglichkeiten, um solch eine Frage zu beantworten. So gibt es zunächst Referenzimplementierungen der o. g. Ansätze in verschiedenen Computersystemen. Beispielsweise bietet Matlab ein eigenständiges Modul zur Lösung quadratischer Programme an. Somit wäre es möglich, die für eine möglichst stabile Bewegung des Roboters notwendigen (Positions-)Parameter effizient zu bestimmen. 28 Abbildung aus [56], S vgl. [51], S. 35 f. 30 vgl. [51], S. 78 f. 31 vgl. [51], S

73 5.1. Lösungen aus der Informatik Darüber hinaus müssen weiterhin Methoden vorhanden sein, welche die schnelle Auswertung bzw. Versorgung dieser Algorithmen mit Sensordaten realisieren. Ausserdem ist es notwendig, die Hardware des Aldebaran Nao entsprechend zu den dabei gewonnenen Ergebnissen dynamisch zu steuern. In Anbetracht dessen dient die Informatik somit gleichermaßen als evaluierende, ausführende und beobachtende Schicht, wenn es um die Realisierung von zeitkritischer Kinematik in Robotersystemen geht Künstliche Intelligenz und Informatik Die Notwendigkeit fundamentaler künstlich intelligenter Aspekte ist eine der wichtigsten Erkenntnisse der Konzeptanalyse in Kapitel 4. Wenn man das theoretische Modell (vgl. Abbildung 4.6, S. 45) betrachtet, so bilden diese mehr oder weniger das Rückgrat des gesamten Systems. Deshalb sind sie zunächst durch abstrakte Elemente in allen Zielen modelliert worden. Abbildung 5.25 zeigt zwei davon exemplarisch auf. In Abschnitt (S. 41 ff.) wurde dabei die Erkenntnis gewonnen, dass ihre Realisierung nur durch die Einführung vernetzter und kontextsensitiver Modifikationen an den Methoden der einzelnen Teillösungen zu erreichen ist. Darüber hinaus ist dort auch die Imitation von intelligenten Prozessen für die Bewältigung des Navigationsproblems spezifiziert worden. Abbildung 5.25.: Anforderungen: künstliche Intelligenz Für eine Erfüllung dieser Anforderungen müssen daher jene Konzepte und Schemata aus der Informatik gesucht werden, welche eine derartige Interkommunikation und Problemlösung erbringen. Interkommunikation Die Übermittlung bzw. das Teilen von Daten zwischen verschiedenen Rechnern oder Unterprogrammen sind gleichermaßen nicht wegzudenkende Prozesse in der Informatik. Entsprechend gibt es dazu eine große Menge verschiedener Konzepte, welche für eine Vernetzung der einzelnen Teillösungen (z. B. von Merkmalserkennung und Kartografie) in Frage kommen. Nutzklasse A Datenklasse mit Schnittstelle (Kartografie) Pointer Nutzklasse B Abbildung 5.26.: gemeinsame Datenklasse Eine Lösung besteht beispielsweise schlicht in der Nutzung von Eigenschaften der objektorientierten Programmierung. So wäre es ohne Probleme möglich, Klasseninstanzen, welche gleiches Kontextwissen benötigen, miteinander zu verbinden. Dafür stehen prinzipiell mehrere Optionen zur Auswahl. Die simpelste Variante ist in der Einrichtung gegenseitiger Abfrage- und Aktualisierungsmethoden zwischen den Objekten zu sehen. Das wäre jedoch sehr unpraktisch, da eine Folge hiervon die Erzeugung vieler Duplikate von Daten im System ist. Ausserdem würden sich weitere Probleme durch deren individueller Aktualität ergeben. Besser ist die Nutzung einer gemeinsamen Datenklasse, auf die alle Module eines Systems zugreifen können. Bei einer derartigen Vorgehensweise kann eine unnötige Duplikation der Daten vermieden werden. Abbildung 5.26 zeigt eine derartige Konfiguration beispielhaft auf. Dabei muss natürlich jedoch noch der gleichzeitige Zugriff durch die Implementierung einer Schnittstelle berücksichtigt werden. 61

74 5. Lösungen des theoretischen Modells Ein anderes Konzept ist in der Verwendung von Message-Queues Nutzklasse C gegeben. Hierbei werden Teile eines Programms durch gemeinsame Nachrichtenkanäle direkt und fest miteinander verbunden. Queues Nutzklasse A Nutzklasse B Der Datenaustausch findet anschließend durch die jeweilige wiederholte Abfrage bzw. Befüllung letzterer durch die einzelnen Kommunikationspartner statt. In Abbildung 5.27 wird dieses Abbildung 5.27.: Queues Konzept exemplarisch dargestellt. Für die Modifikation der Methoden eines Robotersystems eignen sie sich jedoch nur beschränkt, weil bei zunehmender Vernetzung unübersichtliche und somit schwer verwaltbare Architekturen entstehen. Ausserdem sind dann in jedem Modul entsprechende kommunikative Methoden notwendig, was das System recht verkompliziert. Darüber hinaus könnte eine Lösung aus asynchronen Events auf Basis eines einheitlichen Messaging - Bus (z. B. XML - SOAP) bestehen. Bei diesem Ansatz werden Programmmodule bzw. verschiedene Einzelsysteme lose durch eine gemeinsame Definition miteinander verknüpft. Hierbei werden Funktionen für die Bearbeitung der Events an eine zentrale Kontrollinstanz gebunden. In diesem Fall würde beispielsweise die Kartografie aktuellste Erkenntnisse aus der Merkmalserkennung direkt und ohne eigenes zutun erhalten. Effektive Kommunikation kommt dabei also erst dann zustande, wenn sie auch wirklich notwendig ist. Zeitkritische Aspekte könnten somit modelliert werden. Zudem haben derartige Systeme erfahrungsgemäß oft die Eigenschaft modular und flexibel erweiterbar zu sein. Es stellt beispielsweise kein Problem dar, mehrere Empfänger an einen Sender zu binden. Diese drei Konzepte stellen natürlich nur eine minimale Auswahl dar. Interkommunikation wäre beispielsweise weiterhin auch durch die Nutzung von TCP Sockets oder durch Datenbanksysteme durchführbar. Für eine Implementierung sollte möglichst Wert auf Simplizität und Erweiterbarkeit gelegt werden. (Intelligente) Problemlösung Die Lösung von komplexen Problemen ist quasi ein permanentes Thema in der Informatik. Analog dazu hat sich im Verlauf der letzten Jahrzehnte ein enormes Repertoire an Wissen und Algorithmen entwickelt, welches für viele verschiedene Zwecke einsetzbar ist. Soll die Navigation eines Roboters realisiert werden, so muss man nach Murphy auf Erkenntnisse aus der Graphentheorie zurückgreifen. 33 Dabei ist von Vorteil, dass sich ein gleichartiges Problem in der Informatik beispielsweise auch schon bei der Implementierung von Netzwerkprotokollen ergab. In diesem Fall musste ein möglichst optimaler Transportweg für ein Datenpaket gefunden werden. Die dafür nutzbaren Algorithmen sind also die gesuchte Äquivalenz für die Abbildung künstlicher Intelligenz in puncto Problemlösen. Auf die beiden wichtigsten davon wird hier kurz eingegangen. In diesem Zusammenhang erscheint oftmals zuerst der Algorithmus von Dijkstra, welcher aufgrund seiner Verbreitung als Referenz betrachtet werden kann. Es handelt sich dabei um eine Abbildung 5.28.: Knotenauswertung durch Dijkstra 32 Methodik für die Berechnung kürzester Pfade in einem Graph auf Basis eines gegebenen Startpunktes. Alle Kanten müssen dazu mit positiven Gewichten versehen sein. Im Wesentlichen verfolgt der Algorithmus stets zuerst alle Kanten, welche die minimalste Distanz von Start und 32 Abbildung aus [9] 33 vgl. [42], S

75 5.2. Lösungen aus der Robotik Ziel aufweisen könnten. Erst dann wird der Rest des Graphen evaluiert. Abbildung 5.28 zeigt exemplarisch einen Zwischenschritt einer derartigen Wegfindung. Der A*-Algorithmus ist eine logische Weiterentwicklung der Dijkstra-Methodik. Hierbei liegt der wesentliche Unterschied darin begründet, dass statt einer zeitintensiven Betrachtung aller Knoten nur jene analysiert werden, welche mit einer hohen Wahrscheinlichkeit in Richtung des Ziels liegen. Als Grundlage hierfür dient eine Heuristik, welche die Kosten des bisher beschrittenen und des noch ausstehenden Weges aus der Perspektive eines jeden Knoten abschätzt. Dies führt u. a. zu einer starken Verkürzung der Laufzeit. Es existieren noch zahlreiche weitere derartige Algorithmen, wie D* und FloodFill, auf die hier nicht weiter eingegangen wird. Mit der Existenz dieser (und weiterer) geeigneter Konzepte und Lösungsmuster aus der Informatik ist sicher, dass die Aspekte Vernetzung und Problemlösung für die Implementierung künstlich intelligenten Verhaltens realisiert werden können. Demzufolge sind alle beachtenswerten Aspekte aus Optik, Akustik, Kinematik und Psychologie für eine prototypische Implementierung des Gesamtkonzeptes gefunden Lösungen aus der Robotik Von Erkenntnissen aus der Robotik sind alle Punkte und Anforderungen des theoretischen Modells abhängig, da sie mitunter auch systemspezifische Konzepte, Modelle und spezielle Lösungsmuster aus dem Wissensschatz dieses Fachgebiets benötigen. Weiterhin ist es für eine (prototypische) Implementierung erwartungsgemäß erforderlich, eine möglichst gute Synthese aus ihnen und den Ansätzen aus Abschnitt 5.1 (S. 47 ff.) zu finden, um alle Teillösungen optimal miteinander zu einem sinnvollen Gesamtsystem verbinden zu können. Robotik Lösungen aus Informatik + + Architektur Steuerungskonzepte Datenstrukturen Gesamtsystem Abbildung 5.29.: Notwendigkeit von Lösungen aus der Robotik Wie in Abbildung 5.29 dargestellt, spielen hierfür einige Grundlagen, wie verschiedene Steuerungskonzepte und spezielle Datenstrukturen (z. B. für Navigation) eine wichtige Rolle. Zudem beeinflussen insbesondere erstere die Wahl einer passenden Referenzarchitektur aus diesem Fachgebiet. Daher werden in diesem Abschnitt zunächst derartige essenzielle Begriffe speziell für die Modellierung von intelligenten Robotersystemen eingeführt. Anschließend findet eine Vorstellung möglicher Referenzarchitekturen für die Einbettung aller bis zu diesem Punkt gewonnenen Erkenntnisse in einem System statt. Die Theorien von Murphy ([42]) dienen dabei als maßgebliche Quelle. 63

76 5. Lösungen des theoretischen Modells Steuerungskonzepte Für die Realisierung von künstlich intelligenten Robotersystemen stehen nach derzeitigem Stand drei verschiedenartige Konzepte bzw. Paradigmen zur Verfügung, welche sich in der Robotik historisch nacheinander ergaben (vgl. Abschnitt 2.1 ff., Seite 7 ff.). Diese können folgendermaßen aufgezählt werden: 1. Hierarchische Systeme Reaktive bzw. Verhaltensorientierte Systeme Hybride Systeme 36 Sie alle verkörpern grundlegend verschiedene Vorgehensweisen bei der Modellierung und Konzeption von Softwaresystemen für Roboter, indem sie die Primitiva der Robotik unterschiedlich deuten und zusammensetzen. Bevor also auf erstere näher eingegangen werden kann, ist es sinnvoll, eine Definition dieses Begriffs zu geben. Primitiva der Robotik Wie man in Tabelle 5.2 sehen kann, handelt es sich dabei um die grundlegenden Funktionen, welche für die Verwirklichung eines Robotersystems mindestens existieren müssen. Primitivum Datenquelle Erzeugt Messen (Sense) (unverarbeitete) Sensordaten Sensorinformationen Planen (Plan) Informationen (aus Sensorik oder kognitivem Kontext) Direktiven Agieren (Act) Direktiven oder Sensorinformationen Befehle an Aktuatoren Tabelle 5.2.: Primitiva der Robotik 37 Sie orientieren sich im Wesentlichen an humanoidem Verhalten. Analog zu diesem geschieht zunächst eine Messung von Informationen aus der Umgebung, ehe sie durch Planung zielgerichtet zu Direktiven weiterverarbeitet werden können. Auf dieser Basis erfolgen schließlich entsprechende Aktionen. Auch Reflexe bzw. unterbewusste Verhaltensweisen lassen sich beschreiben, indem die Sensordaten direkt mit Aktionen verknüpft werden. Erwartungsgemäß ist dabei dann der Aspekt der Planung zunächst völlig ausgeschlossen. Mit dieser Definition ist es nun möglich, auf den individuellen Aufbau, sowie Eigenschaften und Anwendungsgebiete der einzelnen Steuerungskonzepte einzugehen. Hierarchische Systeme Systeme, welche einem hierarchischen Steuerungskonzept folgen, existieren seit den ersten Stunden der modernen Robotik (ca. ab 1967). Somit kann diese Vorgehensweise vorab als eine Referenz heutiger Systeme eingeordnet werden. 34 vgl. [42], S. 6, 41 ff. 35 vgl. [42], S. 8, 105 ff. 36 vgl. [42], S. 9, 257 ff. 37 Tabelle und Inhalte aus [42], S. 5 f. 64

77 5.2. Lösungen aus der Robotik Messen Planen Agieren Aktion durchführen Abbildung 5.30.: Workflow hierarchischer Systeme 38 Im Rahmen dieses Paradigmas sind Roboter nur durch eine strikte Befolgung der in Abbildung 5.30 dargestellten Befehlskette in der Lage, Ziele in der realen Welt umzusetzen. Dementsprechend wird zuerst die Umgebung anhand der Sensorik wahrgenommen, anschließend auf Basis der erhaltenen Daten geplant und letztendlich die Ausführung passender Aktionen ausgelöst. Diese Vorgehensweise wiederholt sich ständig in einer Art Unendlichkeitsschleife und ist daher in vielen Punkten nicht flexibel bzw. vorteilhaft. So dauert es beispielsweise eine komplette Iteration, bis Veränderungen in der Umgebung durch Daten aus der Sensorik in die Planung einfließen können. Durch den Schwerpunkt der Planung sind weiterhin keine reflexartigen Verhaltensweisen umsetzbar. Kurz gesagt, das System plant einfach immer, auch wenn das möglicherweise durch Referenzwissen vermieden werden könnte. Dies führte bei der Modellierung von unvorhersehbaren Ereignissen zu Schwierigkeiten. Ein Vorteil ist jedoch, dass die Implementierung eines Robotersystems bei der nicht-existenz von derartigen Ereignissen durch die Simplizität dieses Paradigmas erleichtert wird. Hierarchische Systeme sind daher vorwiegend an solchen Orten zu finden, in denen eben jene Nachteile keine Rolle spielen. So ist es beispielsweise denkbar, einen Industrieroboter der ausschließlich in einem abgesperrten Bereich operiert auf diese Art und Weise zu modellieren bzw. programmieren. Reaktive Systeme Einen völlig anderen Ansatz verkörpern hingegen reaktive Systeme. Sie traten erstmals Ende der 80er Jahre in Erscheinung und sind als Antwort auf die Nachteile hierarchisch inspirierter Vorgehensweisen zu sehen. Messen Agieren Abbildung 5.31.: Workflow reaktiver Systeme 39 Der wesentlichste Unterschied besteht hierbei aus dem vollständigen Verzicht des Planungsaspektes. Roboter sollen dabei nur durch das reine Zusammenspiel von einer Vielzahl gleichzeitig ablaufender Verhaltensweisen (sog. Behaviors) Ziele in der realen Welt umsetzen. Dazu werden Messergebnisse direkt mit einer Auswahl von passenden Reaktionen verknüpft. Abbildung 5.31 zeigt diesen Zusammenhang unter Berücksichtigung der Primitiva schematisch auf. Murphy nennt hierzu die Vermeidung eines Hindernisses als praktisches Beispiel. 40 So ist es vorgesehen, 38 Abbildung/Inhalte nach [42], S. 6 f. 39 Abbildung/Grundlagen aus [42], S. 7 f. 40 vgl. [42], S. 8/9 65

78 5. Lösungen des theoretischen Modells dass eine Kombination der Verhaltensweisen für Vorwärts- und Ausweichbewegung quasi unbewusst die Vermeidung einer Kollision zur Folge hat. Bei der Anwendung dieses Paradigmas ergeben sich augenscheinlich zunächst nur Vorteile. Durch den Wegfall einer unter Umständen komplexen Planung ist die Laufzeit derartiger Systeme sicherlich kleiner einzuschätzen als bei den hierarchischen Varianten. Zusätzlich entfällt die Modellierung unvorhersehbarer Situationen natürlich komplett, da sie quasi per se zur Laufzeit dynamisch berücksichtigt werden. Nachteile ergeben sich jedoch auch in zweierlei Hinsicht. So ist einerseits die Menge an potentiell möglichen Neben- und Seiteneffekten zwischen verschiedenen Verhaltensweisen bei zunehmender Komplexität schwer einschätz- und überschaubar. Andererseits setzt die Vielzahl von gleichzeitig ablaufenden Programmen (ebenfalls bei hoher Systemkomplexität) die Basis entsprechend leistungsfähiger Hardware beispielsweise für Multithreading voraus. Reaktive Systeme eignen sich aber trotzdem besonders gut für Szenarien, in denen überschaubare, flexible Prozesse mit möglichst wenig Rechenaufwand automatisiert werden sollen. Ein Beispiel dafür kann man, unter anderem, in Kinderspielzeug sehen. Hybride Systeme Seit Anfang der 90er Jahre versuchen hybride Systeme die Vorteile ihrer hierarchischen und reaktiven Verwandten zu vereinigen. Sie gelten bis heute als der derzeitige Maßstab in der Robotik. Planen Messen Agieren Abbildung 5.32.: Workflow hybrider Systeme 41 Das Paradigma stützt sich grundsätzlich primär auf Eigenschaften reaktiver Systeme. Jedoch wird der zuvor eliminierte Planungsaspekt wieder eingebracht, um die Modellierung bestimmter, sehr komplexer Anforderungen stark zu vereinfachen bzw. um extreme Korrekturen zur Laufzeit zu ermöglichen. Ein Roboter erreicht dabei sein Ziel, indem er eine bestimmte Aufgabe zunächst in sinnvolle Teilprobleme durch Planung dividiert und deren Lösung adäquaten Verhaltensweisen überlässt. Anstelle einer direkten Steuerung der einzelnen Aktuatoren sind letztere somit quasi als Werkzeug für die Realisierung maßgeblich. Die hierbei anfallenden Messdaten können zusätzlich seitens der planungsgebenden Schicht eingesehen und genutzt werden, um nötigenfalls den Plan aus passenden Verhaltensweisen umzustellen. Ein derartiges Steuerungskonzept erlaubt tatsächlich die Nutzung von Vorteilen beider Welten. So ist es prinzipiell möglich, sowohl die Simplizität von hierarchischen Systemen bei der Abbildung von spezifischen Anforderungen als auch die Effizienz reaktiver Systeme bei der Berücksichtigung unbekannter Situationen gleichermaßen zu Nutzen. Zusätzlich müssen rechenintensive 41 Abbildung/Inhalte aus [42], S. 7, 9 66

79 5.2. Lösungen aus der Robotik Planungsschritte nicht mehr permanent, sondern nur bei Notwendigkeit ausgeführt werden. Bei Murphy wird dies beispielsweise durch die Möglichkeit, Planungs- und Verhaltensroutinen zu unterschiedlichen Zeitpunkten auszuführen, beschrieben. 42 Dennoch existieren auch Einschränkungen. Die schwere Einschätz- und Überschaubarkeit der reaktiven Systemschicht bei zunehmender Komplexität bleibt nämlich weiterhin bestehen. Zudem müssen dann auch zusätzliche Seiteneffekte durch eine eventuelle Umplanung der Aktionen zur Laufzeit berücksichtigt und modelliert werden. Dazu sind die Methoden der hierarchischen und reaktiven Ebene entsprechend auszubalancieren. Daraus ergibt sich ein unter Umständen hoher Aufwand bei der Implementierung. Trotz dessen eignen sich hybride Systeme ob ihrer Vielseitigkeit am besten für den Einsatz in modernen Robotersystemen. Durch die Synthese beider Ansätze sind dabei eine Vielzahl von möglichen Anwendungsgebieten denkbar, beispielsweise in der Raumfahrttechnik oder auch in mobilen Kleinstrobotern Datenstrukturen für Lokalisation und Navigation Sowohl bei der Zielspezifikation (vgl. Abschnitt 3.2.4, S. 22) als auch der Konzeptanalyse (vgl. Abschnitt 4.1.3, S. 33 ff.) ist die Notwendigkeit einer zentralen Karte der Umgebung für die Lokalisation und Navigation um potentielle Gefahrenquellen ausführlich erläutert worden. Die Wahl einer dafür möglichst passenden Datenstruktur für deren Implementierung ist dabei tatsächlich ein weit verbreitetes Problem bei der Modellierung von intelligenten Robotersystemen. Deswegen existieren dazu viele verschiedene Ansätze in der Robotik. Analog zu den Steuerungskonzepten spielen deren Ausgestaltungen, spezifische Eigenschaften/Eigenheiten und Anwendungsgebiete eine nicht zu unterschätzende Rolle bei der Wahl einer passenden Architektur. Zugleich stellen sie eine wissenschaftlich fundierte Referenz für den Transfer der entsprechenden Anforderungen aus dem theoretischen Modell (vgl. Abbildung 4.6, Seite 45) dar. Die hierfür signifikantesten Konzepte lassen sich nach Murphy wie folgt auflisten: Belegungstabellen 43 Quadtrees 44 Meadow-Maps 45 Voronoi-Graphen 46 Im Folgenden werden diese anhand der angesprochenen Charakteristika eingeführt und vorgestellt. Belegungstabellen Karten auf Basis von Belegungstabellen stellen die einfachste Art und Weise dar, um Umgebungsinformationen abstrakt in einer Datenstruktur abzubilden. Hierfür wird der Raum der gesamten Aussenwelt durch ein einfaches zweidimensionales Gitter beschrieben. Die einzelnen 42 vgl. [42], S vgl. [42], S vgl. [42], S vgl. [42], S vgl. [42], S

80 5. Lösungen des theoretischen Modells Zellen repräsentieren dabei uniforme Teilabschnitte des Areals, welche auf Basis dessen jeweiliger Topologie unterschiedliche Eigenschaften enthalten können. Abbildung 5.33 zeigt eine mögliche Ausgestaltung dieses Konzeptes in einem Robotersystem auf. So sind diejenigen Bereiche, welche durch Hindernisse, wie z. B. Wände oder Gegenstände besetzt werden, entsprechend als nicht passierbar markiert (graue bzw. schwarze Hervorhebung im Bild). Analog dazu werden freie Zellen auch als solche gekennzeichnet (weiß im Bild). Die Position des Roboters im Gitternetz wird ebenfalls gespeichert. R Ob seiner Simplizität bringt dieses Konzept auch einige Nachteile mit sich. Beispielsweise ergibt sich das Problem, dass selbst kleinste Hindernisse bzw. Objekte sofort die Besetzung einer ganzen Zelle zur Folge haben. Es wird also sehr schnell und möglicherweise völlig unnötig Platz verschwendet. Zur Lösung kann Abbildung 5.33.: Konzept einer Belegungstabelle 47 hierfür nach Murphy die Granularität des Modells durch eine Verkleinerung der einzelnen Zellen erhöht werden. Natürlich steigt dadurch aber auch der Speicherverbrauch enorm (vgl. [42], S. 358, digitization bias ). Da sich eine solche Datenstruktur erfahrungsgemäß einfach implementieren lässt, kommen die sog. Occupancy Grids in vielen Robotersystemen zum Einsatz, welche in einem eingeschränkten Bezugsraum operieren sollen. Quadtrees Eine weitere Möglichkeit zur Etablierung von Kartenstrukturen in der Robotik ist durch die Nutzung von Quadtrees gegeben. Sie können als eine logische Weiterentwicklung bzw. Verfeinerung der Belegungstabellen gesehen werden, da sie im Wesentlichen deren Logik bei der Erfassung der Topologie einer bestimmten Umgebung weiter verwenden. So sind weiterhin entsprechend besetzte Bereiche als nicht passierbar bzw. leere Segmente als frei zu markieren. Um ihren spezifischen Problemen jedoch entgegenzuwirken (s. o.), wird ein erweitertes Datenmodell eingeführt. Bei diesem sind die einzelnen Teilstücke aus kleineren Elementen zusammengesetzt, welche in sich erneut Belegungstabellen repräsentieren. Abbildung 5.34 zeigt eine nach einem derartigen Konzept entstandene Karte exemplarisch auf. Abbildung 5.34.: Konzept eines Quadtrees 48 R Es ist schnell erkennbar, dass sich dabei der signifikanteste Nachteil von einfachen Belegungstabellen die Frage nach einer passenden Granularität des Modells für die Modellierung kleinster Hindernisse erübrigt. Möchte man die Auflösung erhöhen, so setzt man die Verschachtelung einfach fort. Dennoch geschieht das auf Mehrkosten in Form von CPU-Instruktionen, da für einen erfolgreichen Zugriff auf ein bestimmtes Element zunächst alle Elternsegmente passiert werden müssen. Ihr Einsatzszenario ist identisch zu dem einfacher Belegungstabellen. 47 Abbildung adaptiert aus [42], S Abbildung adaptiert aus [42], S

81 5.2. Lösungen aus der Robotik Meadow-Maps Völlig anders funktionieren Kartenstrukturen auf Basis sog. Meadow-Maps. R Bei diesen wird die Topologie eines Areals nämlich anhand von Polygonen, welche zwischen dessen Grenzen und potentiellen Hindernissen aufgespannt werden, dargestellt. Dafür ist es notwendig, jede Ecke und Kante einer (vorgegebenen) Karte zuvor zu analysieren und die errechneten Polygonfolgen anschliessend nacheinander zu speichern. Wie Abbildung 5.35 zeigt, ergeben sich somit eine Reihe von geometrischen Zusammenhängen, an welchen sich ein Robotersystem letztendlich orientieren kann. Hierbei sind die in diesem Fall wichtigen Polygone als schwarze, durchgezogene Linien dargestellt. Bei deren Berechnung wurden ausserdem zuvor alle Hindernisse künstlich erweitert, um den Platzbedarf des Abbildung 5.35.: Konzept einer Meadow-Map 49 Roboters zu modellieren. Orientierung (bzw. zum Teil eigentlich auch schon Navigation) erfolgt dabei nach Murphy, indem stets nur die Mittelpunkte der einzelnen Teilstrecken als Basis herangezogen werden (unterbrochene Linie im Bild). 50 Meadow-Maps bieten durch diese Vorgehensweise ein paar Vorteile. So fällt der Speicherverbrauch im Vergleich zu Belegungstabellen geringer aus, da eigentlich nach Abschluss der Analyse nur die gefundenen Polygone abgelegt werden müssen. Auch erübrigt sich das Problem der Berücksichtigung kleinster Hindernisse im Datenmodell. Zudem wird der Umstand einer späteren Navigation bereits im Vorfeld berücksichtigt. Problematisch ist jedoch, dass für ihre Initialisierung eigentlich alle topologischen Aspekte der Umgebung schon im Voraus bekannt sein müssten, was bei vielen Szenarien zumeist nicht der Fall ist. Aus diesem Grund kommen sie in der Robotik auch nicht besonders häufig vor. Z Voronoi-Graphen Schlussendlich werden auch gerichtete Voronoi-Graphen (GVGs) zur Erstellung von Karten in der Robotik genutzt. R Dabei wird der passierbare Raum der gesamten Aussenwelt durch eine zentrale Voronoi-Kante beschrieben, deren Konstruktion zuvor aus kleineren Graphen erfolgt. Hierbei ist ähnlich wie bei den Meadow-Maps die Existenz von Hindernissen und Wänden gleichermaßen von Relevanz, da der Abstand zu diesen als primäre Informationsquelle dient. Abbildung 5.36 zeigt exemplarisch die dabei entstehende Repräsentation der Umgebung. Jene Abbildung 5.36.: Konzept einer Voronoi-Map 51 einzelnen Graphen werden hierfür durch Voronoi-Knoten miteinander verbunden und ergeben somit eine Art Netz. Anhand dessen kann dann eine Orientierung bzw. (Selbst-)Lokalisation stattfinden. Die Vorteile dieses Ansatzes sind im Wesentlichen identisch zu denen von Meadow-Maps. Zusätzlich entfällt jedoch die Notwendigkeit, alle Hindernisse und Wände künstlich zu erweitern. 49 Abbildung adaptiert aus [42], S vgl. [42], S Abbildung aus [42], S

82 5. Lösungen des theoretischen Modells Ausserdem können nach Murphy derartige Kartenstrukturen auch in unbekanntem Terrain verwendet werden. 52 Deswegen sind Voronoi-Graphen neben Belegungstabellen öfter in Robotersystemen anzutreffen. So ist beispielsweise [23] eine von vielen Referenzen Referenzarchitekturen Auf Basis dieser Grundbegriffe ist es nun möglich, einige charakteristische Referenzarchitekturen aus dem Forschungsgebiet der Robotik kurz vorzustellen. Sie greifen die eingeführten Konzepte und Ansätze unterschiedlich auf und setzen sie anschließend in verschiedenen Ausprägungen um. Da jene Architekturen sich in ihrer Zusammensetzung zumeist an einem bestimmten Steuerungskonzept orientieren, wird im Folgenden jeweils ein Beispiel für jede Variante gegeben. Deren spezifischer Aufbau, sowie Eigenheiten, werden diesbezüglich näher betrachtet. Prinzipiell eignen sich jedoch alle für die Synthese der Lösungsmuster dieses Kapitels zu einem Gesamtsystem, welches die Idee dieser Arbeit realisiert. Nested Hierarchical Controller Die NHC-Architektur stellt eine Möglichkeit zur Modellierung von Robotersystemen dar, welche einem hierarchischen Steuerungskonzept unterliegen. Entsprechend zu dessen Charakteristika (vgl. Seite 64 f.) ist sie aus unterschiedlichen Komponenten zusammengesetzt, welche in Summe die drei Primitiva der Robotik realisieren. Ihr Aufbau ist in Abbildung 5.37 schematisch dargestellt. Messen Planen Missionsorganisator Navigator Weltmodell/Kontextwissen Pilot Sensor Sensor Sensor Agieren Antrieb Low-level Controller Lenkung Abbildung 5.37.: Nested Hierarchical Controller-Architektur 53 Analog zu der Bearbeitungsreihenfolge der Aufgaben bei Nutzung dieses Paradigmas macht es Sinn, zuerst die für die Messung zuständige Sektion dieser Architektur zu betrachten. Hierbei werden zuerst Daten aus beliebigen Teilen der Sensorik gewonnen und zu einem umfassenden 52 vgl. [42], S Abbildung und Inhalte vgl. [42], S. 54 ff. 70

83 5.2. Lösungen aus der Robotik Weltmodell zusammengesetzt. Als Datenstruktur für dessen Speicherung könnten dazu alle vorgestellten Konzepte (Belegungstabellen, Quadtrees, Meadow Maps und Voronoi-Graphen) zum Einsatz kommen. Sie alle müssen anschließend kontinuierlich per Iteration durch neue Daten aktuell gehalten werden. Alternativ wäre es möglich, im Voraus definierte Karten als Grundlage zu benutzen. Der Planungsaspekt von Robotersystemen wird bei der NHC-Architektur weiterhin durch einen Komplex aus drei unterschiedlichen Subsystemen verkörpert. Diese bearbeiten dabei jeweils ein spezielles Gebiet des gesamten Planungsprimitivums. Die Zerlegung einer komplexen Aufgabe in logisch-lösbare Segmente übernimmt hierbei der sog. Missionsorganisator. Auf Basis des Weltmodells und der Eigenschaften der zugrundeliegenden Hardware erzeugt diese Komponente hierfür atomare Befehle (bzw. einen Missionsplan), welche eine Lösung des jeweiligen Problems unter deren Kontext beschreiben. Beispielsweise ist die Aufgabe, einen Stift in einem anderen Raum aufzuheben, eigentlich zunächst mit einer Navigation, der anschliessenden Fahrt zum Bestimmungsort, der Lokalisation des Zielobjektes und einem letztendlichen Aufhebeprozess verbunden. Derartige Missionen können dabei entweder selbst erzeugt oder von einem Menschen vorgegeben werden. Erwartungsgemäß erfüllt die Komponente des Navigators den Planungsaspekt der Navigation. Hier kommen zumeist Implementierungen der vorgestellten Suchalgorithmen (z. B. Dijkstra, A*, vgl. S. 62 ff.) zum Einsatz. Natürlich ist das Weltmodell des Systems hierfür die wesentliche Datenquelle. Für die Übersetzung der Planungsergebnisse ist weiterhin die Komponente des Pilots zuständig. Dieser führt deren letztendliche Transformation zu einer Befehlskette für die Hardwarekomponenten durch und verwaltet anschließend die Realisierung letzterer. Hierfür sind schlussendlich Komponenten in der NHC-Architektur verantwortlich, die das Primitivum der Aktion darstellen (grüner Bereich in Abbildung 5.37). So hat hier eine Steuerung der jeweiligen Controller, welche passende Befehle an alle Aktuatoren des Systems wie beispielsweise Antrieb und Lenkung senden, zu erfolgen. Eine Eigenheit dieser Architektur liegt in der Tatsache, dass das hierarchische Steuerungskonzept in einigen Punkten erweitert wird. Wie an den Doppelpfeilen in Abbildung 5.37 erkennbar ist, werden bei dieser nämlich alle wesentlichen Komponenten der Messung, Planung und Aktion miteinander vernetzt. Die stetige serielle Schaltung aller drei Primitiva findet daher nur im Hintergrund innerhalb des Missionsorganisators statt. Dadurch entsteht jedoch der Vorteil, dass das System unvorhersehbare Zustände zum Teil selbst beheben kann. Stellt der Pilot beispielsweise ein Problem beim Beschreiten des Weges fest, so könnte er auch das Weltmodell aktualisieren, ohne dass dazu eine neue Iteration (und damit eine neue Sensorabfrage) notwendig ist. Durch die Vernetzung wird somit also tatsächlich auf eine einfache Art künstlich intelligentes Verhalten erzeugt (vgl. Abschnitt 4.2.3, S. 41 ff.). Reaktive Architekturen auf Basis von Subsumption Reaktive Architekturen lassen sich hingegen nur schwer in bestimmte Referenzmodelle zusammenfassen. Stattdessen geht man bei der Modellierung derartiger Systeme von unterschiedlichen Denkansätzen aus, durch welche wesentliche Eigenschaften von Verhaltensorientierung realisiert werden könnten. Nach Murphy existieren hierfür hauptsächlich zwei Varianten: Subsumption 54 und Potenzfelder 55. Abbildung 5.38 zeigt eine Architektur, welche im Kontext des ersten Ansatzes entstanden ist, exemplarisch auf. 54 vgl. [42], S. 113 ff. 55 vgl. [42], S. 122 ff. 71

84 5. Lösungen des theoretischen Modells Vorwärtsbewegung Umherlaufen Richtung Hindernisse vermeiden modif. Richtung Level 1 Level 0 Kraft Kraft auswerten Kraft Wegbewegen + Richtung Lenkung Sonar Polarbild Richtung Werte Kollision Haltesignal Abbildung 5.38.: Beispielhafte subsumptiv-reaktive Architektur 56 Hierbei ist ein Robotersystem modelliert, welches in einem Raum frei umherlaufen und auf Basis von Sonardaten Hindernissen autonom ausweichen soll. Analog zu dem zugrundeliegenden Steuerungskonzept ist dabei die Nutzung von Verhaltensweisen (blau im Bild) natürlich ein zentrales Element. Diese verbinden Sensordaten (lila im Bild) direkt mit passenden weiterführenden Reaktionen bzw. Aktuatoren (rot im Bild). Bei subsumptiv-orientierten Architekturen wird hierfür in verschiedenen Schichten vorgegangen, welche sukzessiv aufeinander aufbauen und dabei immer komplexere bzw. abstraktere Funktionen durch Vernetzung der daran beteiligten Verhaltensweisen realisieren. So bildet die unterste Ebene in Abbildung 5.38 folglich die elementarsten Zusammenhänge für ein derartiges Robotersystem ab. In diesem Fall wird der gegenseitige Einfluss von Sonardaten, Vorwärtsbewegung und Lenkung beschrieben. Hierbei dient das Polarbild des Sonarsensors, welches eine Abstandsbeschreibung aller Hindernisse in dessen Sichtfeld enthält, einerseits für die Richtungsberechnung, andererseits im Falle einer unmittelbar bevorstehenden Kollision jedoch auch zum Stoppen des Gesamtsystems. Zudem dürfen sich Lenkung und Vorwärtsbewegung gegenseitig manipulieren, um beispielsweise bei scharfen Lenkmanövern die Geschwindigkeit dynamisch reduzieren zu können. Entsprechend ist die zielorientierte Verhaltensweise, das Umherlaufen an sich, in der nächsten Schicht der Architektur (Level 1 in Abbildung 5.38) zu finden. Wie bei derartigen Systemen zumeist, kann sie die Ergebnisse bzw. Verhaltensweise der Basisschicht überschreiben und somit ihr spezielles Ziel verwirklichen (in diesem Fall eine spezifische Richtungsvorgabe beim Umherwandern). Genau dieser Prozess macht die wesentliche Eigenschaft subsumptiver Architekturen aus. Das Ergebnis ist dann die Summe beider Richtungen, der entsprechend gefolgt wird. Subsumptiv-reaktive Architekturen besitzen gerade im Hinblick auf die vorgestellten Grundbegriffe eine besondere spezifische Eigenheit. Sie verzichten dabei nach Murphy vollständig auf die Speicherung interner Zustände. 57 Es kommen also keine Kartenstrukturen für die Ablage von Umgebungsdaten zum Einsatz. Stattdessen müssen alle notwendigen Daten immer direkt und unmittelbar aus der Umwelt bezogen werden. Darüber hinaus könnten sich Konflikte zwischen verschiedenen Schichten ergeben. Hierbei gewinnt immer diejenige Schicht, welche die höchste Abstraktionsebene abbildet Abbildung nach [42], S vgl. [42], S. 115, No internal state 58 vgl. [42], S. 115, The solution in subsumption is a type of winner-take-all, where the winner is always the higher layer. 72

85 5.2. Lösungen aus der Robotik Autonomous Robot Architecture (AuRA) Abschliessend soll eine Architektur vorgestellt werden, welche die Nutzung eines hybriden Steuerungskonzeptes präferiert. Abbildung 5.39 zeigt dabei den Aufbau der Autonomous Robot Architecture, welche von Ronald C. Arkin 1987 in seiner Doktorarbeit erstmals öffentlich vorgestellt wurde. 59 Weltmodell Planungsebene Missionsorganisator Kartografie Navigator Pilot Gleichgewichtskontrolle hierarchische Schicht reaktive Schicht Sensorik Verhaltensmanager Motorschemata ps1 ps2 ps1 ps2 + Aktuatoren Sensoren Abbildung 5.39.: Autonomous Robot Architecture 60 Analog zu der Dualität des zugrundeliegenden Paradigmas verwundert es kaum, dass sie aus Kernkomponenten der bereits diskutierten hierarchischen und reaktiven Architekturen konstruiert werden kann. Entsprechend ist sie daher in zwei Schichten einteilbar. Die hierarchische Schicht (lila Hälfte im Bild) gleicht im wesentlichen Aufbau der Nested Hierarchical Controller-Architektur. So ist beispielsweise die Planungsebene, bestehend aus Missionsorganisator, Navigator und Pilot von der Zusammensetzung der Komponenten bzw. deren Aufgabengebiet her absolut gleich. Ebenfalls parallel ist die Verwendung eines Weltmodells für die Repräsentation und Speicherung von Sensordaten aus der Umgebung. Somit gelten für diese Komponenten die gleichen Betrachtungen, welche auf Seite 70 f. angegeben sind. Abweichungen von der NHC-Architektur ergeben sich jedoch spätestens, wenn man die Umsetzung der Primitiva Aktion und Messung betrachtet. Für sie sind in AuRA, entsprechend des hybriden Steuerungskonzepts, nämlich Komponenten reaktiver Systeme verantwortlich. Dies ist darauf zurückzuführen, dass bei dieser Architektur auf eine direkte Ansteuerung der Hardware des Roboters verzichtet wird. Anstatt dessen dient eine Sammlung von festgelegten Verhaltensweisen als wesentliches Werkzeug für die Realisierung. Deswegen spiegeln sich in der 59 vgl. [8], S. 39 ff. bzw. [42], S Abbildung und Inhalte nach [42], S. 265 ff. 73

86 5. Lösungen des theoretischen Modells reaktiven Schicht (blaue Hälfte im Bild) auch dazu gehörige Konzepte wider. So ist es durchaus vorstellbar, dass eine subsumptiv-reaktive Architektur, wie sie beispielsweise auf Seite 71 f. beschrieben wird, als ausführendes Subsystem zum Einsatz kommt. Analog dazu finden sich die hierfür notwendigen Sensor-Aktuator Kopplungen als gestrichelte Linie im Bild. Die Komponente des Verhaltensmanagers beinhaltet dabei alle Abstraktionsebenen und überwacht die Ausführung der durch die Planung zuvor ausgewählten Verhaltenskette(n). Ein kleines Beispiel hilft, das Zusammenspiel zwischen hierarchischer und reaktiver Schicht besser zu verstehen. Angenommen, ein Robotersystem auf Basis der AuRA-Architektur soll in einem geschlossenen Raum unter Berücksichtigung eines speziellen Suchmusters umher wandern. Aus der Sicht der Kartografie liegt zunächst keine bestimmte Information über irgendwelche Hindernisse vor. Demzufolge geht der Navigator von einer einfachen und vollständigen Umsetzbarkeit des Suchmusters aus. Somit weist der Pilot den Verhaltensmanager an, dieses unverändert durch Bewegungsabläufe bzw. Verhaltensweisen zu realisieren. Noch vor einer erneuten Iteration der hierarchischen Schicht können die Verhaltensweisen jedoch autonom sicherstellen, dass der Roboter dabei mit keinem plötzlich zuvor aufgetretenem Hindernis kollidiert. Es werden dazu natürlich Wege eingeschlagen, die ursprünglich nicht vorgesehen waren. Wenige Momente später erhält die hierarchische Schicht dieselben Sensordaten und kommt zu dem Schluss, dass sich der Roboter selbstständig korrigiert haben muss und passt durch entsprechende Neuplanung automatisch das Suchmuster an. Aufgrunddessen kann das Weltmodell somit zeitverzögert aktualisiert werden, ohne jemals Gefahr zu laufen, unbekannten Hindernissen zu begegnen. Die gleichzeitig stattfindende, mehrfache und eigenständige Auswertung von Sensordaten durch alle beteiligten Schichten ist eine spezielle Eigenheit dieser Architektur. Darüber hinaus existiert nach Murphy in manchen Implementierungen eine Art Gleichgewichtskontrolle, welche die Autonomie der Verhaltensweisen beschränken kann (vgl. [42], S. 267). Das ist zum Beispiel dann sinnvoll, wenn aufgrund bestimmter Umstände (z.b. Sensorstörungen) keine unmittelbaren Maßnahmen durch die reaktive Schicht erfolgen dürfen. Anstattdessen kann in diesem Falle ein vorgegebener Plan, wie bei der NHC-Architektur, befolgt werden Grenzbetrachtung: Aldebaran Nao Die in diesem Kapitel gefundenen Lösungsmuster und -ansätze aus der Informatik/Robotik stellen im Folgenden die wesentlichen Bausteine für eine Realisierung des Gesamtkonzeptes bzw. dessen Komponenten an einem beliebigen Robotersystem dar. Im Sinne der Schaffung eines weitgehend unabhängigen Systementwurfs ist dabei (mit Ausnahme der Kinematik) versucht worden, zunächst von keiner bestimmten Referenzplattform auszugehen. Da jedoch der Aldebaran Nao hierfür in dieser Arbeit zum Einsatz kommt, ist es sinnvoll, sich bereits im Vorfeld der Implementierung mit den Eigenheiten und Grenzen seines Systems im Hinblick auf die vorgestellten Praktiken vertraut zu machen. Daher findet nun eine Grenzbetrachtung dieser Plattform statt. Es wird untersucht, inwiefern Hardware, Peripherie bzw. deren jeweilige Konfiguration eine Realisierung jener Lösungsmuster möglicherweise limitieren. Als Basis hierfür werden sowohl Elemente der technischen Spezifikation (vgl. Abschnitt 2.2, ab Seite 11) als auch persönliche Beobachtungen, die während der Einarbeitung in das System gemacht wurden, herangezogen. Auf diese Art und Weise können die dabei resultierenden Probleme und Erkenntnisse bereits im Voraus identifiziert und ihre Auswirkung auf eine prototypische Implementierung des Gesamtkonzeptes dieser Arbeit berücksichtigt werden. Dadurch ist es möglich, abschliessend dessen Machbarkeit am Aldebaran Nao zu klären. 74

87 5.3. Grenzbetrachtung: Aldebaran Nao Rechenleistung Die wesentlichsten Limitationen ergeben sich allein schon durch die Hardware des Gesamtsystems, welche in Abschnitt 2.2.6, Seite 16 f. vorgestellt wurde. Hierbei sind die CPU und die Größe des Arbeitsspeichers des Nao Academics Edition H25 V3.3 als hauptsächliche Gründe zu nennen. Der AMD GEODE x86-prozessor, welcher mit einer Taktung von 500 MHz sowohl das Linux-Betriebssystem als auch die Steuerungssoftware NaoQI (vgl. Abschnitt 6.1, S. 81 ff.), als zentrales Element steuert, ist im Kontext derzeitig moderner Technologie im mobilen Sektor als eher unterdimensioniert einzustufen. Dies ergibt sich alleine schon aus der Tatsache, dass er nur über einen einzigen physikalischen Rechenkern verfügt. Zudem sorgt eine maximale Cachegröße von 128 kbyte für viele Speicherzugriffe Abbildung 5.40.: Geodeim System, was die Effizienz in einigen Szenarien ebenfalls negativ CPU 61 beeinflussen kann. Da die letzte Revision dieser Prozessorfamilie im Jahre 2005 stattfand, ist all das kaum überraschend. Im Hinblick auf die vorgestellten Lösungskonzepte lassen sich schon jetzt einige Probleme erahnen. Da schon beim Ruhezustand des Robotersystems, bei dem nur das Linux-Basissystem und NaoQI wirklich aktiv Leistung beziehen, im Schnitt etwa 23 bis 40 Prozent CPU-Last anliegen, müssen eigene Programme und verwendete Bibliotheken äusserst CPU-schonend programmiert sein. Dies liegt in der Tatsache begründet, dass im Falle der Volllast ein stabiles Verhalten des Roboters nicht mehr garantiert werden kann. 62 Es könnte also passieren, dass er mitten im Gang zusammenbricht und das Gesamtsystem dadurch Schaden erleidet. Deswegen müssen traditionell CPU-intensive Aufgaben bereits im Vorfeld vermieden werden. So sind entsprechend rechenaufwändige Ansätze für die Verarbeitung optischer Eindrücke von vornherein auszuschließen bzw. intelligent zu minimieren. Auch die Emulation bzw. häufige Verwendung von Multithreading, beispielsweise für die Implementierung gleichzeitig ablaufender Verhaltensweisen reaktiver Architekturen (vgl. S. 71 f.), ist eher nicht zu empfehlen. Das hierfür notwendige Scheduling kann dabei wichtige Teile das Nao-Gesamtsystems überfordern und ebenfalls die Instabilität des NaoQI zur Folge haben (s. o.). Der verbaute Arbeitsspeicher stellt mit einer fixen Größe von 256 MByte in Anbetracht dieser Probleme ebenfalls einen potentiellen Flaschenhals dar. Vor allem da bei einer Systempartition von 2 GByte kein Swap für die virtuelle Erweiterung des Speichers auf dem USB-Stick mehr angelegt werden kann. Da, natürlich aufgrund seiner Komplexität, das NaoQI-Steuersystem bereits einen Großteil des RAM nutzt, dürfen weiterhin eigene Programme auch nicht zu sehr speicheraufwändig sein. Insbesondere oft vorkommende Fehler, wie z. B. Memory Leaks, müssen auf jeden Fall vollständig gemieden werden. Als erfahrungsgemäß besonders problematisch erweist sich an dieser Stelle erneut die Realisierung von Lösungskonzepten aus der Bildverarbeitung. Da deren Effizienz zumeist extrem von der Auflösung der zugrundeliegenden Quelldaten abhängt (doppelte Auflösung = quadratischwachsender Speicherverbrauch), ergibt sich dabei schnell Speicherknappheit. Auch bei der Umsetzung anderer Lösungsmuster muss auf diese Eigenheit des Aldebaran Nao Rücksicht genommen werden. So sollten u. a. beispielsweise bei der Implementierung von Interkommunikation nur minimalste Datenmengen zum Einsatz kommen bzw. versendet werden. 61 Abbildung und Hintergrundinformationen aus [1] 62 Anm. Das für das Laufen zuständige Modul ist sehr CPU intensiv und kann bei Aushungerung fehlerhaft arbeiten. vgl. dazu auch [5], Abschnitt Reference, NAOqi API, NAOqi Motion. Dort wird dazu eine Echtzeitanforderung von 20ms spezifiziert. 75

88 5. Lösungen des theoretischen Modells Optik Ein weiterer Anlass für mögliche Limitationen ergibt sich aus dem optischen Subsystem des Aldebaran Nao Academics Edition H25 V3.3, welches in Abschnitt 2.2.5, Seite 15 ff. beschrieben wurde. Hierfür sind insbesondere die Leistungsfähigkeit und die Konfiguration der Kameras verantwortlich. So ist deren Auflösung mit maximal 640x480 Bildpunkten (0,3 Megapixel) aus heutiger Sicht nur relativ gering. Insbesondere, wenn man andere mobile Geräte, wie beispielsweise das Apple iphone, welches nach derzeitigem Stand Bilder mit bis zu 5 Megapixeln erzeugen kann, als vergleichbaren Maßstab heranzieht. Weiterhin sind die vom Nao erzeugten Bilder generell von typischen Eigenschaften bzw. Fehlern preisgünstiger Webcams geplagt. So kommt auch bei diesem Roboter erfahrungsgemäß ein Kameraaufbau zum Einsatz, welcher radiale und tangentiale Störungen Abbildung 5.41.: Bild aus gleichermaßen verursacht. Dies liegt vor allem an der Ver- Nao-Cam wendung einer Linse mit fester Brennweite und einer nicht exakten Ausrichtung des CCD- Sensors. Das Ergebnis sind leicht optisch-verschobene Bilder, die zudem über eine gewisse Unschärfe verfügen (vgl. Abbildung 5.41). Ausserdem hat sich gezeigt, dass eine Aufnahme von Bildern mit maximaler Auflösung und Abfragefrequenz durch NaoQI zu einer starken Latenz aufgrund der damit verbundenen hohen CPU-Auslastung führt. Im Kontext der für dieses Gebiet maßgeblichen Lösungskonzepte bzw. -muster ergeben sich aus derartigen Eigenheiten diverse Schwierigkeiten bei deren Implementierung am Nao. Die eingeführten Vorgehensweisen zur Extraktion von Merkmalen aus einem Bild können z. B. durch Unschärfe bzw. Bildrauschen teilweise massiv gestört werden und somit falsche Ergebnisse erzeugen. Es wird daher notwendig sein, die erhaltenen Daten entsprechend entweder im Vorfeld zu filtern oder einen daraufhin robusten Algorithmus zu verwenden. Da die Auflösung und Abtastrate zugunsten des CPU-Verbrauchs minimiert werden müssen, ist weiterhin die gesamte Grafikverarbeitung an anderer Stelle anzupassen. Hierbei könnte beispielsweise eine Skalierung zum Einsatz kommen, welche jedoch auch nur möglichst wenig Leistung erfordern darf. Durch das verzerrte Bild wird ausserdem die Distanzmessung nach dem Pinhole-Kameramodell verfälscht. Aus diesem Grund muss daher zusätzlich eine Lösung gefunden werden, welche die dafür verantwortlichen Effekte bestmöglich eliminiert. (a) Bild der oberen Kamera (b) Bild der unteren Kamera Abbildung 5.42.: Gleichzeitige Aufnahme einer Szene mit beiden Kameras Eine besonders ärgerliche Limitation in puncto Optik ergibt sich weiterhin aus der Konfiguration der beiden Kameras im Kopf des Roboters. Da sich, wie bereits in Abbildung 2.13 (Seite 76

89 5.3. Grenzbetrachtung: Aldebaran Nao 16) dargestellt, deren Blickwinkel nicht überschneiden, ist die Nutzung eines stereoskopischen Kameramodells entsprechend auch nicht möglich. Diese Tatsache wurde während der Einarbeitung in das System getestet. Zu diesem Zweck ist aus einer sitzenden Position heraus jeweils ein Bild aus der oberen bzw. unteren Kamera nacheinander aufgenommen worden. Die dabei entstandenen Resultate sind in den Abbildungen 5.42a und 5.42b zu sehen. Da die untere Kamera quasi vollständig nur den Fuß- bzw. Bodenbereich erfasst, kann keinesfalls eine Überschneidung der beiden Kamerabilder, nicht einmal im Unendlichen, vorliegen. Deshalb ist weder die Errechnung eines Disparitätsbildes noch die empirische Abschätzung der Distanz zu einem Objekt aus diesem möglich. Für eine Implementierung am Aldebaran Nao bleibt daher dafür nur die Nutzung simpler geometrischer Zusammenhänge als Kompromisslösung übrig Kinematik Als ähnlich einschneidend stellen sich auch Eigenheiten bei der Nutzung des Fortbewegungssystems dieser Roboterplattform heraus. Limitationen ergeben sich dabei durch die komplexe Problematik des humanoiden Laufens sowohl in Hardware (vgl. Abschnitt 2.2.3, Seite 14 ff.) als auch der dafür verwendeten Vorgehensweise (vgl. Abschnitt 5.1.3, Seite 58 ff.). Abbildung 5.43 zeigt das daraus entstehende Problem schematisch und beispielhaft auf. y (in m) 1,0 0,5 Pfad (1,0,0) 0 0,5 1,0 x (in m) Abbildung 5.43.: Ungenauigkeit des Fortbewegungssystems bei eindeutigen Koordinaten Demnach arbeitet das Fortbewegungssystem des Aldebaran Nao AE H25 V3.3 nicht exakt und zuverlässig genug, um ein vorgegebenes Ziel im Bezugsraum mit hoher Wahrscheinlichkeit wiederholbar deterministisch zu erreichen. Viel mehr unterliegt das zielorientierte Laufen einer gewissen Unvorhersehbarkeit, welche mit reinen Bordmitteln des Systems nicht gelöst werden kann. So führt erfahrungsgemäß der Befehl, in x-richtung 1 Meter voranzuschreiten, bei jeder Ausführung zu einem unterschiedlichen Ergebnis. In seltenen Fällen wird dabei tatsächlich der gewünschte Pfad (grüner Pfeil in Abbildung 5.43) beschritten. Wesentlich häufiger sind ähnliche (orangene Pfeile in Abbildung 5.43) oder gar völlig wirre Wege (rote Pfeile in Abbildung 5.43) als Resultat vorzufinden. Vor allem ist jedoch die Unkenntnis darüber, welche Position vom Roboter nach einer fehlgeschlagenen bzw. falschen Bewegung im Bezugsraum nun tatsächlich eingenommen wird, ein schwerwiegendes Problem. 77

90 5. Lösungen des theoretischen Modells An diesem Verhalten sind grundsätzlich mehrere Faktoren schuld. So werden einerseits die Eigenschaften unterschiedlicher Bodenbeschaffenheiten (Teppich, PVC-Belag etc.) nicht bei der Kontrolle des Bewegungsmodells seitens des NaoQI-Systems berücksichtigt. Andererseits ist bei einer Beobachtung des Systemverhaltens erkennbar, dass der Schwerpunkt des Roboters mit fortschreitender Laufzeit der Gehbewegungen zunehmend instabil wird, was eine stetig anwachsende Schwingung des gesamten Torsos zur Folge hat. Dies lässt darauf schließen, dass es noch Probleme bei der Umsetzung des humanoiden Laufens an sich am Aldebaran Nao gibt, was sich bei einer kurzen Recherche dazu passender Arbeiten ([24], [27]) als ein eigenes Forschungsgebiet der Robotik herauskristallisiert. Das Laufmodell ist diesbezüglich jedenfalls noch lange nicht perfekt. Im Hinblick auf die in diesem Kapitel vorgestellten Lösungsmuster und -konzepte und der späteren Implementierung ergibt sich das Problem der Kompensation dieses Verhaltens und der daraus resultierenden Limitationen. Ob der komplexen Natur des zugrundeliegenden Fortbewegungssystems können dabei jedoch nur externe Maßnahmen ergriffen werden. So käme beispielsweise in Frage, die Schrittgeschwindigkeit des Roboters so zu verlangsamen, dass das Schwanken des Körpers nicht oder nur kaum eintritt. Eine andere viel diskutierte Möglichkeit besteht in einer fortwährenden Reorientierung des Roboters anhand fester oder variabler Fixpunkte, wobei dies im Falle der Vermeidung von individuellen Gefahrensituationen als zunächst nur schwer umsetzbar erscheint. Für eine Implementierung muss daher ein passender Kompromiss gefunden werden Akustik Auch das akustische Subsystem des Aldebaran Nao, dessen Spezifikation in Abschnitt (S. 15 ff.) eingeführt wurde, bringt gewisse Limitationen mit sich. Vornehmlich basieren sie auf der Konfiguration der verwendeten Mikrofone und den Sonarsensoren. Die Mikrofone des Aldebaran Nao, welche sich allesamt im Kopf des Roboters befinden, sind beispielsweise aus heutiger Sicht nur von einfachster Bauart. Da sie weder über Rauschunterdrückung, noch über eine gute Abschirmung vom Rest des Robotersystems verfügen, kann man sie maximal mit den Mikrofonen einfacher Headsets gleichsetzen. Es werden also sämtliche Störgeräusche, welche durch den Betrieb des Systems entstehen, mit aufgezeichnet. Auch eine Filterung von Halleffekten, wie sie in großen, leeren Räumen entstehen können, muss manuell geschehen. Diese Eigenheiten limitieren im Hinblick auf die Erkenntnisse dieses Kapitels insbesondere Aspekte und Lösungsansätze der Spracherkennung. Da sie erfahrungsgemäß gegen derartige Störungen nur schwer bestehen können, müssen letztere bei der Implementierung entsprechend minimiert werden. Dabei hilft in diesem Fall eigentlich nur die Veränderung des Szenarios. So besteht die Möglichkeit, Spracherkennung nur dann zu erlauben, wenn der Roboter gerade still steht. Ausserdem sollte der Sprecher für ein optimales Ergebnis zumeist immer neben dem Nao verweilen. Weiterhin liefern die Sonarsensoren des Nao nicht immer einen eindeutigen mittleren Abstandswert zu einem Hindernis, welches vor dem Roboter positioniert wurde. Das liegt an ihrer Lage in der Brust des Nao, welche sich nach Abbildung 2.14 (Seite 16) jeweils in der linken bzw. rechten Körperhälfte befinden. Steht der Roboter beispielsweise durch eine falsche Bewegung des Laufsystems derart schief vor einem Hindernis, sodass die Messachse eines Sensors an diesem vorbei verläuft, entstehen falsche Messwerte. Ein Abgleich der unterschiedlichen Daten wird dabei nicht automatisch vom NaoQI-Steuersystem vorgenommen. 78

91 5.3. Grenzbetrachtung: Aldebaran Nao Diese Eigenheit limitiert jedoch nur in einem kleinen Maß das Lösungsprinzip zur Abstandsmessung und stellt daher ein minimales Problem dar. Zur Lösung müssen einfach die separaten Messwerte der einzelnen Sensoren zusätzlich individuell überwacht werden Fazit: Machbarkeit Die Hardware, Peripherie bzw. deren jeweilige Konfiguration des Aldebaran Nao bringen Tatsache eine Vielzahl an Limitationen mit sich, die die Umsetzung der in diesem Kapitel eingeführten Lösungsansätze zum Teil entscheidend erschweren. Insbesondere stellen die minimalistische Hardware und das instabile Laufmodell des Roboters die größten Hürden dar. Prinzipiell kann man jedoch feststellen, dass sich grundsätzlich das Gesamtkonzept dieser Arbeit am Aldebaran Nao implementieren lassen sollte, solange man für die Grenzen des Systems gute Kompromisse in Form von Annäherungslösungen oder geschickten Umgebungsbedingungen findet. Die Machbarkeit ist somit also gegeben. 79

92

93 6. Prototypische Implementierung Mit der Kenntnis der Lösungsansätze und -muster aus Kapitel 5 kann eine prototypische Implementierung des Gesamtkonzeptes, welches die Ziele der Spezifikation (vgl. Abschnitt 3.2, S. 20 f.) gemäß deren Analyse (vgl. Kapitel 4, ab S. 31) umsetzt, an einem realen, exemplarischen Robotersystem durchgeführt werden. Sie bildet den Schwerpunkt dieses Kapitels. Als Vorlage für die Realisierung dient dazu natürlich insbesondere das theoretische Systemmodell, welches auf Seite 45, Abschnitt 4.3, diskutiert wurde. Da im Zuge dessen ein Softwaressystem für den Aldebaran Nao entstehen soll, ist es sinnvoll, zunächst die mitgelieferte Entwicklungsumgebung das NaoQI-SDK einzuführen und deren Eigenschaften näher zu betrachten. Abschnitt 6.1 beinhaltet dazu eine Evaluation dieses Frameworks. Zunächst sind hier sowohl Grundlagen, wie dessen Hintergrund, Umfang und Aufbau als auch Programmbeispiele, welche seine Nutzung verdeutlichen, zentrale Themen. Eine kurze Untersuchung, welche Komponenten aus diesem dabei am besten mit den in Kapitel 5 vorgestellten Ansätzen für die Umsetzung korrespondieren, findet anschliessend in Abschnitt (S. 93 ff.) statt. Sollten für einige Aspekte des Gesamtkonzepts möglicherweise keine guten Äquivalenzen in NaoQI vorliegen, so sind dazu passende Alternativen abschliessend in Abschnitt (ab S. 95) angegeben. Für die Implementierung muss das theoretische Modell natürlich weiter konkretisiert werden. Der Transfer in ein umfassendes Softwaremodell, welches sowohl Erkenntnisse und Lösungsmuster aus Informatik und Robotik als auch systemspezifische Eigenschaften/Beschränkungen des NaoQI-SDK bzw. des Roboters selbst berücksichtigt und miteinander vereint, wird hierfür in Abschnitt 6.2 (S. 96) vorgenommen. Dazu werden jeweils die vielversprechendsten Praktiken aus Kapitel 5 herangezogen. Das dadurch entstehende Ergebnis ist im Folgenden die Richtlinie für die Realisierung des Gesamtkonzeptes am Roboter. Diese wird detailliert ab Seite 101 (Abschnitt 6.3) beschrieben. Hierbei steht die konkrete Ausgestaltung der einzelnen Komponenten des Softwaremodells im Brennpunkt. So werden sowohl versuchte als auch die letztendlich verwendeten Lösungskonzepte anhand exemplarischer Codefragmente aufgezeigt und erläutert. Ausserdem werden alle relevanten Abläufe und Prozesse geklärt. Weiterhin wird auch auf die Kompromisslösungen eingegangen, welche durch die Limitationen des zugrundeliegenden Robotersystems notwendig geworden sind. Schlussendlich muss für eine Implementierung das auf diese Weise erzeugte System im Roboter zur Ausführung gebracht werden. Die hierfür notwendigen Maßnahmen, welche das Deployment der einzelnen Module in NaoQI umfassen, sind im Abschnitt 6.4 (S. 153) dargestellt und runden das Kapitel somit ab Evaluation des NaoQI-SDK Das NaoQI-Framework, welches parallel seit den ersten Prototypen des Nao (ca. ab 2005) seitens Aldebaran Robotics kontinuierlich weiterentwickelt wird, liegt standardmäßig allen verkauften Robotern der Serie unabhängig von Version bzw. Modell als vorinstalliertes Softwarepaket bei. Es 81

94 6. Prototypische Implementierung stellt das grundlegende Steuerungssystem dar, welches jede Funktion des Roboters zentral abbildet, verwaltet und das Gesamtsystem während dessen Nutzung stetig überwacht. Daher wird es auch bei jedem Einschaltvorgang automatisch gestartet und residiert bis zur Beendigung seitens des Benutzers (durch Herunterfahren/Kill) als Daemon im Speicher des Linux-Betriebssystems. Abbildung 6.1 zeigt exemplarisch auf, welche Aspekte und Aufgaben des Robotersystems hierbei von NaoQI besonders detailliert behandelt werden. Systemintegrität Kommunikation Kameras Motorik Speicher/ Threads NaoQI- Framework Systemzustand Soundsystem Sonar Abbildung 6.1.: Exemplarischer Funktionsumfang des NaoQI-Frameworks Demnach sind sowohl systemspezifische Elemente (wie z. B. die Nutzung der Motorik bzw. des bipedalen Fortbewegungssystems als Komplex) als auch die Hardwareabstraktion (Kamera, Sonar, Speicher) in Form von Subsystemen in dessen Funktionsumfang mit einbegriffen. Darüber hinaus stellt NaoQI umfassende Schnittstellen zu diesen bereit, was die Entwicklung eigener Software für den Roboter ermöglichen soll. Somit kann es als eine Art Metabetriebssystem bzw. Entwicklungsplattform gesehen werden, welches roboterspezifische Aspekte des Gesamtsystems weitgehend anwenderfreundlich abbilden will. Zudem sind neben einer aktuellen Linux-Distribution auch weitere Entwicklungswerkzeuge teil von NaoQI. So sind die offenen und weit verbreiteten Bibliotheken Boost (u. a. für effiziente Speicherverwaltung) und OpenCV (für computergestützte Bildverarbeitung) ebenfalls feste Bestandteile, welche mit jeder neuen Version aktualisiert werden. Updates geschehen zumeist in einem Halbjahreszyklus und umfassen oftmals auch die Überarbeitung der Systemschnittstellen. Als Referenzversion dieser Arbeit dient NaoQI V , welche im Juni 2012 erschienen ist. Obwohl auch viele andere derartige Systeme/Frameworks im Umfeld der Robotik existieren (z. B. ROS 1 ), ist NaoQI im Vergleich zu diesen zweifelsohne das mit der bestmöglichen Unterstützung für die Komponenten des Aldebaran Nao. Beispielsweise muss daher auch bei der Nutzung von ROS zum Teil auf die Methoden jenes Frameworks zurückgegriffen werden. 2 Auch allein wegen dieses Hintergrunds ist daher bei der prototypischen Implementierung auf dessen Fähigkeiten aufzubauen. Schlussendlich ist jedoch die weite Verbreitung des NaoQI-Frameworks in zahlreichen Projekten der ausschlaggebende Faktor für dessen Verwendung. Daher ist es notwendig, seinen Funktionsumfang bzw. seine Nutzung weiterführend in einer Evaluation zu klären. 1 Robot Operating System: Ein unabhängiges Roboterbetriebssystem, welches 2007 an der Universität Stanford ins Leben gerufen wurde. 2 vgl. [2] 82

95 6.1. Evaluation des NaoQI-SDK Aufbau und Nutzung Im Rahmen dieser Evaluation wird daher zunächst der Aufbau und die Nutzung des NaoQI- Systems näher betrachtet. Aufbau Die systeminterne Implementierung des Funktionsumfangs und die Bereitstellung von Schnittstellen zur Entwicklung eigener Projekte wird in NaoQI gleichermaßen über eine spezielle Systemarchitektur gelöst. Abbildung 6.2 zeigt sie schematisch auf. NaoQI-Prozess Proxys NaoQI-Bibliotheken: libalbase.so NaoQI-Module: Main Broker bonjour = nao.local ip = port = 9559 executable = $AL_DIR/bin/naoqi ALPreferences ALLogger ALMemory NaoQI-Methoden: - insertdata( ) - getdata( ) - raiseevent( ) libalxxx.so ALVideoDevice ALMotion ALSonar ALTextToSpeech ALLeds Low-Level Controller / Hardware Abbildung 6.2.: Aufbau des NaoQI-Frameworks 3 Das hierbei vorrangig tragende Konzept ist die Verwendung von unabhängigen Programmmodulen, welche jeweils einen ganz speziellen Teil des gesamten Robotersystems realisieren. Einige wichtige davon sind beispielhaft durch die weißen Ellipsen in Abbildung 6.2 dargestellt. So wird die Speicherverwaltung des Frameworks beispielsweise durch das Modul ALMemory implementiert. Tatsächlich sind sämtliche Funktionen des Systems durch derartige Bausteine in NaoQI repräsentiert. Seitens Aldebaran Robotics ist dabei eine umfassende Bibliothek an Modulen, welche Funktionen wie Sprachsynthese oder die Steuerung der LEDs implementieren, standardmäßig beigefügt. Auf diese Art und Weise wird vermieden, dass ein Programmierer auf Low-Level-Controller und Hardware direkt zugreifen muss. Module ähnlicher Art sind weiterhin in NaoQI zumeist in dynamischen Bibliotheken zusammengefasst, welche allesamt beim Start des Systems automatisch geladen werden. Ein Modul ist grundsätzlich in etwa mit einer Klasse einer beliebigen objektorientierten Programmiersprache, wie etwa C++, vergleichbar. Entsprechend kapseln Module in NaoQI anwen- 3 Bestandteile der Grafik bzw. Konzepte aus [5], Abschnitt Programming, Programming Guide, NAOqi 83

96 6. Prototypische Implementierung dungsspezifische Nutzdaten und dazu passende Operationen bzw. Methoden zunächst in einer uniformen Datenstruktur. Darüber hinaus müssen sog. ALModules jedoch diejenigen Methoden, welche frei genutzt werden dürfen, eindeutig durch deren Bindung an eine Servicedefinition deklarieren (vgl. NaoQI-Methoden von ALMemory in Abbildung 6.2). Dies ist darauf zurückzuführen, dass für deren Veröffentlichung im System ein Vorgehen genutzt wird, welches im Wesentlichen einem sog. Enterprise Service Bus gleicht. Hierbei hängen alle Module an einem Kommunikationsbus beliebiger Art und stellen ihre jeweiligen Dienste (klassifiziert durch die zuvor gebundenen Funktionen) untereinander zur Verfügung. Dafür tauschen sie auf dem Bus untereinander Nachrichten aus, welche die Ausführung der jeweiligen Methoden bestimmter Module zur Folge haben. Dieses Designprinzip zieht sich im Folgenden durch das gesamte NaoQI-System. Alle Module hängen daher an einer zentralen Verwaltungsinstanz und Kommunizieren auf Basis von TCP/IP und XML-Datenstrukturen. Innerhalb eines NaoQI-Prozesses (und damit im Linux-System des Roboters) wird diese Aufgabe durch den Main-Broker (grüner Block in Abbildung 6.2) wahrgenommen. Er wird beim Start des Frameworks als Erster initialisiert und dient als Anmeldepunkt für alle darauf hin geladenen Module des Systems. Darüber hinaus stellt er die einzige Kommunikationsmöglichkeit nach aussen dar, da er einen TCP-Port öffnet. Für eine Implementierung wird es daher auf jeden Fall wichtig und notwendig sein, über den Broker auf die bereits vorhandenen Module des Frameworks zugreifen zu können. Im Regelfall werden dazu Proxies verwendet, welche sich clientseitig an der zentralen Verwaltungsinstanz anmelden. Anschließend können sie unter Berücksichtigung der Funktionsweise des Service Bus ebenso Daten und Funktionen des Systems nutzen bzw. manipulieren. Nutzung Analog zum Aufbau des NaoQI-Frameworks können eigene Programme somit also nur in Form von einem bzw. mehreren spezialisierten Modulen in das System eingebracht werden. Sie stellen daher zum Großteil auch die Clients dar, welche sich über den Main-Broker durch einen Proxy mit dem Metabetriebssystem verbinden. Programm A (Module) Programm B (Module) Programm C (Module) Client Proxy A Proxys Main Broker bonjour = nao.local ip = port = 9559 executable = $AL_DIR/bin/naoqi Abbildung 6.3.: Anmeldung von mehreren Clients am NaoQI-Framework Für die Programmierung eigener Module stehen seitens Aldebaran Robotics grundsätzlich zwei unterschiedliche Konzepte zur Verfügung. Diese können wie folgt unterschieden werden: 1. graphische Programmierung mit Aldebaran Choregraphe 2. direkte Programmierung mittels einer unterstützten Programmiersprache 84

97 6.1. Evaluation des NaoQI-SDK Da ihre jeweilige Anwendung stark vom Kontext der Anforderungen eines eigenen Projektes abhängt, werden deshalb beide Ansätze im Rahmen der Evaluation betrachtet. Graphische Programmierung mit Aldebaran Choregraphe Der simpelste Weg für die Kreation eigener Module auf Basis des NaoQI-Frameworks besteht in der Verwendung der Aldebaran Choregraphe Entwicklungsumgebung. Sie ist, neben dem Framework selbst, standardmäßig bei jedem Roboter Teil des Lieferumfangs und erlaubt eine visuell-anschauliche Programmierung bzw. Nutzung der Komponenten des Robotersystems. Ihre Bedienoberfläche und ein darin erstelltes Beispielprogramm sind in Abbildung 6.4 exemplarisch dargestellt. Abbildung 6.4.: Entwicklungsumgebung Aldebaran Choregraphe mit Beispielprojekt Die dadurch angefertigten Programme folgen dabei einem Prinzip, welches sich an einfachen Flussdiagrammen orientiert. So werden die einzelnen Module des NaoQI-Frameworks, welche durch Boxen repräsentiert sind, miteinander über Graphen verbunden, welche ihren gegenseitigen Start und Stopp sowie die Übertragung einfacher Zustandsdaten symbolisieren bzw. modellieren. Darüber hinaus existieren in Choregraphe auch Konstrukte für die Manipulation des Programmflusses, wie beispielsweise Schleifen und Bedingungen. Weiterhin sind mehrfache Funktionsverknüpfungen durchaus möglich. Derartige Module müssen dabei immer einen definierten Start- und Endpunkt durchschreiten. Bei der Ausführung des Programms in Abbildung 6.4 wird daher eine Art Startsignal an den ersten NaoQI-Systembefehl, welcher ein Aufstehen des Roboters implementiert, gesendet. Da dessen Outputs jeweils Meldungen über den Erfolg bzw. Misserfolg der Aktion sind, können anhand dieser weitere Module (wie etwa das Laufen bzw. die Aktivierung des Sonars) gestartet werden. Wird der Laufprozess beendet, weil entweder ein vorgegebenes Ziel erreicht oder ein niedriger Abstandswert aus der Sonarsensorik die Stimulation des Stop-Eingangs zur Folge hatte, ist es möglich, den Roboter anschließend wieder in Sitzstellung zu bringen. Sobald sie vorliegt, kann daraufhin der Endpunkt aktiviert und das Programm beendet werden. 85

98 6. Prototypische Implementierung In der Begriffswelt von Choregraphe handelt es sich bei dergleichen Programmen um sog. Verhaltensweisen. Einmal in den Speicher des Roboters hochgeladen, können sie bei Bedarf wie ein Musikstück abgespielt werden. Dabei verwenden sie einen systeminternen Proxy zum Main- Broker des Frameworks. Da sie auch genutzt werden können um Sensor-Aktuator Kopplungen zu erzeugen, sind sie gewiss bewusst ähnlich zum passenden Steuerungskonzept in der Robotik (vgl. Abschnitt 5.2.1, Seite 65 f.) benannt worden. Die Programmierung entsprechender Architekturen fällt daher teilweise in den Anwendungsbereich von Choregraphe. Trotz des Arguments der Simplizität wird der Gebrauch von Choregraphe durch einen starken Nachteil getrübt. Er begründet sich in der Tatsache, dass nur und ausschließlich vorgefertigte Module des NaoQI-Frameworks bei der Kreation eines eigenen Programms zur Verfügung stehen. Obwohl zwar die Möglichkeit besteht, diese durch die Modifikation weniger Parameter zu verändern, so ist es aufgrund der fehlenden Flexibilität auf Implementierungsebene nicht wirklich möglich, eigene Ansätze (z. B. für eine optimierte Bilderkennung) einzubringen. Gerade im Hinblick auf die Komplexität des Gesamtkonzeptes muss daher mit hoher Wahrscheinlichkeit auf die ausschließliche Nutzung von Choregraphe verzichtet werden. Direkte Programmierung mit NaoQI Ein anderer Weg für die Implementierung eigener Module besteht in deren direkten Programmierung auf Basis der Vorgaben und Spezifikationen des NaoQI-Frameworks. Zu diesem Zweck bietet das Entwicklungssystem eine Vielzahl von Toolchains für Kompilierung/- Debugging, sowie Schnittstellen an, welche die Nutzung vieler verschiedener Programmiersprachen ermöglichen. Seitens Aldebaran Robotics werden dabei alle weit verbreiteten Varianten und Betriebssysteme (Windows/Linux/Mac OS X) durch NaoQI unterstützt. Module können daher grundsätzlich in den folgenden Sprachen verfasst sein: C++ Python 2.x Java C# F# Urbi Visual Basic Matlab Man sollte jedoch berücksichtigen, dass nur die ersten beiden davon komplett durch NaoQI abgedeckt und deren jeweilige Bindungen im Entwicklungssystem regelmäßig bei Updates aktualisiert werden. Aus diesem Grund beschränkt sich die Evaluation und spätere prototypische Implementierung auf eben jene Programmiersprachen. Bei der direkten Programmierung von Modulen mit NaoQI existieren darüber hinaus verschiedene Paradigmen, welche sich je nach Verwendungszweck unterschiedlich für eine Implementierung eigener Ideen eignen. Hierbei sind vor allem Geschwindigkeit, Stabilität und Komplexität des zu erzeugenden Systems entscheidende Faktoren. In puncto Geschwindigkeit steht es beispielsweise dem Programmierer grundsätzlich frei, sein Modul entweder durch die CPU des Roboters oder durch den (wesentlich schnelleren) Prozessor seines Computers lokal ausführen zu lassen. Aspekte der Stabilität und Komplexität hingegen werden durch eine entsprechende Positionierung 86

99 6.1. Evaluation des NaoQI-SDK seines Moduls im NaoQI des Robotersystems bzw. durch erweiterte Brokerkonzepte und somit also auf Busebene abgedeckt. Diese Wahlfreiheit bezüglich Ausführung und Deployment entsteht aus der Tatsache heraus, dass jedes Paradigma bei der direkten Programmierung von NaoQI-Modulen stets auf Fähigkeiten zur Interkommunikation im Service Bus zurückgreifen kann. Auch dabei ist der Main-Broker des NaoQI die entscheidende Instanz, welche die Interaktion zwischen internen und externen Modulen regelt. Solange also die Kommunikationspartner auf dem Bus bekannt sind, spielt es keine Rolle, wo eine Funktion gerade wirklich läuft. Auf diese Art und Weise wird erzielt, dass beispielsweise ein Programm, welches mit der Mac-Version von NaoQI kompiliert wurde, eigenständig mit dem Main-Broker im NaoQI des Roboters über ein Netzwerk kommuniziert um den Roboter zu steuern. Aufgrund dieser Diversität bei der direkten Programmierung werden Aspekte der Nutzung bzw. Eigenschaften der jeweiligen Paradigmen im Rahmen der Evaluation dargestellt. Client-Proxy Programmierung Das simpelste Paradigma für die direkte Programmierung eigener Programme zur Steuerung des Roboters ergibt sich schlicht in der Nutzung eines Client-Proxy-Modells, welches in Abbildung 6.5 schematisch dargestellt ist. NaoQI-Prozess im Roboter: NaoQI-Framework im Computer: Main Broker bonjour = nao.local ip = port = 9559 Client-Verbindung Main Broker bonjour = pc.local ip = port = 9559 NaoQI-Bibliotheken: libalxxx.so NaoQI-Bibliotheken: libalxxx.so ALTextToSpeech NaoQI-Methoden ALProxy say() say() Low-Level Controller / Hardware Einfaches Benutzerprogramm (kein Modul!) Abbildung 6.5.: Direkte Programmierung durch Client-Proxy Paradigma Hierbei ist es nicht erforderlich, Module im eigentlichen Sinne von NaoQI zu entwickeln. Viel mehr werden dabei in beliebigen Programmen einfach Elemente eines lokal installierten NaoQI- Frameworks inkludiert und dessen Implementierung genutzt, um über eine Clientverbindung direkt Methoden aus Modulen innerhalb des Roboters auszuführen. Dazu erfolgt eine Weitergabe von Eigenschaften, Verhalten und Funktionen der jeweilig realen Modulinstanz durch eine stellvertretende Proxyklasse über den Service-Bus an den Client. Dieser ruft dann die jeweiligen Methoden auf, so als ob sie lokal vorliegen würden. Die Nutzung dieses Paradigmas bringt sowohl Vor- als auch Nachteile mit sich. 87

100 6. Prototypische Implementierung Vorteilhaft ist mit Sicherheit die Tatsache, dass sehr schnell auf die Module der Entwicklungsumgebung bzw. des Roboters zugegriffen werden kann, um mit der lokal verfügbaren Rechenleistung ein simples Programm für dessen Steuerung zu erstellen. So würde beispielsweise in der Programmiersprache C++ ein einfaches Programm, welches dem Roboter befiehlt, seine umliegende Welt durch Sprachsynthese zu begrüßen, folgendermaßen implementiert werden: 1 #include <alproxies/ altexttospeechproxy.h> 2 3 int main(int argc, char* argv[]) 4 { 5 AL:: ALTextToSpeechProxy tts("<ip des Roboters >", 9559); 6 tts.say("hello world!"); 7 return 0; 8 } Listing 6.1: Hello World in NaoQI durch Client-Proxy Paradigma (C++) 4 Mehr als die bloße Fernsteuerung der Module kann jedoch mit einem derartigen Ansatz aber nicht erreicht werden. Darüber hinaus sind logischerweise auf diese Art entstandene Programme kaum flexibel. Dies ergibt sich aus der Tatsache, dass sie später natürlich nur auf einen jeweiligen Rechner beschränkt bleiben und nur dann funktionieren, wenn eine stabile Netzwerkverbindung zum Roboter existiert. Daher eignen sie sich bestenfalls für den Test von Prototypen während der Entwicklungsphase eines Projektes. Der fundamentalste Nachteil ergibt sich jedoch dadurch, dass deshalb kein komplexes, autonomes Robotersystem, welches Interkommunikation zwischen allen beteiligten Modulen erfordert, mit diesem Paradigma realisiert werden kann. Client-Broker Programmierung Während Softwaresysteme auf alleiniger Basis der Client-Proxy Architektur sich somit nicht wirklich als eine eigenständige Implementierung von NaoQI-Modulen herausstellen, bildet das dabei verwendete Kommunikationsprinzip die Grundlage für das Paradigma, welche deren Nutzung explizit vorsieht. Die dazu umzusetzende Konfiguration ist schematisch in Abbildung 6.6 dargestellt. Sie beschreibt die eigentliche Vorgehensweise, welche bei der Realisierung eigener Module durchzuführen ist. Seitens Aldebaran Robotics wird dafür grundsätzlich die Nutzung eines zusätzlichen Brokers, welcher sich als Client mit der zentralen Kontrollinstanz des jeweilig zu steuernden Systems (Roboter-NaoQI oder System-NaoQI) verbindet, als beste Vorgehensweise empfohlen. 5 Dieser verwaltet eine beliebige Anzahl an Programmklassen, welche eigene Logik enthalten können, indem er deren gebundene Methoden publiziert und an sie gerichtete Aufrufe weiterleitet. Ausserdem stellt er die Verknüpfung zu der Aldebaran Modulbibliothek her und ermöglicht so deren Verwendung. Auf diese Art und Weise wird eine zweite Laufzeitumgebung geschaffen, welche zwar unabhängig von NaoQI existiert, jedoch trotzdem an der aktiven Kommunikation auf dem Service-Bus beteiligt ist. Somit sind entsprechend gebaute Softwaresysteme in NaoQI gleichermaßen flexibel als auch in der Lage komplexe Kommunikationsprozesse über letzteren abzuwickeln. Ausserdem wird die Stabilität des Gesamtsystems nicht gefährdet, da Fehler in eigenen Programmen nur zu einem Absturz des damit verbundenen Brokers bzw. der Laufzeitumgebung führen. Aufgrund der Tatsache, dass der Ort der Ausführung nunmehr auch keine Rolle spielt, können mit diesem 4 Codefragment adaptiert aus [5], Abschnitt Programming, C++, Mastering Key Concepts 5 vgl. dazu [3], Abschnitt NAOqi Framework, Architecture overview, Architecture diagram 88

101 6.1. Evaluation des NaoQI-SDK NaoQI-Prozess im Roboter: NaoQI-Bibliotheken: libalxxx.so Main Broker bonjour = nao.local ip = port = 9559 Client-Verbindung NaoQI-Framework im Computer: Main Broker bonjour = pc.local ip = port = 9559 Client Broker port = 9999 ALTextToSpeech libalxxx.so Eigene Methoden: NaoQI-Methoden ALUserModule1 sayhello() say() ALProxy (z.b. TTS) ALUserModule2 ALUserModule3 Low-Level Controller / Hardware NaoQI-Bibliotheken Eigene Bibliotheken Abbildung 6.6.: Direkte Programmierung im lokalen Rechner durch Client-Broker Paradigma Paradigma sowohl lokale Systeme im Rechner als auch autonome Systeme im Roboter selbst mit NaoQI umgesetzt werden. Im Falle der Verwendung der permanent aktiven NaoQI-Instanz des Roboters wird die hierfür notwendige Netzwerkverbindung hinfällig und einfach durch eine lokale Kommunikation auf Basis von TCP-Sockets ersetzt. Die Proxyverbindungen bleiben jedoch bestehen. Abbildung 6.7 verdeutlicht eine derartige Konfiguration. Aus diesem Ansatz folgt, dass bei der direkten Programmierung eines eigenen Moduls für das NaoQI-System grundsätzlich dieselben Strukturen und Eigenschaften zu verwenden sind, wie sie seitens Aldebaran Robotics bei der Implementierung der mitgelieferten Modulbibliothek genutzt wurden. Eigene Programme werden daher in NaoQI also mittels Vererbung der Klasse ALModule und durch anschließende Funktionsbindung innerhalb eigener Bibliotheken realisiert. Es gibt dann keinerlei Grenzen hinsichtlich der Umsetzung individueller Logiken. NaoQI-Prozess im Roboter: ALProxies Main Broker bonjour = nao.local ip = port = 9559 Client Broker port = 9999 NaoQI-Bibliotheken: libalxxx.so Eigene Bibliotheken: Eigene Methoden: ALTextToSpeech NaoQI-Methoden ALUserModule1 ALUserModule2 sayhello() say() ALUserModule3 Low-Level Controller / Hardware Abbildung 6.7.: Direkte Programmierung im Aldebaran Nao durch Client-Broker Paradigma 89

102 6. Prototypische Implementierung Unter den genannten Bedingungen und Schemata könnte eine beispielhafte Implementierung eines benutzerdefinierten Moduls in C++ dabei folgendermaßen aussehen: 1 #include " helloworld.h" 2 #include <iostream > 3 #include <alcommon/albroker.h> 4 #include <alproxies/ altexttospeechproxy.h> 5 6 using namespace AL; 7 8 HelloWorld:: HelloWorld(boost:: shared_ptr <ALBroker > broker, const std:: string& name): 9 ALModule(broker, name) 10 { 11 /** Constructor */ 12 setmoduledescription("a hello world module."); 13 functionname("sayhello", getname(), "Say hello to the world"); 14 BIND_METHOD( HelloWorld:: sayhello); 15 } HelloWorld::~HelloWorld() {} void HelloWorld:: init() 20 { 21 /** Init is called just after construction.*/ 22 sayhello(); 23 } void HelloWorld:: sayhello() 26 { 27 const std:: string phrasetosay("hello world"); 28 /** Create a proxy to TTS. */ 29 ALTextToSpeechProxy tts( getparentbroker ()); 30 /** Call the say method. */ 31 tts.say( phrasetosay); 32 return; 33 } Listing 6.2: Hello World Module in NaoQI (C++) 6 Wie man insbesondere in den Zeilen 9 und 29 sieht, ist im Gegensatz zur Implementierung in Listing 6.1 (Seite 88) die Funktionsrealisierung nicht mehr von der Adresse des zu bedienenden NaoQI-Systems im Netzwerk abhängig. Stattdessen wird nur noch von der Existenz eines Brokers ausgegangen, welcher die Kommunikation zu diesem regelt. Darüber hinaus findet in den Zeilen 12 bis 14 die Funktionsbindung statt. Dennoch bleibt das Kommunikationsprinzip grundsätzlich bei der Verwendung von Proxies, wie an Zeile 29 zu erkennen ist. Derartig publizierte Module bzw. Methoden können daraufhin an jeder Stelle des Service Bus verwendet werden. Dazu muss lediglich die Adresse des verwaltenden Brokers im Vorfeld bekannt sein. Falls dieser sich bereits zuvor am MainBroker von NaoQI angemeldet hat, sind dessen Daten einfach herauszufinden, da ersterer natürlich stets alle mit ihm verbundenen Clients kennt. Um die Logik der sayhello()-funktion aufzurufen, können anschliessend Proxies zum Einsatz kommen. Listing 6.3 zeigt beispielhaft die hierfür notwendigen Anweisungen, unter der Bedingung, dass das C++-Modul zuvor an den TestBroker gebunden wurde, aus einer Python-Sitzung heraus exemplarisch auf. 1 from naoqi import * 2 3 mytest = ALProxy(" TestBroker","IP des Roboters", 9999) 4 mytest.sayhello() Listing 6.3: Hello World-Modulaufruf in NaoQI (Python) 6 Codefragment adaptiert aus [5], Abschnitt Programming, C++, C++ Tutorials, Extending NAO API - Creating a new module, How to create a remote module 90

103 6.1. Evaluation des NaoQI-SDK Ungeachtet der Tatsache, dass sie mit denen des Client-Proxy Prinzips identisch sind, ist der Steuerungsweg bei der Nutzung dieses Paradigmas daher dennoch wesentlich flexibler und mobiler als bei Programmen des ersten Ansatzes, was deren Nachteile beseitigt und den Vorteil einer einfachen Steuerung des gesamten Robotersystems alleine übrig lässt. Demnach können bei der Client-Broker Programmierung sowohl alle Freiheiten der jeweilig verwendeten Programmiersprache als auch alle Module aus der Standardbibliothek des NaoQI- Frameworks vollständig nach eigenem Belieben eingesetzt werden. Somit scheint ein idealer Weg für die Implementierung eigener Module gefunden. Es ist daher im Hinblick auf die Realisierung des Projektes sehr wahrscheinlich, dass man auf diesen zurückgreifen muss. Main-Broker Programmierung Als letztes Paradigma für die Programmierung eigener Module für den Aldebaran Nao ist seitens des Frameworks auch die direkte Manipulation des zentralen Main-Brokers innerhalb des Robotersystems möglich. Bei dieser Vorgehensweise handelt es sich um einen Spezialfall der Client-Broker Programmierung, welche nur wohl überlegt für bestimmte Aufgaben genutzt werden soll. Abbildung 6.8 zeigt die dabei umzusetzende Konfiguration schematisch auf. NaoQI-Prozess im Roboter: Main Broker bonjour = nao.local ip = port = 9559 NaoQI-Bibliotheken: libalxxx.so Eigene Bibliotheken: ALTextToSpeech NaoQI-Methoden say() ALUserModule1 Eigene Methoden: sayhello() Low-Level Controller / Hardware Abbildung 6.8.: Direkte Programmierung im Aldebaran Nao innerhalb des Main-Brokers Hierzu werden Module programmiert, welche anschließend innerhalb einer NaoQI-Instanz selbst lokal also auf gleicher Ebene mit den Modulen von Aldebaran Robotics unter alleiniger Kontrolle des Main-Brokers auszuführen sind. Sie verzichten daher bei der Kommunikation mit NaoQI auf das externe Proxy-Prinzip und stellen somit eine Ausnahme zum empfohlenen Entwicklungskonzept dar. Entsprechend werden alle zuvor evaluierten Paradigmen im Kontext von NaoQI auch als Vorgehensweisen der remote-programmierung bezeichnet, da sie sich lediglich auf die Nutzung der Client-Schnittstelle der zentralen Kontrollinstanz beschränken. Auf Codeebene unterscheiden sich die dabei anzufertigenden Module jedoch nur kaum. Da ohnehin alle von Seiten des Anwenders selbst erzeugten Programme einen unabhängigen bzw. eigenständigen Aufbau auf Basis eines ALModules nach Listing 6.2 (Seite 90 f.) vorweisen müssen, ist also lediglich deren Einhängung in den Main-Broker zu gewährleisten. 91

104 6. Prototypische Implementierung Es existiert hierfür im NaoQI-Framework ein spezielles Deklarationsprinzip, dessen Implementierung als Einsprungspunkt einer benutzerdefinierten Modulbibliothek hinzugefügt werden muss. Der dazu notwendige Code wird in Listing 6.4 beispielhaft dargestellt: 1 #include " helloworld.h" 2 #include <boost/ shared_ptr.hpp > 3 #include <alcommon/albroker.h> 4 #include <alcommon/ albrokermanager.h> 5 6 // we're in a dll, so export the entry point 7 #ifdef _WIN32 8 # define ALCALL declspec( dllexport) 9 #else 10 # define ALCALL 11 #endif extern "C" 14 { 15 ALCALL int _createmodule(boost:: shared_ptr <AL:: ALBroker > broker) 16 { 17 // init broker with the main broker instance 18 // from the parent executable 19 AL:: ALBrokerManager:: setinstance(broker ->fbrokermanager.lock()); 20 AL:: ALBrokerManager:: getinstance()->addbroker(broker); 21 // create module instances 22 AL:: ALModule:: createmodule <HelloWorld >( broker, " HelloWorld"); 23 return 0; 24 } ALCALL int _closemodule( ) 27 { 28 return 0; 29 } 30 } // extern "C" Listing 6.4: Einsprungspunkt für lokale Module in NaoQI (C++) 7 Die Transformation eines direkt programmierten Moduls in einen lokalen Ausführungskontext findet also tatsächlich nur durch dessen Bindung an den Main-Broker der jeweiligen NaoQI- Instanz statt. Dies wird vor allem deutlich, wenn man die Zeilen in Listing 6.4 näher betrachtet. Zuerst muss eine Brokerinstanz durch einen Manager für eine bevorstehende Bindung vorbereitet werden. Anschließend wird das gewünschte Modul (z. B. das HelloWorld-Modul) an diesem eingehängt. Ist die Brokerinstanz der Main-Broker, kommt so der gewünschte Effekt zustande. Dazu muss lediglich die Bibliothek im Rahmen des NaoQI-Startprozesses geladen werden. Dieser Vorgang wird später in Abschnitt 6.4 (S. 153 ff.), welcher die wesentlichen Schritte des Deployments erklärt, weiter erläutert. Derartig erzeugte Module verfügen weiterhin durch die identische Ausführungsebene gleichermaßen über die selben Rechte in puncto Hardwarezugriff und Nutzung von Rechenzeit wie die nativen Bestandteile der NaoQI-Bibliothek. Somit eignen sie sich besser für die Implementierung CPU-intensiver bzw. hardwarenaher Lösungen als Client-Proxy oder Client-Broker Systeme. Der Zugriff auf diese spielt sich, aufgrund der Tatsache, dass sie durch den vorgestellten Prozess quasi auch zu Standardmodulen werden, analog über interne Proxystrukturen ab. Allerdings existieren zwei wesentliche Nachteile bei der Main-Broker Programmierung in NaoQI. Einerseits muss hier die Implementierung der Module in C++ geschehen und mittels eines speziellen Cross-Compilers in einen für den Prozessor des Roboters kompatiblen Maschinencode gebracht werden. Andererseits wird die Stabilität des Robotersystems entscheidend gefährdet. Stürzt beispielsweise ein solches Modul wegen eines Speicherfehlers ab, führt dies zur vorzeitigen 7 Codefragment adaptiert aus [5], Abschnitt Programming, C++, C++ Tutorials, Extending NAO API - Creating a new module, How to create a local module 92

105 6.1. Evaluation des NaoQI-SDK Termination des gesamten NaoQI-Prozesses. Im Falle des Roboters würde das zu einem sofortigen Zusammenbrechen führen, da dann auf die Hardware keinerlei Kontrolle mehr ausgeübt wird. Dies kann auch passieren, wenn die Methoden des Moduls zuviel CPU-Leistung benötigen, was bereits bei der Betrachtung der Systemgrenzen (vgl. Abschnitt 5.3.1, Seite 75 ff.) erwähnt wurde. Es wird sich zeigen, ob für die Realisierung des Projektes Module nach einem derartigen Paradigma verwendet werden müssen. Da alle Paradigmen und Vorgehensweisen für die Implementierung eingehend betrachtet wurden, ist der Aufbau und die Nutzung des NaoQI-Systems somit im Rahmen der Evaluation geklärt Referenzmodule für Implementierung Im Hinblick auf die Implementierung ist es natürlich sinnvoll, sich weiterhin mit den bereits mitgelieferten Bestandteilen der Standardbibliothek des NaoQI-SDK vertraut zu machen. Zu diesem Zweck ist dessen Modulverzeichnis, welches in [3], Abschnitt APIs, gefunden werden kann, daher eingehend zu untersuchen. Hierbei sind diejenigen Komponenten gesucht, welche am ehesten Ähnlichkeiten mit den in Kapitel 5 eingeführten Lösungsmustern bzw. -konzepten aus der Informatik und Robotik besitzen. Gleichermaßen sollten sie die Anforderungen der Zielspezifikation des Konzeptes (vgl. Abschnitt 3.2, S. 20 ff.) erfüllen. Anhand des derzeitigen Funktionsumfangs des NaoQI-Frameworks können dabei folgende Module identifiziert werden: ALAudioPlayer ALBehaviorManager ALExtraktor ALFsr ALLandmarkDetection ALLeds ALMemory ALModule ALMotion ALProxy ALSentinel ALSonar ALSpeechRecognition ALTextToSpeech ALVideoDevice ALValue ALVisionRecognition Tabelle 6.1.: Liste möglicher NaoQI-Module für Implementierung Ihre jeweilige Korrespondenz zu den Ansätzen bzw. Anforderungen wird im Folgenden in Form von Stichpunkten erläutert. ALAudioPlayer ALBehaviorManager ALExtraktor Wiedergabe und Aufnahme von Soundsamples, benutzbar zum Abspielen von Warngeräuschen, die als Teil der Bedienungsphilosophie in Abschnitt 3.4 (S. 26 ff.) erwähnt werden. Ausserdem nutzbar für Aufnahmen, um anschließend Ansätze aus der Akustik realisieren zu können (vgl. Abschnitt 5.1.2, ab S. 54). Verwaltung und Steuerung von Modulen, welche Verhaltensweisen enthalten. Möglicherweise sinnvoll für die Nachbildung eines reaktiven Steuerungskonzeptes nach Abschnitt (S. 65 f.) dieser Arbeit. Basisklasse für den Bau eigener Detektoren, kann verwendet werden um bspw. Bilderkennung manuell zu implementieren. Hierbei könnten die Methoden und Vorgehensweisen aus Informatik und Optik, Abschnitt (ab S. 48) zum Einsatz kommen. 93

106 6. Prototypische Implementierung ALFsr Modul für den Umgang mit den Fußsensoren des Aldebaran Nao. Könnte eingesetzt werden, um Aspekte der Kinematik des Robotersystems (nach Abschnitt 5.1.3, S. 58 ff.) abzubilden. ALLandmarkDetection Erkennung von sog. Naomarks 8 über die Kamera im Raum. Möglicherweise für die Reorientierung des Roboters verwendbar (siehe dazu Grenzbetrachtung, in Abschnitt 5.3.2, ab Seite 76). ALLeds ALMemory ALModule ALMotion ALProxy ALSentinel ALSonar ALSpeechRecognition ALTextToSpeech ALVideoDevice ALValue Modul zur Steuerung der LEDs des Aldebaran Nao, somit wäre eine Beleuchtung im Gefahrenfall (vgl. Abschnitt 3.4.4, S. 28) realisierbar. Kernmodul für die Verwaltung des Speichers, sowie für eventbasierte Kommunikation zwischen registrierten Modulen im System. Könnte genutzt werden, um den Aspekt der künstlichen Intelligenz durch Kommunikation bzw. Vernetzung zu implementieren (siehe Abschnitt 5.1.4, S. 61 ff.). Basisklasse für den Bau eigener Module. Muss genutzt werden, um diejenigen Aspekte des Systems, welche nicht durch vorgefertigte Module abgedeckt werden, selbst zu implementieren (Abschnitt 6.1.1, ab Seite 88). Komponente, welche sämtliche Aspekte der Bewegung des Aldebaran Nao abdeckt. Sie beinhaltet u. a. die Implementierung eines Laufmodells und die damit verbundene Methodik in verschiedenen Abstraktionsebenen. Löst Aspekte der Kinematik (Abschnitt 5.1.3, S. 58 ff.). Metamodul für die Addressierung aller Module innerhalb des NaoQI- Service-Bus Systems. Ist notwendig, um Aktionen/Sensordaten des Roboters durch eigene Methoden zu erhalten bzw. zu steuern. Siehe dazu Abschnitt 6.1.1, Seite 87. Modul, welches Reflexion über das jeweilige Nao-System ermöglicht. Erlaubt die Abfrage des Batteriestandes und emittiert darüber hinaus Warnungen im Fehlerfall. Nutzbar für Aspekte der Benutzerinteraktion (vgl. Abschnitt 3.4.1, auf Seite 27). Modul für die Ansteuerung der Sonarsensoren des Aldebaran Nao. Erlaubt Aspekte der akustischen Abstandsmessung, wie sie in Abschnitt 5.1.2, ab Seite 55 beschrieben werden, zu realisieren. Implementiert ein einfaches Spracherkennungssystem. Somit könnte der interaktive Aspekt des Bedienungskonzeptes (Anforderung in Abschnitt 3.4.2, S. 28) ermöglicht werden. Modul für Sprachsynthese, Verwendungszweck ähnlich wie bei der Spracherkennung (Abschnitt 3.4.1, Seite 27 f.). Modul für den eigenständigen Zugriff auf das Kamerasystem des Nao. Die damit erzeugten Daten sind als Quelle für die in Abschnitt (ab S. 48) dargestellten Schemata für die computergestützte Bildverarbeitung ausschlaggebend. Containerklasse für Datenaustausch zwischen Modulen. Sie kann dabei Arrays aus einfachen Datentypen transportieren. Wird häufig in 8 Spezielle, mitgelieferte Schilder seitens Aldebaran Robotics 94

107 6.1. Evaluation des NaoQI-SDK ALVisionRecognition Verbindung mit ALMemory genutzt und teilt sich daher dessen Anwendungsgebiet. Modul, welches eine einfache Bilderkennung implementiert. Könnte genutzt werden, um Gefahrensituationen auf Basis von Schildern zu erkennen. Verkörpert sowohl Praktiken aus Abschnitt 5.1.1, S. 48 ff. als auch die dazugehörige Anforderung in Abschnitt 3.2 (Seite 20) gleichermaßen. Es ergibt sich also bei der Untersuchung des NaoQI-SDK ein ziemlich umfangreicher Satz von Modulen, welche durchaus Überschneidungen zu den Lösungsmustern und Anforderungen des Gesamtkonzeptes dieser Arbeit aufweisen. Ihre entsprechende Verwendung ist daher für dessen prototypische Implementierung am Aldebaran Nao maßgeblich Zusatzsoftware und Lücken Leider lassen sich jedoch nicht alle Aspekte des Gesamtkonzeptes durch die in Tabelle 6.1 (Seite 93) angegebenen NaoQI-Module beschreiben. Dies ist grundsätzlich auf zweierlei Gründe zurückzuführen. Einerseits hat sich während erster Systemtests herausgestellt, dass sich entgegen der Annahme einige hiervon doch nicht für eine Implementierung dieses bestimmten Konzeptes eignen. Andererseits sind schlicht einige andere notwendige Lösungsmuster und Ansätze von vornherein einfach nicht im Framework vorhanden. Somit ergeben sich Lücken, die entweder durch jeweilige Implementierungen selbst gelöst oder von anderen Bibliotheken bzw. Softwaresystemen extern hinzugefügt werden müssen. Deren Betrachtung und eine kurze Beschreibung der dazu passenden Lösungen sollen daher die Evaluation des NaoQI-SDKs abrunden. Als in dieser Hinsicht besonders problematisch hat sich die integrierte Bilderkennung des NaoQI- Frameworks erwiesen, welche seitens Aldebaran Robotics hauptsächlich im Modul ALVisionRecognition zu finden ist. Es erkennt eigentlich zuvor trainierte Objekte zumeist nur sporadisch und arbeitet daher nicht zuverlässig genug, um auf Dauer im Projekt eingesetzt werden zu können. Ausserdem ist es nicht in der Lage, die ungefähre Distanz zu einem Objekt abzuschätzen. Die alternative Nutzung des ALLandmarkDetection-Moduls erübrigt sich ebenfalls, da jenes sich nicht für die Erkennung individueller Warnschilder eignet. Aus dieser Tatsache heraus entsteht die Notwendigkeit der Erschaffung eines entsprechend leistungsfähigeren Ersatzes. Es wird daher im Projekt erforderlich sein, ein eigenes Modul so zu kreieren, dass es anstelle der ALVisionRecognition benutzt werden kann. Im Umfeld der computergestützten Bildverarbeitung existiert hierzu die offene Bibliothek Open- CV, welche über optimierte Implementierungen aller diesbezüglichen Lösungskonzepte (vgl. Abschnitt 5.1.1, S. 48 ff.) verfügt. Im Falle der Entwicklung auf einem Computer müsste dabei diese als zusätzliche Software heruntergeladen, kompiliert und anschliessend in das System integriert werden, bevor die Erschaffung entsprechender Programme stattfinden kann. Ein ähnliches Szenario würde sich auch im Falle der Entwicklung eines eigenen Moduls für die Bildverarbeitung auf Basis des Nao-Kamerasystems ergeben. Dies wäre jedoch zusätzlich durch die Tatsache erschwert, dass die im Aldebaran Nao verwendete Prozessortechnologie nicht mit gewöhnlichen x86-basierten Architekturen kompatibel ist. Allein schon deswegen ist daher eine minimierte Version der OpenCV-Bibliothek wohl schon werkseitig ein Teil des NaoQI-Frameworks. Somit kann bei einer selbstkonzipierten Implementierung auf dieses zurückgegriffen und auf die Einführung von externen Bibliotheken bzw. Softwaresystemen in diesem Fall verzichtet werden. Eine weitere Lücke des NaoQI-Frameworks besteht in der kompletten Abstinenz von Modulen, welche die in Abschnitt 5.2 (S. 63 ff.) eingeführten Lösungskonzepte der Robotik adressieren. So 95

108 6. Prototypische Implementierung sind weder eine Referenzarchitektur noch schlüssige Weltrepräsentationen, welche für die Implementierung hybrider oder planungsorientierter Systeme benötigt werden würden, vorzufinden. Auch hierfür ist es prinzipiell möglich, zur Lösung dieser Probleme die dafür notwendigen Strukturen entweder von einer externen Quelle zu beziehen oder sie selbst zu implementieren. Wie in Abschnitt 6.2 gesehen werden kann, ist dazu die Wahl auf letzteres gefallen. Selbstverständlich waren jedoch die von Murphy vorgestellten Architekturen hierzu inspirierend. 9 Ebenso stellt die kontinuierliche Unzuverlässigkeit des Laufens bei der Nutzung des ALMotion- Moduls seitens NaoQI eine ernstzunehmende Lücke des Entwicklungssystems dar. Ob der komplexen Natur des dabei verantwortlichen Problems (vgl. Abschnitt 5.3.3, ab Seite 77) ist ebenfalls die Inklusion externer Softwaresysteme bzw. Bibliotheken auszuschließen. Es wird daher im Projekt erforderlich sein, mit einem Fokus auf die Entwicklung eigener Module, welche die Methoden des Fortbewegungssystems modifizieren und stabilisieren, zu arbeiten. Wie anhand dieser Beobachtungen gesehen werden kann, sind trotz zahlreicher und durchaus komplexer Lücken innerhalb des NaoQI-Frameworks im Hinblick auf die Implementierung des Konzeptes keine zusätzlichen, externen Bibliotheken oder Softwaresysteme einzubringen. Stattdessen scheinen eigene Lösungen der einzige Weg zu sein, was den Entwicklungsprozess nachhaltig erschwert. Lediglich für die Visualisierung der Ergebnisse könnten externe Bibliotheken, wie beispielsweise das Qt-Framework, genutzt werden. Sie sind aber jeweils nur auf dem dazu genutzten Rechner bzw. im einem dazu speziell erzeugten Client unabhängig vom Robotersystem einzubringen Softwaremodell Für eine prototypische Implementierung des Konzeptes am Aldebaran Nao-Roboter muss neben der Kenntnis über Aufbau und Nutzung der dazugehörigen Entwicklungsinstrumente zusätzlich ein Softwaremodell als konkrete Richtlinie für die Umsetzung vorliegen. Als Grundlage dient natürlich das theoretische Systemmodell, welches in Abschnitt 4.3 (Seite 45) als Endergebnis der Konzeptanalyse eingeführt wurde. Abbildung 6.9 zeigt es der Übersicht halber noch einmal auf. Im Wesentlichen wurden für seine Gewinnung die abstrakten Anforderungen der Zielspezifikation (vgl. Abschnitt 3.2, S. 20 ff.) in atomar zu lösende Teilprobleme aus verschiedenen Gebieten der Wissenschaft zerlegt. Deren Lösung und ein anschließender Transfer zu einem Gesamtkomplex wird daher mit Sicherheit ein System mit den gewünschten Eigenschaften zur Folge haben. Wie jedoch an der starken Mannigfaltigkeit hierfür möglicher Lösungsansätze bzw. -muster bereits gesehen werden kann (vgl. Kapitel 5), ist die Erzeugung eines entsprechenden konkreten Lösungsmodells keine triviale Aufgabe. Die Diversität der möglichen Softwaremodelle stellt dabei die größte Schwierigkeit dar. Insbesondere da sie je nach Anwendungszweck unterschiedliche Vor- und Nachteile bzw. Detailgrade mit sich bringen. Im Zuge dieser Arbeit wurden daher viele verschiedene Modelle für die Implementierung erschaffen und evaluiert. Als oberste Priorität galt dabei die Findung eines Softwaremodells, welches sowohl gleichermaßen eine Anwendung der vielversprechendsten Lösungsansätze bzw. -muster aus Informatik/Robotik als auch eine möglichst elegante Einbettung des Gesamtsystems in die Entwicklungsparadigmen bzw. Bibliotheken des NaoQI-Frameworks ermöglicht. Zusätzlich stellte eine einfache Einführbarkeit von Kompromisslösungen, welche Aufgrund von Limitationen des Nao (vgl. Abschnitt 5.3, ab S. 74) bzw. Lücken im NaoQI-Framework (vgl. Abschnitt 6.1.3, S. 9 vgl. [42], S. 54 ff., 113 ff., 265 ff. 96

109 6.2. Softwaremodell 95 ff.) notwendig wurden, ein wichtiges Kriterium dar. Die letztendlich verwendete Iteration ist in Abbildung 6.10 zu sehen. Gesamtkonzept Ziele Physik Wissenschaften Mathematik Psychologie Kartografie Linguistik 1. Suchen und Extrahieren von Bedrohungen Erhalten von Daten aus Sensorik Analyse dig. Daten nach Gefahren Refmodelle/Metriken (Optik/Akustik) hier: ausführende Wissenschaft Algebra für Merkmalsberechnung Geometrie für korrektur von Fehlern KI Modifikationen Perzeption Reflexion Zugriffsmethoden Historie Bewegungen Umgebungsdaten 2. Erkennen d. Bedeutung Interpretation der Daten aus Sensorik Klassifikation von Merkmalen KI Modifikationen Evaluation Kognition Zugriffs- und Änderungsmethoden Topologie d. Umgebung 3. Lokalisation Analyse der Daten aus Sensorik Ref.modelle/Metriken (Optik/Akustik/ Umgebung/Kinematik) Geometrie für Positionsabschätzung KI Modifikationen Reflexion Zentrale Kartenstruktur etablieren Schnittstelle bereitstellen 4. Navigation Gesezesmäßigkeiten/ Referenzmodelle/ Metriken Suchalgorithmen Graphentheorie Maße und Ordnungen im Koordinatenraum KI Modifikationen Konvergenz Problemlösen Schnittstelle ist Datenquelle 5. Interaktion Umsetzung des Laufens Überwachung des Laufens Kinematik Sensorik Algebra für Berechnung der Bewegungen Wahrscheinlichkeitsbewertungen KI Modifikationen Perzeption Reflexion Evaluation Lageplan Schnittstelle: Laufen Ausgabe SysZustand/ Ergebnisse Spracherkennung Steuerung Abbildung 6.9.: Theoretisches Modell des Gesamtkonzeptes (Rekapitulation von Abbildung 4.6) Rein grundsätzlich handelt es sich hierbei um ein eigens für den Nao konzipiertes Softwaremodell, welches in einigen Aspekten sowohl von Elementen der Nested Hierarchical Controller- Architektur (NHC, vgl. Seite 70 ff.) als auch von der Autonomous Robot Architecture (AuRA, ab Seite 73 ff.) inspiriert ist. NaoQI-Prozess im Roboter: ALProxy-Verbindungen (TCP) Python-Prozess im Roboter: Main Broker bonjour = nao.local ip = port = 9559 Client Broker port = 9999 NaoQI-Bibliotheken: libalxxx.so + libcuxxx.so Planen ALTextToSpeech Messen Missionplanner ALMotion CUSURF Detector ALEvents Cartographer NavNode ALBehaviorManager ALMemory CUSonar ALEvents Agieren Navigator ALVideoDevice VisionReactor Movement Low-Level Controller Hardware des Nao AE H25 V3.3 Pilot Abbildung 6.10.: Softwaremodell für prototypische Implementierung am Aldebaran Nao 97

110 6. Prototypische Implementierung Dies kann man an den gestrichelten Linien in Abbildung 6.10 sehen, welche deren ursprüngliche Zusammenhänge im Modell erkennen lassen. Weiterhin wird, auf Empfehlung des Herstellers Aldebaran Robotics, weitestgehend das Client-Broker Paradigma (vgl. Seite 89) als wesentliche Basis für dessen Architektur herangezogen. 10 Letzteres trifft insbesondere auf alle Module des Softwaresystems zu, welche sich maßgeblich mit der eigentlichen Abwicklung der Ziele des Konzeptes bzw. der Steuerung der hierfür notwendigen Aktionen auseinandersetzen (rechte Hälfte von Abbildung 6.10). Eine Ausnahme bilden jedoch alle Module der Sensorik, welche zusätzlich unter dem Paradigma der Main-Broker Programmierung modelliert worden sind (gelbe Ellipsen in Abbildung 6.10). In gewisser Weise ist daher das Modell durch zwei zunächst unabhängige, unterschiedliche Segmente konstituiert, welche selbstständig implementiert werden müssen. Wie später in Abschnitt 6.3 (ab S. 101) sichtbar sein wird, ergeben sich daraus wesentliche Vorteile und Möglichkeiten für das Gesamtsystem. Trotz der somit teils sehr unterschiedlichen Komponenten entsteht jedoch grundsätzlich ein Gesamtmodell, welches den Anforderungen des theoretischen Systemmodells gerecht wird. Es begünstigt durch eine geschickte Vernetzung vieler verschiedener und verteilter Lösungsansätze die Kreation von künstlich intelligenten Systemen und versucht ihre Komplexität auf elegante Art und Weise zu zerlegen. Hierfür wird vollends auf die Fähigkeiten des NaoQI-Frameworks zurückgegriffen. So können Sensorik und Steuerung durch dessen Interkommunikationssystem trotz unterschiedlicher Paradigmen direkt miteinander verbunden werden. Zudem ergibt sich natürlich die Nutzung bereits vorhandener NaoQI-Module für die Steuerung des Roboters bzw. den Zugriff auf dessen Hardware. Verbunden mit der Wahlfreiheit sowohl in puncto Programmiersprache als auch der Implementierung an sich sind somit praktisch alle Anforderungen, sowie Mängel, durch eigene Module an den richtigen Stellen durchführ- und behebbar. Infolgedessen ermöglicht dieses Modell, das Gesamtkonzept prototypisch am Nao zu implementieren. Zu diesem Schluss kommt man, wenn man die Aufgaben der einzelnen Elemente des Softwaremodells in Abbildung 6.10 mit den Anforderungen des theoretischen Systemmodells vergleicht. Da sich jede davon tatsächlich zu einer Komponente aus ersterem zuordnen lässt, erlauben sie einen Transfer der entsprechenden Lösungsansätze. Deshalb folgt eine Beschreibung des Zwecks einer jeden Komponente des Softwaremodells, beginnend mit dem Steuerungssystem (rechte Hälfte von Abbildung 6.10): Der ClientBroker stellt den zentralen Kommunikationsknoten für alle Komponenten bzw. Module des Steuerungssystems dar. Er verbindet dieses mit der NaoQI-Modulbibliothek auf dem Roboter und verwaltet darüber hinaus sämtliche anderen Teilmodule untereinander. Dadurch werden automatisch alle Zusammenhänge zwischen den verschiedenen Programmmodulen von Messung, Planung und Aktion realisiert (schwarze, durchgezogene Pfeile in Abbildung 6.10). Wie in dessen Implementierung (vgl. Abschnitt 6.3.1, S. 101 f.) zu erkennen sein wird, kommen dazu unterschiedliche Techniken zum Einsatz. Durch die Anwendung eines internen Client-Broker Paradigmas ist er ein obligatorisches Modul. Im Wesentlichen bildet er somit den Aspekt der künstlichen Intelligenz durch Vernetzung und damit jeglichen Kommunikationsaufwand zwischen den verschiedenen Teillösungen ab (vgl. schwarze Pfeile im theoretischen Modell, Abbildung 6.9). Dadurch betrifft er sämtliche Funktionen des Systems als grundlegende Struktur. Dementsprechend kann er auch als zentrale Kontrollinstanz für das Steuerungssystem gesehen werden, da er prinzipiell einen Einblick in bzw. die Manipulation von Variablen aller anderen Module ermöglicht. Das Missionplanner-Modul ist analog zum Missionsorganisator der NHC bzw. AuRA-Architektur zu sehen. Seine zentrale Aufgabe besteht in der Erfüllung einer abstrakten Gesamtmission an sich. Im Falle des Konzeptes dieser Arbeit kann jene folgendermaßen definiert werden: 10 vgl. dazu [3], Abschnitt NAOqi Framework, Architecture overview, Architecture diagram 98

111 6.2. Softwaremodell Ein vorgegebenes Ziel in einem Raum muss erreicht werden Alle potentiellen Gefahren auf dem Weg dorthin müssen erkannt werden Alle erkannten Gefahren müssen vermieden werden Infolgedessen wird somit der abstrakte Suchprozess des Roboters an sich durch dieses Modul modelliert. Es stellt daher auch die grundlegende Struktur für die Realisierung der Logik dar. Wie in dessen Implementierung gesehen werden kann (vgl. Abschnitt 6.3.2, S. 105 f.), ist dabei eine kontrollierende Suchschleife das Maß der Dinge. Sie verbindet Ergebnisse und Abhängigkeiten zwischen Karte, Navigation und Bewegung untereinander. Hieraus ergibt sich, dass dieses Modul an der Realisierung aller Ziele des theoretischen Systemmodells beteiligt ist, da nach einer einmaligen Initialisierung ein selbstständiger Kreislauf in Gang gesetzt wird. Hierbei werden durch Navigation und Bewegung kontinuierlich Umgebungsdaten erzeugt, die entsprechend weitere Navigation und Bewegungen zur Folge haben. Dadurch entstehen neue Umgebungsdaten, was den Kreislauf/die Suchschleife bis zu dessen/deren Terminierung am Leben erhält. Das Cartographer-Modul implementiert, parallel zu seinen Äquivalenten aus NHC bzw. AuRA, eine grundsätzliche Repräsentation der Umwelt des Robotersystems (ab S. 109). Hierbei kann theoretisch jedwede Datenstruktur verwendet werden, die in Abschnitt (S. 67 ff.) ausführlich eingeführt wurde. Aus der Sicht des Moduls ist dabei deren Initialisierung, Aktualisierung auf Basis von Sensordaten, sowie die Regelung des Zugriffs auf sie die hauptsächliche Aufgabe. Insbesondere die Aktualisierung ist von entscheidender Bedeutung für das System, da das den abstrakten Suchprozess des Missionplanner-Moduls logischerweise maßgeblich beeinflusst. Somit werden weiterhin praktisch alle Anforderungen an die Kartografie und alle davon abhängigen Teilziele wie beispielsweise die Speicherung von Umgebungsdaten für die Vermeidung von Mehrfachmessungen bzw. einer Topologie für die Navigation des theoretischen Modells (vgl. Abbildung 6.9, S. 97) befriedigt. Zudem erfüllt es sämtliche Aspekte des Zieles der Lokalisation (vgl. Punkt 3 in Abbildung 6.9), da es eine selbstständige und kontinuierliche Interpretation aus den Sensordaten bzgl. der relativen Position von Gefahrenquellen, sowie des Roboters, im Bezugsraum des Szenarios selbst realisiert. Das Navigator-Modul kümmert sich, entsprechend seiner designierten Rolle in NHC/AuRA, um eine kontinuierliche (Neu-)Planung des Laufweges und verwirklicht daher vollständig alle derartigen Aspekte in Punkt 4 des theoretischen Systemmodells (vgl. Abbildung 6.9, S. 97) bzw. der Zielspezifikation (vgl. Abschnitt 3.2, ab S. 20). Hierfür greift es über den ClientBroker auf die zentrale Datenstruktur des Cartographer-Moduls zu und versucht einen beliebigen Algorithmus aus der Graphentheorie auf diese anzuwenden. Dabei gilt das zuvor durch das Missionplanner- Modul festgelegte Ziel als maßgeblicher Faktor. Als Ergebnis entsteht hierbei eine Liste von Direktiven, welche die durchzuführenden verbleibenden Bewegungen relativ zu der Karte des Gesamtsystems bzw. zur Position des Roboters beschreiben. Das NavNode-Modul ist notwendig, um den Inhalt der zentralen Kartenstruktur des Cartographers in eine für graphentheoretische Algorithmen adäquate Knotenrepräsentation zu überführen, falls diese nicht bereits verwendet wird. Es ist im Softwaremodell daher optional und muss nur bei entsprechenden Datenstrukturen zum Einsatz kommen. Wie später in Abschnitt (S. 115 f.) gesehen werden kann, war das im Rahmen dieser Arbeit der Fall. Die letztendliche Konversion der Direktiven des Navigators in Bewegungsmuster bzw. Steuerbefehle ist die hauptsächliche Aufgabe des Pilot-Moduls (ab S. 121 f.). Hierfür erhält es stets eine Liste mit den jeweils aktuellsten Direktiven und verwendet unter Berücksichtigung der gegenwärtigen Orientierung des Roboters Methoden des Movement-Moduls, um ihn im Bezugsraum sukzessive zu steuern. Deshalb bildet es die Schnittstelle zwischen Navigation und Interaktion im theoretischen Modell (vgl. Kartografie in Punkt 5: Interaktion in Abbildung 6.9, S. 97) ab. Da weiterhin nur dieses Modul Kenntnisse über die Steuerungsmöglichkeiten des Roboters besitzt, 99

112 6. Prototypische Implementierung kapselt es zudem einige maschinenspezifische Funktionen für andere Module. Das ist notwendig, da beispielsweise der Missionplanner bei Start das Robotersystem natürlich erst komplett initialisieren muss. Das Movement-Modul, welches speziell für die prototypische Implementierung des Gesamtkonzeptes am Aldebaran Nao designt wurde, enthält neben einer Schnittstelle zu dessen Laufsystem (vgl. Basismodul ALMotion in Abbildung 6.10, S. 97) zusätzlich alle Methoden für die weiterführende Steuerung von verschiedenen Gelenken des Roboters. Ausserdem werden einige hardwarenahe Prozesse, wie die Steifheit der Motoren, geregelt. Im Falle des Laufens wird, aufgrund der Mängel im Fortbewegungssystem, dabei nicht nur eine einfache Steuerung von Aktuatoren (wie bei der NHC-Architektur), sondern auch reaktives Verhalten auf Basis des Kamerasystems genutzt um Fehler weitestgehend zu korrigieren. Wie man später bei der Implementierung sieht (vgl. Abschnitt 6.3.7, S. 126 f.), erfolgt jedwede Bewegung zunächst durch Fussschrittplanung. Anschließend geschieht durch direkte Sensor-Aktuator Kopplung eine statistisch fundierte Bewertung der dabei geleisteten Qualität, was im Fehlerfall zu entsprechenden Gegenmaßnahmen führt. Im Gegensatz zu den Modulen der Planungsebene steht seine Architektur aufgrunddessen zwischen NHC und AuRA. Da es somit jedoch grundsätzlich eine vollständige Umsetzung und Überwachung des Laufens nach Punkt 5 des theoretischen Modells (vgl. Abbildung 6.9) enthält, befriedigt es dessen Anforderungen und stellt daher die Basis für das Pilot-Modul des Steuerungssystems dar. Das VisionReactor-Modul stellt als unmittelbares Verbindungsglied die direkte Kopplung zwischen Movement-Modul und Sensorik sicher, indem es die hierfür relevanten Daten empfängt und puffert. Die Module CUSURFDetector und CUSonar implementieren, analog zu den Ansätzen in den zugrundeliegenden Architekturen, alle Aspekte der Sensorik innerhalb des Softwaremodells (vgl. gelbe Ellipsen in Abbildung 6.10, S. 97). Eine Betrachtung ihrer individuellen Aufgaben rundet den Transfer zwischen letzterem und dem theoretischen Systemmodell ab. Im Falle des CUSURFDetector-Moduls (Abschnitt 6.3.8, S. 136 ff.) handelt es sich hierbei um eine eigenständige Implementierung eines Bildverarbeitungssystems für die Erkennung bestimmter planarer Elemente innerhalb eines Bildes, welche durch den Mangel adäquater Erkennungsmodule seitens Aldebaran Robotics notwendig wurde (siehe dazu Abschnitt 6.1.3, ab S. 95). So wird mithilfe einer kontinuierlichen Suchschleife jedes Bild aus dem Kamerasystem des Nao nach bestimmten Schildern durchsucht, mögliche Kandidaten mit Referenzen verglichen und bei entsprechender Übereinstimmung die Distanz zu den jeweiligen Objekten errechnet. Das konsolidierte Endergebnis jeder Iteration wird schlussendlich als Event dem Cartographer-Modul des Steuerungssystems übermittelt, welcher die Daten weiterführend interpretiert und somit die Gesamtmission des Missionplanners entscheidend beeinflusst. Da demnach die eigentliche Erkennung von Gefahrensituationen stattfindet, deckt dieses Modul insbesondere alle Anforderungen an Physik und Mathematik aus den Zielen Suchen und Extrahieren von Bedrohungen, Erkennen der Bedeutung und Lokalisation (Punkte 1, 2 und 3 des theoretischen Systemmodells in Abbildung 6.9, S. 97) ab. Aufgrund der Begebenheit, dass der dabei zum Einsatz gekommene Algorithmus für die Klassifikation von Gefahren prinzipiell auch zur Bestimmung von Unterschieden zwischen zwei Bildern geeignet ist, kann die Suchschleife darüber hinaus für die Ausgabe entsprechender Daten manipuliert werden. Wie in der Implementierung dieses Moduls ersichtlich (vgl. Abschnitt 6.3.8, ab Seite 149), umfasst das die Berechnung eines graduellen Versatzes, welcher anschließend direkt als Event an den VisionReactor gesendet wird. Auf dessen Basis erfolgt letztendlich die Qualitätsbestimmung eines Schritts. 100

113 6.3. Modulimplementierung und Abläufe Das CUSonar-Modul besteht weiterhin aus einer einfachen Weiterleitung der Abstandswerte, welche durch eine automatische Auswertung der Sonarsensoren seitens der NaoQI-Instanz auf dem Roboter entstehen. Sie werden ebenfalls kontinuierlich als Events über den ClientBroker an das Cartographer-Modul geschickt und stellen somit eine Alternative für die Erkennung besonders naher Hindernisse dar. Daher deckt es ein ähnliches Aufgabengebiet wie das Kameramodul ab. Aspekte der Linguistik sind darüber hinaus in alle Module für eine leichtere Fehlersuche bzw. Statusmeldung in Form der Sprachsynthese eingeflossen. Dazu war der in Abschnitt (Seite 27) eingeführte Wortschatz hierfür maßgeblich. Auf die Spracherkennung wurde weiterhin verzichtet, da der verwendete Nao-Roboter über kein Nuance-Erkennungspaket verfügt. Das wurde mit der Betreuung in einem Gespräch entsprechend geklärt. Wie an diesen Betrachtungen gesehen werden kann, sind durch den vorgestellten Entwurf somit tatsächlich alle wesentlichen Anforderungen der Zielspezifikation, sowie des theoretischen Modells realisierbar. Aus diesem Grund wird es weiterhin als konkrete Richtlinie für die Ausführung der prototypischen Implementierung verwendet Modulimplementierung und Abläufe Jene Ausführung der prototypischen Implementierung bedeutet letztendlich, dass nun alle Module, Segmente und Verbindungen des Softwaremodells aus Abbildung 6.10 (S. 97) weiterhin am Aldebaran Nao zu realisieren sind. Dies erforderte, angesichts der Komplexität der damit verbundenen Arbeiten bzw. des Sachverhalts an sich, einen nicht zu unterschätzenden Anteil an der Bearbeitungszeit dieser Abschlussarbeit. Da eine detaillierte Beschreibung aller Lösungskonzepte eines jeden Moduls mit Sicherheit den Rahmen des Kapitels ins unermessliche Ausdehnen würde, beschränkt sich die Darstellung auf die wesentlichen Aspekte und Abläufe, welche für ein Verständnis des Gesamtsystems ausschlaggebend sind. Die Intention dieses Abschnitts besteht also in der Konkretisierung der Ausgestaltung jeder einzelnen Komponente, wie sie bei der Vorstellung des Softwaremodells (vgl. Abschnitt 6.2, S. 96 ff.) spezifiziert wurde. Hierfür dienen dazu förderliche Fragmente aus dem Quellcode der Ausarbeitung. Weiterhin sind an einigen Stellen Hinweise zu Lösungswegen angegeben, welche aufgrund der speziellen Systemeigenschaften bzw. Limitationen des Zielsystems leider vorzeitig verworfen und durch Kompromisslösungen ersetzt werden mussten. Man sollte erwähnen, dass hierbei das Steuerungssystem in der Programmiersprache Python, die Sensorik jedoch aus Gründen einer besseren Performanz unter C++ entwickelt wurde. Das geht jedoch konform mit den Möglichkeiten des NaoQI-Frameworks bzw. den damit anwendbaren Paradigmen ClientBroker Da der ClientBroker als zentraler Kommunikationsknoten zwischen allen Modulen des Steuerungssystems und der lokalen NaoQI-Instanz auf dem Roboter fungiert, muss bei dessen Implementierung zwar nur grundsätzliche jedoch sehr wichtige Arbeit verrichtet werden, um ein System entsprechend des Modells zu ermöglichen. Er stellt das fundamentale Programmmodul dar, welches immer als erstes gestartet werden muss, um die Software verwenden zu können. Im Wesentlichen sind bei einer Realisierung dazu folgende Aufgaben zu erledigen: 1. Laden und Prüfen der Definition aller Module des Steuerungssystems 101

114 6. Prototypische Implementierung 2. Erzeugung des Brokers 3. Erzeugung aller notwendigen Proxyverbindungen im Brokermodul 4. Instanziieren/Vernetzen aller Module des Steuerungssystems im Brokermodul 5. Bindung der Events für Kommunikation mit Sensorik im Brokermodul 6. Bindung des Steuerungssystems an den Main-Broker des Roboters 7. Unendlichkeitsschleife bis zum Ende des Systems Grundsätzlich existieren dabei für die Erzeugung eines NaoQI Client-Brokers genügend Beispiele für dessen Programmierung. Sie sind im Entwicklungshandbuch angegeben. 11 Daher müssen lediglich die entsprechenden Stellen um die Komponenten des Softwaremodells ergänzt werden. 1. Laden und Prüfen der Definition aller Module des Steuerungssystems Wie bei den meisten Programmiersprachen muss auch in Python die Verwendung eines Moduls bzw. einer Implementierung aus einer anderen Datei durch einen entsprechenden Importmechanismus definiert sein (vgl. Listing 6.5). 1 import visionreactor 2 import missionplanner 3 import cartographer 4 import navigator 5 import pilot 6 import movement 7 from naoqi import ALProxy 8 from naoqi import ALBroker 9 from naoqi import ALModule Listing 6.5: Modulimport in Python Hierbei werden automatisch einfache syntaktische Prüfungen an den zu ladenden Elementen des Steuerungssystems vorgenommen. Gibt es Probleme, schlägt die Programmausführung bereits an dieser Stelle fehl. 2. Erzeugung des Brokers Da zuvor aus dem NaoQI-Paket die hierfür wesentlichen Implementierungen importiert bzw. geladen wurden, wird mit Hilfe der Zuweisung in Zeile 4 (Listing 6.6) ein zunächst leerer NaoQI Client-Broker angelegt. 1 # We need this broker to be able to construct 2 # NAOqi modules and subscribe to other modules 3 # The broker must stay alive until the program exists 4 mybroker = ALBroker(" SearchAndMoveBroker", 5 " ", # listen to anyone , # find a free port and use it 7 "nao.local", # parent broker IP ) # parent broker port Listing 6.6: Erzeugung des Brokers An diesen können nun beliebig viele weitere Module gebunden werden, wie beispielsweise ein zentrales Broker-Modul. 11 vgl. dazu [5], Abschnitt Programming, Python, Python tutorials, Making a Python module - Reacting to events 102

115 6.3. Modulimplementierung und Abläufe 3. Erzeugung aller notwendigen Proxyverbindungen im Brokermodul An sich ist ein solches Broker-Modul nichts anderes als ein gewöhnliches ALModule, welches die Architektur des Systems entgegen nimmt. 1 class SearchAndMove( ALModule): 2 def init (self, name): 3 ALModule. init (self, name) 4 # No need for IP and port here because 5 # we have our Python broker connected to NAOqi broker 6 try: 7 #get NaoQI internal modules for interfacing with the robot 8 self.motion = ALProxy("ALMotion") 9 self.speech = ALProxy(" ALTextToSpeech") 10 self. behavior = ALProxy(" ALBehaviorManager") 11 self.memory = ALProxy("ALMemory") Listing 6.7: Erzeugung von Proxyverbindungen im Brokermodul Entsprechend laufen in dessen Konstruktor alle diejenigen Schritte ab, welche alle Vernetzungsaspekte des Anwendungssystems betreffen. Benötigt letzteres beispielsweise Elemente aus der Modulbibliothek des Main-Brokers, so wird das durch einfache Proxyverbindungen erledigt. Die hierbei gebundenen Ressourcen stehen danach sämtlichen anderen Komponenten als Variable der ClientBroker-Klasse zur Verfügung. Im Rahmen der prototypischen Implementierung des Gesamtkonzeptes am Nao werden daher für das Steuerungssystem Verbindungen zu den Modulen ALMotion, ALTextToSpeech, ALBehaviorManager und ALMemory an dieser Stelle aufgebaut. 4. Instanziieren/Vernetzen aller Module des Steuerungssystems im Brokermodul Wenn alle für das Steuerungssystem notwendigen Bibliotheken durch den ClientBroker verfügbar sind, ist es letztendlich möglich, dessen Komponenten zu instanziieren. Wie an den Zeilen 7 bis 9 in Listing 6.8 zu sehen ist, werden hierfür in Python einfach die Konstruktoren der jeweiligen Module aufgerufen und die dabei erzeugten Objekte bzw. Referenzen zugewiesen. Sie sind für die restliche Laufzeit des ClientBroker als Variablen desselbigen gespeichert. 1 class SearchAndMove( ALModule): 2 def init (self, name): 3 ALModule. init (self, name) 4 # No need for IP and port here because 5 # we have our Python broker connected to NAOqi broker 6 try: 7 self. movement = movement.movement(" MovementModule", self) 8 self.pilot = pilot.pilot(" PilotModule", self) 9 self. navigator = navigator. Navigator(" NavigatorModule", self) Listing 6.8: Erzeugung und einfache Vernetzung von Steuerungskomponenten im Konstruktor Da jene Komponenten in ihren jeweiligen Konstruktoren ebenfalls von der Klasse ALModule erben (vgl. Zeile 1 und 3 in Listing 6.8), werden sie dabei von dem zugrundeliegenden ALBroker automatisch erfasst und im System publiziert. Darüber hinaus wird durch eine Weitergabe einer Objektreferenz auf den ClientBroker, sichergestellt, dass sie jenen als gemeinsames Kommunikationsmedium auf Objektebene verwenden können. Das ermöglicht das spezifische Verhalten der Programmiersprache Python, bei dem alle Methoden und Daten einer Klasse grundsätzlich zunächst öffentlich zugänglich sind. Auf diese Art und Weise können daher sehr einfach modulübergreifende Funktionsaufrufe und Datenaustauschprozesse realisiert werden. Die Nutzung gemeinsamer Objektreferenzen ist daher 103

116 6. Prototypische Implementierung mit eine der wesentlichen Techniken, um derartige Zusammenhänge zwischen Messung, Planung und Aktion zu realisieren. 5. Bindung der Events für Kommunikation mit Sensorik im Brokermodul Da das Softwaremodell neben einer simplen Kommunikation auf Basis des gemeinsamen Client- Brokers zusätzlich auch den Empfang von asynchronen Events aus der Sensorimplementierung vorsieht, müssen die entsprechenden Mechanismen des NaoQI-Frameworks aktiviert und an die jeweiligen Partner gebunden werden. Ersteres wird dabei durch die Deklaration eines NaoQI- Events (vgl. Zeile 5 in Listing 6.9) bewerkstelligt. 1 class SearchAndMove(ALModule): 2 def init (self, name): 3 ALModule. init (self, name) 4 try: 5 self.memory. declareevent(" SeenEvent", " VisionReactorModule") 6 self.memory. subscribetoevent(" SeenEvent", " CartographerModule", "update") Listing 6.9: Deklaration und Bindung von Events für Kommunikation mit Sensorik Ein NaoQI-Event ist gleichzusetzen mit einer Nachricht, welche unter der Verwendung eines gemeinsamen Namens eine geringe Menge an Nutzdaten atomar durch den Speicher des Roboters transportieren kann. Dies wird insbesondere bei der Implementierung des CUSURFDetectors effektiv genutzt. Sollte ein bestimmtes Modul innerhalb des gesamten NaoQI Service-Bus ein derartiges Ereignis aussenden, so erhalten es automatisch alle Module, welche jenes abonniert haben. Zeile 6 zeigt eine derartige Bindung beispielhaft. Hierbei muss jeweils eine Funktion des empfangenden Moduls spezifiziert werden, welche sich um die Abarbeitung des eintreffenden Datenpakets kümmert. Auf diese Art und Weise wird somit die lose Kopplung zwischen Sensorik und Cartographer bzw. Movement-Modul ermöglicht. 6. Bindung des Steuerungssystems an den Main-Broker des Roboters Die letztendliche Bindung des Gesamtsystems an den MainBroker der lokalen NaoQI-Instanz des Roboters geschieht durch eine einfache Instanziierung des Brokermoduls im Gültigkeitsbereich des in Schritt 2 (vgl. S. 102) angelegten ALBrokers. 1 global SearchAndMoveObject 2 SearchAndMoveObject = SearchAndMove(" SearchAndMoveObject") Listing 6.10: Bindung des Steuerungssystems an den Main-Broker des Roboters Hierbei wird automatisch dessen Konstruktor durchlaufen und das vordefinierte Netz aus Objektreferenzen, NaoQI-Events und der automatischen Bindung aller dabei initialisierten ALModule zum Leben erweckt. Insbesondere durch letzteres ist somit das Steuerungssystem vollständig in NaoQI bekannt. 7. Unendlichkeitsschleife bis zum Ende des Systems Nach erfolgreicher Deklaration, Instanziierung und Bindung aller Komponenten verbleibt der Broker durch eine einfache Schleife solange aktiv, bis er nicht mehr gebraucht wird. 104

117 6.3. Modulimplementierung und Abläufe 1 try: 2 while True: 3 time.sleep(1) 4 except KeyboardInterrupt: 5 mybroker.shutdown() 6 sys.exit(0) Listing 6.11: Unendlichkeitsschleife bis zum Ende des Systems Letzteres tritt nur ein, wenn das Steuerungssystem seine Aufgabe beendet hat und kein Grund mehr für eine Kommunikation besteht. Daher endet die Implementierung dieses Moduls in dem in Listing 6.11 gezeigten Code. Somit sind alle Kernaspekte, welche bei der Implementierung des ClientBrokers beachtet werden müssen, vorgestellt Missionplanner Die Implementierung des Missionplanner-Moduls beinhaltet, entsprechend seiner Rolle des Missionsorganisators, den wesentlichen Programmablauf des gesamten Steuerungssystems. Um den abstrakten Such- bzw. Wegfindungsprozess des Gesamtkonzeptes dieser Arbeit abzubilden, müssen hierbei grundsätzlich alle Abhängigkeiten und Ergebnisse zwischen Karte, Navigation und Bewegung beachtet und miteinander koordiniert werden. Wie bereits in der Vorstellung des Softwaremodells erwähnt, ist dazu eine Art kontrollierende Suchschleife notwendig. Die hierfür realisierte Ausgestaltung lasst sich zunächst zusammenfassend durch folgendes Flussdiagramm beschreiben: Start initrobot() subscribevision() subscribesonar() Initialization setgoal() and setreplan() checkifdone() True SensorEvent setreplan() False Replan set? True MapToNavigator() False findway() save DirectionList() setdone() False existdirectives() True senddirectivesto Pilot() Search Loop Shut Down driveonepatch() End shutrobot() unsubscribe Vision() unsubscribe Sonar() Abbildung 6.11.: Ablauf des Missionplanner-Moduls 105

118 6. Prototypische Implementierung Wie in Abbildung 6.11 gesehen werden kann, sind hierbei neben der eigentlichen Suchschleife zwei weitere Segmente in der Implementierung vorzufinden. Sie sind zusätzlich notwendig, da das Missionplanner-Modul als zentrales Kontrollprogramm ebenfalls die Initialisierung bzw. das Herunterfahren des Aldebaran Nao-Roboters an sich sowie der für das Steuerungssystem notwendigen Sensorik durchführen muss. Schließlich dient es aufgrund seiner Rolle als fundamentaler Einsprungs- bzw. Endpunkt für das Gesamtsystem, welcher durch einen entsprechenden Aufruf am ClientBroker angestoßen und auch gestoppt werden kann. Deshalb wird im Folgenden auf die wesentlichen Kernaspekte der Implementierung jener einzelnen Segmente des Flussdiagramms näher eingegangen und ihre Bedeutung für das Steuerungssystem erläutert. 1. Initialisierung Da das Missionplanner-Modul stets parallel zu allen anderen Prozessen ausgeführt werden muss, besteht es grundsätzlich aus einem eigenen Thread im Steuerungssystem. Entsprechend wird es nach der dafür vorgesehenen Methodik in Python innerhalb seines Konstruktors initialisiert (vgl. Zeile 1, 4 ff. in Listing 6.12). Zusätzlich werden jedoch dort bereits auch einige Variablen definiert, welche für den Ablauf der Suchschleife von wesentlicher Relevanz sind (siehe dazu Segment 2, S. 107). Dies stellt eine Initialisierung des Moduls aus technischem Standpunkt dar. 1 class MissionPlanner( threading.thread): 2 def init (self,parent): 3 """ init planner """ 4 threading.thread. init (self) 5 self.parent = parent 6 self.running = True 7 self. fulfilled = False 8 self. max_cycles = None 9 self.cycles = 0 10 self. need_replan = False 11 pass def run(self): 14 #tell pilot to init the robot 15 self.parent.pilot. initrobot() #subscribe to the sensors 18 self.parent. visiondetector. subscribe(" SearchAndMove") 19 self.parent. sonardetector. subscribe(" SearchAndMove") #get reference to the system internal map 22 self.mymap=self.parent. cartographer.mymap #since we have no information, we sure need to replan 25 self. need_replan = True #we sure know our goal a priori, so lets set it 28 self.mymap [5][4] = [True,"goal",0,0] Listing 6.12: Initialisierung des Missionplanners Bei einem späteren Start des Systems beinhaltet weiterhin die Ablaufmethode des Threads die eigentliche Umsetzung des in Abbildung 6.11 dargestellten Programmflusses. Sie benötigt des weiteren die Durchführung weiterer Schritte zur Vorbereitung. Hierbei wird zunächst das Pilot-Modul angewiesen, die gesamte Roboterhardware zu initialisieren (Zeile 15 in Listing 6.12). Wie an den jeweiligen Modulimplementierungen später gesehen werden kann (vgl. Abschnitt 6.3.5, Seite 125), handelt es sich dabei um eine Anspannung aller Motoren/Gelenke, sowie der Ausführung einer vordefinierten Verhaltensweise zum Aufstehen, 106

119 6.3. Modulimplementierung und Abläufe sofern sich der Roboter in sitzender oder liegender Position befindet. Anschliessend wird die Sensorimplementierung gestartet. Da jene grundsätzlich in NaoQI durch sog. Extraktoren realisiert werden (vgl. Abschnitt 6.3.8, S. 136 ff.), erfolgt dies durch das Abonnieren ihrer jeweiligen Events (siehe dazu Zeile 18/19 in Listing 6.12). Somit erhält das Steuerungssystem kontinuierlich Umgebungsdaten. Schlussendlich werden Maßnahmen vorgenommen, welche das eigentliche Suchverhalten initialisieren. So wird ein vorher festgelegtes Ziel in die Karte eingetragen und die daraus resultierende Notwendigkeit einer Planung (zu diesem Ziel hin) entsprechend hinterlegt. 2. Suchschleife Die Suchschleife stellt das eigentliche Herzstück der Logik des Missionplanner-Moduls dar, welche im Rumpf der Ablaufmethode des umgebenden Threads gleich nach der Initialisierung zu finden ist und somit stets parallel zu den zentralen Erkennungsschleifen der Sensorimplementierung abläuft. Sie bildet den gesamten abstrakten Such- und Bewegungsprozess des Roboters im Raum ab und kann durch drei unterschiedliche Faktoren, welche bei jeder Iteration durch einen logischen Ausdruck überprüft werden, terminieren. 1 class MissionPlanner( threading.thread): 2 def run(self): 3 #init already done here 4 5 while self.running == True and self. fulfilled == False 6 and self.cycles < self. max_cycles: 7 if self. need_replan == True: 8 # give the navigator the map 9 self.parent. navigator.mymap=self.mymap # let him calculate a new way 12 self.parent. navigator.findway() # save the result in an internal array 15 self. direction_list = self.parent. navigator.erg # we have a new path, so replanning is done 18 self. need_replan = False 19 pass # if there is at least one direction to go in the list, we walk 22 if len(self. direction_list) >= 1: 23 # give the map to the pilot 24 self.parent.pilot. direction_list=self. direction_list # drive one patch further 27 self.parent.pilot. driveonepatch() 28 pass 29 else: 30 # the direction list is empty, we should be done 31 self. fulfilled = True 32 pass # increment cycle step for a reference how far the system advanced 35 self.cycles = self.cycles pass Listing 6.13: Suchschleife des Missionplanners Hierbei dienen die Variablen running und cycles für die Steuerung von außen, respektive für eine vorzeitige Beendigung des Steuerungssystems. Erstere konstituiert sich durch einen einfachen booleschen Wert. Zweitere hingegen wird als Integer-Zahl bei jedem Durchlauf der Suchschleife inkrementiert und enthält daher die Anzahl der bereits abgearbeiteten Bewegungsschritte. Lediglich die dritte Variable, fulfilled, hat etwas mit der eigentlichen Implementierung des Konzeptes zu tun. 107

120 6. Prototypische Implementierung Rein vom Prinzip her arbeitet das Steuerungssystem (und damit die Suchschleife) mit einer Liste von noch auszuführenden Bewegungsschritten (sog. Direktiven), welche die Erreichung des Ziels beschreiben und somit ermöglichen. Diese werden bei aktiver und paralleler Sensorimplementierung nacheinander sukzessive abgearbeitet. Erfolgt durch Events der Sensorimplementierung eine Veränderung von Teilen der Karte durch potentielle Gefahren im Bezugsraum, so wird der Missionplanner benachrichtigt, eine entsprechende Überarbeitung der Direktiven anzustoßen, um diesen auszuweichen. Das geschieht so lange, bis keine Direktive (bzw. Bewegungsschritt) mehr übrig ist, um das Ziel zu erreichen. Da sich der Roboter nun an diesem befinden sollte, kann die Mission als erfüllt deklariert werden. Deswegen wird dabei die hierfür vorgesehene Variable (fulfilled) gesetzt, um die Suchschleife zu verlassen. Eine Schleifeniteration beginnt daher grundsätzlich immer mit der Prüfung, ob eine Neuplanung der Bewegungsdirektiven notwendig ist. Die hierbei ausschlaggebende Variable, need_replan, wird entweder bei der ersten Iteration oder durch Sensorevents anderer Iterationen durch das Cartographer-Modul auf wahr gesetzt. In diesem Fall erfolgt anschließend eine Weitergabe einer Referenz auf die jeweils aktuelle Karte an das Navigator-Modul, welches daraufhin einen neuen Weg (und damit einen neuen Satz an Bewegungsdirektiven) bestimmt. Nach dem Speichern der Ergebnisse kann entsprechend der damit verbundene Zustand verlassen werden. All dies wird in den Zeilen 7 bis 19 in Listing 6.13 abgewickelt. In den Zeilen 22 bis 32 findet darüber hinaus die sukzessive Abarbeitung der Bewegungsdirektiven statt. Hierbei wird die Liste der verbleibenden Bewegungsschritte an das Pilot-Modul weitergegeben, welches sich gemäß seiner Implementierung (vgl. Abschnitt 6.3.5, ab S. 121) um die Abwicklung des dabei vorrangigsten Elementes bemüht. Nur wenn die Liste kein Element mehr enthält, kann die Suchschleife verlassen werden. 3. Herunterfahren Mit Beendigung der Suchschleife steht grundsätzlich fest, dass die Gesamtmission (unabhängig von der Art und Weise wieso) prinzipiell beendet ist. Aus diesem Grund verbleiben lediglich die in Abbildung 6.11 (S. 105) dargestellten Schritte, um das Robotersystem nach Erreichen des Ziels in den selben Ursprungszustand zu bringen, welcher vor der Initialisierung vorherrschte. 1 class MissionPlanner( threading.thread): 2 def run(self): 3 #init and search loop already done here 4 5 # unsubscribe to the sensors 6 self.parent. visiondetector. unsubscribe(" SearchAndMove") 7 self.parent. sonardetector. unsubscribe(" SearchAndMove") 8 9 #tell pilot to shut the robot down 10 self.parent.pilot. shutrobot() if self. fulfilled == True or self.cycles == self. max_cycles: 13 self.parent.speech.say("mission accomplished!") #Exit thread 16 self.stop() 17 return Listing 6.14: Herunterfahren des Missionplanners Wie in Listing 6.14 gesehen werden kann, sind dafür jedoch nur die entsprechenden Gegenstücke zu den Methoden der Initialisierung aufzurufen. Analog dazu wird daher die Sensorimplementierung durch eine Deabonnierung der damit verbundenen Events bzw. Extraktoren gestoppt (Zeile 6/7). Anschliessend fährt das gesamte Robotersystem auf Hardwareebene herunter. Das 108

121 6.3. Modulimplementierung und Abläufe schließt im Falle, dass sich der Nao noch im Stand befindet, die Rückkehr in eine sitzende Position, sowie eine Entspannung aller für die Gelenke maßgeblichen Motoren mit ein (vgl. dazu Implementierung Pilot, ab S. 125 bzw. Movement-Modul, ab S. 135). Schlussendlich kann der umgebende Thread beendet werden. Somit sind alle Kernaspekte und Prozesse, welche bei der Implementierung des Missionplanners realisiert wurden, vorgestellt Cartographer Die Konzeption und letztendlich prototypische Implementierung einer geeigneten Repräsentation der Umwelt des Robotersystems, welche sowohl die spezifischen Eigenheiten der Fortbewegung des Aldebaran Nao als auch eine möglichst simple bzw. effektive Grundlage für die Realisierung des Konzeptes modelliert, ist grundsätzlich kein einfaches Unterfangen. Hierfür spielen einfach zu viele unterschiedliche Faktoren eine maßgebliche Rolle. Wie beispielsweise schon leicht an der Diversität der hierfür geeigneten Lösungsansätze gesehen werden kann (vgl. Abschnitt 5.2.2, ab Seite 67), hängt die Wahl einer dafür idealen Datenstruktur zumeist allein schon von der Beschaffenheit des Raums, sowie von der Sensorik und Bewegungsfähigkeit des zu steuernden Roboters ab. Wenn wie im Falle des verwendeten Aldebaran Nao zusätzlich ein nur unzureichend genaues Fortbewegungssystem vorliegt (siehe Abschnitt 5.3.3, S. 77 f.), sind quasi bereits alle Ansätze, welche ein hohes Maß auf Präzision legen, von vornherein nicht mehr sinnvoll anwendbar. Deshalb wird daher bewusst nur die einfachste hierfür mögliche Datenstruktur, eine sog. Belegungstabelle 12, bei der Implementierung des Cartographer-Moduls ausgewählt. Die folgende Abbildung zeigt hierbei das damit verbundene Konzept im Falle der umzusetzenden Anforderungen dieser Arbeit schematisch auf. y = 0 Seitwärtsbewegung y = 9 x = 0 N Vorwärtsbewegung G Koordinate (x=4, y=9) 40cm 40cm [false, "", centroid_x, centroid_y] x = 9 [true, "stop150", centroid_x, centroid_y] Abbildung 6.12.: Konzept der Umweltrepräsentation im Cartographer-Modul 12 vgl. dazu [42], S. 358 bzw. S. 67 dieser Arbeit 109

122 6. Prototypische Implementierung Demnach konstituiert sich die Belegungstabelle der prototypischen Implementierung als ein einfaches zweidimensionales Array mit insgesamt 10 Zeilen und 10 Spalten. Hieraus ergibt sich eine Gesamtanzahl von 100 Zellen, welche allesamt uniforme Fragmente des Bezugsraums beliebiger Szenarien (vgl. dazu Szenario N in Abbildung 3.6, Seite 25) darstellen. Durch Messung und Test bei der Entwicklung des Laufsystems kann dabei ein solches Teilstück auf eine reelle Größe von etwa 40x40 Zentimetern festgelegt werden, was der Distanz einer elementaren Direktive bzgl. der Vorwärtsbewegung im Steuerungssystem entspricht (vgl. dazu Abschnitt 6.3.7, ab S. 127). Allerdings muss grundsätzlich die Vorraussetzung, dass dessen Ausführung fehlerfrei ablief, erfüllt sein. Die Orientierung in dieser Kartenstruktur ist absolut zu der initialen Startposition und Blickrichtung des Roboters zu sehen. Daher ist es für eine adäquate Funktion der Karte wichtig, dass er auch entsprechend bei der Abarbeitung eines beliebigen Szenarios immer von einem festen Startpunkt aus beginnt. Alle Zeilen des Datenmodells, die durch die x-koordinate einzeln adressiert werden können, repräsentieren dabei eine Vorwärtsbewegung im Bezugsraum. Analog dazu entsprechen dadurch alle Spalten Seitwärtsbewegungen auf der Karte, welche somit durch die y-koordinate eines Teilstücks erfassbar sind. Darüber hinaus beinhaltet jedes Fragment eine eigene Datenstruktur, welche Abruf und Modifikation seines jeweiligen Status bzgl. seiner Belegung im Kartenmodell ermöglicht. Wie in Abbildung 6.12 gesehen werden kann, handelt es sich dabei um ein weiteres eindimensionales Array, welches die damit verbundenen Informationen durch vier unterschiedliche Variablen beschreibt. Hierbei dient zunächst ein einfacher boolescher Wert zur Modellierung des grundsätzlichen Belegungszustandes. Sollte dieser Wert wahr sein, so enthalten die anderen Variablen zusätzliche Informationen über das vorliegende Objekt aus dem Bezugsraum, welches die jeweilige Zelle belegt. Sie bestehen aus einer kurzen Bezeichnung, sowie im Falle von Schildern welche im Rahmen dieser Arbeit potentielle Gefahrensituationen für den Nao darstellen weiterhin aus einem Satz von Koordinaten. Letztere beschreiben den Zentroid des Schildes, welcher dessen Position relativ zum Bildraum der damit verbundenen Aufnahmen der Kamera definiert. Grundsätzlich sind bei der Initialisierung der Kartenstruktur alle Zellen leer und somit für entsprechende Bewegungen des Roboters nutzbar. Belegungen ergeben sich im Modell weiterhin nur durch dessen Position bzw. des Ziels selbst, sowie durch alle Hindernisse, die auf dem Weg zu letzterem durch die Sensorik registriert werden (vgl. graue Zellen in Abbildung 6.12). Hierbei ist der Bestimmungsort, gemäß der Implementierung des Missionplanners (siehe dazu Abschnitt 6.3.2, S. 106 ff.), bereits im Voraus festgelegt. Die Lokalisation des Roboters hat darüber hinaus durch die bereits abgearbeiteten Bewegungsdirektiven des Steuerungssystems zu erfolgen. Eine Bewegung ist somit durch die Freigabe bzw. Belegung der jeweiligen Teilstücke der Karte darstellbar. Hindernisse werden jedoch auf eine andere Art und Weise in das Kartenmodell eingetragen. Hierfür erhält das Cartographer-Modul direkt Events aus der parallel ablaufenden Sensorimplementierung. Jene enthalten im Falle der Existenz von Hindernissen im unmittelbaren Blickfeld des Roboters deren Art, Zentroid, sowie eine Distanzabschätzung. In Verbindung mit der Lokalisation des Roboters wird dadurch deren Positionierung in der Belegungstabelle ermöglicht. Dazu muss anhand des Zentroids bzw. der Distanzabschätzung eine Zelle des Datenmodells ausgewählt werden, welche relativ zu diesen Daten deren Standort abschätzt. Bevor jedoch überhaupt eine entsprechende Änderung erfolgt, findet eine Kontrolle der sich hierbei ergebenden Zellen statt. Optional kann die Anzahl der maximal zu erfassenden Hindernisse festgelegt werden. Dadurch ist es möglich, Mehrfach- bzw. Fehlerkennungen schon im Vorfeld großteilig auszuschließen. Für eine Erfassung der Fehler des Fortbewegungssystems des Aldebaran Nao, werden darüber hinaus alle erkannten Hindernisse im Kartenmodell mit einer stärkeren Gewichtung versehen (vgl. graue Zellen um das Stop-Schild in Abbildung 6.12). Ein derartiger Updateprozess ist zudem 110

123 6.3. Modulimplementierung und Abläufe immer mit der Benachrichtigung des Missionplanners zu verbinden, welcher daraufhin gemäß seiner Implementierung eine Neuplanung der Bewegungsdirektiven veranlässt. Durch diesen Entwurf ergibt sich somit eine Realisierung eines Kartenmodells, welche den Anforderungen des Gesamtkonzepts entspricht. Daher werden im Folgenden drei wesentliche Segmente hiervon, welche die Initialisierung, die Eintragung von Hindernissen, sowie die Lokalisation des Roboters im Steuerungssystem ermöglichen, kurz auf Codeebene näher betrachtet. 1. Initialisierung Die Initialisierung der Kartenstruktur findet bereits bei der Instanziierung eines Cartographer- Modulobjektes statt. 1 class Cartographer( ALModule): 2 def init (self,name,parent): 3 ALModule. init (self,name) 4 self.parent = parent 5 self.y_max = range(10) 6 self.x_max = range(10) # Dimension 10x10 7 self.mymap = None 8 self. my_position = None 9 self. initoccupancygrid() 10 self. initrobotposition() 11 pass def initoccupancygrid(self): 14 self.mymap = [[ [False,"",0,0] for col in self.y_max] for row in self.x_max] 15 pass def initrobotposition(self): 18 self.mymap [0][4] = [True,"naorobot",0,0] 19 pass Listing 6.15: Initialisierung der Belegungtabelle in Python Wie die Implementierung des Konstruktors in Listing 6.15 zeigt, werden hierfür nach der obligatorischen Vernetzung des Moduls mit NaoQI bzw. dem ClientBroker des Steuerungssystems (Zeilen 3 und 4) verschiedene Variablen angelegt. Diese dienen zur Festlegung der Dimension und zur Speicherung der Datenstruktur im Objekt (Zeilen 5-8). Anschließend erfolgen Methodenaufrufe, welche letztendlich gemäß des o. g. Konzeptes die Belegungstabelle erzeugen und die Startposition des Roboters in dieser eintragen. Abbildung 6.13.: Konsolenausgabe der initialisierten Belegungstabelle des Steuerungssystems In der Programmiersprache Python ist ein derartiges Array grundsätzlich durch eine zweidimensionale Liste zu beschreiben, deren Erzeugung auf einfache Art und Weise in Zeile 14 (Listing 6.15) vorgenommen wird. Der Zugriff auf einzelne Zellen bzw. die Zuweisung von Belegungsdaten erfolgt anschließend, analog zu Arrays anderer Sprachen, mithilfe der entsprechenden Operatoren (Zeile 18). Durch Ausgabe der Variable mymap auf der Konsole ist erkennbar, dass somit eine Instanz der Belegungstabelle vorliegt (vgl. Abbildung 6.13). Diese wird weiterhin kontinuierlich im Steuerungssystem gehalten und erst mit dessen Terminierung gelöscht. 111

124 6. Prototypische Implementierung 2. Eintragung von Hindernissen Listing 6.16 enthält einen Auszug aus der Methode, welche die Eintragung von potentiellen Gefahren in die Belegungstabelle des Cartographer-Moduls nach dem o. g. Konzept vornimmt. Hierbei wird, stellvertretend für alle anderen Fälle, der damit verbundene Prozess im Falle der Erkennung eines Schildes, das Rutschgefahr durch Rollsplitt symbolisiert, aufgezeigt. 1 def update(self, strvarname, value, message): # cartographer callback function 2 if self. listening == True and self. obstacle_amount < self. max_obstacles: 3 if value[0] == " slippery150" 4 and self. slippery_scenario_seen < self. slippery_scenario_amount: 5 if value[3] <= 60: #more than 1.5 patches away 6 x_penalty, y_penalty = self. getdirectedestimatedpenalties(value[1], 7 value[2]) 8 estd_x = self. my_position[0] + x_penalty 9 estd_y = self. my_position[1] + y_penalty 10 if self. updatepatch(value, estd_x, estd_y): 11 self. listening=false 12 self. expandobstaclescontrolled(estd_x,estd_y) 13 self.parent.mission. need_replan=true 14 self. obstacle_amount = self. obstacle_amount self. slippery_scenario_seen = self. slippery_scenario_seen pass 17 pass 18 pass 19 pass Listing 6.16: Ausschnitt aus der Update-Funktion der Belegungtabelle des Steuerungssystems Gemäß dem Softwaremodell empfängt sie hierzu direkt Events als Handler aus der parallel ablaufenden Sensorimplementierung (zuvor aktiviert durch den Missionplanner bzw. gebunden durch den ClientBroker) und verarbeitet die mit ihnen übertragenen Umgebungsdaten weiter. Diese befinden sich in der Variable value, die seitens des NaoQI-Systems automatisch beim Aufruf des Eventhandlers befüllt wird. Noch bevor dabei eigentlich irgendeine Auswertung geschieht, muss jedoch zuerst auf globaler Ebene eine Überprüfung stattfinden, ob zur Zeit überhaupt die Verarbeitung von Sensordaten gewünscht ist (Zeile 2). Das stellt das erste und pragmatischste Mittel zur Vermeidung von Mehrfach- oder Fehlerkennungen dar, welches entsprechend von aussen oder durch eine maximale Anzahl an zu erkennenden Hindernissen geregelt werden kann. Ist die Verarbeitung aktiviert, so wird weiterhin durch eine Kaskade von unterschiedlichen Abfragen der Inhalt der value-variable weiter evaluiert. Hierbei wird zuerst der Typ der Gefahr untersucht (Zeile 3/4). Aufgrunddessen kann an dieser Stelle auch eine Plausibilitätsprüfung der Messung erfolgen, welche ebenfalls eine Mehrfachbzw. Fehlerkennung anhand der Häufigkeit einer bestimmten Gefahrenklasse im Datenmodell als pragmatisches Mittel erschwert. Natürlich werden somit Kenntnisse über das abzuarbeitende Szenario bereits im Vorfeld in das System eingegeben, was nur im Falle der prototypischen Implementierung des Konzeptes am Aldebaran Nao wirklich sinnvoll ist. Fällt die Prüfung positiv aus, wird anhand der Distanz der Gefahr beschlossen, ob und welche Maßnahmen für dessen Eintragung in die Kartenstruktur vorgenommen werden müssen. Wie man gleich erkennen kann, begründet sich dies durch eine Anwendung unterschiedlicher Gewichte bei der Abschätzung der Gefahrenposition. Aus Gründen der Vereinfachung wird dabei in Listing 6.16 nur ein derartiger Block (Zeilen 5-15) gezeigt, welcher die Verarbeitung besonders naher Gefahren verdeutlicht. Er enthält die eigentliche Implementierung für die Eintragung, welche vom Ansatz her parallel in allen anderen Teilen der Kaskade vorkommt. Als erstes wird in den Zeilen 6 bis 9 (Listing 6.16) eben jene Abschätzung der Gefahrenposition vorgenommen. Die in diesem Fall herangezogene Methode ist in Listing 6.17 zu sehen. 112

125 6.3. Modulimplementierung und Abläufe 1 def getdirectedestimatedpenalties(self,val1,val2): 2 perspective=self.parent.pilot. last_direction 3 if perspective == "forward": 4 return (2, self. estimator150(val1,val2)) 5 elif perspective == "left": 6 return (self. estimator150(val1,val2),2) 7 elif perspective == "right": 8 return (self. estimator150(val1,val2),-2) 9 pass Listing 6.17: Funktion zur Abschätzung der Position einer Gefahr im nahen Fall Sie bestimmt ein Paar an Gewichten, welche relativ zur letzten Bewegungsdirektive berechnet und zugewiesen werden. Durch die absolute Orientierung der Karte ergibt sich natürlich ein Wechsel derer Reihenfolge und Vorzeichen bei Rotation des Roboters. Da das Hindernis weniger als zwei Kartenfragmente entfernt war, wird in diesem Fall entsprechend die 2 als Distanzgewicht genutzt. Analog dazu ist letzteres bei größeren Entfernungen natürlich zu erhöhen, was andere Funktionen im Cartographer-Modul auch abbilden. Für die Erzeugung des Lagegewichts dient hingegen eine Auswertung des Zentroids, welcher entsprechend aus der value-variable Linke Bildhälfte LGW= -1 Bildmitte LGW= 0 Rechte Bildhälfte LGW= +1 Abbildung 6.14.: LGW durch Zentroidestimation zuvor übergeben wurde. Anhand dessen x-koordinate wird in der dazu genutzten Methode des Cartographer-Moduls, estimator150, einfach die somit bekannte relative Lage des Hindernisses im Bild genutzt, um eine Aussage über dessen Richtung zu erhalten. Abbildung 6.14 zeigt das an einem Bild aus dem Robotersystem exemplarisch auf. y =3 y = 5 y = 3 y = 9 x = 0 Start x = 0 Start N N x = 5 Sensorwert: ["stop150", 160, 120] Orientierung: forward DGW = 2, LGW = 0 Nao = (1,4) Koordinate = (3,4) x = 3 Sensorwert: ["stop150", 300, 120] Orientierung: left DGW = 2, LGW = 1 Nao = (1,5) Koordinate = (2,7) (a) Schätzung bei Forward-Direktive (b) Schätzung bei Left-Direktive Abbildung 6.15.: Visualisierung zweier beispielhafter Schätzungsprozesse Wie in Zeile 8/9 (Listing 6.16) erkennbar ist, werden letztendlich die so gewonnenen Gewichte einfach auf die jeweiligen Koordinaten der derzeitigen Roboterposition addiert, um somit die Position des Hindernisses in der Karte zu estimieren. Das dabei realisierte Systemverhalten ist essenziell für die Funktion des Cartographer-Moduls und daher in den Abbildungen 6.15a und 6.15b beispielhaft visualisiert. Im einfachen Fall der Abschätzung eines direkt vorausliegenden Schildes (Abbildung 6.15a) führt der Algorithmus daher lediglich zu einer entsprechenden Inkrementierung der x-koordinate durch das Distanzgewicht. Selbst jedoch in einem komplexeren Szenario, bei dem der Roboter bereits eine Linksdrehung vollzogen und ein nicht vor ihm unmittelbar liegendes Schild erkannt hat, werden richtige Ergebnisse erzeugt. Hierbei führt eine 113

126 6. Prototypische Implementierung geschickte Drehung der Gewichte (vgl. Zeile 6 in Listing 6.17) zu einer passenden Abschätzung der Hindernisposition im absoluten Weltbild der Kartenstruktur. Anschließend wird in Zeile 10 (Listing 6.16, S. 112) versucht, das so gewonnene Koordinatenpaar als neue potentielle Gefahr in die Karte einzutragen. Dazu findet zunächst eine Prüfung statt, ob die avisierte Zelle überhaupt unbesetzt ist. Ist das der Fall, so werden die Sensordaten in diese übertragen und der Zustandswert des Teilbereichs auf true gesetzt. Scheitert die Überprüfung, so ist das entsprechende Fragment bereits besetzt und eine Weiterverarbeitung daher nicht notwendig. Bei einer erfolgreichen Eintragung verbleibt gemäß dem o. g. Konzept noch die Gewichtung des neuen Hindernisses in der Belegungstabelle und die Benachrichtigung des Missionplanners. Letzteres geschieht durch ein einfaches Setzen der hierfür vorgesehenen Variable über die ClientBroker-Verbindung (Zeile 13, Listing 6.16, S. 112). Darüber hinaus werden in den Zeilen 11, 14 und 15 weitere pragmatische Maßnahmen für die Vermeidung von Messfehlern ergriffen. So erfolgt eine Inkrementierung der jeweiligen Zählvariablen für die bereits vorgestellten Plausibilitätsprüfungen. Ausserdem wird im Rahmen der prototypischen Implementierung kurzweilig die Interpretation der Events deaktiviert. Wie später in der Realisierung des Pilot-Moduls erkennbar ist (vgl. Listing 6.26, Seite 124), wird dies jedoch bei der Abarbeitung einer neuen Bewegung sofort rückgängig gemacht, um den Erhalt neuer Messwerte zu ermöglichen. 1 def expandobstaclescontrolled(self,x,y): 2 centroid_checker = any(item[0] == x and item[1] == y for item in self. expanded) 3 if centroid_checker == True: 4 return 5 neighbors_checker = False # we assume all neighbors are ok 6 7 #check here for neighbor collision 8 n1 = any(item[0] == x+1 and item[1] == y for item in self. expanded) 9 n2 = any(item[0] == x-1 and item[1] == y for item in self. expanded) 10 n3 = any(item[0] == x and item[1] == y+1 for item in self. expanded) 11 n4 = any(item[0] == x and item[1] == y-1 for item in self. expanded) 12 n5 = any(item[0] == x+1 and item[1] == y+1 for item in self. expanded) 13 n6 = any(item[0] == x-1 and item[1] == y+1 for item in self. expanded) 14 n7 = any(item[0] == x+1 and item[1] == y-1 for item in self. expanded) 15 n8 = any(item[0] == x-1 and item[1] == y-1 for item in self. expanded) if n1 == True or n2 == True or n3 == True or n4 == True or n5 == True 18 or n6 == True or n7 == True or n8 == True: 19 neighbors_checker = True 20 pass if neighbors_checker == True: 23 return #if the item is not there, add it to the list 26 self.expanded.append((x,y)) if x > 0 and centroid_checker == False and neighbors_checker == False: 29 if y > 0 and centroid_checker == False and neighbors_checker == False: 30 try: 31 self.mymap[x+1][y] = self.mymap[x][y] 32 self. expanded.append((x+1,y)) 33 except Exception, e: 34 pass 35 #and so on for every neighbour Listing 6.18: Ausschnitt der Funktion zur Gewichtung einer Gefahr in der Belegungstabelle Letztendlich findet die Gewichtung eines Hindernisses in der Kartenstruktur durch eine einfache Expansion seiner Daten an alle direkt umliegenden Nachbarn statt (vgl. Zeile 12 der Auflistung auf Seite 112). Die hierfür signifikanten Schritte der damit verbundenen Methode sind in Listing 6.18 zu sehen. Hierbei wird zuerst geprüft, ob der jeweilige Punkt nicht bereits expandiert wor- 114

127 6.3. Modulimplementierung und Abläufe den ist. Dazu besitzt das Cartographer-Modul eine Liste an allen bereits ausgedehnten Punkten. Mittels des Kommandos in Zeile 2 erfolgt daher eine entsprechende Abfrage. Da darüber hinaus nicht bereits expandierte Zellen anderer Hindernisse überschrieben werden dürfen, wird selbiges auch für alle potentiellen Nachbarn ausgeführt. Schlägt jeweils eine von beiden Prüfungen fehl, findet keine Expansion statt, um das Modell nicht unnötig zu überfluten. Sind jedoch alle Tests positiv ausgefallen, werden einfach alle Daten zwischen den Zellen kopiert und letztere der Belegungsliste des Cartographer-Moduls hinzugefügt. Durch die Implementierung all dieser Schritte ist es somit möglich, Gefahren in der Kartenstruktur nach dessen Konzept einzutragen. 3. Lokalisation des Roboters im Steuerungssystem Da gemäß dem o. g. Konzept die Lokalisation des Roboters durch die bereits abgearbeiteten Bewegungsdirektiven des Steuerungssystems zu erfolgen hat, sind in der Implementierung des Cartographer-Moduls ebenso einige Schnittstellen hierfür enthalten. Listing 6.19 zeigt die dazu am häufigsten genutzte Methode. 1 def updateposition(self, x, y): 2 if x > self.x_max[-1] or y > self.y_max[-1]: 3 return False 4 else: 5 target_patch = self.mymap[x][y] 6 if target_patch[0]!= False or target_patch [1]!= "" or target_patch [2]!= 0 7 or target_patch[3]!= 0: 8 return False 9 else: 10 self.mymap[self. my_position [0]][ self. my_position [1]] = [False,"",0,0] 11 self. my_position = (x,y) 12 self.mymap[x][y] = [True,"naorobot",0,0] 13 return True Listing 6.19: Lokalisation des Roboters im Steuerungssystem durch Zugriffsmethoden Wie an diesem Codefragment leicht zu erkennen ist, sind jene jedoch nicht besonders komplex. Das kommt von der Simplizität der hierbei verwendeten Datenstruktur. Die Selbstlokalisation des Roboters in der Karte erfolgt somit einfach nur durch eine simple Umbelegung seiner speziellen Zelle in der Belegungstabelle. Das Ziel muss dabei von der Implementierung des Pilot-Moduls bestimmt werden (vgl. Abschnitt 6.3.5, ab S. 125). Ist eine gewünschte Zelle nicht verfügbar, so wird eine Umbelegung entsprechend verweigert, was eine Fehlerbehandlung seitens des aufrufenden Moduls notwendig macht. Durch die Betrachtung dieser Segmente der Implementierung des Cartographer-Moduls sind somit alle damit verbundenen Kernaspekte und Prozesse vorgestellt Navigator/NavNode Die Implementierung eines adäquaten Navigator-Moduls bedeutet im Wesentlichen die Lösung des heutzutage häufig vorkommenden Problems einer automatisierten Wegfindung. Wie die Vorstellung diesbezüglicher Lösungsmöglichkeiten zeigt (vgl. Abschnitt 5.1.4, S. 62), existiert dazu eine Vielfalt an hierfür nutzbaren Algorithmen in der Informatik bzw. Robotik. Im Rahmen erster Tests bei der prototypischen Implementierung des Gesamtkonzeptes am Aldebaran Nao wurden daher einige hiervon in der Theorie näher untersucht. Dies umfasste zunächst pragmatische Ansätze, wie die Wegfindung durch eine simple Flutung der Kartenstruktur (gegeben durch Dijkstra bzw. FloodFill-Algorithmus). Im Zuge fortschreitender Studien in diesem Fachgebiet jedoch sind dabei durchaus auch die darauf aufbauenden Weiterentwicklungen (A 115

128 6. Prototypische Implementierung bzw. A*-Algorithmus) betrachtet worden. Schlussendlich ergab sich sogar bei der Evaluation entsprechender Werke aus der Robotik 13 eine Analyse hierauf speziell zugeschnittener Abarten (D bzw. D*-Algorithmus), welche Wegfindung in unbekannten Szenarien unter geringstem Rechenaufwand versprechen. Bei der finalen Auswahl, welcher Ansatz aus dieser umfassenden Bandbreite letztendlich zum Einsatz kommt, spielten einige Aspekte bzw. Anforderungen eine wesentliche Rolle. So sollte der Algorithmus grundsätzlich zunächst möglichst nicht schwierig zu verstehen bzw. zu implementieren sein. Ausserdem wäre es sinnvoll, wenn die berechneten Wege so effizient wie möglich ausfallen. Darüber hinaus ist selbstverständlich eine möglichst einfach herzustellende Kompatibilität mit der Kartenstruktur des Cartographer-Moduls (welche sich durch eine Belegungstabelle konstituiert, vgl. dazu Abschnitt 6.3.3, S. 109 ff.) wünschenswert. Weil der Systemprozessor des verwendeten Aldebaran Nao zwar nicht sehr schnell, jedoch aber durchaus leistungsfähiger als gewöhnliche integrierte Steuerungslösungen aus der Elektrik ist, sind besonders rechenarme Algorithmen jedoch nicht unbedingt erforderlich. Da die Implementierung des A*-Algorithmus sich hierbei am besten mit diesen Anforderungen deckt, wurde er daher als Ausgangspunkt für die Realisierung des Navigator-Moduls verwendet. Um ihn in das System des Softwaremodells einzubetten, sind dabei die folgenden, wesentlichen Prozesse umzusetzen gewesen: 1. Herstellung der Kompatibilität durch Transformation der Kartenstruktur 2. Wegfindung auf Knotenebene 3. Erstellung von Bewegungsdirektiven für das Steuerungssystem Deshalb werden diese wichtigen Segmente der Realisierung im Folgenden näher betrachtet. 1. Herstellung der Kompatibilität durch Transformation der Kartenstruktur Da der A*-Algorithmus aus dem Spezialgebiet der Graphentheorie stammt, operiert er grundsätzlich nur auf Datenstrukturen, welche sich aus Knoten zusammensetzen. Dies steht zunächst augenscheinlich im Widerspruch mit dem Implementierungskonzept des Cartographer-Moduls, welches eine Belegungstabelle für die Lokalisation von Hindernissen bzw. des Roboters selbst im Bezugsraum eines Szenarios vorsieht (vgl. S. 109 ff.). Aufgrund der Tatsache jedoch, dass für die erfolgreiche Umwandlung in eine Knotenrepräsentation lediglich nur eine Modellierung der Nachbarschaftsbeziehungen zwischen den einzelnen Zellen der Tabelle durchgeführt werden muss, ist grundsätzlich die Möglichkeit einer entsprechenden Transformation gegeben. Die hierfür notwendige Implementierung eines Knotens bzw. die Methode des Navigator-Moduls, welche den Umwandlungsprozess letztendlich vornimmt, ist in Listing 6.20 zu sehen. Ein Knoten-Objekt besteht demnach zunächst einfach aus den Koordinaten einer Zelle der Belegungstabelle. Darüber hinaus kann jedes derartige Objekt durch eine eigene Methode selbstständig seine Nachbarn berechnen. Dies kommt einer Modellierung von solchen Beziehungen gleich. Die Menge der hierfür zu wählenden Elemente der Tabelle hängt dabei jeweils vom zu realisierenden Bewegungsverhalten bzw. der Holonomie des zu steuernden Roboters ab Wege Nachbarschaften verbieten beispielsweise diagonale Schritte bei der späteren Abarbeitung eines Pfades. Analog dazu erfordern Richtungsänderungen jedoch dann eine stationäre Drehung um 90 innerhalb eines Knotens. Da das Bewegungsmodell des Aldebaran Nao durch seine Ungenauigkeit keine zuverlässige Ausführung diagonaler Bewegungen ermöglicht, wurde deswegen bei 13 vgl. dazu [42], S bzw. [23], [50] 14 vgl. [42], S. 358,

129 6.3. Modulimplementierung und Abläufe der Implementierung auf einen 4-Wege Ansatz zurückgegriffen. Um die Heuristik bzw. Kostenberechnung, welche als Basis für die Wegfindung des A*-Algorithmus fungieren (siehe Segment 2, S. 118 ff.), abzubilden, besitzt jeder Knoten ausserdem die Variablen g und h sowie einen eigenen Gleichheitsoperator. 1 class navnode(object): 2 def init (self,x,y): 3 self.x, self.y = (x,y) 4 self.g = 0 5 self.h = 0 6 self.parent = None 7 pass 8 9 def eq (self,other): 10 return isinstance(other, navnode) and 11 (self.x == other.x and self.y == other.y) def neighbors(self): 14 n1 = navnode(self.x - 1, self.y) # left neighbor 15 n2 = navnode(self.x, self.y + 1) # under neighbor 16 n3 = navnode(self.x + 1, self.y) # right neighbor 17 n4 = navnode(self.x, self.y - 1) # upper neighbor 18 return (n1,n2,n3,n4) def getf(self): 21 return self.g + self.h f = property(getf) def transformgrid(self): 26 for x in range(10): 27 for y in range(10): 28 if self.mymap[x][y][1] == "stop150" 29 or self.mymap[x][y][1] == " slippery150" 30 or self.mymap[x][y][1] == " SensedEvent" 31 or self.mymap[x][y][1] == " stairs150": 32 self. obstacles.append(navnode(x,y)) 33 if self.mymap[x][y][1] == "goal": 34 self.goalnode = navnode(x,y) 35 if self.mymap[x][y][1] == "naorobot": 36 self. startnode = navnode(x,y) # Maintain a list for all nodes 39 self. nodelist.append(navnode(x,y)) 40 pass 41 pass 42 return Listing 6.20: Transformation der Kartenstruktur in Knoten Für die eigentliche Transformation werden hierbei durch die Methode (Zeile 25) alle Elemente der Belegungstabelle durch Schleifen durchlaufen und entsprechende Objekte erzeugt. Wie an den Zeilen 27 bis 34 erkennbar ist, erfolgt ausserdem eine Zuordnung der Knoten in verschiedene Listen anhand ihrer ursprünglichen Bedeutung in der Kartenstruktur. Dies hängt mit der Implementierung der eigentlichen Wegfindung auf Knotenebene zusammen, die im nächsten Segment näher betrachtet wird (S. 118 ff.). Hierbei entsprechen allen möglichen potentiellen Gefahren Hindernisknoten, die später aufgrund ihrer Sonderstellung nicht in die Planung mit einbezogen werden. Somit entsteht auf Basis der Belegungstabelle eine knotenbasierte Datenstruktur der Karte, wie sie in Abbildung 6.16 visualisiert ist. Sie stellt dabei das Äquivalent zum Szenario in Abbildung 6.12 (Seite 109) dar. 117

130 6. Prototypische Implementierung y = 0 Seitwärtsbewegung y = 9 x = 0 L L L L N L L L L L L L L L L L L L L L L L L H H H L L L L Vorwärtsbewegung L L L L L L H H H L L L L L L H H H L L L L L L L L L L L L L L L L G L L L L L L L L L L L L L L L L L L L L L L L L L x = 9 L L L L L L L L L L Abbildung 6.16.: Knotenbasierte Repräsentation der Belegungstabelle 2. Wegfindung auf Knotenebene Durch die Transformation der Belegungstabelle des Cartographer-Moduls in eine knotenbasierte Form kann anschließend eine Implementierung des A*-Algorithmus die eigentliche Wegfindung durchführen. Die hierfür erstellten Methoden des Navigator-Moduls sind in Listing 6.21 zu sehen. 1 def manhattan(self,position,goal): 2 return abs(goal.x - position.x) + abs(goal.y - position.y) 3 4 def performsearch(self, obsts, start, goal): 5 openlist = [start] 6 closedlist = [] 7 8 while openlist: 9 n = min(openlist, key=lambda x: x.f) 10 if n == goal: 11 result = [] 12 while n.parent: 13 result.append(n) 14 n = n.parent 15 return result 16 openlist.remove(n) 17 closedlist.append(n) 18 for neighbor in n. neighbors(): 19 if neighbor in self. obstacles: 20 continue 21 neighbor.g = n.g if neighbor in openlist + closedlist: 23 continue 24 neighbor.h = self. manhattan(neighbor, goal) 25 neighbor.parent = n 26 openlist.append( neighbor) 27 return [] Listing 6.21: Wegfindung auf Knotenebene durch A*-Algorithmus in Python 118

131 6.3. Modulimplementierung und Abläufe Hierbei enthält die Funktion performsearch eine leicht modifizierte Fassung dieses Algorithmus, wie er in praktisch jedem Lehrbuch zur Graphentheorie bzw. auf vielen Internetseiten, die sich mit diesem Thema befassen, zu finden ist. 15 Er wurde lediglich mit den Mitteln der Programmiersprache Python realisiert und bzgl. des Einsatzszenarios etwas verändert. Wie die Originalfassung arbeitet diese Variante grundsätzlich auf Basis einer Analyse aller Knoten, welche zwischen Start und Ziel liegen. Ebenfalls parallel ist dabei die Verwendung zweier Listen, die für den Suchprozess wesentlich sind. Sie können in den Zeilen 5 bzw. 6 (Listing 6.21) gefunden werden. Die Variable openlist beinhaltet alle Knoten, die durch die Analyse bereits bekannt sind und möglicherweise noch einen Weg zum Ziel darstellen könnten. Zu Beginn des Algorithmus kommt dafür natürlich nur der Startknoten als Initialisierung in Frage. Er ist, im Falle der prototypischen Implementierung, gleichzusetzen mit der Position des Roboters. Im Gegensatz dazu hat die closedlist alle diejenigen Knoten aufzunehmen, die bereits vollständig bei der Wegberechnung berücksichtigt wurden. Der eigentliche Suchprozess wird durch eine Schleife auf der openlist realisiert, welche zwischen den Zeilen 8 und 27 (Listing 6.21) zu finden ist. Dabei ist es zunächst immer notwendig, denjenigen Knoten aus ihr auszuwählen, welcher gerade die minimalsten Kosten zum Ziel verspricht. G L L L L L L L L L L L L L L L Abbildung 6.17.: Manhattan - Distanz zwischen Knoten Wie bereits in Segment 1 (S. 116) ankündigt, werden hierfür die beiden Variablen g und h eines Knotens als Quellen für eine Heuristik zur Kostenabschätzung benutzt. g beinhaltet die Länge des bereits zurückgelegten Weges, um einen Knoten zu erreichen. Dies ist, im Falle der transformierten Datenstruktur der Implementierung, gleichzusetzen mit der Anzahl der hierfür vom Startpunkt aus zu durchlaufenden Zellen. Im Gegensatz dazu enthält h eine Abschätzung der Distanz eines Knotens zum Ziel. Jene basiert auf der sog. Manhattan-Metrik. Hierzu wird die Summe der absoluten Differenzen aller Koordinatenkomponenten zwischen dem gerade betrachteten und dem Zielknoten gebildet, um einen Abstandswert zu erhalten. Die hierfür ausschlaggebende Hilfsfunktion ist den ersten beiden Zeilen der Codeauflistung zu finden. Abbildung 6.17 zeigt das dabei realisierte Prinzip exemplarisch auf. Eine einfache Addition von g und h ergibt weiterhin eine Zahl f, welche somit ein Kostenmaß eines Knotens im Sinne der Wegfindung zum Ziel darstellt. Initial ist es bei allen Knoten 0 und wird erst im weiteren Suchverlauf effektiv berechnet, wie später in dessen Implementierung gesehen werden kann. In der Programmiersprache Python lässt sich der o. g. Selektionsprozess sehr elegant durch das in der Zeile 9 gezeigte Kommando umsetzen. Hierbei wird der entsprechende Knoten aus der openlist anhand der global verfügbaren Minimumsfunktion in Verbindung mit einem Lamba- Operator als Schlüssel, welcher das Kostenmaß jedes Knotens als Seiteneffekt neu berechnet, gefunden und zugewiesen. Anschliessend muss, analog zur standardgemäßen Methodik des A*- Algorithmus, der auf diese Art und Weise erhaltene Knoten weiter analysiert werden. Hierfür wird er aus der openlist entnommen und der closedlist hinzugefügt (Zeile 16/17). Weiterhin besteht die Analyse im eigentlichen Sinne des Suchprozesses aus einer Betrachtung seiner Nachbarn (Zeile 18-26). An dieser Stelle ergibt sich ein wesentlicher Unterschied zur Referenzimplementierung. Hierbei gilt, dass alle Knoten der Nachbarschaft, welche ein Hindernis darstellen, niemals weiter analysiert werden. Dadurch ergibt sich deren Ignorierung bei der Berechnung eines Weges bzw. letztendlich das hindernisvermeidende Verhalten bei der Navigation, was eine diesbezüglich komplexe Modifikation der Heuristik vermeidet. 15 vgl. z. B. [49], S. 274 f. 119

132 6. Prototypische Implementierung Ansonsten ist die Analysephase des Algorithmus in Listing 6.21 jedoch unverändert. Demgemäß dürfen jene Nachbarn des Knotens, welche bereits Teil einer der beiden beiden Listen sind, nicht weiter betrachtet werden (Zeile 22/23). Ausserdem wird das Kostenmaß bzw. werden die entsprechenden Komponenten eines jeden Nachbarknotens neu generiert und diese der openlist hinzugefügt. Das realisiert sowohl deren spätere Berücksichtigung bei der Suche als auch die effektive Berechnung ihres jeweiligen Kostenmaßes zur Laufzeit. Darüber hinaus erhalten sie eine Referenz auf ihren zentralen Knoten. Dies alles geschieht so lange, bis entweder kein Knoten mehr in der openlist für die Analyse übrig ist oder dabei der Zielknoten als Element mit dem geringsten Kostenmaß auftritt. Im ersten Fall wäre dann kein Pfad zum Ziel möglich. Entsprechend anders ist der zweite Fall zu sehen. Da das Ziel hierbei durch eine wiederholte Ausführung der Analyse derjenigen Knoten mit dem minimalsten Kostenmaß erreicht wurde, gilt ein Pfad als gefunden. Er ist daher sogar der kürzest mögliche. Um ihn zu erhalten, muss lediglich nur noch jede Referenz auf die daran beteiligen Zentralknoten bis zum Start hin aufgelöst werden. Somit erhält man einen Pfad in Form von allen zu durchlaufenden Knoten zwischen Ziel und Start, welcher sich weiter verarbeiten lässt. Wenn man ihre Koordinaten im Fall des Szenarios von Abbildung 6.16 (S. 118) ausgibt, so zeigt sich beispielhaft folgendes Ergebnis: Node 0: x=6 and y=4 Node 1: x=6 and y=5 Node 2: x=6 and y=6 Node 3: x=5 and y=6 Node 4: x=4 and y=6 Node 5: x=3 and y=6 Node 6: x=2 and y=6 Node 7: x=1 and y=6 Node 8: x=1 and y=5 Node 9: x=1 and y=4 Wie ein kurzer Vergleich ergibt, beschreiben sie tatsächlich einen gültigen Pfad, welcher das Hindernis vermeidet. 3. Erstellung von Bewegungsdirektiven für das Steuerungssystem Auf dieser Basis können dann letztendlich die Bewegungsdirektiven erstellt werden, welche für die Steuerung des Aldebaran Nao im Bezugsraum eines Szenarios heranzuziehen sind (vgl. dazu Implementierung des Missionplanners, Abschnitt 6.3.2, S. 105 ff.). Dies erfordert lediglich eine Rücktransformation des Ergebnisses der Wegfindung in die absolut orientierte Umweltrepräsentation des Cartographer-Moduls. Listing 6.22 zeigt die hierfür implementierte Methode des Navigationssystems. Wie an ihr gesehen werden kann, stellt diese Aufgabe jedoch kein komplexes Unterfangen dar. Zuerst wird hierbei die Liste der Knoten invertiert, um entsprechend einen Pfad vom Startknoten (bzw. der gegenwärtigen Position des Roboters) zum Ziel zu erhalten (Zeile 2). Anschließend findet eine einfache Betrachtung der relativen Position zweier aufeinander folgender Knoten des Ergebnisses statt, um so auf die Richtung der damit verbundenen Bewegung zu schließen. Hierzu wird eine Schleife durchlaufen, welche jeweils in Abhängigkeit ihrer Koordinaten in der Belegungstabelle eindeutige Schlüsse aus absoluter Perspektive zieht (Zeilen 11-26). Diese werden dann in einem Array zusammengefasst und als Bewegungsdirektiven an das Steuerungssystem übergeben. 120

133 6.3. Modulimplementierung und Abläufe 1 def parsemovements(self): 2 self.result.reverse() 3 directions = ("forward","backward","left","right") 4 commands = [] 5 6 startx = self. startnode.x 7 starty = self. startnode.y 8 prex = startx 9 prey = starty for node in self.result: 12 nodex = node.x 13 nodey = node.y if nodex > prex and nodey == prey: 16 commands.append( directions [0]) 17 if nodex < prex and nodey == prey: 18 commands.append( directions [1]) 19 if nodex == prex and nodey > prey: 20 commands.append( directions [2]) 21 if nodex == prex and nodey < prey: 22 commands.append( directions [3]) prex = nodex 25 prey = nodey 26 pass 27 return commands Listing 6.22: Erstellung von Bewegungsdirektiven durch Evaluation des Pfades Im Falle des Szenarios aus Abbildung 6.16 (S. 118) entsteht hierbei beispielhaft die folgende Liste: [ forward, left, left, forward, forward, forward, forward, forward, right, right ] Jene Bewegungen würden eine Vermeidung des Hindernisses modellieren und entsprechen daher den Anforderungen aus dem Softwaremodell. Durch die Betrachtung dieser drei Segmente sind somit die wesentlichen Aspekte und Kernprozesse bei der Implementierung des Navigator-Moduls abgedeckt Pilot Nach den Anforderungen des Softwaremodells (vgl. Abschnitt 6.2, Seite 96 ff.) muss die Implementierung des Pilot-Moduls zwei wesentliche Elemente enthalten, um die Funktion des Steuerungssystems im Sinne der prototypischen Implementierung des Gesamtkonzeptes dieser Arbeit sicherzustellen. Einerseits handelt es sich hierbei um die Konversion der Bewegungsdirektiven aus der Navigation in Bewegungsmuster/Steuerungsbefehle, welche durch die direkte Bedienung entsprechender Methoden des Movement-Moduls bzw. der Hardwareschnittstelle realisiert werden müssen. Andererseits ist darüber hinaus eine Kapselung von jenen Teilen hiervon, welche maschinenspezifische Funktionen jenseits des Laufens implementieren, an dieser Stelle umzusetzen. Sie umfassen dabei beispielsweise Prozesse, die mit der ordnungsgemäßen Initialisierung bzw. einem schonenden Herunterfahren des Robotersystems zu tun haben. Wenn man allerdings auch das Konzept des Cartographer-Moduls (vgl. Abschnitt 6.3.3, ab S. 109) berücksichtigt, so ergibt sich ein zusätzlicher Anspruch an die Implementierung. Er entsteht aus der Spezifikation, dass die Selbstlokalisation des Roboters über die bereits abgearbeiteten Bewegungsdirektiven zu erfolgen hat, heraus. Da, aufgrund seiner Aufgabe, nur das Pilot-Modul über dieses Wissen zur Laufzeit des Steuerungssystems verfügt, muss ersteres daher zusätzlich 121

134 6. Prototypische Implementierung selbstständig die neue Position des Roboters bestimmen und jene über die Schnittstelle der Cartographer-Implementierung in die systeminterne Karte eintragen. Somit ergeben sich auch hier drei Segmente, deren Aspekte und Kernprozesse die Implementierung des Pilot-Moduls definieren. Sie sollen daher im Folgenden kurz betrachtet werden. 1. Konversion der Bewegungsdirektiven in Steuerbefehle Wie bereits in der Realisierung des Missionplanners erkennbar ist (vgl. hierzu Zeile 27 des Listing 6.13, Seite 107), wird zur Steuerung des Nao auf Basis der Bewegungsdirektiven die Methode driveonepatch() des Pilot-Moduls aufgerufen. Die damit verbundene Logik ist als Flussdiagramm in Abbildung 6.18 dargestellt. Start getdirectionlist() setpatchdirection() checkdestination() notifycartographer() checkturnaround() drive() False True TurnAroundFirst() left patch forward patch right patch False TurnLeft() check PrevLeft() False check PrevLeft() True TurnRight() check PrevRight() False TurnRight() setlflag() True True check PrevRight() True setrflag() TurnLeft() False walkforward() walkforward() walkforward() unsetrflag() unsetlrflag() unsetlflag() removedirection() reactivatesensors() End Abbildung 6.18.: Flussdiagramm der Methode driveonepatch() des Pilot-Moduls Im Wesentlichen kommt hierbei eine Art Zustandsautomat zum Einsatz, der die jeweils vorrangigste Bewegungsdirektive aus der Liste entnimmt und sich um deren kontextabhängige Abwicklung bemüht. Dieser Ansatz hat sich aufgrund der Verwendung von möglichst wenigen Richtungszuständen bei deren Generierung bzw. durch deren absolute Orientierung getreu der Umweltrepräsentation des Cartographer-Moduls als am sinnvollsten herausgestellt, da dabei natürlich Mehrdeutigkeiten in puncto der durchzuführenden Aktionen entstehen. Für eine eindeutige Konversion müssen jene daher zunächst durch den Automat aufgelöst werden. Als Beispiel hierfür dient das Ergebnis der Navigation von Seite 121. Um das Hindernis des damit verbundenen Szenarios zu umgehen und das Ziel zu erreichen, wurden dazu die drei Richtungszustände forward, left, right in folgender Reihenfolge als Bewegungsdirektiven ermittelt: [ forward, left, left, forward, forward, forward, forward, forward, right, right ] 122

135 6.3. Modulimplementierung und Abläufe In diesem Fall liegen allein schon durch die ersten vier Bewegungsdirektiven unterschiedlich durchzuführende Aktionen vor, die hierbei folgendermaßen aufzulösen wären: Nach der Abarbeitung des ersten Vorwärtsschrittes im Bezugsraum des Szenarios ergibt sich als nächstes eine Linksdirektive. Ihre Realisierung wäre beim ersten Mal mit einer entsprechend stationären Linksdrehung des Robotersystems verbunden, ehe durch ein weiteres Vorwärtslaufen tatsächlich der passende Abschnitt der Karte betreten werden kann. Bei der Umsetzung der direkt darauf folgenden Richtungsangabe ist jedoch ein anderes Vorgehen notwendig. Obwohl diese ebenfalls eine Linksdirektive darstellt, ist durch die bereits im Vorfeld durchgeführte Drehung keine weitere solche erforderlich. Entsprechend wäre hier dann nur ein weiterer Vorwärtsschritt auszuführen. Da die vierte Direktive hingegen wieder aus einem forward besteht, muss das Robotersystem zuvor aus dem Linkszustand heraus nach Rechts gedreht werden. Somit wird die ursprüngliche Orientierung des Roboters wiederhergestellt. Anschliessend ist es möglich, im Bezugsraum voran zu schreiten. 1 class Pilot(ALModule): 2 def init (self,name,parent): 3 ALModule. init (self,name) 4 self.parent = parent 5 6 if self.parent.movement == None: 7 exit(1) 8 9 self. direction_list = None 10 self. last_direction = None 11 self. left_flag = False 12 self. right_flag = False 13 return Listing 6.23: Initialisierung des Pilot-Moduls Um derartige Auflösungsprozesse programmatisch abzubilden, ist es notwendig, pro Methodenaufruf jeweils die zu einer Direktive relevanten Zustande zu prüfen. Zu diesem Zweck enthält das Pilot-Modul boolesche Variablen, welche in dessen Konstruktor (Zeile 11/12, Listing 6.23) initialisiert werden. Sie speichern hierbei den Rotationszustand des Roboters während der gesamten Laufzeit des Steuerungssystems. Darüber hinaus wird auch eine Variable angelegt, welche als Referenz für die jeweils zuletzt durchgeführte Bewegung genutzt werden kann. Von dieser hängt, unter anderem, die Implementierung des Cartographer-Moduls (vgl. Bestimmung von Lage-/Distanzgewichten bei der Eintragung von Hindernissen, Abschnitt 6.3.3, S. 112 ff.) ab. Sie wird dazu später im Rahmen der Selbstlokalisierung des Roboters gesetzt (vgl. Segment 3, S. 125). 1 def driveonepatch(self): 2 patch_direction = self. direction_list [0] 3 walked=false 4 if self. last_direction!= None: 5 if self. last_direction == "right" and patch_direction == "left": 6 self.parent.speech.say("oops, i have to turn around") 7 self.parent. movement. turnaroundplanned() 8 self. right_flag=false 9 self. left_flag=true 10 if self. last_direction == "left" and patch_direction == "right": 11 self.parent.speech.say("oops, i have to turn around") 12 self.parent. movement. turnaroundplanned() 13 self. right_flag=true 14 self. left_flag=false 15 pass 16 pass 17 #to be continued... Listing 6.24: Zustandsabfrage des Pilot-Moduls im Falle l/r bzw. r/l 123

136 6. Prototypische Implementierung Nach der Extraktion der vorrangigsten Bewegungsdirektive aus der Liste findet, gemäß des Flussdiagramms aus Abbildung 6.18 (S. 122), eine erste derartige Prüfung dieser Variablen im Rahmen des Auflösungsprozesses durch die Methode driveonepatch() des Pilot-Moduls statt. Wie in Listing 6.24 erkennbar ist, handelt es sich dabei um die Betrachtung der Fälle einer left- nach right-direktive bzw. right- nach left-direktive (Zeilen 5-16). Hierfür werden die o. g. Variablen abgefragt und im zutreffenden Falle Maßnahmen ergriffen, was eine Drehung des Roboters um 180 durch das Movement-Modul bzw. eine Umverteilung der damit verbundenen Rotationszustände zur Folge hat. Das geschieht noch im Vorfeld der eigentlichen Abarbeitung einer left bzw. right-direktive, um ein entsprechend konsistentes Systemverhalten in diesem Spezialfall sicherzustellen. 1 if patch_direction == "forward": 2 self.parent.speech.say("forward") 3 if self. left_flag == True: 4 self.parent.movement. turnrightassistedangledminimalplanned2() 5 pass 6 if self. right_flag == True: 7 self.parent.movement. turnleftassistedangledminimalplanned() 8 pass 9 self.parent.movement. walkforwardstepwiseassistedplanned() 10 walked=true 11 self. left_flag=false 12 self. right_flag=false 13 pass Listing 6.25: Zustandsabfrage des Pilot-Moduls im Falle forward Listing 6.25 zeigt weiterhin den eigentlichen Auflösungsprozess der Methode im Falle einer forward-direktive exemplarisch auf. Er realisiert den mittleren Pfad des Flussdiagramms auf Seite 122. Dazu werden nach einer Prüfung der Rotationszustände zuerst entsprechende Gegenmaßnahmen eingeleitet, falls sie jeweilig erforderlich sind. Sollte sich also das Robotersystem durch eine bestimmte Direktive im Vorfeld bereits in einem links- bzw. rechtsrotierten Zustand befinden, so wird die Implementierung des Movement-Moduls angewiesen, diesen stationär um 90 nach rechts bzw. links zu drehen. Anschliessend findet die eigentliche Vorwärtsbewegung statt. Da somit durch die Zustandsbetrachtung nun garantiert von der selben Orientierung des Roboters wie zum Start das Szenarios ausgegangen werden kann, ist es notwendig, beide Rotationswerte analog dazu zu negieren. 1 if patch_direction == "left" and self. left_flag == False and walked ==False: 2 self.parent.speech.say("left") 3 self.parent.movement. turnleftassistedangledminimalplanned() 4 self. left_flag=true 5 self. right_flag=false 6 walked=true 7 self.parent.movement. walkforwardstepwiseassistedplanned() 8 self.parent. cartographer. setlisteningtosensors() 9 if patch_direction == "left" and self. left_flag == True and walked == False: 10 self.parent.speech.say("left") 11 self.parent.movement. walkforwardstepwiseassistedplanned() 12 self. right_flag=false 13 walked=true 14 self.parent. cartographer. setlisteningtosensors() 15 # same for right patch direction 16 # remove direction from list 17 del self. direction_list [0] 18 return Listing 6.26: Zustandsabfrage des Pilot-Moduls im Falle left Wie Listing 6.26 weiterführend zeigt, unterscheidet sich die Verarbeitung einer left-direktive nur kaum vom forward-fall. Analog zur linken Hälfte des Programmablaufs (Abbildung 6.18, 124

137 6.3. Modulimplementierung und Abläufe S. 122) unterteilt sich der Auflösungsprozess der Methode dabei jedoch in zwei unterschiedliche Fälle. Liegt noch keine Linksrotation des Roboters vor (erster Fall, Zeile 1), so wird durch eine entsprechende Drehung zuerst eine solche hergestellt (Zeile 3). Anschliessend werden die dazu relevanten Variablen des Pilot-Moduls gesetzt (Zeilen 4/5). Erst dann wird eine Vorwärtsbewegung des Roboters ausgelöst. Ist jener Zustand jedoch schon vorhanden (zweiter Fall, Zeile 9), so kann natürlich direkt vorangeschritten werden. Die Konversion einer right-direktive funktioniert parallel und wird daher weggelassen. Auf diese Art und Weise ist es somit möglich, die absolut-orientierten Direktiven des Steuerungssystems in die passenden Befehle der Bewegungsschnittstelle zu konvertieren. 2. Kapselung von maschinenspezifischen Funktionen Entsprechend den Anforderungen des Softwaremodells werden von der Implementierung des Pilot-Moduls darüber hinaus sämtliche Fähigkeiten der Bewegungsschnittstelle gekapselt, welche für die Nutzung des Aldebaran Nao im Sinne der prototypischen Implementierung notwendig sind. Hierzu ist in Listing 6.27 ein exemplarisches Beispiel einer derartigen Methode zu sehen. 1 def shutrobot(self): 2 self.parent.behavior. stopallbehaviors() 3 time.sleep(3) 4 self.parent.movement. firesitdown() 5 self.parent.movement. unstiffenbody() 6 return Listing 6.27: Kapselung der Verfahren aus dem Movement-Modul für ein Herunterfahren des Aldebaran Nao Sie ermöglicht ein unkompliziertes, jedoch schonendes Herunterfahren des Robotersystems. Dazu wird zunächst jegliche sich im Ablauf befindliche Aktion des Nao gestoppt und anschließend eine in Aldebaran Choregraphe festgelegte Bewegungsreihenfolge abgespielt. Sie bringt den Roboter in eine sitzende Ausgangsstellung, falls eine solche nicht bereits vorliegt. Da jener Aufruf blockierend ist, kann nach dessen Beendigung von einer sicheren, stabilen Haltung des Nao im Bezugsraum ausgegangen werden. Somit ist die letztendliche Abschaltung aller Motoren des Roboters ungefährlich und kann entsprechend erfolgen. Weitere derartige Aufrufe realisieren u. a. auch eine Initialisierung des Systems aus dieser Position heraus, sodass eine Abbildung von Kreisläufen, wie sie für das Steuerungssystem benötigt werden (vgl. Implementierung des Missionplanners, Abschnitt 6.3.2, S. 105 ff.), möglich wird. 3. Selbstlokalisation des Roboters über Bewegungsdirektiven Durch die in diesem Modul stattfindende Konversion der Bewegungsdirektiven in konkrete Steuerbefehle (vgl. Segment 1, ab S. 122) wird zudem das nötige Wissen erzeugt, um eine sinnvolle Selbstlokalisierung des Roboters in der Belegungstabelle des Cartographers zu ermöglichen. Hierbei sind sowohl die neue Position als auch der Zeitpunkt der Aktualisierung klar berechen- bzw. festlegbar. Wie in Listing 6.28 gesehen werden kann, ist dazu lediglich eine Modifikation der Karte durch dessen Schnittstelle erforderlich. Dabei wird anhand der gerade anliegenden Bewegungsdirektive und des zuvor geltenden Standortes des Roboters im absolut orientierten Weltbild diese neue Position errechnet. 125

138 6. Prototypische Implementierung 1 def notifycartographer(self, patch_direction): 2 robot_position = self.parent. cartographer. getposition() 3 robot_x = robot_position [0] 4 robot_y = robot_position [1] 5 if patch_direction == "forward": 6 robot_x = robot_x elif patch_direction == "right": 8 robot_y = robot_y elif patch_direction == "left": 10 robot_y = robot_y pass 12 self.parent. cartographer. updateposition(robot_x,robot_y) 13 self. last_direction = patch_direction 14 return Listing 6.28: Selbstlokalisation durch Kartenschnittstelle Da die Abarbeitung einer Bewegungsdirektive per Definition mit der Traversierung immer nur einer Zelle der Belegungstabelle verbunden ist, müssen dazu nur die entsprechenden Komponenten inkrementiert/dekrementiert werden (Zeile 5-11). Dies geschieht im Rahmen der prototypischen Implementierung des Konzeptes vor der Ausführung einer jeden Bewegung. Somit sind die wesentlichen Aspekte bzw. Kernprozesse der Implementierung des Pilot-Moduls dargestellt VisionReactor Das VisionReactor-Modul verfügt, wie die Implementierung des Cartographers, über eine Methode, welche als Event-Receiver Datenpakete aus der parallel ablaufenden Sensorik entgegen nimmt. Dabei werden die jeweiligen Messwerte, welche den graduellen Versatz eines elementaren Schrittes beschreiben, jedoch lediglich nur als Variablen der Klasse abgelegt. Das geschieht, um die zeitkritische Verarbeitung der Logik der Movement-Klasse sicherzustellen. Da sich ansonsten die Implementierung dieser Methode von der des Cartographers (siehe Listing 6.16, S. 112) in puncto Event-Handling kaum unterscheidet, soll hier nicht näher darauf eingegangen werden Movement Die Realisierung des Movement-Moduls muss entsprechend der Spezifikation (vgl. dazu das Softwaremodell in Abschnitt 6.2, S. 96 ff.) eine möglichst effiziente Steuerung der Hardware des Aldebaran Nao umfassen. Dessen Funktion ist daher von entscheidender Relevanz für das Steuerungssystem, nicht allein schon aus dem Grund, dass es ohne diesem letzten Element schwer fällt, die Ergebnisse bzw. den Zweck aller anderen Bestandteile sichtbar zu machen. Darüber hinaus ist natürlich die selbstständige Fortbewegung des Roboters im Bezugsraum eines Szenarios der wesentliche Schlüsselaspekt und auch Datenlieferant für das Suchkonzept dieser Arbeit (vgl. Implementierung des Missionplanners, Abschnitt 6.3.2, Seite 105 ff.). Um diesen Ansprüchen gerecht zu werden, ist dessen Implementierung durch die folgenden fünf Segmente gegeben: 1. Vorwärtsbewegung 2. Stationäre Rotation 3. Steuerung einzelner Gelenke 126

139 6.3. Modulimplementierung und Abläufe 4. Steuerung eines Gelenkverbunds durch Verhaltensweisen 5. Verwaltung des Systemzustandes Daher soll eine Betrachtung der hierzu unternommenen Schritte und letztendlich geschaffenen Lösungen die Funktionsweise dieses Moduls verdeutlichen. 1. Vorwärtsbewegung Die Implementierung einer selbstständigen Vorwärtsbewegung des Roboters unter Benutzung des Laufsystems stellt die grundsätzlich elementarste Anforderung an das Modul dar, welche aus diesem Grund auch zuerst bearbeitet wurde. Sie kommt zum Einsatz, wenn durch den Pilot eine entsprechende Direktive erkannt und angeordnet wird. 1 def walkforward(self): 2 self.parent.motion.walkto (0.28,0.0,0.0) 3 self. steps_made = self. steps_made return Listing 6.29: Simple Vorwärtsbewegung durch walkto-aufruf In den ersten Versionen des Steuerungssystems ist dazu einfach die Methode walkto() des ALMotion-Moduls verwendet worden. Listing 6.29 zeigt eine solche Anweisung exemplarisch auf. Hierbei wird die konkrete Steuerung der einzelnen Aktuatoren beider Beine automatisch durch die NaoQI-Modulbibliothek vorgenommen und der Roboter jeweils anhand der übergebenen Parameter x, y in Metern bewegt. Zusätzlich findet eine Rotation um theta statt, welche im Radmaß anzugeben ist. Obwohl dieser Ansatz zunächst recht vielversprechend erscheinen mag, so ist er im praktischen Einsatz am verwendeten Aldebaran Nao grundsätzlich nicht geeignet. Das zeigten die ersten Tests sehr schnell auf, in denen durch dessen fehlerbehaftetes Fortbewegungssystem (vgl. dazu Abschnitt 5.3.3, S. 77) dabei immer sehr unterschiedliche Ergebnisse erzielt wurden. Eine zuverlässige Vorwärtsbewegung war somit nicht zu erreichen. Dies stellte im Hinblick auf die prototypische Implementierung ein enormes Problem dar, dessen Lösung eigentlich nichts mit der Umsetzung des Gesamtkonzepts zu tun hatte. Deshalb wurde auch dafür erst relativ spät im Zuge einiger Gespräche mit dem betreuenden Professor die Möglichkeit zweier Kompromisslösungen hierfür eruiert. Beide bauten dazu in gewisser Weise auf dem Prinzip reaktiver Systeme auf, bei dem Sensorik und Aktuatoransteuerung unmittelbar miteinander gekoppelt werden (vgl. hierzu Abschnitt 5.2.1, S. 65). Einerseits gäbe es die Möglichkeit einer permanenten (Re-)Orientierung des Robotersystems im Raum durch den Einsatz von einem bzw. mehreren visuellen Markern, wie sie beispielsweise auch Murphy in seinem Buch vorschlägt. 16 Da sie hierzu jedoch innerhalb des Bezugsraums eines jeden Szenarios angebracht und jederzeit für die Ausführung jedweder Bewegung notwendig wären, stehen sie somit schon in ihrem Ansatz mit der Idee dieser Arbeit ein unbekanntes Szenario eigenständig zu erkunden augenscheinlich in Konflikt. Eine andere Möglichkeit würde sich grundsätzlich durch die Verwendung irgendeiner Form eines Kompasses, um die Abweichung einer ausgeführten Bewegung von der ursprünglich geplanten zu bestimmen, ergeben. Da die Hardware des verwendeten Aldebaran Nao jedoch über keinen derartigen direkt von außen zugänglichen Sensor 17 verfügt, müsste allerdings hierzu ein angemessener Ersatz zunächst selbst geschaffen werden. 16 vgl. [42], S. 326 f. 17 Anm. Die Gyrometer des Nao werden von einer eigenen CPU verwaltet, welche keine Anbindung an NaoQI hat. 127

140 6. Prototypische Implementierung Wie noch in diesem Segment bzw. später an der Implementierung der Sensorik zu sehen ist (vgl. Abschnitt 6.3.8, ab S. 149), war dies jedoch aufgrund der verwendeten Erkennungstechnologie bei der Bildverarbeitung relativ effizient umsetzbar. Dazu wird die Güte eines jeden Schritts durch den graduellen Versatz des Roboters bestimmt, der auf der Basis eines visuellen Kompasses entsteht. Anschließend können dann adäquate Korrekturmaßnahmen ergriffen werden. Obwohl somit prinzipiell die Unzulänglichkeiten des Fortbewegungssystems erfass- und steuerbar wurden, stellten sich im weiteren Verlauf der prototypischen Implementierung auch noch andere negative Eigenschaften der walkto()-funktion heraus. Diese beschleunigte/bremste den Roboter jeweils auf eine nicht näher parametrisierbare Art und Weise, was im Falle des verwendeten Nao oftmals zu einem Versagen des Laufsystems bzw. zum Zusammenbruch des Roboters führte. 18 Ausserdem verstärkte sie durch dieses Verhalten die Diversität der anzutreffenden Ergebnisse enorm und variabel zum Bodenbelag. Insgesamt machte das eine nachvollziehbare Kalibration/- Fortbewegung des Roboters in einem Szenario gemäß der Direktiven bzw. der Repräsentation des Steuerungssystems erneut unmöglich. 19 Somit musste eine andere Lösung für die Abbildung einer elementaren Direktive des Steuerungssystems bzgl. der Vorwärtsbewegung gefunden werden, welche konsistentere Ergebnisse erzeugt. Die Grundidee der Fortbewegung um eine uniforme Einheit (einer Zelle der Karte) sollte jedoch erhalten bleiben. Für eine erfolgreiche Kalibration des Nao in einem Szenario waren diesbezüglich einige Faktoren maßgeblich. So spielte beispielsweise der Mindestabstand für die Erkennung von Warnschildern neben den Maßen des Roboters eine wichtige Rolle. Ersterer beläuft sich im Falle der vorliegenden Sensorimplementierung auf 40 cm (vgl. dazu Abschnitt 6.3.8, S. 145). Zweiterer im Falle seiner Tiefe auf ca. 16 cm. Entsprechend musste ein Ansatz/eine Schrittweite definiert werden, welche(r) häufig eine ausreichend große, festgelegte Distanz zurücklegt. Sie ergab sich aus den o. g. Angaben und dem zuzüglich zu berücksichtigenden Korrekturaufwand für die Stabilisation des Laufsystems. Tests haben dabei gezeigt, dass hierfür in etwa eine Vorwärtsbewegung um 28 cm plus etwaiger Korrekturschritte am sinnvollsten ist, um den Roboter im Mittel um den Mindesterkennungsabstand voranzutreiben. Letztere konnte somit für die Definition der Größe einer Zelle der Belegungstabelle herangezogen werden. Für die möglichst exakte Realisierung eines derartigen Bewegungsmusters wurden die entsprechenden Alternativen der Bewegungsschnittstelle des ALMotion-Moduls evaluiert und hinsichtlich dieser Anforderungen getestet. 1 def walkforwardsimple(self): 2 self.parent.motion. setwalktargetvelocity (1.0,0.0,0.0,1.0) 3 time.sleep(1) 4 self.parent.motion. setwalktargetvelocity (0.0,0.0,0.0,0.0) 5 return Listing 6.30: Simple Vorwärtsbewegung durch setwalktargetvelocity-aufruf Eine dieser Alternativen war durch die Methode setwalktargetvelocity() gegeben. Hierbei wird der Roboter in einen kontinuierlichen Laufprozess geschickt, der anschließend noch zur Laufzeit beliebig manipuliert werden kann. Das geschieht durch die einzelnen Parameter, welche jeweils Teilbereiche der Maximalbeschleunigung des Roboters jeweils in x, y Richtung als Wert akzeptieren. Darüber hinaus können Rotationswinkel und Schrittfrequenz festgelegt werden. Analog zur walkto()-methode wird dabei die Steuerung der betreffenden Aktuatoren automatisch durch das ALMotion-Modul der Bibliothek vorgenommen. 18 Anm. Dies ist allerdings auch der starken Abnutzung des Roboters über Jahre hinweg durch andere Studenten zuzurechnen. 19 Anm. Es musste bei jedem Schritt nachkorrigiert werden. 128

141 6.3. Modulimplementierung und Abläufe Der Versuch aus diesem Ansatz heraus eine Funktion des Movement-Moduls zu erschaffen, welche einen elementaren Schritt gemäß der Anforderungen des Steuerungssystem implementieren soll, ist in Listing 6.30 zu sehen. Wie sich jedoch bei den anschließenden Tests erwiesen hat, war sie zu unzuverlässig. Dafür war insbesondere der variable Zeitverbrauch der Sleep-Funktion, welche durch die Realisierung des Roboterbetriebssystems nicht die Echtzeit als Zeitmaß heranzog, verantwortlich. Ausserdem konnten die automatisch durchgeführten Ausgleichsbewegungen des ALMotion-Moduls zur Stabilisation des Roboters nicht erfasst werden, was somit die Realisierung eines Voranschreitens um eine festgelegte Distanz unmöglich machte. 1 def walkforwardsimplefoot(self): 2 legname = ["LLeg", "RLeg"] 3 X = Y = Theta = footsteps = [[X, Y, Theta], [X, Y, Theta]] 7 fractionmaxspeed = [0.0005,0.0005] 8 clearexisting = True 9 self.parent.motion. setfootstepswithspeed(legname, footsteps, fractionmaxspeed, 10 clearexisting) 11 time.sleep(3) 12 self.parent.motion. setfootstepswithspeed(legname, footsteps, fractionmaxspeed, 13 clearexisting) 14 return Listing 6.31: Simple Vorwärtsbewegung durch Fussschrittplanung Die andere Alternative bestand in der Nutzung der Methode setfootstepswithspeed(), wie sie in Listing 6.31 angegeben ist. Hier wird auf die Fähigkeit des ALMovement-Moduls zur Planung bzw. Durchführung einzelner Fußschritte zurückgegriffen. Sie stellt die direkteste Form der Steuerung des Fortbewegungssystems des Aldebaran Nao dar, da sie quasi direkt auf die Aktuatoren Einfluss nimmt. Allerdings werden bei ungünstigen Werten nach wie vor automatisch Ausgleichsschritte erzeugt, die einen Sturz des Roboters zu verhindern versuchen. Im Gegensatz zu den anderen Ansätzen sind jene jedoch zumeist von stationärer Natur. Die Parameter X und Y beschreiben dabei die relative Position der einzelnen Füße des Roboters zueinander in Metern. Theta dient zur Festlegung der Rotation mit dem Torso des Nao als Ursprung. fractionmaxspeed legt die Geschwindigkeit fest, mit der die neue Position der Beine erreicht werden soll. Wie an dem Codeblock des Listings sichtbar ist, werden weiterhin zwei aneinander folgende Schritte mit insgesamt jeweils 7 cm Schrittweite ausgeführt. Der Roboter legt also eine Distanz von 14 cm zurück, welche sich leicht durch einen doppelten Aufruf auf die geforderten 28 cm erweitern lässt. Hierbei dient die Pause zur Stabilisation bzw. zur Vermeidung von Fehlern durch die Instabilität des Fortbewegungsmodells/der verwendeten Motoren. Ein Test dieser Funktion hat ergeben, dass sie die gewünschten Anforderungen unter den gegebenen Umständen am besten realisiert. 20 Deshalb ersetzte sie den zuvor genutzten walkto()-aufruf der Implementierung. Eine Verbindung dieser zwei Komponenten (visueller Kompass/Planung einzelner Fussschritte) machte somit letztendlich die Realisierung einer anwendbaren, elementaren Vorwärtsbewegung möglich. Der dabei zum Einsatz kommende Ablauf und ein dazu passendes Beispiel sind in den Abbildungen 6.19a und 6.19b dem Verständnis halber dargestellt. Die gesamte Funktion ist darüber hinaus im Anhang A.1 (S. XXIX) zu finden. 20 Anm. Es entstehen natürlich immer noch Abweichungen durch das defekte Laufsystem, allerdings treten diese weniger häufig/stark auf. 129

142 6. Prototypische Implementierung true Start checkinitial() walkinit() false docalibration Step() turnhead Normal() activate Vision() unset Initial() waitfor Calibration() StepAmount < 2? true make StartShot() false correct Overall() deactivate Vision() End Elementarschritt 1: Leichter Linksdrift entsprechend Geradestellung vor Elementarschritt 2 waitshot() walkforward Simple() Step 4 MoveHead() StepAmount ++ make StopShot() waitshot() get Deviation() waitdeviation () MoveHead() StepAmount ++ Zelle 1,4 Zelle 0,4 Korrektur Step 3 save Deviation() deviation < 5 correct Minor() deviation>5 & <=10 evaluate Deviation() deviation>10 & <=20 deviation > 20 correct Small() correctbig() Step 2 Step 1 Elementarschritt 2: Leichter Rechtsdrift, Nachkorrektur um 6 Grad um System wieder gerade zu stellen MoveHead() StepAmount ++ StepAmount ++ MoveHead() (a) Flussdiagramm für Vorwärtsbewegung (b) Exemplarische Vorwärtsbewegung Abbildung 6.19.: Visualisierung der walkforward()-methode des Movement-Moduls Hierbei wird von der Methode des Movement-Moduls zuerst geprüft, ob eine Vorwärtsbewegung zum ersten Mal stattfindet. Ist das der Fall, erfolgt der Start einer festgelegten Ereigniskette, um einen garantierten Initialzustand des Roboters zu Beginn der Laufzeit des Steuerungssystems einzunehmen. Im Zuge dessen wird der Nao zunächst in die sog. walkinit-stellung gebracht und ein einzelner Schritt unternommen. Ausserdem geschieht eine Zentrierung seines Kopfes. Daraufhin hat der Benutzer 10 Sekunden Zeit, um den Roboter richtig im abzuarbeitenden Szenario zu platzieren bzw. zu kalibrieren. Dabei sollte er möglichst ohne jedwede Rotation innerhalb des Bezugsraums platziert werden (vgl. dazu den linken unteren Bildabschnitt in Abbildung 6.19b). Anschließend wird durch die Schleife der Methode die eigentliche Steuerung des Roboters realisiert. Hierfür ist das folgende Prinzip ausschlaggebend: Die grundsätzliche Vorwärtsbewegung zwischen zwei Zellen der Umweltrepräsentation setzt sich aus zwei sog. Elementarschritten zusammen. Diese sind durch die in Listing 6.31 (S. 129) dargestellte Funktion zur Aktuatorsteuerung implementiert. Ein Elementarschritt besteht also jeweils aus zwei einzelnen, realen Fußschritten des Roboters, welche ihn um ca. 14 cm bewegen. 21 Vor Beginn bzw. nach dem Ende eines derartigen Schrittes werden jeweils die damit verbundenen Bilder aus der parallel ablaufenden Erkennungsschleife der Sensorimplementierung festgehalten. Die so entstehenden Differenzbilder können als Referenz für die Berechnung des graduellen Versatzes bzw. dessen Richtung durch den visuellen Kompass dienen (siehe hierzu Implementierung der Sensorik, Abschnitt 6.3.8, S. 149 f.). Je nach Intensität der dabei festgestellten Ergebnisse wird dann unterschiedlich vorgegangen. Liegt nur eine minimale Abweichung vor (weniger als 5 Grad), so werden nur die Richtung und der Versatz selbst gespeichert. Bei größeren Unstimmig- 21 Anm. Wie später im Test sichtbar wird (vgl. S. 158 f.), hängt dies mitunter von der Temperatur der Motoren ab, sodass niemals wirklich von Präzision gesprochen werden kann. 130

143 6.3. Modulimplementierung und Abläufe keiten erfolgen jedoch sofort Gegenmaßnahmen. Sie sind durch Aufrufe an die Schrittplanung, welche eine adäquate Rotation des Robotersystems verursachen, implementiert. Anschliessend wird der Kopf des Nao bewegt, um die Suche nach Gefahrenquellen zu unterstützen. Eine Iteration schließt darüber hinaus immer mit der Inkrementierung einer Zählvariable ab, welche die Anzahl der bereits durchgeführten Elementarschritte erfasst. Wird die Schleife verlassen, so findet anschliessend eine Betrachtung der Gesamtabweichung statt. Sie manifestiert sich aus allen minimalen Abweichungen, welche ihrer Richtung entsprechend gegengerechnet wurden. Fällt diese zu groß aus, wird eine abschliessende Korrekturmaßnahme vorgenommen. Das hierdurch realisierte Steuerungsverhalten ist exemplarisch in Abbildung 6.19b erkennbar. Es enthält ein mögliches Szenario, welches besonders häufig auftrat. 22 Hierbei wird durch eine forward-direktive der Roboter zunächst in den Initialzustand gebracht. Anschliessend erfolgt die Abwicklung des ersten Elementarschritts gemäß dem Ablauf. Da durch die Fehler des Bewegungssystems hierbei ein leichter Linksdrift entsteht, wird dieser durch die Sensorik festgestellt. Somit folgt eine Gegenmaßnahme, um den Roboter wieder gerade zu stellen. Bei der Durchführung des zweiten Elementarschritts ergibt sich dann zumeist ein Rechtsdrift. Er ist oftmals eine Nachwirkung der ersten Korrektur, da natürlich auch die Rotation des Roboters durch das Bewegungssystem nicht immer exakt vorgenommen werden kann. Demzufolge wird eine weitere Korrektur notwendig, um den Roboter erneut optimal auszurichten. Insgesamt ergibt sich somit eine nur noch leicht schlingernde bzw. schräge Vorwärtsbewegung des Nao im Bezugsraum eines Szenarios, welche im Vergleich zur völlig unberechenbaren Implementierung der walkto()-methode auf jeden Fall besser abschneidet. 2. Stationäre Rotation Analog zur Vorwärtsbewegung war auch die Implementierung der stationären Rotationen des Aldebaran Nao, wie sie die absolut orientierten Bewegungsdirektiven left bzw. right des Steuerungssystems benötigen, zuerst durch einfache Aufrufe an die walkto()-methode des ALMotion- Moduls realisiert worden. Da sich dabei natürlich die selben Probleme durch die Ungenauigkeit des bipedalen Fortbewegungssystems an sich bzw. die Eigenwilligkeiten der Methode ergaben, musste auch hier eine entsprechende Kompromisslösung gefunden werden. Grundsätzlich erschien die Findung eines guten Ansatzes zunächst denkbar einfach. So müsste der Roboter eigentlich nur so lange gedreht werden, bis der visuelle Kompass der Sensorik letztendlich eine Rotation von 90 in die gewünschte Richtung feststellt. Hierfür wäre es erforderlich, einfach nur die Methodik des Vorwärtslaufs (vgl. Segment 1, S. 127 ff.) zu kopieren und in zwei Aspekten zu verändern. Sie lassen sich folgendermaßen benennen: 1. kontinuierliche Aufsummierung der graduellen Versätze zwischen allen Drehbewegungen 2. Anpassung der Aufrufe an die Schrittplanung des ALMotion-Moduls Wie die Tests der diesbezüglich implementierten Methoden ergaben, schien ein derartiger Ansatz vom Prinzip her durchaus zu funktionieren. Allerdings waren die Ergebnisse nur selten optimal. Meistens konnten Über- bzw. Unterabschätzungen beobachtet werden, welche zu einer Fehlrotation des Roboters führten. Auch das war eine Folge der Ungenauigkeit des Laufmodells, welche bei stationären Rotationen noch zusätzlich durch die Beschränkungen der bipedalen Fortbewegung an sich bzw. durch die damit verbundenen Ausgleichsschritte noch stärker variierende Ergebnisse verursachte. 22 Anm. Insbesondere nach einer langen Laufzeit, welche die Ungenauigkeit der Motoren weiter erhöht. (vgl. S. 158) 131

144 6. Prototypische Implementierung Aus diesem Grund wurde bei der Realisierung entsprechender Methoden des Movement-Moduls zusätzlich auf die Kompromisslösung einer möglichen (Re-)Orientierung des Robotersystems durch externe visuelle Merkmale zurückgegriffen (vgl. dazu Segment 1, S. 127 f.). Da Rotationen bzw. die damit verbundenen left/right-direktiven ohnehin nur durch die Existenz von Gefahrenzeichen im Bezugsraum eines Szenarios auftreten, lassen sich letztere somit auch geschickt als Fixpunkt einsetzen, um eine ordnungsgemäße Rotation sicherzustellen. Aufgrund des orthogonalen Konzeptes der Umweltrepräsentation des Cartographer-Moduls könnte hierfür jeweils entweder das Schild, welches die Rotation verursacht oder ein anderes, dass gerade in der Zielrichtung liegt, herangezogen werden. Start activate Vision() Orientation Mode Endzustand Iteration 8 Endzustand setrotation Limit() prepare Robot() Referenz isrotation90() true setrotated() false make StartShot() Orientation Mode Iteration 6 rotateblindly() true check FirstRotation() false check Remaining() Referenz false check Orientation Sign() true set Orientation Mode() RotateMinor() update Rotation() check Orientation Mode() <5.0 & >=0.1 <10.0 & >=5.0 RotateSmall() get Deviation() false search Orientation Sign() <20.0 & >=10 <89.0 & >=20 Rotate Medium() make StopShot() search Frontal() Rotate Large() false search Turned() Referenz Iteration true Orientation Mode() true true Calibrate ToCentroid () End false Referenz Iteration 0 Ausgangszustand (a) Flussdiagramm für Rotation (b) Rotation mit/ohne Orientierung Abbildung 6.20.: Visualisierung der turnleft()-methode des Movement-Moduls Der Programmfluss bzw. eine exemplarische Darstellung des durch diesen realisierten Verhaltens ist in den Abbildungen 6.20a und 6.20b zu sehen. Hierbei handelt es sich um die letztendlich verwendete Iteration der Methode für eine stationäre Linksdrehung des Aldebaran Nao, wie sie auch in Anhang A.2 (S. XXXI) vorzufinden ist. Wie man am Flussdiagramm erkennen kann, kommt dabei rein vom Prinzip her eine ähnliche Methodik wie bei der Vorwärtsbewegung des Roboters zum Einsatz. So wird nach dem Aufruf zunächst der visuelle Kompass der Sensorimplementierung aktiviert und eine Initialisierung des Laufsystems vorgenommen. Im Gegensatz zur walkforward()-methode handelt es sich bei dieser allerdings um eine Ausrichtung beider Beine des Nao in der Form, dass sie parallel zum Torso zueinander stehen. Das wird durch einen bestimmten Aufruf an die Schrittplanung sichergestellt. Ausserdem werden im Zuge dessen die zwei Variablen rotation und remaining, welche jeweils die bereits durchgeführte bzw. noch ausstehende Rotation des Nao als graduellen Wert erfassen, definiert und angelegt. Danach erfolgt innerhalb einer Schleife die eigentliche Realisierung der Rotation um 90. Hierfür wird analog zu walkforward() grundsätzlich vor jedem Aufruf an die Schrittplanung ein Referenzbild für die spätere Berechnung des Winkelversatzes festgehalten. 132

145 6.3. Modulimplementierung und Abläufe Da anfangs keine Rotationsdaten vorliegen, findet hiernach blindlings eine erste, sehr geringfügig ausfallende, Drehung durch die Schrittplanung statt. Dies dient dazu, das Laufsystem des Roboters aus der Initialstellung heraus in eine rotationsförderliche Position entsprechend der Richtung zu bringen. Ein solcher Schritt hat sich anhand mehrfacher Tests als sinnvoll herausgestellt, da sonst häufig durch die automatisch durchgeführten Ausgleichsschritte falsche Messdaten erzeugt werden. Um einen sinnvollen weiteren Ablauf der Rotationsschleife sicherzustellen, wird dann die Variable remaining um einen festen, geringen Wert (um 1 ) dekrementiert (bzw. rotation inkrementiert). Anschließend verlaufen alle darauf folgenden Iterationen immer nach der folgenden Methodik. So wird nach der Aufnahme des Referenzbildes anhand einer Prüfung der rotation-variable entschieden, inwieweit das Robotersystem durch einschlägige Aufrufe an die Schrittplanung noch zu drehen ist. Hierbei hat sich die Betrachtung vier unterschiedlicher Fälle als am zielführendsten herausgestellt. Sie sollen ein schrittweises Herantasten an die gewünschte Rotation von 90 realisieren. Ist dabei die noch zu bewältigende Drehung größer als 20 bzw. kleiner als 89 Grad, so wird versucht, den Roboter entsprechend stark zu bewegen. Diese Aktion darf jedoch nicht die maximal erfassbare Rotation des visuellen Kompasses (ca. 30 Grad, vgl. dazu Abschnitt 6.3.8, S. 149) überschreiten. Analog dazu fallen alle anderen Schritte geringer aus. Sie werden verwirklicht, wenn die verbleibende Rotation weniger als 20 beträgt. Nach der Durchführung der auf diese Art und Weise selektierten Maßnahme durch die Schrittplanung erfolgt daraufhin die Aufnahme des zweiten Referenzbildes. Der somit gewonnene graduelle Versatz zwischen den beiden Bildern wird anschliessend genutzt, um die maßgeblichen Variablen zu aktualisieren. Wie an dem Flussdiagramm in Abbildung 6.20a zu sehen ist, kann diese Schleife grundsätzlich durch zwei Ereignisse terminieren. Im einfachen Fall wurde dabei durch alle vorausgehenden Iterationen die rotation-variable soweit inkrementiert, dass sie durch einen Wert um etwa 90 das Erreichen der Zielstellung anzeigt. All das entspricht den ersten Versionen dieser Methode, welche bei Tests zu den o. g. Über- bzw. Unterabschätzungen durch die Fehler des Laufsystems führten. Getreu der Kompromisslösung kann daher die Schleife darüber hinaus auch dann verlassen werden, wenn durch die parallel ablaufende Sensorik ein geeignetes Schild für die Orientierung gefunden wird. Hierzu werden die Variablen des VisionReactor-Moduls, welcher gemäß dem Softwaremodell als EventReciever genutzt wird, im Rahmen einer jeden Iteration abgefragt. In diesem Fall tritt sofort der sog. Orientation Mode der Methode in Kraft, welcher die Kompromisslösung implementiert. Hierbei wird durch eine Ausrichtung des Nao zum Zentroid des gefundenen Schildes anhand kontinuierlicher Fussschritte die angebrochene Rotation exakt finalisiert und anschliessend die Methode beendet. Dies kann natürlich nur unter der Vorraussetzung erfolgen, dass sich ein solches gerade in Richtung der Drehung befindet. Da letzteres durch die Diversität unbekannter Szenarien nicht immer der Fall ist, wird daher nach jeder konventionellen Beendigung der Rotationsschleife versucht, ein für die (Re)-Orientierung geeignetes Warnzeichen zu finden. Dies geschieht in zweierlei Stufen. Zuerst probiert der Roboter durch leicht rotierende Schritte dennoch die Erkennung eines frontal liegenden Schildes zu ermöglichen. Schlägt das nach insgesamt 3 Versuchen fehl, so wird er in Ausgangsstellung gebracht und sein Kopf entgegen der Rotationsrichtung um 90 gedreht. Dies bildet die Annahme ab, dass das Schild, welches ursprünglich die Rotation verursacht hat, somit noch in seinem Sichtfeld sein müsste. Anschliessend erfolgen auch hier leicht rotierende Schritte, um eine Erkennung zu ermöglichen. Ist eine Phase dieses Suchprozesses erfolgreich, so tritt der Orientation Mode zur finalen Ausrichtung in Kraft. Hat hingegen auch die Drehung des Kopfes keinen Erfolg, so gibt die Methode auf und wird in der Annahme, dass die Rotation gut genug war, beendet. In diesem Falle erfolgt allerdings die Ausgabe einer Warnung. 133

146 6. Prototypische Implementierung Das somit realisierte Verhalten ist in den Szenarien in Abbildung 6.20b (S. 132) verdeutlicht. Der linke Teil des Bildes enthält dabei den Fall, dass während des Ablaufs ein geeignetes Schild für die (Re)-Orientierung gefunden wird. Gegensätzlich ist das Szenario der rechten Bildhälfte, bei dem prinzipiell nur die Bewegung anhand der Schleife erfolgt, weil auch der Suchprozess im Nachhinein mangels Erkennung hierfür passender Schilder aufgegeben werden muss. In beiden Fällen wird der Nao zunächst durch die Methodik der Rotationsschleife gedreht. Nach jeweils 4 Iterationen liegen dabei schon unterschiedliche Ergebnisse vor. Sie begründen sich durch die Ungenauigkeiten des Laufmodells, welche jeden Lauf individuell machen. Wesentliche Unterschiede bei der Ausführung der Implementierung ergeben sich dann im späteren Verlauf der Szenarien. Da der Roboter der linken Bildhälfte durch seinen Fortschritt in der Lage ist, ein Schild für die (Re)-Orientierung zu finden, verlässt er in Iteration 8 seine Schleife und tritt in den Orientation Mode ein. Dieser erlaubt es ihm, sich exakt auszurichten und somit die Drehung ordnungsgemäß zu vollziehen. Der Nao des anderen Szenarios hat jenen Bezugspunkt jedoch nicht, wodurch er sich durch weitere Iterationen solange dreht, bis er die Schleife auf konventionelle Art und Weise verlässt. Durch die Ungenauigkeiten bzw. automatischen Ausgleichsschritte seitens des ALMotion-Moduls hat er dabei in Wirklichkeit jedoch nur eine Rotation um 85 durchgeführt. Diese ist zwar nicht exakt, jedoch angesichts der Umstände durchaus noch akzeptabel. Somit ergibt sich eine Implementierung einer stationären Linksrotation, welche wesentlich konsistenter als die walkto-funktion arbeitet. Ausserdem kann aus ihr die Realisierung einer Rechtsdrehung sehr schnell gewonnen werden. Hierfür sind lediglich die Vorzeichen aller Rotationswinkel der verwendeten Schrittplanung daraufhin anzupassen. Darüber hinaus dient sie als Grundlage für eine Drehung des Robotersystems um 180, wie sie das Steuerungssystem verlangt (vgl. dazu l/r Direktive im Pilot, Abschnitt 6.24, S. 123 f.). Dazu müssen nur zwei gleichartige Rotationen nacheinander durchgeführt werden. 3. Steuerung einzelner Gelenke Neben dem Aufwand zur Bedienung und Korrektur der Fehler des Laufsystems beinhaltet des Movement-Modul gemäß den Anforderungen weiterhin einige Funktionen, welche die Beeinflussung einzelner Gelenke des Aldebaran Nao ermöglichen. Die hierbei mit am häufigsten im Steuerungssystem verwendeten Methoden sind in Listing 6.32 zu sehen. Sie realisieren Bewegungen des Kopfes um 90 nach links bzw. in dessen Ausgangsstellung. Das dient im Rahmen des Suchprozesses zur Erweiterung des Sichtfeldes der Kamera (vgl. Suche für Schild bei Rotation des Nao, Segment 2, S. 131 ff.). 1 def turnhead90left(self): 2 self.parent.motion. angleinterpolation(["headyaw"], [1.5708], [3], True) 3 time.sleep(3) 4 return 5 6 def turnheadnormal(self): 7 self.parent.motion. angleinterpolation(["headyaw"], [0.0], [3], True) 8 time.sleep(3) 9 return Listing 6.32: Gelenksteuerung durch angleinterpolation() Prinzipiell sind alle derartigen Aufrufe immer mit einer Ansteuerung der angleinterpolation()- Methode aus dem ALMotion-Modul verbunden (Zeile 2). Hierbei muss zunächst jeweils das zu bewegende Gelenk spezifiziert werden. Ausserdem sind der einzunehmende Winkel und die Zeitdauer, wie lange die Bewegung dauern darf, festzulegen. Ersterer kann entweder absolut oder relativ zur derzeitigen Aktuatorposition angegeben werden. Im Falle der prototypischen Implementierung wurden stets absolute Winkelangaben gesetzt. 134

147 6.3. Modulimplementierung und Abläufe 4. Steuerung eines Gelenkverbunds durch Verhaltensweisen Da ein selbstständiges Aufstehen bzw. Hinsetzen des Aldebaran Nao schon an sich sehr komplexe Prozesse sind, wurde hierfür auf die Fähigkeiten der mitgelieferten Entwicklungsumgebung, Aldebaran Choregraphe, zur Realisierung entsprechender Unterprogramme zurückgegriffen. 1 def firesitdown(self): 2 self.parent.behavior. runbehavior("sitdown") 3 time.sleep(10) 4 return Listing 6.33: Start einer Choregraphe-Behavior Jene basieren auf Referenzimplementierungen, welche diese Anforderungen durch reaktive Verhaltensweisen lösen. Sie sind im Rahmen der Modulbibliothek bereits verfügbar und mussten daher nur zu Programmfragmenten zusammengesetzt und durch Choregraphe in den Roboter geladen werden. Seitens des Steuerungssystems sind diese dann einfach an der richtigen Stelle aufzurufen. Listing 6.33 zeigt dazu eine solche Methode exemplarisch auf. Hierbei handelt es sich um einen Start des Unterprogramms, welches ein Hinsetzen des Roboters verwirklicht. Zu diesem Zweck übernimmt der ALBehaviorManager automatisch die Kontrolle über die Methoden der Bewegungsschnittstelle, wie sie durch das ALMotion-Modul zur Verfügung gestellt werden. Deshalb muss man daher nichts weiter beachten. 5. Verwaltung des Systemzustandes Das letzte wesentliche Segment der Implementierung des Movement-Moduls besteht aus Methoden, welche den Systemzustand aller Gelenke verwalten. Dies ergibt sich aus der Notwendigkeit heraus, dass NaoQI dies nicht automatisch vornimmt, um den Roboter vor Beschädigungen durch ungewollte Bewegungen bei der Entwicklung mit bzw. der Nutzung der Bewegungsschnittstelle zu schützen. Hierbei gilt, dass grundsätzlich zuerst alle Motoren/Gelenke des Roboters programmatisch aktiviert werden müssen, ehe Aufrufe an das ALMotion-Modul überhaupt eine Wirkung zeigen. Die dafür implementierte Funktion ist in Listing 6.34 zu sehen. 1 def stiffenbody(self, *_args): 2 self.parent.motion. stiffnessinterpolation("body", 1.0, 1.0) 3 time.sleep(1.5) 4 return 5 6 def unstiffenbody(self, *_args): 7 self.parent.motion. stiffnessinterpolation("body", 0.0, 1.0) 8 time.sleep(1.5) 9 return Listing 6.34: Spannen/Lockern der Motoren des Aldebaran Nao Sie gibt dazu einen passenden Befehl an die Bewegungsschnittstelle ab. Das führt natürlich zu stark erhöhtem Energieverbrauch und Wärmeentwicklung und sollte deshalb nur im begrenztem Maße zum Testen verwendet werden. Analog dazu existiert daher auch eine Methode im Movement-Modul, welche die Anspannung rückgängig macht (vgl. Zeile 6 ff.). Somit sind alle wichtigen Segmente der Implementierung des Movement-Moduls, sowie des Steuerungssystems an sich, dargestellt. 135

148 6. Prototypische Implementierung CUSURFDetector Das CUSURFDetector-Modul umfasst entsprechend des Softwaremodells eine eigenständige Implementierung eines Bildverarbeitungssystems zur Erkennung bestimmter planarer Objekte innerhalb eines Bildes. Es realisiert somit die eigentliche Wahrnehmung von Hindernissen als Sensorik, welche mangels hierfür anwendbarer Module aus der NaoQI-Bibliothek (vgl. hierzu Abschnitt 6.1.3, S. 95 ff.) vollständig selbst konzeptioniert und implementiert werden musste. (a) Stop-Schild (b) Treppenstufen (c) Rollsplit (d) Orientierung Abbildung 6.21.: Referenzschilder für die prototypische Implementierung 23 Hierbei waren im Rahmen der prototypischen Implementierung zunächst verschiedene Anforderungen und Aspekte zu verwirklichen. Grundsätzlich sollte der Aldebaran Nao durch eine angemessene Methodik in der Lage sein, die in Abbildung 6.21 dargestellten Warnzeichen bzw. Schilder selbstständig in einem geschlossenen Raum bestmöglich zu erkennen. Dies bedeutet zunächst, dass dieser Prozess möglichst zeitnah und zuverlässig auf Basis der Hardware des Roboters stattfinden sollte, um so verlässliche Werte/Ereignisse für die Funktion der Suchschleife des Steuerungssystems zu generieren. Hierzu hat, gemäß der Implementierung des Cartographer- Moduls (vgl. Abschnitt 6.3.3, S. 112), auch eine Berechnung der Distanz zu den jeweiligen Hindernissen zu erfolgen. Aufgrund der Tatsache, dass zur Laufzeit des Systems die eigentliche Position bzw. die Orientierung der zu erkennenden Schilder nicht bekannt ist, sollte der genutzte Algorithmus darüber hinaus auch möglichst invariant zu Skalierung, Rotation und Ebenenverschiebungen relativ zur Bildfläche sein. Die Realisierung eines visuellen Kompasses, der für die Stabilisation des Vorwärtslaufens bzw. Umsetzung der Rotation verwendet werden kann, war anfänglich eigentlich nicht vorgesehen. Sie ergab sich jedoch im Laufe des Projektfortschritts automatisch durch die letztendliche Umsetzung der anderen Anforderungen. Wie an der Mannigfaltigkeit nutzbarer Lösungen zur Objekterkennung und Klassifikation aus dem Bereich der computergestützten Bildverarbeitung sichtbar ist (vgl. dazu Abschnitt ff., Seite 49 ff.), stellt die Findung eines dazu passenden Ansatzes kein leichtes Unterfangen dar. Da das NaoQI-SDK jedoch die weit verbreitete Bibliothek OpenCV beinhaltet, konnten die hierfür geeignetsten Segmente aus dieser herangezogen und durch verschiedene Implementierungen im Rahmen des Entwicklungsprozesses getestet werden. Hierbei ist in etwa eine Zeit von 3 Monaten vergangen, bis der spezifizierte Funktionsumfang erreicht wurde. Der diesbezüglich erste Ansatz basierte auf einem kontinuierlichen Musterabgleich zwischen dem jeweils aktuellen Bild und den Referenzschildern auf Basis von einfachem Template Matching. Das hierfür angefertigte Python-Modul des Steuerungssystems ist auf der DVD in der Datei sources\prototypes\python\template.py zu finden. Die Klassifikation der Warnzeichen erfolgte dabei durch eine Kaskade von Abfragen, welche hierzu unterschiedlich große Versionen der Gefahrenquellen als Ausgangspunkt für deren Suche im Bild verwendete. Obwohl sich somit in der Theorie ein erster praktikabler Ansatz ergab, musste er jedoch wieder schnell verworfen wer- 23 Abbildungen aus [57] 136

149 6.3. Modulimplementierung und Abläufe den. Dies lässt sich auf die damit verbundenen Tests zurückführen, welche eine Laufzeit einer Iteration dieses Moduls von über 20 Sekunden erkennen ließen, sobald es durch die (schwache) CPU des Roboters ausgeführt wurde. Hierfür waren sowohl der zu einfach gewählte Brute-Force Ansatz als auch die Tatsache, dass die Programmiersprache Python stets interpretierend ist, ausschlaggebende Faktoren, welche den Rechenaufwand enorm in die Höhe trieben. Dementsprechend wurde bei einem anderem Testprogramm versucht, möglichst CPU schonend zu arbeiten. Das sollte, nach den Möglichkeiten des NaoQI-Frameworks (vgl. Main-Broker Programmierung, S. 91), durch eine Umstellung der Implementierung auf die Programmiersprache C++, sowie durch die Verwendung eines neuen Erkennungsansatzes erreicht werden. Hierbei war die Idee, sowohl die Kanten des jeweils aktuellen Bildes als auch die der Referenzschilder durch eine Anwendung des Canny-Algorithmus (vgl. Abschnitt 5.1.1, S. 49) als Merkmale zu extrahieren und sie mittels einer kontinuierlich ablaufenden Kaskade innerhalb einer Schleife für eine Klassifikation zu vergleichen. Das hierfür realisierte Modul ist ebenfalls auf der DVD zu finden (sources\prototypes\c++\canny.cpp). Da der Canny-Algorithmus insbesondere bei niedrig auflösenden Bildern als besonders effizient gilt und die hierbei entstehenden Konturen durch einfache Punktlisten repräsentierbar sind, sollte somit eine kürzere Laufzeit bei der Objekterkennung erzielt werden. Wie die damit verbundenen Tests auch zeigten, war das mit einer Laufzeit von unter 0,5 Sekunden pro Iteration der Fall. Allerdings musste auch dieser Ansatz leider verworfen werden. Dies lag an der Tatsache, dass die gefundenen Punkte der Konturen eines Referenzschildes in einem Bild zwar perspektivisch korrekt und auch invariant von Rotation/Skalierung waren, jedoch über keine festgelegte Reihenfolge verfügten. Da somit die Ermittlung einer entsprechend verschobenen Referenzebene bei leicht abgewandten Schildern nur noch ungenau erfolgen konnte, war eine robuste Distanzberechnung nicht möglich. Ausserdem erschien der weiterhin verwendete Brute-Force Ansatz zum Vergleich der Konturen noch immer nicht prozessorfreundlich genug, um längerfristig sinnvoll eingesetzt werden zu können. Die o. g. Nachteile/Probleme führten zu einem Test der Objekterkennung und Klassifikation auf Basis sog. SURF-Merkmale. 24 Diese werden durch eine verbesserte, weniger rechenintensive Variante des SIFT-Algorithmus bestimmt, wie er in der dazu von D. Lowe verfassten Arbeit ([37]) vorliegt. Wie schon in Abschnitt (S. 49) beschrieben, wird hierbei aus einem Bild ein Satz von Deskriptoren extrahiert, welche markante bzw. besonders detailreiche Schlüsselpunkte in ihm markieren. Die auf diese Art und Weise gewonnenen Merkmale sind dabei genauso invariant zu Rotationen, perspektivischen Verschiebungen oder Skalierungen. Vom Prinzip her arbeitete das damit verbundene Testprogramm zunächst identisch zu seinen Vorgängern. So wurde auch hier eine Schleife verwendet, welche jeweils die Merkmale aus dem jeweils aktuellen Bild bzw. den Referenzschildern berechnet und sie miteinander per Brute-Force vergleicht. Die damit einhergehenden Kontrollen wiesen allerdings eine Laufzeit eines solchen Moduls von 2 Sekunden auf, was diesen Ansatz zunächst ebenfalls unvorteilhaft erschienen lies. Sie entstand durch die Komplexität der Methode für die Extraktion von Merkmalsvektoren, welche stark von der Performanz des ausführenden Prozessors abhängt. Da jene nur kaum parametrisierbar ist, mussten andernorts Optimierungen vorgenommen werden. Eine Möglichkeit hierfür ergab sich dabei durch weiterführende Studien der Fähigkeiten der OpenCV-Bibliothek. So ist eine Klassifikation derartiger Merkmale beispielsweise auch durch deren wesentlich leistungsfähigere knearestneighbor-implementierung möglich. Durch deren Einsatz konnte eine Reduzierung der Laufzeit auf akzeptablere 1,5 Sekunden erzielt werden. Darüber hinaus brachte die Verwendung von SURF-Merkmalen einen entscheidenden Vorteil mit sich, den die anderen Ansätze nicht besaßen. Er begründet sich in dem Fakt, dass dazu in den relevanten Teilen des OpenCV-Frameworks weiterhin Methoden, welche die Projektion einer 24 Speed Up Robust Features, vgl. dazu [10] 137

150 6. Prototypische Implementierung korrespondierenden Ebene zu einem derartig klassifizierten Objekt automatisch vornehmen können, existieren. Ihre Verwendung wird exemplarisch in einem Modul der Bibliothek aufgezeigt, welches daher mit als Anhaltspunkt genutzt werden konnte. 25 Da somit das Problem der Findung einer entsprechend verschobenen Referenzebene für die Berechnung der Distanz zu einem Schild ideal lösbar war, fiel letztendlich die Wahl auf einen derartigen Erkennungsansatz bei der Implementierung des CUSURFDetector-Moduls. Init initspeech() Calibrate() initnaocam() load RefImages() train RefImages() Module Load Recognition Loop check Running() cleanup Iteration() getnao Image() savedebug Image() getscene SURF() check NeedValue() assist Rotation() knnmatch() check Preserve Stop() Preserve StopImage() locate Signs() check Preserve Start() Preserve StartImage() calculate Distances And RaiseEvents() Abbildung 6.22.: Initialisierung und zentrale Suchschleife des CUSURFDetectors Sie fand auf Basis der Fähigkeiten des ALExtractor-Moduls statt, welches seitens NaoQI die Definition und Implementierung einer eigenen Sensorlogik ermöglicht. Zu diesem Zweck stellt es ein komplexes Konstrukt aus virtuellen Methoden zur Verfügung, welche u. a. Initialisierung, Suchschleife und abschließende Aufräumaktionen beinhalten müssen. Der Aufruf der damit verbundenen Logik und die Erstellung eines eigenen Threads hierfür übernimmt dabei automatisch der Main-Broker, an dem das auf diese Art und Weise erstellte Modul lokal gebunden wird. Dessen Initialisierung erfolgt beim Start der betreffenden NaoQI-Instanz automatisch (vgl. dazu Abschnitt 6.4, Seite 153). Aufgrund dieser Komplexität ist eine komplette Beschreibung aller Funktionen der finalen Implementierung, wie sie auf der DVD, Datei sources\c++\cusurfdetector.cpp, gefunden werden kann, im Rahmen der Ausarbeitung nicht möglich. Daher beschränkt sich die folgende Betrachtung bewusst nur auf die für die Bildverarbeitung relevanten Konzepte und Teile, wie sie in Abbildung 6.22 dargestellt sind. Sie bestehen genauer aus den wichtigsten Teilschritten der Initialisierung, sowie der zentralen Suchschleife. Letztere läuft immer parallel zu der Kontrollschleife des Steuerungssystems und ist als EventGenerator sowohl für die Wahrnehmung von Hindernissen als auch für die Funktion des visuellen Kompasses verantwortlich. Hierzu bearbeitet sie per Iteration jeweils ein Bild durch die dargestellten Methoden. 25 vgl. dazu [64] 138

151 6.3. Modulimplementierung und Abläufe Initialisierung Die einzelnen Schritte der Initialisierung werden direkt beim Ladevorgang des Moduls, also noch vor dem Start der eigentlichen Bildverarbeitung, dediziert abgearbeitet. Sie umfassen neben einschlägigen Aufrufen an die zentrale NaoQI-Instanz zur Reservierung/Ansteuerung der Kamera und Sprachausgabe eine Kalibrations- und Lernphase. Letztere sind für die korrekte Funktion der Methoden der Suchschleife maßgeblich. Da die Kamera des Aldebaran Nao einer einfachen Webcam entspricht, leidet das von ihr erzeugte Bild mit Sicherheit an radialen bzw. tangentialen Störungen, welche durch günstige Linsen und Herstellungsverfahren typisch für alle derartigen Aufnahmegeräte sind und zu Verzerrungen führen. 26 Daher ist eine kontinuierliche Korrektur dieser Einflüsse notwendig, um Fehler bzw. Ungenauigkeiten bei der Erkennung von Schildern durch die Logik der Suchschleife zu vermeiden. Zu diesem Zweck hat eine Kalibrierung der Kamera zunächst zu erfolgen, um deren Verzerrungskoeffizienten eindeutig bestimmen zu können. Dazu muss, unter anderem, eine Abbildung 6.23.: Schachbrettmuster für Kalibration sog. intrinsische Matrix gefunden werden, die im Bereich der computergestützten Verarbeitung folgendermaßen festgelegt ist (vgl. [12], S. 373 f.): f x 0 c x intrinsics = 0 f y c y Hierbei beschreiben c x und c y Abweichungen des CCD-Sensors von der optischen Achse der Linse. f x und f y modellieren die unterschiedlichen Brennweiten in jeweils horizontaler bzw. vertikaler Richtung der einzelnen bildgebenden Zellen. Sie entstehen insbesondere durch schlecht geformte bzw. billige Linsen. Für eine Ermittlung dieser Koeffizienten wären normalerweise einige komplexe geometrische Berechnungen auf Basis des Pinhole-Kameramodells notwendig. 27 Da die Kalibrierung von Kameras durch ihre große Verbreitung jedoch eine sehr häufig ausgeführte Aufgabe ist, gibt es für dieses Standardproblem der computergestützten Bildverarbeitung zahlreiche Lösungen. In OpenCV existiert hierfür speziell die Funktion cvcalibratecamera2(), welche auf Basis verschiedener Aufnahmen eines vorher festgelegten Musters die Werte der intrinsischen Matrix bzw. der Verzerrungskoeffizienten sehr gut abschätzt. Als besonders weit verbreitete Referenz dient hierbei ein Schachbrett mit 54 Zellen, welches von der Webseite des Frameworks bezogen werden kann. 28 Abbildung 6.23 zeigt es aus der Sicht des Roboters. Durch eine Adaption der ebenfalls auf der Webseite bzw. in [12] zu findenden exemplarischen Implementierung 29, ergeben sich dabei beispielsweise im Falle der Kamera des verwendeten Nao die folgenden Werte: intrinsics = 132, , , , vgl. [12], S vgl. [12], S vgl. [66] 29 vgl. [65] und [12], S

152 6. Prototypische Implementierung Obwohl die intrinsische Matrix im Rahmen der prototypischen Implementierung festgelegt werden könnte, wird sie bei jedem Start des CUSURFDetectors neu bestimmt. Das hat sich bei Tests durch unterschiedliche Umgebungsbedingungen (Beleuchtung etc.) als am sinnvollsten erwiesen. Die auf diese Art und Weise erhaltenen Koeffizienten sind weiterhin bei der Abholung eines neuen Bildes für die Entzerrung zu verwenden. 1 void CUSURFDetector:: trainrefimages() 2 { 3 // initialize stop sign detection variables 4 stopkeypoints = 0; 5 stopdescriptors = 0; 6 7 // setting OVERALL SURF Params 8 params = cvsurfparams (600,1); 9 cvextractsurf( refstop, 0, &stopkeypoints, &stopdescriptors, storage, params ); 10 stop_src_corners = {{0,0}, {refstop ->width,0}, {refstop ->width, refstop ->height}, 11 {0, refstop ->height}}; // getting datalength for copying data into the cv:: Mat 14 datalength = (int)( stopdescriptors ->elem_size/sizeof(float)); // getting cv:: Mat where stop descriptors are saved for knnmatch 17 m_stop = cv:: Mat(stopDescriptors ->total, datalength, CV_32F); // copy stop sign descriptors into class variable m_stop (type cv:: Mat) 20 CvSeqReader obj_reader; 21 float* obj_ptr = m_stop.ptr <float >(0); 22 cvstartreadseq( stopdescriptors, & obj_reader ); 23 for(int i = 0; i < stopdescriptors ->total; i++ ) 24 { 25 const float* descriptor = (const float*) obj_reader.ptr; 26 CV_NEXT_SEQ_ELEM( obj_reader.seq ->elem_size, obj_reader ); 27 memcpy(obj_ptr, descriptor, datalength*sizeof(float)); 28 obj_ptr += datalength; 29 } 30 // same for other sign classes } Listing 6.35: Extraktion der SURF-Deskriptoren aus einem Referenzbild Damit die Merkmale der Referenzschilder (vgl. Abbildung 6.21, S. 136) später durch knn- Klassifikation gefunden werden können, ist es nötig, sie natürlich zuerst durch eine Lernphase zu trainieren. Listing 6.35 zeigt einen Ausschnitt der hierfür implementierten Funktion. Im Wesentlichen werden hierbei die SURF-Deskriptoren bzw. die damit verbundenen Schlüsselpunkte durch einen einfachen Aufruf an die Methode cvextractsurf() (Zeile 9) gewonnen und durch die umgebenden Befehle in dazu vorgesehenen Klassenvariablen des Moduls als Vektoren für die spätere Klassifikation geschrieben. Wenn man die so erhaltenen Merkmale in die Referenzmuster einzeichnet, entstehen die folgenden Ergebnisse: (a) Stop-Schild (b) Treppenstufen (c) Rollsplit (d) Orientierung Abbildung 6.24.: SURF-Deskriptoren der Referenzschilder 140