Roboter Tagebuch

Model für einen Zweirad-Roboter
[1] Ich habe sowohl die Frage als auch die bisherigen drei Antworten aufmerksam gelesen. Angesichts der hohen Punktzahl die die Antwort1 erhalten hat, scheint die Stackoverflow Community wohl der Meinung zu sein, dass diese Antwort richtig ist. Darin wird ein mathematisches Modell erläutert was aus mehreren Formeln besteht, die Gebrauch machen von Sinus und Cosinus Berechnungen. Ferner wird auf ein Paper verwiesen „Structural properties and classification of kinematic and dynamic models of wheeled mobile robots“ was bei google Scholar stolze 1261x zitiert wurde, was ein extrem hoher Wert ist. Normalerweise ist es immer ein bisschen risky sich gegen das Urteil der breiten Masse auszusprechen, aber ich es versuche es im folgenden.

Zunächst einmal ist ein mathematisches Modell wie es in dem Paper beschrieben wurde allein nicht ausreichend um den Roboter zu steuern, der zwei Räder besitzt. Rein formal mögen die Gleichungen richtig sein, mit denen man ermittelt wohin der Roboter zeigt, wenn man die Räder einzeln bewegt, das Problem ist nur dass sich der Roboter entweder in einer Physik-Engine befindet oder sogar im Reallife. Und die dort auftretenden Bedingungen werden durch wenige mathematische Formeln nicht im mindesten abgedeckt. Wenn man das Problem richtig modellieren möchte, muss man die Sprachwissenschaft bemühen. Schritt 1 ist das Aufstellen einer Taxonomie, diese besteht aus Oberbegriffen und dazugehörigen Motion Primitive. Im Schritt 2 werden die Motion Primitive als Finite State Machine ausformuliert und zwar mittels Scripting AI. Das Verfahren wird im Bereich der Computerspiele als Behavior Tree bezeichnet, wird aber auch in der Computeranimation eingesetzt. Das fertige Modell besteht aus:
– mathematischen Formeln
– Taxonomie
– Motion Primitive
– Finite State Machine

Erst dieses Modell ist in der Lage, den beschriebenen zweirädrigen Roboter wirklich umfassend zu modellieren.

Roboter lernt laufen mit neuronalem Netz
[2] Zugegeben, das Video sieht schon sehr professionell aus. Es wurde offenbar mit einer neuen Kamera aufgenommen, die Mechanik ist ordentlich verkabelt und Laufen tut der lustige Kerl auch noch, was will man mehr? Dennoch möchte ich eine Anmerkung machen und zwar geht es in der Forschung nicht darum Dinge zu präsentieren die funktionieren sondern interessant sind vor allem die Bugs. Das heißt, aus Gründen der Anschlussfähigkeit sind Projekte besser bei denen das neuronale Netz nicht in der Lage ist die gestellte Aufgabe zu lösen weil man dann Experten fragen muss, woran das liegen könnte. Wenn jedoch kein Bug vorliegt, kann man auch keine Oberschlauen Sprüche machen. Und ich glaube, das ist auch der Grund warum Wettbewerbe wie Robocup erfunden wurden, weil man dort Bugs am laufenden Band produziert. Kurz gesagt, dein Roboter funktioniert zu perfekt, und das ist nicht gut.

subsumption Architektur

[3] Zitat: „Dabei wird das Gesamtverhalten des Roboters als Netzwerk aus Einzelverhalten ausgedrückt. Die Verhalten sind in Ebenen organisiert. Jede Ebene ist von der anderen unabhängig. Aber… ganz durchdrungen habe ich dieses Konzept wohl noch nicht, wie es scheint.“

* Suche bestimmtes Objekt
* fahre Objekt an
* hebe Objekt auf

