H2 und H-infinity control

Bei Robotics.Stackexchange gibt es mal wieder Hausaufgaben für andere Leute zu lösen. Diesmal möchte jemand den Unterschied wissen zwischen H square control und H-infinity control und stellt dazu noch sehr detailierte Fragen: https://robotics.stackexchange.com/questions/12803/whats-the-diffrence-between-h-2-and-h-infty-controll Schon allein an der Art der Fragestellung kann man ablesen, dass der Fragende die Antwort eigentlich selber weiß. Weil das Fragen sind wie aus einer Matheklausur. Die Antwort ist bekannt, es ist nur noch die Frage ob auch die Stackoverflow Community sie schon weiß. Das schöne daran ist, dass die richtige Antwort schon längst jemand gegeben hat, dafür auch gebührend hochgevoted wurde und sogar das begehrte Accept Häckchen erhalten hat. Problem gelöst, was gibt es schöneres? Nun mal nicht so schnell, meine Antwort steht da noch nicht drunter. Ich möchte sie hier im Blog geben. Schließlich ist das hier das Trollheaven-Blog, das weltbeste Blog für Fragen der Robotik und künstlicher Intelligenz. Um es sehr kurz zu machen: H2 und H-infinity control sind nicht wirklich Algorithmen um damit Roboter zu steuern, sondern genau betrachtet sind es mathematisch ausformulierte Probleme, ähnlich wie das Minimax, das Knapsack oder das Busybeaver Problem. Das heißt, man kann H-Infinity nicht wirklich verstehen, sondern was man verstehen kann ist nur, was gesucht wird. Gesucht wird der Algorithmus um ein komplexes System zu steuern. Sei es die Hand eines Roboters, die Fußbewegungen eines Roboters oder gerne auch die Parameter für das Stabbalance Problem. All das kann man in der H-Infinity Syntax ausdrücken. Auch der sogenannte LQG-controller ist eigentlich kein richtiger Controller, sondern wiederum handelt es sich um die Formulierung eines Problem. Genauer gesagt ist es das LQG problem, also die Frage wie der Controller aussieht.

Komischerweise sieht das Schulmathematik, oder was immer bei Stackoverflow diskutiert wird, ein wenig anders. Dort denken die Leute doch tatsächlich, dass sie bereits die Lösung hätten, wenn sie definieren können was H-square bedeutet. Das können sie nicht, sondern sie wissen nur, dass sie keine Ahnung haben. Um die angesprochenen Robotik- und Controller Aufgaben zu lösen, also eine Gleichung bzw. einen Algorithmus aufzustellen benötigt man etwas gänzlich anderes als Mathematik. Genauer gesagt benötigt man eine Heuristik, welche von der Domäne abhängig ist und die man entweder in Papern nachlesen kann, oder durch manuelle Steuerung selber herausfinden kann. Wie diese Heuristik konkret aussieht lässt sich nicht mathematisch definieren sondern nur natürlichsprachlich. Eventuell kann man auch Pseudocode angeben. Vielleicht mal ein Beispiel: angenommen man möchte einen Controller entwickeln um das Cartpole Beispiel zu lösen. Dann könnte die Lösung so aussehen, dass man ein wenig mit dem Cart herumprobiert und irgendwann auf die Idee kommt, dass wenn das Pendel einmal einen Schwellwert unterschritten hat, man es am besten fallen lässt und dann lieber nochmal neu aufschwingt. Solange es hingegen in dem Schwellwertbereich befindet, kann man durch rechtzeitiges Gegenlenken ein Fallen verhindern. Das ist — grob gesagt — eine Heuristik. Um sie formal zu formulieren, reicht Mathematik allein nicht aus, sondern man muss schon die Sprache Python bemühen, zur Not tut es auch Lisp oder Forth. Aber was in keinem Fall ausreicht ist, wenn man sich klarmacht, dass sich das Pendel in einem zustandsraum bewegt, der prinzipiell unendlich groß ist. Das ist zwar nicht verkehrt, aber das ist nur die Beschreibung des Problems, nicht jedoch die eigentliche Lösung.

