Missionsplanung für Multi-Robot-System

[1] Zugegeben, die Aufgabe ist nicht gerade alltäglich. Es kommt nicht oft vor, dass bei Robotics Stackexchange jemand mit einem Quadcopter Waypoints abfliegt, laut dem verlinkten H.264 Video offenbar schon eine fertige Software im Einsatz hat und jetzt die Crowd um Hilfe bittet, um das System ein wenig aufzumotzen und noch spritziger zu gestalten. Zu meinem Bedauern muss ich leider zugeben, mich mit Künstlicher Intelligenz im Allgemeinen und Robotik im Speziellen nicht so gut auszukennen, als dass ich wirklich einen Tipp geben könnte. Nur soviel vielleicht: Waypoints sind Knoten in einem größeren Graphen. Wenn der Graph aus 20 Nodes besteht kann man davon 3 Nodes auswählen und die von dem UAV abfliegen lassen. Solche Graphen, besser bekannt als Navmesh, können entweder manuell in die Map eingezeichnet werden, oder aber automatisiert über Routenverlegungs-Algorithmen berechnet werden.

Der Zweite Teil der Frage mit dem Multi-Robot-System ist auch für mich relevant. Mein Fachwissen reicht leider nicht aus, um das umfassend zu beantworten, aber Multithreading dürfte hier das Zauberwort sein. Die Idee ist es, jeden Quadcopter mit einem eigenen Prozess zu starten und dann über die Main-Loop welche den Framecounter hochzählt zu synchronisieren. Eine Multi-Threading Anwendung für einen Roboter habe ich schonmal in Python programmiert, der Sourcecode müsste noch irgendwo im Archiv schlummern, für ein Multi-Agenten-System müsste man das Konzept hochskalieren, was relativ kompliziert sein dürfte. Das Hauptproblem besteht im Timing:

Angenommen, der Roboter1 führt laut dem High-Level-Planner die Tasks a und b aus. a dauert 100 Frames, b dauert 50 Frames. Gleichzeitig führt Roboter2 den Task c aus, welcher 50 Frames dauert. Jetzt startet man das System und es passiert folgendes:

          0   25   50    75   100   125   150
Roboter 1 |-----------a--------||-----b----|
Roboter 2 |----c----|

Das Problem ist, dass sich jetzt Roboter2 schon bewegt, und Roboter1 gleichzeitig dazu eine Ausweichroute berechnen muss. Noch komplizierter wird es, wenn während sich die Umgebung verändert, klar wird, dass die Tasks auf dem Roboter abgeändert werden müssen. Weil Roboter2 jetzt an der falschen Position ist, muss Roboter1 von „a-b“ auf „a-d“ als neuen Taskplan wechseln. Aber das größte Hinderniss kommt noch. Wenn man in den Threads absolute Timinigangaben in Millisekunden definiert, kann man in der Simulation das ganze nicht einfach schneller laufen lassen. Das jedoch braucht man um verschiedene Task-pläne durchzutesten, weil ein bestimmtes Ziel erreicht werden soll. Kurz gesagt, mehrere Roboter, die noch unterschiedliche Tasks ausführen dürfen kann ziemlich Messy werden und sollte nur von erfahrenen Programmiererinnen angegangen werden.

Roboter Librarys für Echtzeitplanung

[1] Leider lautet die Antwort nein, es gibt keine Out-of-the-box Bibliotheken mit denen man Echtzeitplanung ausführen kann. Der Grund dafür ist, dass jeder Wettbewerb komplett anders ist und man die Software nur from-scratch schreiben kann. Woran man sich jedoch orientieren kann sind Paper die bereits auf Google Scholar erschienen und die Beispielimplementierungen vorstellen. So gibt es Paper für Robocup, Robocup Soccer, driverless Car Competitions oder Maze-Wettbewerbe. Üblicherweise finden sich in diesen Papern Algorithmen wie A*, RRT und zahlreiche Derivate davon.

Wenn man noch ganz neu in der Materie ist, und überhaupt keine Ahnung hat, bietet es sich an, zunächst einmal mit Echtzeitstrategiespielen herumzuexperimentieren. Viele davon besitzen einen Debug-Mode wo man sich anzeigen kann, wie der Pfadplanner funktioniert. Man kann darüber erkennen, wo er nicht funktioniert und wie man eine hohe Performance erreicht.