Oh ich sehe gerade, das Posting ist schon etwas älter (aus dem Jahr 2015) aber dennoch ist das Thema interessant. Richtig ist, dass die Brooks Subsumption Architektur für sich allein in der Tat keinen Sinn macht, man muss ontop noch ein „natural language interface“ zuhinzuprogrammieren als obersten Layer. Über diesen interagiert der Human-Operator dann mit dem System. Man kann sich das Interface so vorstellen wie in einem Textadventure, auf das Beispiel bezogen könnte ein Kommando lauten: „Fahre zu Objekt“. Das heißt, die Eingabe besteht aus einem Befehl und einem Zusatz. Daraus erzeugt ein Parser dann die Aufrufe an das Hauptprogramm.

Mit diesem Hintergrundwissen kann man auch leichter erahnen wie die Programmierung der veschiedenen Layer genau aussieht. Und zwar besteht das Ziel darin, am Ende auf textuelle Befehle reagieren zu können. Es geht also nicht darum, dass der Roboter irgendwie intelligent ist, sondern nur darum, dass er für den User-Befehl die Steuerkommandos an die Servos sendet. In der Praxis werden die unterschiedlichen Layer der Subsumption Architektur übrigens mit Hilfe von Objektorientierter Programmierung realisiert. Damit kann man schön das Programm in Untereinheiten kapseln und einzeln testen.

Subsumption ist mit sicherheit ein Here-to-stay, allerdings sind die meisten Paper in denen es erläutert wird hoffnungslos veraltet, so dass es fast schon normal ist, wenn zunächst Konfusion entsteht.

RI Seminar

Didaktische Fails in der Robotik
[1] Zunächst einmal ist der Ansatz lobenswert, den Informatik Studenten etwas über Robotik zu erzählen. in der Mitte des Videos wird erläutert, dass man Macroactions benötigt um den Problemraum effektiv zu sampeln. Das ist korrekt. Ebenfalls Stand der Forschung ist es, dafür einen PDDL ähnlichen Planner zu nutzen. Vom inhaltlichen gibt es also wenig bis gar nichts zu bemängeln. Was jedoch stört ist das dahinterstehende didaktische Konzept. Ich bezweifel, dass auch nur einer der anwensenden Zuhörer etwas lernen konnte. Das liegt zum einen darin, dass außer einer Powerpoint Präsentation nichts geboten wurde, vor allem kein ablauffähiges Programm. Oh ja, natürlich gibt es derartige Software. In ROS wurden die angesprochenen Konzepte bereits realisiert, die Knowrob Engine und die SMACH Engine arbeiten damit. Nur, ROS ist mehrere Gigabyte groß. Wir haben also einerseits einen sehr abstrakten Vortrag plus eine messy-Software die die Collyer Brother geschrieben haben und jetzt sollen Anfänger in Sachen Robotik sich daraus einen Reim machen. Das kann nur scheitern.

Besser wäre es gewesen, wenn der Vortragende zunächst einmal seine Hausaufgaben macht, bevor er Lernaufgaben für seine Schüler ausgibt. Dazu gehört, aus dem Vortrag selber die komplizierten Dinge zu entfernen. Man muss nicht unbedingt einen symbolischen Planner erläutern nur weil man Macroactions nutzt, man kann in einer Zwischenstufe den Behaviortree auch manuell, d.h. interactiv ausführen. Und zweitens wäre es nötig, didaktisch wertvolle Software bereitzustellen, die aus weniger als 1000 Lines of Code worin das Konzept anschaulich gezeigt wird. Allein schon die Vorstellung, dass die Studenten nach dem hören des theoretischen Teils an eine ROS-Workstation hinüberwechseln um sich dort durch Millionen Lines of C++ Code zu scrollen auf der Suche nach dem ominösen PDDL Planner ist schrecklich.

Der Grund für derartige Fails dürfte darin bestehen, dass die Intention in dem Vortrag keineswegs die ist, Robotik didaktisch aufzubereiten, sondern es geht um universitäre Robotik. Also die, welche an der CMU oder anderen US-amerikanischen Elite Unis durchgeführt wird.