Ich vermute mal, dass die Stackoverflow meine Antwort nicht so gut findet, weil sie erstens auf Deutsch geschrieben ist und zweitens erheblich von den anderen Antworten abweicht. Deshalb poste ich sie auch nur hier in mein eigenes Blog. Vielleicht hilft es ja trotzdem dem OP …

Instabile Quadcopter PID Steuerung

https://robotics.stackexchange.com/questions/14022/unstable-quadcopter-pid
Und mal wieder die tägliche Dosis an Robotics.Stackexchange Hausaufgabenkost. Diesmal geht es um die PID Steuerung für einen Quadcopter. Ein wie ich finde — sehr schönes Spielzeug. Der OP schildert dass sein Fluggerät nach dem Start zu einer Seite wegdriftet und hat dankenswerterweise auch noch den Sourcecode seines PID Controllers angefügt. Gut gemacht, die Frage wurde korrekt gestellt, betrifft ein interessantes Thema und demzufolge gibt es auch eine First-Class Antwort darauf. Also, …, das Problem liegt im User Interface, genauer gesagt in der Mensch Maschine Schnittstelle. Allein einen PID Controller zu programmieren reicht nicht, weil Driftings und ähnliche Probleme bei instabilen Systemen zum Alltag gehören. Was hingegen wirklich weiterhilft ist, wenn man die Sache grafisch veranschaulicht, am besten indem man die Flugsteuerung als overlay einblendet und dann manuell mittels Joystick nachregelt. So wie das im folgenden Paper erläutert wurde:

Tim Moritz Julius Fricke: Flight Control with Large Time Delays and Reduced Sensory Feedback, 2017, https://www.researchgate.net/profile/Tim_Fricke/publication/316884189_Flight_Control_with_Large_Time_Delays_and_Reduced_Sensory_Feedback/links/5919d1dd0f7e9b1db65283db/Flight-Control-with-Large-Time-Delays-and-Reduced-Sensory-Feedback.pdf

Das ist zugegebenermaßen etwas härtere Kost (300 Seiten DIN A4 wollen erstmal verdaut werden), aber bevor man einen PID Controller programmieren kann ist es wichtig zunächst einmal manuell via Joystick zu ermitteln wohin man das Fluggerät eigentlich stabilisieren möchte. Mein Tipp lautet: soviele Informationen wie nur möglich aus dem Quadcopter auslesen und in einem übersichtlichen grafischen Modell darstellen, danach das Driften mittels Joysticksteuerung ausgleichen und die gewonnene Heuristik in den Sourcecode übernehmen. Viel Glück.

Warum Academia.edu die beste Erfindung seit geschnitten Brot ist

Academia.edu mag man aus mehreren Gründen kritisieren. Sei es, weil die Premium Mitgliedschaft stolze 100 US$ jährlich kostet, weil das Portal keine Qualitätskontrolle besitzt oder weil die interne Suchfunktion zu langsam ist. Aber einen Vorteil hat das ganze: es dauert — ungelogen — weniger als 5 Minuten um ein PDF Dokument dort hochzuladen. Im Grunde reicht es, wenn man einige Mausklicks vornimmt, dann noch die Keywords korrekt einträgt und schon ist das Paper online. Es kann jetzt zumindest theoretisch von 7 Milliarden Menschen gelesen und kommentiert werden, auch wenn das natürlich nur selten passiert, aber zumindest ist es erstmal online. Das mag in Zeiten von Facebook, youtube und Blogs wie eine Selbstverständlichkeit klingen, aber gerade im Wissenschaftlichen Umfeld ist das etwas besonderes. Man möge sich zum Vergleich einmal den Upload Button von Arxiv.org anschauen oder bei Sciencedirect auch nur einen Upload Button suchen. Man wird nichts dergleichen finden. Kurzum, Academia.edu ist eine sehr nützliche Erfindung.

Head up Displays vs Behavior Trees