Noch ein Hinweis: SLAM hat mit Pfadplanung nichts zu tun, das ist eine gänzlich andere Baustelle. Beides gehört in den Bereich des „spatial cognition“, also des raumzeitlichen Schlussfolgerns.

Roboter — warum?

Sebastian Thrun hat einmal seine Motivation erläutert sich mit autonomen Autos zu beschäftigen. Und zwar möchte er gerne die Verkehrsunfälle auf Null reduzieren und damit sehr viele Menschenleben retten. Und in der Tat, wenn es gelänge autonomes Fahren voranzutreiben stehen die Chancen gut dass die mehr als 1 Millionen verkehrstote im Jahr reduziert werden.

Es gibt aber noch einen weiteren Grund sich mit autonomem Fahren näher zu zubeschäftigen. Und zwar betrifft das die Auslastung von PKWs. Laut http://www.zukunft-mobilitaet.net/13615/strassenverkehr/parkraum-abloesebetrag-parkgebuehr-23-stunden/ steht das durchschnittsliche Fahrzeit 95% der Zeit in einer Parkbucht. Aktuell sind in Deutschland 46 Mio PKW zugelassen. Das heißt, gleichzeitig sind davon nur 2,3 Mio auf den Straßen unterwegs. Das wiederum bedeutet, dass selbst das hochmotorisierte Land Deutschland nur einen Bedarf hat von effektiv vielleicht 3 Mio PKW, vorausgesetzt man würde diese Autos als Taxi nutzen. Das könnte man über autonome Steuerung erreichen. Wo man sich also ein Auto per Smartphone direkt vor die Haustür rufen lässt. Die Folge wäre nicht nur eine Einsparung von Metall zur Produktiv der vielen Autos, sondern man könnte auch riesige Mengen an Arbeitskraft einsparen. Denn wenn die Autos heute 95% der Zeit im Stau stehen heißt das auch, dass 95% der Autos fürs Parken gebaut werden. Slebst wenn man also die Produktiv der Automobile unverändert manuell durchführt, könnte man durch einen Autopiloten bereits sehr viel zum guten bewirken.

Der Witz wäre die Kostenrechnung für das ganze. Wenn man den Auslastungsgrad eines PKW erhöht, sinken dadurch natürlich die Kosten pro gefahrenem Kilometer. Das heißt, dass es für die Konsumenten sogar viel billiger wird, mit dem Auto irgendwohin zu fahren als heute. Und alles nur durch folgenden simplen trick. Man muss einfach dafür sorgen, dass die Autos nicht so wie heute parken, sondern dass sie permanent auf der Straße fahren. Das heißt, wenn man mit dem Auto vom Einkaufen nach Hause kommt, wird das Auto nicht etwa in die Garage gefahren damit es dort 14 Stunden am Stück wartet bis es wieder gebraucht wird, sondern das Auto hält kurz an, die Person steigt aus, und weiter geht die Fahrt.

Derartige Autos die Rund um die Uhr im Einsatz sind, könnte man sehr viel hochpreisiger bauen als heutige Modelle. Man könnte in das Auto Technik im Wert von 100000 EUR Und mehr verbauen ohne dass dadurch die Kosten ansteigen würden. Das Auto gehört dann nicht mehr einer Person oder einer Familie, sondern es gehört einem Konzern der es stundenweise vermietet. Um diesen Traum zu realisieren reicht eine simple Software, genannt Autopilot. Also eine Software die ähnlich wie beim Google Car, das Auto sicher durch den Verkehr navigiert.

CARSHARING
Warum sich bisher Carsharing nicht hat durchsetzen können ist simpel. Will man es machen wie bei einem Taxi braucht man einen Fahrer, der ist jedoch teuer. Will man Carsharing ohne Taxifahrer machen muss man das Auto an einen zentralen Stellplatz bringen, der ist jedoch zu weit weg. Wer bitteschön hat Lust, erst 10 km mit dem Bus zu fahren um sich dort ein Auto zu mieten? Richtig, Carsharing war bisher ein Flop und das ist gut so.