Surgical robotics
[2] Kompliment für den Vortrag. Der Vortragende kommt aus der Praxis und setzt den vorgestellten Roboter selber ein. Zuerst gibt es einen Rückblick auf das Davinci System. Der Vorteil damals war, dass eine Videoaufzeichnung möglich wurde und dass der ausführende Arzt an einem anderen Ort sein kann. Im zweiten Teil des Vortrages wird das Nachfolgeprodukt von Medrobotics vorgestellt: der Surgical Snake Robot (Medrobotics Flex). Aufgelockert wird der Vortrag noch durch eklige Aufnahmen aus dem Körperinnneren bei dem Schnitte am lebenden Gewebe ausgeführt werden.

Aus Sicht der Robotik gibt es dennoch etwas zu bemängeln. Beim Davinci Surgical Robot gab es parallel dazu noch ein OpenSource Modell genannt „Raven II“ was explizit entwickelt wurde, um Algorithmen zu testen. Wo ist das Raven II Äquivalent zum Medrobotics Flex System?

Eskalation bei Robocup

Wenn man die Robocup Challange mit richtigem Fußball vergleicht so stellt man fest, dass es bei dem Roboterwettbewerb sehr gesittet zugeht. Klar, manchmal applaudieren die Fans wenn ein Tor geschossen wurde, aber soetwas wie Problemfans und Hooligans gibt es bei Robocup nicht. Woran liegt das? Schauen wir uns zunächst einmal echten Fußball an, der über eine lange Tradition verfügt, und anhand derer das Gewaltphänomen gut erforscht ist. Im Regelfall geht Gewalt dort von Männern aus und zwar insbesondere wenn die eigenen Mannschaft verliert. Die Enttäuschung ist groß, es entsteht Frust und das erzeugt Wut. Sowas weiß auch die Security und hat ein besonderes Augenmark auf die ersten Anzeichen einer sich abzeichnenden Eskalation. Wenn der erste Pyro explodiert und noch dazu Alkohol im Spiel ist, steigt die Wahrscheinlich dass es zu unschönen Szenen noch im Stadion oder am Bahnhof kommt.

Das auslösende Moment ist dabei einerseits der Wettbewerbscharakter des Fußballspiels und als logische Folge davon die Unterscheidung in Sieg und Niederlage. Es ist selten bis unwahrscheinlich, dass die Fans der Siegermannschaft anfangen herumzupöbeln, im Regelfall geht es diesen Fans super. Ihre Mannschaft hat triumphiert, sie haben gezeigt, dass sie Fußball beherschen und sie klopfen der unterlegenen Mannschaft sogar aufmunternd auf die Schuler „Hey nicht so schlimm, nächstes Mal gewinnt ihr vielleicht“. Von Seiten der Verlierer sieht die Lage weit weniger entspannt aus, dort hat man sich lange auf das Match vorbereitet, intensiv trainiert und wurde von seinen Fans unterschützt. Wenn jetzt die Niederlage da ist, fällt das alles von einem ab. Und man fragt sich ob der Schiedsrichter vielleicht unfair war und ob es gerecht zuging. Wenn das verneint wird, ist die Versuchung groß dies als persönliche Niederlage zu verstehen, als Angriff auf die eigene Ehre. Und das ist dann der Moment wo die die zerbrochene Bierflasche genutzt wird um … ach die Details lassen wir mal, es reicht zu wissen, dass Gewalt eskalieren kann.

Auch bei Robocup gibt es eine Verlierermannschaft. Dies ist in den Regeln explizit so gewollt. Und ähnlich wie beim richtigen Fußball auch empfinden sie die Niederlage als persönliche Zurücksetzung. Die Berichterstattung über diesen entscheidenen Moment ist jedoch noch mangelhaft. Es gibt keine Videos wo zu sehen ist, wie eine enttäuschte Verlierermannschaft ihren Frust mit Gewalt ausagiert. Was sich jedoch findet auf Youtube sind Videos mit dem Titel „Robocup final“ und „Robocup wins“, wo also der Moment am Ende des Spiels festgehalten wird wo der strahlende Sieger gekührt wird. Wenn man sich dann auf das gegnerische Team fokussiert wird man dort lange Gesichter sehen. Es sind die selben Mechanismen die auch beim regulären Fußball erkennbar sind. Die Verlierermannschaft und dessen Fans sind also potentielle Problemkandidaten. Also Leute die Stress machen könnten.