Behavior Trees gelten als gute Möglichkeit, domänenspezifisches Wissen als Computerprogramm zu speichern. Sie verwenden Variablennamen und Methodenaufrufe um mögliche Aktionen der Künstlichen Intelligenz zu strukturieren. Üblicherweise kommen Behavior Trees in Computerspielen zum Einsatz wenn Non-Player-CHaraktere gescriptet werden. Neben Behavior Trees gibt es noch eine weitere Methode, wie man Domänenwissen speichern kann. Diese hat den Vorteil, auch mit ungenaumen Wissen umgehen zu können. Gemeint sind Head-up Displays. Head up Displays werden ähnlich wie normale Computerprogramme auch programmiert. Das heißt, im Stile der objektorientierten Programmierung erstellt. Ihr Vorteil ist, dass sie einerseits machinenlesbar sind, aber gleichzeitig nicht die undankbare Aufgabe besitzen eine künstliche Intelligenz steuern zu müssen. Sondern Head up Displays sind unverbindliche Zusatzinformationen, die für den Spieler eingeblendet werden. Er kann sich daran orientieren muss es aber nicht.

Behavior Trees sind 1:1 mit einer Künstlichen Intelligenz verbunden. Wenn als Methode enthalten ist „walkto“ dann wird diese Methode nach dem Start des Bots tatsächlich so ausgeführt. Wurde sie falsch programmiert, stürzt der Roboter ins Chaos. Im Gegensatz dazu werden Head-up Displays nicht ausgeführt, jedenfalls nicht direkt. Sie werden zwar auch innerhalb der Game-loop abgearbeitet aber im worst-Case sind die dargestellten Informationen verpixelt, es sind nur Bildpunkte mehr nicht. Head-up Displays erfordern eine weitere Instanz will man sie zur Steuerung von Robotern einsetzen. Und zwar eines Head-up Display Parsers, also ein Computerprogramm was die dargestellten Informationen abgreift und zu sinnvollen Entscheidungen weiterverarbeitet. Dieser Head-up Display Parser ist sehr viel kompakter aufgebaut als ein klassischer Behavior Tree, er enthält nicht das komplette Domänen-Wissen sondern ist nur ein Zusatzlayer der dafür sorgt, dass der Bot auch mit unklaren Informationen noch klarkommt.

Bei der Wissensmodellierung wird Expertenwissen machinenlesbar aufbereitet. Behavior Trees sind dazu in der Lage. Das Prozesswissen wird in Task untergliedert, die sich gegenseitig aufrufen können. Es handelt sich um eine verbesserte Finite State Machine, die ebenfalls Wissen darstellen kann. Bei Head-up Displays ist das Abstraktionsniveau höher. Damit ist gemeint, dass ein Head-UP Display ebenfalls Wissen enthält, das aber nicht direkt mit den Aktoren verbunden ist. Die Funktionsweise ist üblicherweise so, dass das Head-up Display Informationen anzeigt, die werden von einem Man-in-the-loop interpretiert und der Man-in-the-loop bewegt dann den Joystick. Das Head-up Display kann also nicht direkt den Joystick bewegen.

Das interessante an Head-up Displays ist, dass sie anders funktionieren als man es erwarten dürfte. Sie verwenden keineswegs Programmiersprachen wie Prolog und auch keine OWL Ontologien um Wissen in deklarativer Form darzustellen, sondern wie der Name schon sagt sind Head-up Display ein Grafikfenster von 300×200 Pixel auf denen unstrukturierte Informationen angezeigt werden. Also Piktogramme, Zahlen, Texte und Karten. Sie sind damit das genaue Gegenteil einer formalen OWL-Ontologie. Dieser Unterschied kommt dadurch zustande, dass bei der OWL-basierenden Wissensmodellierung von einem autonomen System ausgegangen wird, während Head-up Display einen Human-Operator in the-loop benötigen. Wenn kein Mensch vor dem Bedienpult sitzt, der die lustigen Grafiken auswertet, bewegt sich der Roboter keinen Millimeter. Head-up Displays sind keine autonomen Systeme sondern sie sind hochgradig abhängig von menschlicher Intelligenz.