Wenn man jedoch autonomes Fahren mit Carsharing kombiniert — wie es gerade Uber ausprobiert — dann hat man die ultimative Lösung. Voraussetzung ist jedoch dass man die technischen Details des autonomen Fahrens beherscht. Nur wenn das Auto wirklich alleine fährt, kann man daraus ein Geschäftsmodell machen. Nur, um sich mal über die Dimensionen klarzumachen. Weltweit gibt es aktuell 1 Milliarde Autos. Davon sind geschätzt 600 Mio PKW die zu 95% der Zeit nutzlos in der Gegend parken. Wenn das auf autonomes Carsharing umstellt, könnte man mehrere hundert Millionen Autos einsparen. Und das beste ist, es würde niemand bemerken. Die individuelle Mobilität wäre die selbe wie heute auch.

Leider sieht es bei der tecnnischen Umsetzung derzeit noch nicht so gut aus. Soetwas wie eine OpenSource Software für das autonome Auto gibt es nicht. Ja nochnichtmal in einem Simulator wie Torcs gibt es aktuell Software die stabil funktioniert. Warum sich die Softwareentwickler noch nicht näher mit dem autonomen Auto beschäftigt haben ist unklar. Vermutlich weil das Problem aus sehr vielen Submodulen besteht und wenn man nicht alle angeht, wird sich das Auto keinen Zentimeter vorwärtsbewegen.

PROBLEME
Warum sind autonome Autos noch immer nicht realisiert? Was muss man tun, damit es irgendwann Realität wird? Der erste Schritt besteht darin, zunächst einmal nüchtern die Ist-Situation zu beschreiben. Obwohl es häufiger mediale Berichte gibt, wonach am autonomen Auto geforscht wird, und seit den 1980’er sogar Autos im Straßenverkehr unterwegs sind, die von einer Künstlichen Intelligenz gesteuert werden muss man sagen, dass die Ausgangslage extrem schlecht ist. Das fängt schon damit an, dass die Softwareentwickler noch nichtmal in der Lage sind sich eine Programmiersprache auszusuchen, in der sie einen Fahrsimulator schreiben wollen. Es gibt aktuell weder eine Simulations-Software, noch eine Künstliche Intelligenz und erst recht keine Vision Systeme. Zwwar wurde experimentiell schon viele Software entwickelt, doch die ist entweder kein OpenSource oder aber sie ist komplett wertlos. Das einzige was man heute out-of-the-box in einem Fahrzeug installieren kann, ist ein Linux basierendes Entertainment system wo auf dem Cockpit Youtube Videos abgespielt werden. Wie man jedoch das Auto steuert, darüber herscht selbst unter Informatikern das große Rätseln.

Ja schlimmer noch, es gibt keine Bücher, keine Podcasts und keine Internetforen in denen über autonomes Fahren diskutiert wird. Es mangelt also an der Infrastruktur um sich überhaupt mit dieser Technologie zu beschäftigen. Nur unter massivem Aufwand durch die DARPA gelang es im Jahr 2005 das weltweit erste Projekt aufzustellen, aber auch dort wurde keine Meta-Verfahren entwickelt um die Dinge voranzubringen, sondern es wurde das in die Autos verbaut, was sich die Leute im stillen Kämmerlein zusammengehackt haben.

Das Problem dürfte sein, dass in Sachen Autonomes Fahren der Leidensdruck zu niedrig ist. die Leute finden es normal, dass jährlich 1 Mio Leute auf den Straßen ihr Leben lassen, und sie haben sich damit abgefunden, dass ein Privat-PKW 23 Stunden von 24 Stunden in der Garage verbringt um zu ruhen.

Es gibt auch auch wenige Lichtblicke. Die Spielesoftware „Fernbus Simulator“ erfreut sich in der Community gr0ßer Beliebtheit.

Das fahrerlose Auto

Wie ist eigentlich der Ist-Zustand in Sachen driverless Car? Schenkt man den Massenmedien glauben, befindet sich die Technologie kurz vor dem Durchbruch. Es gibt lediglich noch kleinere Probleme mit der Verkehrzulassungsbehörde dann aber kann es losgehen mit dem selbstfahrenden Auto. Hersteller wie Mercedes und BMW sind aktiv an der Erforschung beteiligt … Leider ist das nur eine plumpe Illusion, sie beschreibt den gewünschten Zustand hat aber nichts mit der Realität zu tun. Die Wahrheit ist, dass weder die Technologie zur Verfügung steht sondern noch nichtmal begonnen wurde daran zu entwickeln.