Was die Teams bei Robocup noch lernen müssen ist richtig zu verlieren. Also nach dem Match ihren Frust auch offen zu zeigen, so wie es im richtigen Fußball zum eingeübten Ritual gehört. Aber offenbar glauben viele Teilnehmer, dass man bei einem Roboterwettbewerb keine Gefühle zeigen dürfte und die Niederlage hinnehmen müsste.

Das man auch bei Denksportspielen seinen Frust rauslassen kann, zeigen mehrere Aufnahmen im Profischach, bei denen enttäuschte Verlierer einige unschöne Dinge tun.

Second-order dynamical systems

[1] Es handelt sich um einen Begriff aus der Chaosforschung bei dem komplexe chaotische Systeme wie Mandelbrotmengen untersucht werden. Stefan Schaal (er wird in dem Paper an zwei Stellen in den Literaturangaben zitiert) hat aufbauend auf der Chaostheorie in den 1990’er Jahren die „Dynamic Motion Primitive“ entwickelt, eine weiterentwickelte Form eines PID Controllers, der bei einem Roboter die Arme steuern soll. Dynamic Motion Primitive werden als Pattern Generatoren eingesetzt um die Trajektorie zu erzeugen. Ungefähr in diese Richtung geht auch das verlinkte Arxiv-Paper. Reinforcement Learning wird verwendet um für den Autoencoder die Parameter zu ermitteln. Um das Konzept einzuordnen sollte man wissen, dass der von Schaal vorgeschlagene Ansatz nicht turing-mächtig ist. Es ist ein Oszillator nichts weiter. Das heißt, es ist gegenüber Scripting AI unterlegen und kann nur für sehr simple Probleme verwendet werden. Wenn man richtige Roboter-Control-Systeme bauen will, sollte man lieber das SIMBICON Modell nutzen und das versuchen zu optimieren. Das wird in dem Arxiv-Paper jedoch nicht verlinkt, weil Simbicon ursprünglich im Bereich der Computeranimation und nicht in der Robotik entwickelt wurde.

Roboterwettbewerbe

Außenstehende glauben vielleicht, dass Robotik ein Thema der Inforamtik wäre wo es darum geht den perfekten Kampfroboter zu programmieren um so unendlich viel Macht zu erhalten. Doch das ist nicht wahr. In Wahrheit ist Robotik eine Methode um „computional thinking“ zu erlernen, also ein Lernprogramm für einen selber. Das heißt, der Roboter selber ist egal, sondern es geht um die Leute die sie programmieren. Aber wie lernt man am besten Robotik? Natürlich durch eine Robotics-Challange. Davon gibt es nicht soviele. Wikipedia sagt, dass es aktuell folgende größeren Roboterwettbewerbe gibt:
– Robocup
– Darpa Robotics Challange
– Micromouse
– First Lego League

Gehen wir die Challanges durch: First Lego League ist etwas für Jugendliche und Schüler. Micromouse gilt als weitestgehend gelöst weil im Grunde ein pathplanner ausreicht um die Mouse zu steuern und wie der programmiert wird ist allgemein bekannt. Die Darpa Challange ist etwas für Teams die zuviel Geld haben und mit fetten Etats und Kleinbussen anreisen, bleibt also nur noch die Robocup Challange übrig. Das ist zwar nicht direkt eine Jedermann Veranstaltung aber immerhin ist man so offen, dass die Paper publiziert werden, dass es Youtube-Videos gibt und die Veranstaltung medial supported wird.