Es geht darum, einerseits den menschlichen Operator in der Loop zu belassen gleichzeitig jedoch die Domäne durch ein Computerprogramm abzubilden. Also sowohl Künstliche Intelligenz als auch menschliche Intelligenz zu verwenden. An dieser Stelle sei an den wegweisenden Vortrag „Edwin Olson: Winning the MAGIC 2010 Autonomous Robotics Competition“ erinnert, https://www.youtube.com/watch?v=OuOQ–CyBwc

Debian’s Zukunft ist besser denn je

http://www.pro-linux.de/news/1/25040/matthew-garrett-%C3%BCber-debians-zukunft.html Das die Aussichten von Debian trübe sind, teile ich nicht. Ganz im Gegenteil, Debian wird in Zukunft sogar noch an Bedeutung gewinnen. Man sollte sich vor Augen führen wozu die Free Software Foundation und das Debian Projekt gegründet wurden. Anders als beim Patentkrieg SCO gegen IBM geht es nicht etwa darum, Linux frontal zu attackieren sondern Debian setzt auf Methoden der weichen Beeinflussung. Es ist ein Sprachrohr für Microsoft um die Konsumenten über Freie Software aufzuklären und sie davon zu überzeugen bei Microsoft Windows zu verbleiben. Wie im obigen Text richtig angemerkt wurde, ist Windows 10 sehr viel sicherer als Debian. Und auch als Serverbetriebssystem ist Microsoft klar im Vorteil. Genau darum geht es ja, Debian als schlechtere alternative zu Microsoft zu promototen damit der Kunde die Auswahl hat: will er schlechte GPL Software oder will er zuverlässige ClosedSource Software von einem Konzern. Bei Debian erhält der Kunde weder Support, noch tagesaktuelle Sicherheitsupdates und auch keine technische Innovationen. Genau das ist der Vorteil von dieser Linux-Distributuion. Gleichzeitig ist Debian ideal geeignet um weitere Freie Software Projekte indirekt zu kontrollieren wie z.B. Ubuntu, Linux Mint oder ArchLinux die allesamt auf dem Debian Paketsystem aufbauen. Dadurch behält Microsoft die Kontrolle über Freie Software ohne offenbaren zu müssen, dass man das Krebsgeschwür am liebsten verdrängen will. Die Zukunft von Debian ist besser denn je. *

Vertikal Farming unter Kostenaspekten

Rein von der Machbarkeit ist Vertikal Farming eine gute Idee. Im einfachsten Fall stellt man in ein Gewächshaus einfach ein Regal auf und kann dann auf drei Etagen etwas pflanzen. Lässt man ausreichend Platz dazwischen kann die Sonne wunderbahr hineinscheinen. Wenn man derartige Gewächshäuser in sonnigen Gegenden baut wie Italien oder noch weiter südlich sind 3 Ernten pro Jahr kein Problem. Warum derartige Landwirtschaftliche Konzepte bisher noch die absolute Ausnahme sind, lässt sich leicht erklären. Man kann solche Gewächshäuser nicht mit einem Traktor umpflügen, nicht mit einem Mähdrescher abernten und man muss die Blumenerde in spezielle Schalen füllen die noch dazu aufwendig bewässert werden müssen. Kurz gesagt, der Mehraufwand ist beträchtlich, die Kosten für das Gemüse oder den Reis explodieren, das fertige Produkt ist aus kostengründen nicht konkurrenzfähig auf dem Weltmarkt. Wenn heute tatsächlich ein Betrieb sich zu Mehretagen Gewächshäusern entschlossen hat, wird jeder halbwegs informierte Wirtschaftsberater dazu raten, dieses Experiment schnellstmöglich einzustellen und zu altbewährter ebenerdiger Landwirtschaft zurückzukehren.