Als Stand der Forschung muss man leider annehmen, dass Hobbybastler an ein Arduion Board 4 Räder dranmontieren, dann eine Webcam draufmontieren und dann irgendwie mit C++ versuchen, das Auto vorwärtszubewegen, womöglich noch unter Verwendung von obskuren neuronalen Netzen die auf nvidia Chips laufen. Irgendwas gelöst ist damit nicht, allenfalls ist das eine Demonstration wie es auf keinen Fall gemacht wird.

Ein selbstfahrendes Auto besteht aus einer großen Fülle an unterschiedlichen Komponenten die ähnlich wie bei einem Betriebssystem zusammenwirken. Und ist davon nur eine fehlerhaft, geht es nicht weiter. Von der Schwierigkeit her ist das Entwickeln der passenden Software 100x schwieriger als das Programmieren eines Linux-Kernels. Und nein, eine Software die erfolgreich funktioniert gibt es aktuell nicht. Was man jedoch tun kann ist ungefähr den Weg aufzuzeigen eine solche zu entwickeln. Zunächst einmal gilt es die Kernkomponente eines solchen Systems zu identifizieren, also ein Minimal-System zu entwickeln. Der Carolo-Cup ist ein Wettbewerb für autonome Autos bei dem die Teams auf einem Parcurs gegeneinander antreten. Obwohl dort nur Spielzeugauto in verkleinertem Maßstab eingesetzt werden, ist die Aufgabe noch immer zu anspruchsvoll. Was man zunächst einmal benötigt ist eine Light-Ausgabe des Carolo-Cup. Dieser findet auf einem virtuellen Parcurs statt, wobei die Vision Komponente unwichtig ist. Sondern es geht nur um die Steuersoftware als solche. Also um jenen Teil der letztlich die Lenkung und die Beschleunigung des Autos festlegt und der mit den Verkehrsregeln in Übereinstimmung gebracht werden muss.

Derartige Motion Control Komponenten sind das eigentliche Herzstück eines autonomen Autos. Und hier kann man versuchen, die Dinge nach vorne zu bringen. Üblicherweise wird soetwas iterativ entwickelt. Das heißt man startet mit „interactive control“ bei dem ein human-operator in-the-loop ist und steigert dann den Automatisierungsgrad. Die Herausforderung besteht darin, dass Wissen eines menschlichen Fahrers in ein Computerprogramm zu überführen. Üblicherweise wird dies als Begriffshierarchie durchgeführt, die ähnlich wie eine Klassenbibliothek ausgelegt ist. Es gibt Motion Primitive fürs Einparken, Abbiegen, am Stopschild anhalten, Wegeplanung usw.

Märchen über das autonome Fahren

[1] Hier ist sie wieder, die Behauptung dass selbstfahrende Autos mit Neuronalen Netzen und DeepLearning funktionieren würden. Mag sein, dass das von den Quellen her so belegbar ist. Nicht nur der obige Artikel schreibt das, sondern es finden sich auch viele wissenschaftliche Paper die das zu Protokoll geben. Wer jedoch schonmal versucht hat, auf seinem Arduinio RC ein neuronales Netz a la Caffe zu installieren und darüber versucht hat, das Auto zu steuern wird erkennen, dass neuronale Netze eher aufzeigen wie es auf keinen Fall gemacht wird. Auch Versuche, sogenannte LSTM Netze in einem Simulator wie TORCS einzusetzen um damit einen neuen Streckenrekord aufzustellen haben das Versagen dieser Technologie offenbar. Um es nochmal deutlich zu formulieren, neuronale Netze sind analoge Mustergeneratoren die nicht turing-mächtig sind und den Prozess des Software-Engineering nicht ersetzen können. Wer dennoch mit einer obskurven nvidia Hardware und nicht näher spezifizierten 16 Layer convolutional neural network einem Auto das fahren beibringen will sagt nichts anderes, als dass er zu faul ist echten code zu schreiben, keine Lust hat sich auf Bugsuche zu begegeben und überhaupt sich nur an ein Laienpublikum richtet jedoch nicht wirklich an der Thematik interessiert ist.