Worum geht es bei Robocup? Es geht darum, Spielzeugroboter die der obeneren Preisklasse entstammen Fußball spielen zu lassen. Sie müssen dort als Team agieren und es gilt zu gewinnen, also besser zu sein als die gegnerische Mannschaft. Trotz intensiver Recherche konnte ich keine vergleichbare Challange ausfindig machen, wo also ebenfalls eine Roboterchallange durchgeführt wird, sondern Robocup ist wohl das was als Marktführer in dem Bereich gilt.

Bleibt noch die Frage zu klären ob man womöglich auch ohne Challange Roboter programmieren kann. Also einfach nur ein Paper veröffentlichen und den Studenten erklären wie es gemacht wird. Leider nein, das wurde gemacht bevor es Robocup gab, was dazu geführt hat, dass zwar viel Material über Roboter entstand, das aber alles nicht in der Praxis getestet wurde. Bei Robocup geht es primär um die Demonstration als solche. Und erst wenn eine Mannschaft 10 Tore hintereinander schießt interessiert sich jemand für die technischen Details.

Bleibt als letzte und wichtigste Frage noch zu klären was man mitbringen muss um bei Robocup zu gewinnen? Meiner Ansicht nach reicht es aus, wenn man einen Robotercontroller programmiert der ein Team steuert und das gegnerische Tor mit Treffern überzieht.

Kann man bei Robocup irgendwas gewinnen? Wohl eher nicht. Es sei denn man bezeichnet den Applaus im Publikum als erstrebenswert. Manchmal erhält man bei der Siegerehrung auch eine Auszeichnung überreicht. Aber ich glaube, im Kern geht es darum, das gegnerische Team kaputt zu machen.

Robocup ist aus mehreren Gründen interessant: einmal die Möglichkeit eine Challange durchzuführen bei der es gerne auch etwas aggressiver zugehen kann, dann das Herumspielen mit der allerneuesten Technologie und als drittes die öffentliche Wahrnehmung. Das heißt Robocup wird auch vom Mainstream reflektiert.

DETAILS
https://www.robocup2017.org/eng/leagues_football.html stellt den Wettbewerb nochmal mit etwas Videomaterial da. Es gibt verschiedene Leaguen wobei die Small Size League mit radgetriebenen Robotern funktioniert während die humanoide League schon etwas anspruchsvoller auf die bekannten Nao Modelle setzt.

Programmtechnisch am leichtesten dürfte die Simulation League zu realisieren sein. Dort ist einfach nur eine simulierte Draufsicht enthalten die eine Physik-Engine? verwendet um den Spielausgang zu bestimmen. Aus spieltheoretischer Sicht handelt es sich um ein Realtime-Strategy Game bei dem ein Ball, usw usw. Steht alles im Regelwerk drin. Doch gehen wir mal in die Detail, wie spielt man da mit?

Zunächst einmal fällt auf, dass die Antwort niemand kennt. Was es gibt, sind jedoch wissenschaftliche Paper der einzelnen Teams in denen erläutert wird, wie die jeweilige Software funktioniert. Im Laufe der Jahre wurden Fortschritte erzielt aber die eine Software mit der alle arbeiten gibt es nicht. Vielmehr ist handarbeit angesagt, überlichweise versuchen die Teams das an Wissen in die Software einzubringen was sie schon haben: seien es Kenntnisse über C++ Programmierung, über Suchalgorithmen oder was auch immer. Robocup besteht aus zwei Layern, einmal das öffentlich wahrnehmbare Spiel auf dem Platz und dann die Programmierung der Roboter. Im folgenden versuche ich eine Beschreibung zu liefern wie eine KÜnstliche Intelligenz für Robocup auszusehen hat. Leider ist es bisher nur ein Konzept, der passende Sourcecode muss noch programmiert werden. Aber vielleicht sind ja dennoch wichtige Dinge dabei.