Und dennoch, ein Vorteil ist unbestreitbar: auf der selben Grundfläche kann man deuutlich mehr anbauen. Bei 3 Etagen ungefähr die doppelte Menge (ein wenig verlust wegen der Zusätzlichen Gänge zwischen den Reihen). Wenn man 10 und noch mehr Etagen übereinanderbaut kann die Produktivität weiter erhöht werden. Wenn der Raum wirklich knapp ist, ist Mehretagen-Landwirtschaft die richtige Antwort. Die Schwierigkeit besteht darin, dass die Idee Mehretagenlandwirtschaft allein sinnlos ist. Weil sich die Regalreihen ja nicht von allein aufstellen und auch die Ernte benötigt viel menschliche Arbeitskraft. Um vertikal Farming praktisch zu realisieren braucht man noch eine weiter Erfindung, und zwar Arbeitskräfte die für 0 EUR die Stunde arbeiten. Damit könnte man kostengünstiges Gemüse produzieren. Nur, wo gibt es solche Arbeitskräfte? Meiner Recherche lautet die Antwort: Robotik. Wenn es gelingt, humanoide Roboter zu entwickeln die sowohl Gewächshäuser bauen als auch Tomatenpflanzen im Akkord hochbinden kann man derart aufwendige Gewächshäuser betreiben. Nach meiner Prognose steht diese Technologie frühestens in 20 Jahren bereit, also ab 2040. Solange wird das noch nichts mit vertikaler Landwirtschaft.

Wer die Entwicklung pushen möchte, kann schonmal einen ehrgeizigen Roboterwettbewerb veranstalten, bei dem Lego Mindstorms ähnliche Roboter einen Blumentopf ans Ziel bringen müssen wobei das Ziel etwas erhöht liegt. Also so eine Art von begrüntem Hochregallager, in dem Gabelstapler herumfahren.

Ist P=NP?

http://scienceblogs.de/mathlog/2017/08/15/ein-gegenbeispiel-zu-pnp/ Die verlinkte Arbeit (Das Arxiv Paper A Solution of the P versus NP Problem by Norbert Blum) ist kein wissenschaftliches Paper was sich mit dem P=NP Problem beschäftigt, sondern es ist ein Witz-Paper was mit Scigen erzeugt wurde, und was wohl lustig sein soll. Schon in der Einleitung wird großspuring von einem CNF/DNF-Approximator gesprochen. CNF heißt übersetzt soviel wie konjunktive Normalform, ein Prinzip aus der Mathematik was ganz sicher nicht im Stande ist das P=NP Problem zu lösen. Vielleicht ein kleiner Exkurs dazu. Beim NP-Problem geht es um sogenannte np-harte Probleme, also Aufgaben die ähnlich wie das Rucksackproblem sehr viel Rechenzeit benötigen. Die Frage was die theoretische Informatik beschäftigt lautet, ob es Algorithmen gibt, die weniger Rechenzeit bedürfen. Und wie man schon ahnt geht es also um Turing-Maschinen. Turing-Maschinen lassen sich jedoch nicht mathematisch sondern nur innerhalb der Informatik definieren. Dort verwendet man üblicherweise Compiler, Finite-State-Maschines und Quantencomputer.

Meiner Meinung nach kann man das P=NP Problem nur lösen, wenn man es erweitert zum AI-Complete Problem. Also Probleme definiert, die natürliche Intelligenz verwenden. Dafür jedoch hat nochnichtmal die Informatik eine anerkannte Definition sondern man muss weitere Wissenschaften (speziell die Psychologie) bemühen. Hier der Plan:

Mathematik -> Informatik -> Psychologie

Was das Paper von Norbert Blum macht ist, sich auf die Mathematik zu beschränken, also mit ein wenig Formeln umstellen die Sache abzuhandeln. Das kann nur schiefgehen, es ist so, als wenn man mit einer Zahnbürste das Bad reinigt. Vermutlich wird sich Blum ins Fäustchen lachen, wenn er daran denkt wie sich arglose Arxiv-Leser damit wissenschaftlich auseinandersetzen.