Robotik-Paper finden

Wer sich für Robotik interessiert steht einem Überangebot an Literatur gegenüber. Aber was davon ist relevant, wo spielt die Musik? Schauen wir uns zunächst eine Richtung an, wo nachweislich eine nähere Analyse Zeitverschwendung ist. Und zwar die AGI Community rund um Ben Goertzel, Hugo de Garis und John E. Laird. Schon im Vorwort zu einem aktuellen Buch schreibt Goetzel selber, dass seine Ausführungen sich an ein Laienpublikum richten und populärwissenschaftlich aufbereitet sind. Das heißt, Goertzel sieht sich als Wissenschaftsjournalist und möchte anderen Menschen etwas erklären. Das mag interessant sein für Leute die nicht aus dem Bereich Computer kommen aber es ist nichts, was man näher verfolgen müsste. Ebenfalls ignorieren kann man die sogenannte Behavior Based Robotics Szene rund um Mark Tilden und Rodney Brooks. Brooks verkauft heute zwar echte Industrieroboter und Tilden ist gut im Geschäft mit Spielzeugrobotern aber wirklich etwas neues erfährt man dort nicht. Erstens, ist die Software ohnehin propritär und zweitens ist der Ansatz erstaunlich konventionell. Auch irgendwelche bedeutende Paper in denen konkrete Algorithmen vorgestellt werden gibt es keine, und bis heute rätselt die BEAM Community was ein nv-neuron nun genau ist, und wie man damit einen Laufroboter steuert.

Wesentlich praktischer geht es da schon in einem Bereich zu wo man auf den ersten Blick gar keine Robotik vermutet. Und zwar bei der Computeranimation. Dort gibt es eine Rubrik namens „interactive Animation Control“ die auf der SIGGRAPH Veranstaltung durch Papers und Demos gefeatured wird und wo die richtige Robotik stattfindet. Vorteil Nummer 1 ist, dass man bei der Computeranimation anders als bei AGI Community nicht an theoretischen Fragen interessiert ist, sondern konkrete Controller entwickelt die in Computerspielen und Filmen eingesetzt werden. Insofern gibt es eine regelrechte Hands-on-Mentalität. Der aktuelle Stand ist dort so, dass man man aus Mocap Daten einen Motion Graph erstellt, eine Art von Finite State Machine für Animationen und in diesem Graphen dann via A* nach einer Lösung sucht. Weiterhin kommen Human-in-the-loop Steuermechanismen zum Einsatz die aus dem Bereich Puppetry entlehnt wurden. Zwar kann man auch dort im Detail Kritik äußern, aber die grobe Richtung stimmt schonmal. Wenn man etwas über Robotik lernen will findet man in diesem Umfeld die richtigen Informationen.

Ja ich würde sogar behaupten, dass man nur dort fündig wird. Während die akademische Künstliche Intelligenz (SOAR, ACT-R) wie auch die universitäre Robotik in einer Sackgasse feststecken. Dort hat man zwar echte Roboter wie auch Machine Learning, aber irgendwas konkretes erforscht wird damit nicht. Bei Lichte betrachtet sind auch die Vorlesungen am MIT über Künstliche Intelligenz sowie der Robocup Wettbewerb wo fußballspielende Roboter zu sehen sind, nur Pseudo-wissenschaftliche Veranstaltungen die sich ähnlich wie Ben Goertzel an ein Laienpublikum richten, nicht jedoch an richtiger Robotik interessiert sind. Warum ausgerechnet die etwas abseits stehende Computeranimation, Puppetry und Computerspielebranche die richtige Robotik betreibt und die wirklichen Algorithmen entwickelt ist unklar. Aber Fakt ist, dass aus dieser Ecke wichtige Impulse kommen, die zuknftsfähig sind.