Die Künstliche Intelligenz nutzt eine linguistische Taxonomie. Damit ist ein Wortnetz gemeint was hierarchisch beschreibt was die Motion Primitive sind. wie z.B. „goto ball“, „kick ball“, „standup“ usw. Jedes dieser Motion Primitive wird als Finite State Machine programmiert. Das heißt, mit Sourcecode hinterlegt, der die Parameter und die Lowlevelkommandos enthält. Bei „goto Ball“ wird beispielsweise der Ball lokalisiert und der Roboter bewegt sich dorthin. Die Taxonomie wird in eine GUI eingeblendet um sie interaktiv von einem Human-Operator als Interface zu nutzen. Das heißt, ein Mensch klickt auf die Kommandos und steuert so den Schwarm. Vergleichbar wie bei einem Echtzeitstrategiespiel. Der Unterschied ist jedoch, dass die Roboter mehr können als einfach nur zu einem Punkt zu gehen, sondern es gibt eine reichhalte Auswahl an Motion Primitiven, die bishinunter zur inversen Kinematik jedes Detail des Roboters beeinflussen.

Ist die linguistische interaktive Taxonomie funktioniertfähig und reagiert sie auf menschliche Kommandos geht es im nächsten Schritt darum, den Automatisierungsgrad zu erhöhen. Das Regelwerk von Robocup sieht vor, dass nicht geschummelt werden darf, das heißt, die Roboter müssen autonom agieren. Das bedeutet man muss den Human Operator out-of-the-loop bekommen. Das heißt, man benötigt einen Globalplanner, der aus der Taxonomy den passenden Motion Primitive auswählt. Ein solcher Globalplanner benötigt als Hilfestellung einen Parser, der das Spielfeld visuell analyisert und daraus berechnet welche Aktionen anstehen.

Das heißt, die Künstliche Intelligenz ist kein monolitscher Algorithmus der denken kann, sondern es handelt sich um eine Layer-Architektur die stückweise entwickelt wird und wo erst ganz am Ende eine autonome Steuerung entsteht. In der Literatur wird dieses Design als Bottom up Robotics bezeichnet.

Der richtige Zeitpunkt für Robotik ist jetzt

In einem frühren Blogpost habe ich leicht pessimistisch beschrieben dass in einem industriellen Roboter derzeit überhaupt keine Chance haben und höchstens noch medizinische Roboter denkbar wären weil man dort technischem Fortschritt aufgeschlossen gegenübersteht. Die Grundproblematik ist leider auch mit dem Henne Ei Problem vergleichbar. Das heißt, es fehlt an Firmen die Roboter herstellen, in Folge dessen gibt es keine Nachfrage und das heißt es ist für Firmen nicht interessant sich mit Robotern zu beschäftigen.

Generell lässt sich sagen, dass bevor man mit Robotik beginnt ein passendes Umfeld existieren muss damit ein Bootstrapping Prozess starten kann. Ein solches Umfeld ist der Robocup Wettbewerb, https://cre.fm/cre112-roboterfussball Ein Roboterwettbewerb selbst ist zunächst noch keine Robotik sondern eine Veranstaltung die Robotik fördern möchte. Das heißt, Robocup selber hat gar nichts mit Robotik zu tun, sondern ist eher eine Art von Messe / Show / Sportveranstaltung die Besucher anzieht, Preise vergibt und für ein Rahmenprogramm sorgt. Erst innerhalb dieser Veranstaltung wird dann über konkrete Robotik nachgedacht. Damit hat man das Henne Ei gewissermaßen entschärft. Es gibt jetzt ein Umfeld für Robotik, in folge dessen fühlen sich Roboterbauer davon angezogen, die dann wiederum die Veranstaltung nach vorne bringen.

Aber die Vorteile gehen noch weiter. Im Grunde geht es auch innerhalb von Robocup gar nicht um Robotik oder um Fußball. Weil die meisten Teilnehmer sich gar nicht für Fußball interessieren. Und ergo ist es auch egal, ob sie Roboter dafür programmieren können. Es ist ein komplett nutzloser Wettbewerb der die Menschheit kein bisschen weiterbringt. Denn, selbst wenn es gelingt bis 2050 humanoide Roboter gegen Menschen antreten zu lassen ist damit keines der großen Probleme wie Krieg, Armut oder Krankheit überwunden. Sondern worum es eigentlich geht ist etwas anderes: und zwar Forschung. Also über Algorithmen nachzudenken mit denen man Künstliche Intelligenz realisieren kann.