Vielleicht ist Computeranimation ein Art von Nische um neues auszuprobieren? Wo man fernab der ehrwürdigen Computerscience und der Wissenschaft ein wenig herumprobieren kann und in virtuellen Realitäten seinem Spieltrieb frönt? Fakt ist, dass der konkrete Anwendungszweck immer etwas mit Unterhaltung zu tun. Meist geht es darum Motion Controller für hübfende Lampen oder lustige Hasen zu entwickeln. Offenbar ist dieser naive Anwendungszweck genau der richtige Nährboden um sich in Sachen Artificial Intelligence mal so richtig auszutoben. Als richtige Robotik kann man diese Subdisziplin nicht bezeichnen, eher als social Robotics und dort nur als virtual social robotics, wo es also um Avatare in Spielen geht. Komischerweise geht es ausgerechnet dort sehr enrst zu. Da wird sogar fachlich gestritten ob der animierte Hase nun ein neuronales Netz benötigt oder doch lieber eine Finite State Machine. So als würde es jemanden interessieren, wie die Animation am Ende aussieht.

Behavior based robotics with LejOS

LejOS ist derzeit nur eine sehr rudimentäre Klassenbibliothek um damit funktionsfähige Roboter zu entwickeln. Die Grundfunktionen wie z.B. Sensoren auslesen oder Motoren anzusteuern sind zwar implementiert, allerdings bleibt offen wie damit genau ein Roboterprogramm entwickelt werden kann. Natürlich kann man in Java in nur wenigen Programmzeilen formulieren, „Wenn Hinderniss von vorne, dann lenke nach links“, nur sind derart programmierte Roboter in aller Regel nicht das, was man eigentlich erreichen möchte. Im folgenden soll deshalb die „Behavior Based Robotik“ einer näheren Betrachtung unterzogen werden, mit der man komplexeres Verhalten ermöglichen kann.

Die schlechte Nachricht vorneweg: derzeit ist behavior based robotics wiederum nur auf einem sehr niedrigen Stand in LejOS implementiert und auch die Dokumentation schweigt sich über dieses Thema aus, so dass die Vermutung naheliegt, dass die Entwickler selbst nicht so genau wissen was es damit auf sich hat. Deshalb zunächst etwas zur grundlegenden Idee und was das besondere ist. Grundsätzlich ist Behavior based Robotics eine Gegenbewegung zur akademischen Künstlichen Intelligenz. Behavior Based Robotics ist kein LISP, kein Expertensystem, keine kognitive Architektur und auch keine Artifical General Intelligenz, vor allem aber ist behavior based robotics nicht die Wissenschaft davon wie man einer Maschine Intelligenz einprogrammiert.

Am ehesten kann „behavior based robotics“ mit dem Erstellen eines Aimbots in AutoIt verglichen werden. Dazu ein kleiner Exkurs: In der Spieleszene hat sich eine kleine Subkultur herausgebildet die versucht mit Hilfe der Scriptsprache AutoIt und wenig bis gar keinen Programmierkenntnissen kleine Minibots zu entwickeln, welche browser-basierende Flashgames automatisch spielen können. Die Funktionsweise besteht darin, dass man in einem definierten Bildschirmbereich über eine Funktion namens „pixelsearch“ nach einer bestimmten Farbe sucht und auf diese Koordinate dann den Curser positioniert. Angelehnt ist dieser Programmablauf an „GUI Automatisierung“ hat aber einen spielerischen Charakter. Das besondere an AutoIt Scripten ist, dass wohl keine andere Programmiersprache so sehr dem Stereotyp des Script-Kiddies zuträglich ist. Was bedeutet, dass diese Sprache vom Image her sehr weit unten liegt und viele wissenschaftlich ausgebildete Informatiker an Hochschulen vermutlich noch nie etwas von AutoIt gehört haben dürften. Die Programmiermethode um einen AutoIt-Aimbot zu schreiben und einen behavior-based Roboter zu programmieren ist deckungsgleich. Beides Mal gibt es kein eigentliches Konzept sondern der Quellcode wird auf das spezifische Problem hin optimiert, was im Extremfall darin mündet, dass man die Koordinanten der Buttons auf dem Bildschirm in absoluten Werten angegibt, was bedeutet, dass so erstellte Bots nicht allgemeingültig sind.

Eine erweiterte Form dieser Programmierung findet sich in Wettbewerben wie Starcraft AI wo beispielsweise der EISbot ebenfalls über behavior based robotics erstellt wurde, dort in der Sprache ABL (a behavior language). Auch beim EISbot gibt es das Grundproblem, dass dieser nur das eine konkrete Starcraft Game spielen kann und nichts anderes. Selbst für den Nachfolger (Starcraft 2) ist der Bot nicht mehr zu gebrauchen, insofern kann man ihn als gescripteten AutoIt Bot verunglimpfen.