Die wichtigste Eigenschaft von Robocup ist, dass es auf eine breite Akzeptanz stößt. Das heißt, anders als die akademische Robotik gibt es mehr als 3 Leute weltweit die mitreden können. Das heißt, es existiert dort die seltene Mischung aus Breitenwirkung plus technologischem Tiefgang. Das heißt, einerseits zieht es die Massen an, die teilweise alkoholisiert zu der Veranstaltung kommen und das Niveau damit absenken, gleichzeitig ist es aber nicht billig weil die klügsten Wissenschaftler der Welt nicht wissen, wie es man gewinnt und sich richtig anstrengen müssen. Eigentlich ist es also kein richtiger Fußball, aber richtige Robotik ist es auch nicht.

Wie weiter im Blog?

Schon häufiger habe ich die rhetorische Frage gestellt, wie es denn weitergehen soll mit diesem Blog. In der Titelzeile ganz oben unter dem Trollheaven Schriftzug steht als Ergänzung „Robotik und Künstliche Intelligenz“ und das ist nach wie vor das Programm. Es gibt zwar auch viele Randgebiete wovon besonders Academia.edu und die Zukunft des Publishing mich interessiert, doch die eigentliche Aufgabe von diesem Blog ist es, eine Robot-Control-Software zu entwickeln und leicht verständlich zu erläutern. Die letzte Iterationsstufe auf dem Weg dorthin wurde hier vor einigen Tagen veröffentlicht in einem Blogpost. Zu sehen war ein Screenshot plus der dazugehörige Sourcecode. Aktuell wird ein GUI Menü verwendet aus dem man Motion Primitive auswählen kann welche jeweils eine Finite State Machine darstellen. Im Vergleich zur Robotersoftware wie sie normalerweise an den Hochschulen eingesetzt wird ist diese Robot-Control-Software bereits als advanced einzustufen. weil man sich damit auch komplexe Aktionsfolgen wie dexterous Grasping zusammenklicken kann.

Leider hat es nicht nur Vorteile wenn man etwas besonders gut gemacht hat, weil nicht klar ist, was das nächste Ziel ist. Aktuell ist die Software bereits im Stunde mehr zu leisten als bei der Amazon Picking Challange gefordert ist. Und zwar über die erwännten Motion Primitive die sich in beliebiger Reihenfolge auswählen lassen, womit Pick&Place unter erschwerten Bedingungen möglich ist. Im Grunde ist das schon die Bauanleitung für die Roboter von morgen.

Doch richten wir den Blick auf mögliche neue Ziele. Wohin könnte man die Software weiterentwickeln? Im Vergleich zu wem oder was ist die Software noch unterlegen? Nach meiner Recherche hat Pixar sich mit Dingen beschäftigen die über das hinausgehen was mein eigenes Robot-Control-System zu leisten im Stande ist, und zwar die Animation von abendfüllenden Spielfilmen. Wollte man das vorgestellte Robot-Control-System dafür nutzen um die Charktere aus Toystory zu animieren würde man damit scheitern. Dafür ist die Software nicht leistungsfähig genug. Es gibt nur 13 Motion Primitive und die Charaktere die sich damit bewegen lassen wären nicht realistisch. Insofern besteht das nächste Ziel, an dem man sich schön abarbeiten kann, eine Software zu programmieren die mit Menv mithalten kann. Menv ist der Name der Pixar-Software die in den 1980’er erfunden wurde, um 3D Animationsfilme zu scripten. Es ist eine Software gegen die meine eigene Robot-Control-Software wie ein blutiger Anfänger aussieht.

Und damit ist das Ziel umrissen wie es mit diesem Blog weitergehen soll. Zunächst einmal versuche ich mehr über Menv herauszufinden in der Hoffnung mir kleine Tricks abschauen zu können und dann wage ich mich an die spannende Herausforderung Menv zu klonen. Wohl wissend, dabei vermutlich zu scheitern weil die Aufgabe extrem schwer ist. In einem Paper über Computeranimation stand mal, dass für einen der Pixar Filme mehr als 3000 Behaviors entwickelt werden muss. Vermutlich bestand jeder Behavior noch aus mehreren Motion Primitiven. In meiner eigenen Software sind derzeit nur 13 Motion Primitive vorhanden, was umgerechnet 1-2 Behaviors entspricht. Wie man die Anzahl dramatisch erhöht ist derzeit ein Rätsel. Ob das überhaupt in Python Code möglich ist, bleibt ebenfalls unklar. Fakt ist jedoch, dass man zur Animation eine sehr viel leistungsfähigere Behavior Engine benötigt, bei der der Automatisierungsgrad höher ist. Also wo eben nicht ein Operator sich fleißig durch die Menüs klickt, sondern wo viele Dinge bereits gescriptet sind.

Ob es mir je gelingt Menv nachbauen zu können? Wohl eher nicht. Dafür gibt es zu wenig Literatur wo man nachlesen kann, wie sowas im Detail realisiert werden muss. Aber zumindest gibt Menv mir die Möglichkeit realisitisch einzuschätzen wohin die Reise gehen könnte. Es geht darum, computeranimierte Zeichentrickfilme zu erstellen und zwar vollautomatisch.

PIXAR
Das uns Pixar nicht alles über Menv und ähnliche Programme erzählt dürfte wohl unstrittig sein. Es gibt keine Präsentation zu der Software und OpenSource ist sie auch nicht. Alles was Google Scholar darüber weiß sind Bruchstücke in unterschiedlichen Papern die von Pixar Mitarbeitern erstellt wurden, die nur sehr wenig über die Software erzählen. Und vermutlich auch noch auf die falsche Weise. Aber hey, das ist ok. Umso aufregender wird es, eine Software nachzuprogrammieren von der man weder einen Screenshot hat, noch ihren Quellcode kennt. Sondern allein darüber, dass man die vermututeten Features implementiert, die grob etwas mit Computeranimation zu tun haben. Das Resultat ist jedenfalls überwältigend gut. Keiner erzeugt bessere Filme als Pixar. Insbesondere die frühen Werke aus 1980’er sind eine absolute Glanzleistung. Es grenzt an ein Wunder, wie sie es auf der damaligen Hardware überhaupt hinbekommen haben. Heute ist zwar die Hardware besser, aber wie man die Software schreibt ist unklar. Das einfachste dürfte noch der 3D Renderer sein, wo also eine photorealistische Szene generiert wird. Für sowas gibt es mehrere Programme (kommerziell wie OpenSource), richtig anspruchsvoll sind hingegen Motion Controller für die Charaktere. Also der Teil wo Magic ins Spiel kommt.

Wie Marionette oder Menv funktioniert ist zwar unklar aber eines dürfte sicher sein. Offenbar ist das ganze eine Art von bildungsprogramm. Die Filme werden ja deswegen in den Kinos ausgestrahlt damit sie jemand anschaut und die Paper über Computeranimation veröffenlticht damit sie jemand liest. Das heißt, Pixar möchte im Grunde, dass die Welt klüger wird und Spaß hat.

Pixar ist zwar kein transparantes Unternehmen und ihre wichtigste Software ist auch kein OpenSource, aber komplett abgeschottet agieren sie auch nicht. Es gibt mehrere Backstage Filme auf Youtube und viele Paper auf der Siggraph wo Pixar so eine Art von Host ist. Das heißt, wenn man sich näher mit der Thematik beschäftigen möchte, findet man durchaus Material was man sich anschauen kann. Vielleicht nicht unbedingt gleich den fertigen Sourcecode für Menv, aber doch genug Anregung um selber etwas vergleichbares zu basteln.