Und jetzt vielleicht der zurück zu LejOS. Auch dort kann man mit ähnlichen Vorgehensweisen zu Programmcode gelangen. Bei vielen Robotik-Wettbewerben ist das auch die übliche Praxis ohne dass es näher thematisiert wird, dass die erstellten Problemlösungen nicht verallgemeinerbar sind. Und das dürfte auch die wichtigste Eigenschaft von behavior-based-robotics sein, dass ein theoretisches Fundament fehlt und eine Abstraktion nicht stattfindet. Diese Programmiermethode zeichnet sich dadurch aus, dass eine Scriptsprache verwendet wird, also keine richtige Programmiersprache sondern eine Art von Makro, was Aktionen ausführt. Genauer gesagt wird ein Prozess beschrieben, man sagt also dem Programm bzw. dem Roboter was konkret in welcher Reihenfoge zu tun ist.

Aber daraus zu folgern, diese Programmierung wäre besonders simpel und zu keineren komplexen Problemen zu gebrauchen ist falsch. Die Logik und damit das theoretische Modell ist nicht im Quellcode selber enthalten, sondern muss über vorgelagertes Softwareengineering geleistet werden. Man kann das Erstellen von LeJOS Scripten wie auch das Programmieren in AutoIt sehr wohl unter wissenschaftlichen Aspekten betreiben, und zwar indem man Methoden wie das Wasserfallmodell, UML Diagramme oder Behavior Trees einsetzt. Nehmen wir ein kleines Beispiel wie die Erstellung eines AutoIt Scriptes für Starcraft AI funktioniert.

Zunächst einmal erstellt man eine Anforderungsanalyse worin man in Stichworten beschreibt, was der Bot können muss, welche Spielstärke er mindestens haben sollte, wie umfangreich das Projekt werden darf, wann er fertig sein sollte und wie er in groben Schritten funktionieren soll. Dann überlegt man sich eine grobe Unterteilung in Unterprogramme, also beispielsweise „Strategie, Umgebungserkennung, Handlungsplanung“ und zwar unter dem Gesichtspunkt von Starcraft. Zusätzlich sind noch Behavior Trees, Struktogramme oder UML Diagramme nützlich. Und dann kann man versuchen, dieses Konzept in AutoIt Programmcode zu überführen und zu testen.

VERGLEICH
Im folgenden eine Gegenüberstellung zwischen behavior Based Robotics (aka AutoIt Bot Erstellung) und akadamischer Künstlicher Intelligenz. Die akademische Künstliche Intelligenz ist an Algorithmen interessiert, welche möglichst allgemeingültigen Charakter besitzen und im besten Fall eine echte Künstliche Intelligenz darstellen. Beispiele hierfür sind Neuronale Netze, Prolog Shells, Machine Learning oder genetische Algorithmen. Diese Ansätze sind von der Konzeption her so ausgelegt, dass man den entsprechenden Algorithmus in Software implementiert, das Programm ausführt und dann fängt der Roboter an zu denken und lernt fehlendes Wissen automatisch hinzu. Beispielsweise sind genetische Algorithmen darauf ausgelegt, dass sie ihren eigenen Programmcode zur Laufzeit verbessern können um sich so optimal an Probleme anpassen. Aber auch Algorithmen wie Simulated Annealing können zur akademischen Künstlichen Intelligenz gezählt werden, weil sie universale Lösungsstrategien darstellen die für sehr viele Probleme angewendet werden können.

Im Gegensatz dazu sind AutoIt Scripte (bzw. behavior based robotics) jeweils auf ein konkretes Problem zugeschnitten, sie sind nicht intelligent oder lernfähig. Stattdessen muss die Programmlogik von außen erstellt werden und zwar über Softwareengineering. Das bedeutet, das Verstehen des Problems, das Finden einer Lösung, das Durchdenken unterschiedlicher Möglichkeiten wird nicht im Programmcode durchgeführt sondern ist Aufgabe des Softwareentwicklers. Er verwendet dazu Modellierungstools wie UML-Diagramme, bedient sich zur Recherche des Internets, oder nutzt IDEs um den Programmcode zu erstellen.