 Okay, dann herzlich willkommen zu meinem Vortrag über probabilistische Robotik. Ich möchte euch jetzt hier in der nächsten Stunde ungefähr erzählen, wie man die Interessen eines Roboters als Nutzen formulieren kann. Das ist ein Teilgebiet der probabilistischen Robotik, vielleicht nicht so ganz die klassische probabilistische Robotik, sondern so ein spezielles Gusto davon. Und der Hintergrund, warum ich euch so was vorstellen möchte, ist, dass man in der Praxis immer oder öfters mal kompliziere Aufgabenstellungen hat. Die Aufgabe klingt jetzt auf den ersten Blick relativ einfach. Der Roboter, der hier im Bild zu sehen ist, der soll einfach zu einer GPS-Ziel-Koordinate fahren. Klingt ziemlich trivial, aber wenn man sich das mal genauer überlegt, ist es doch nicht mehr ganz so leicht, weil man sieht in dem Bild schon, es gibt Menschen, die rumlaufen, es gibt Hindernisse, es gibt Bänke, es gibt manchmal auch Autos, die irgendwo parken. Dann gibt es Blumen, das mögen manche Leute nicht so werden, die der Roboter über den Haufen fährt. Und das ist also ein sehr, sehr kompliziertes Problem, wenn man sich das genau anschaut. Und das wird allein dadurch schon deutlich, wenn man nur das Ziel hat, auf einer Straße zu bleiben und nicht von der Straße runter zu fahren, sehen wir hier schon die unterschiedlichsten Situationen, mit denen der Roboter konfrontiert werden kann. Da sehen wir hier links, wie es in so einem Park aussieht. Das unterscheidet sich optisch schon ein bisschen von der Situation hier rechts, wenn wir bei einer großen, ne, bei einer kleineren Straße sind. Oder hier so was ganz Ulkiges, wo der Roboter über eine Brücke sogar drüber fahren muss. Oder vielleicht sogar kritische Situationen, in denen der Roboter auf gar keinen Fall einen Fehler machen darf. Und zwar, wenn ein Fluss direkt neben der Straße ist. Da ist es sehr gefährlich, wenn man da von der Straße abkommt. Und wenn dann kein Mensch da ist, der eingreift, dann ist der Roboter halt kaputt. Das heißt, wenn man in der Praxis einen Roboter autonomen, irgendwie was von A nach B transportieren lassen möchte, muss man all diese Probleme lösen. Und das ist halt sehr, sehr schwierig, wenn man das irgendwie in einer geschlossenen, geschickten Form modellieren will. Und deswegen war unsere Idee, dass wir das Ganze als Interessen aufbrechen und sagen, wir versuchen mal irgendwie zu modellieren, dass unser Roboter einfach nur unterschiedlichste Interessen verfolgt und die Summe dieser Interessen ergibt dann das Gesamtverhalten des Roboters. Und um zu verstehen, wie man sowas umsetzen kann, dann müssen wir erstmal ein bisschen Mathematik uns anschauen, weil das halt auf der Wahrscheinlichkeitstheorie basiert, deswegen der Vortrag auf probabilistische Robotik. Aber bevor wir uns die anschauen, erst nochmal kurz zur Ausgangssituation, was unser Roboter für Sensorik hat, die wir benutzen können, das wird nämlich dann später noch relevant. Und zwar haben wir hier jetzt eine Kamera, mit der können wir unsere Wegerkennung machen, die war vorne am Roboter und guckt in Fahrtrichtung. Dann haben wir einen GPS-System, da haben wir ein Android-GPS bekommen, da können wir unsere Positionen global bestimmen. Dann haben wir einen Laser-Scanner, Lieder-Laser-Scanner, der macht uns im Prinzip einen 2D-Querschnitt durch die Welt und gibt uns für jede Richtung, wie weit bis dort ein Hindernis ist. Als Navigationen waren für den Wettbewerb, auf den ich mich hier jetzt beziehe als Beispiel, wofür man sowas braucht, Open-Street-Maps zugelassen. Man kann sich vorstellen, dass man auch Google Maps benutzt oder irgendwelche anderen Vergleichbaren Karten. Mit diesen 4 Bausteinen kann man jetzt im Prinzip schon, ein Baustein, den ich jetzt so implizit sehe, ist, dass man einen Roboter hat, der irgendwie fahren kann. Das braucht man in jedem Fall. Mit diesen 4 Sensoren kann man jetzt so ein System aufbauen, dass der Roboter sich bewegt. Allerdings sind diese 4 Sensoren jetzt allesamt nicht so perfekt. Bei der Kamera können wir leider nicht Pixel genau erkennen, wo ist Weg und wo ist kein Weg. Das ist irgendwie so ein bisschen unscharf. Manchmal glauben wir, dass Davogras ist befahrbare Region, dass dann Weg ist, oder manchmal umgekehrt, dass auf dem Weg was nicht befahrbar ist. Zum Beispiel auch wenn da jetzt irgendwie nur ein bisschen dreck liegt oder eine komische Fahrbahnmarkierung ist, das kann Roboter schon sehr verwirren oder allein auch Lichtschattenspiel ist ein sehr großes Problem. Beim Android GPS, das ist auf 3 bis 12 Meter genau oder ungenau, kann man jetzt sehen, wie man will. Meistens ist es eher genau, in manchen Fällen ist es allerdings ungenau genug. Zum Beispiel, wenn es darum geht, dass man innerhalb von kürzester Zeit 2 Abbiegungen hat, die irgendwie 3 Meter auseinander sind und man hat gerade nur 12 Meter Genauigkeit, muss ich jetzt sofort abbiegen oder muss ich erst danach abbiegen. Weiß man dann nicht so genau. Bei den Laser Scanners, naja, gut, die sind relativ präziso, die sind nicht so das große Problem, da hat man höchstens den Unterscheidung zwischen dynamischen und statischen Objekten. Das kann man aber in den allermeisten Fällen einfach vernachlässigen und sagen, okay, Laser Scanner funktioniert halbwegs gut. Die sind einfach High-Tech-Geräte. Und bei Open-Street-Maps ist das Problem, dass man dort zwar eine regelrecht genaue Karten hat, aber auch die wieder, zumindest wenn wir versuchen wollen, exakt auf der Straße zu fahren, allein durch GPS und Open-Street-Maps geht das nicht, weil wenn die dann einen Meter schon falsch sind, was durchaus mal vorkommt, ist es einfach zu schlecht. Und das heißt, man sieht, obwohl wir eigentlich Sensoren haben, die auf den ersten Blick ziemlich perfekt sind, ist es doch irgendwie schwer, die Aufgabe. Und da gibt es jetzt, na ja, mal eine kleine Demo für die Kamera, was das bedeutet, dass sie so falsch ist. Da habe ich hier mal was mitgebracht. Und zwar sehen wir hier ein Testvideo, wo wir durch einen Park gelaufen sind mit einer Handykamera und den Boden gefilmt haben, einfach so ein bisschen so ähnlich wie der Roboter das auch sehen würde. Einfach mal zu gucken, wie sieht das aus, wie ein Roboter tatsächlich Straßen wahrnehmen kann und wo eine befahrbare Region ist. Und hier unten sehen wir jetzt live eine Ausgabe, wie so eine Bildverarbeitung aussieht. Die meiste Zeit sieht sie relativ toll aus. Man sieht hier jetzt schon, dass hier so beim Schatten spielt, das Ganze ein bisschen verrauscht wird. Und bereits jetzt sind wir in der Situation, wie man das mit trivialen Algorithmen macht, eigentlich der Roboter keine sinnvolle Traektorien mehr findet. Und da ist ein erster Schritt, auf den ich später nochmal zurückkommen werde, dass man hier unten sieht, dass wir einfach nicht gucken, dieses gesamte Bild an, sondern wir zählen für jede Spalte in dem Bild, wie viele weiße Pixel sind dort. Und dann kriegt man hier schon mal so eine Verteilung wie hier unten raus, die, naja, sobald wir irgendwie ein bisschen was an sinnvoller Informationen haben, schon Werte gibt, die irgendwie ansatzweise die richtige Richtung darstellen. Da werde ich später noch erklären, was das hier unten ist, wie man sowas nennt und was das für ein Zusammenhang mit der Probabilistik hat. Aber so viel jetzt erstmal für den Anfang, dass man so ein Grundverständnis hat, wo da eigentlich das Problem ist bei dem Ganzen, dass das schwer ist. Gut. Damit zur Lösungsidee. Also wir brauchen irgendeine robuste Strategie, wie wir möglichst robust gegen unsere Fehler sind. Wir wollen, also das war eine Anforderung, die wir uns gestellt haben, dass wir eine ungenau unscharfe Formulierung der Lösung wollen und dass wir das irgendwie zusammensetzen können, wollen aus so einzelnen Interessen, die der Roboter verfolgt. Weil der Vorteil einer zusammengesetzten Lösung ist natürlich, dass man nach die Weite in Konker-Prinzip einfache Probleme meistens recht gut lösen kann, aber nen Gesamtproblem oft kompliziert ist. Und naja, da gibt es in der Mathematik so eine Methode, wie man in der probabilistischen Robotik sagt, dass man die ideale Lösung findet, ist man maximiert einfach den Erwartungswert. Ich guck mir für jede Richtung, in die ich fahren kann, an was ist der Erwartungswert, was es mir bringt, in diese Richtung zu fahren. Wir haben es jetzt mal umgangssprachlich formuliert. Und dann guck ich, in welcher Richtung ist eben jener Erwartungswert maximal. Und dadurch habe ich eine sehr robuste Strategie, weil der Erwartungswert entspricht ja immer dem, was man wirklich erwarten kann, unter der Annahme, dass man halt keine Fehler gemacht hat beim Aufstellen vom Erwartungswert. Und mit dem ungenau und unscharfe Formulierung, das werden wir noch sehen, was das damit dann für einen Zusammenhang hat. Aber jetzt erst nochmal zum Erwartungswert. Ich weiß nicht, wie gut eure Mathekenntnisse alle noch sind. Deswegen hier erstmal die Definition davon. Der Erwartungswert wurde in der Schulmathematik. Hier statt diesen U von Omega. Omega ist immer der Winkel, also die Richtung, in die der Robotia fahren möchte, zur Erklärung. Und das heißt, dieses U von Omega ist in der Schulmathematik normalerweise immer nur so ein X gewesen. Und das heißt dann bei der Erwartungswert im Prinzip das Integral von X mal, der Wahrscheinlichkeit, dass dieses Event eintritt. Und wenn wir das Ganze auf einen Würfel uns vorstellen, den Würfelfall kennt jeder wahrscheinlich, da ist es dann für den Erwartungswert, den wir kriegen, wenn wir einen Würfel werfen, ist 3,5. Und zwar ist es 1 mal ein Sechstel, 2 mal ein Sechstel, also 1 mal ein Sechstel plus 2 mal ein Sechstel plus 3 mal ein Sechstel. Und das wäre halt in einem Diskretenfall. Und wenn es kontinuierlich ist, ist es dann statt einer Summe einen Integral. Und was man jetzt machen kann, ist den Erwartungswert eben ein bisschen abstrakter formulieren, als ein Funktional heißt es dann. Und da setzt man dann nicht nur dieses X den Wert ein, sondern stattdessen eine Funktion, die von diesem Wert abhängig ist. Und diese Funktion, die heißt Nutzenfunktion, oder heißt in dem Fall der probabilistischen Robotik Nutzenfunktion. Und diese Nutzenfunktion beschreibt, wie viel nützt es mir, um Omega zu fahren. Und das, was jetzt eigentlich als Ziel dann am Ende gilt, ist, rauszufinden, was man für den Nutzenfunktion braucht, um in Richtung Omega zu fahren. Und jetzt gibt es noch ein Problem bei dieser Gleichung, wo ich mich die ganze Zeit darum gedrückt habe, irgendwas dazu zu sagen. Das ist dieses F von Omega, diese Verteilungsfunktion. Die hängt irgendwie von dem Omega über, um Omega 0, Omega 0 ist die Richtung, die der Roboter wählt, zu fahren. Also es kann man sich so vorstellen, dass wenn der Roboter wählt, in Richtung Omega 0 zu fahren, dann ist der Erwartungswert irgendwie darum gestreut, um die tatsächliche Richtung, weil der Roboter schafft, irgendwie doch meistens in die Richtung zu fahren, aber eben nicht ganz präzise. Und da schauen wir uns jetzt mal an, wie so ein F von Omega aussehen könnte und wie ich bereits schon erwähnt habe, ist das eine Verteilungsfunktion von diesem Omega, wenn ich versuche, Richtung Omega 0 zu fahren. Das heißt, es ist mein Streuungsfehler, den ich in der Nutzenfunktion haben kann, wenn man es mathematisch sieht oder wenn man es eher sich bildlich vorstellen möchte, beim Roboter ist es die Streuung der Richtungen, die ich fahren versuche. Und na ja, was wir jetzt bei unserem Roboter festgestellt haben, was eigentlich für fast alle Roboter gilt, zumindest wenn sie irgendwie so autoähnlich sind, dass diese Nutzenfunktion fast unabhängig von Omega 0 ist. Und zwar insofern, dass sie um Omega 0 zentriert ist, aber es macht keinen Unterschied, ob ich jetzt sage, ich fahre nach 90 Grad, dann kann es genauso sehr passieren, dass ich irgendwie ein Grad davon links oder ein Grad davon rechts bin. Da habe ich die gleiche Streuung, die wir hier gemacht haben, die ganz, ganz streng genommen nicht so korrekt ist. Aber wenn man irgendwie versuchen will, das lösbar zu machen, muss man das immer vereinfachen. Dieses f Omega von zwei Parametern abhängig kann man nicht bestimmen in unser, also kann man sehr schwer nur messen. Man müsste für jede Richtung ausmessen, wie da die Streuung ist mit einem Zufallsexperiment und müsste das ganz oft wiederholen, dann kann man einfach fest sagen, wir messen das jetzt für unsere geradeausfahrt, wie schlimm ist es dann und tun aufgrund dessen unsere Verteilungsfunktionen bestimmen und haben irgendwie eine Möglichkeit, das tatsächlich praktisch umzusetzen und diese Funktion zu bestimmen, wie unser Roboter fährt. Und na ja, was bedeutet das, wenn wir eine Funktion haben, die um dieses Omega 0 zentriert ist, wir können das Ganze umschreiben und dann wird aus unserer Funktion plötzlich eine Verteilung mit einem Parameter und ich muss halt hier mein Omega minus Omega 0 rechnen, damit es zentriert ist. Und das ist, wie hier Fett gedruckt steht, nur nur Approximation. Also das ist keine exakte Lösung mehr. Na ja, jetzt ist die Frage, warum das überhaupt gemacht wurde, es gibt natürlich dann noch einen schönen Zufall, der sich dann ergibt, und zwar wenn wir jetzt für unser F Omega die Funktionen, die wir gerade approximiert haben, einsetzen, dann steht hier genau die Definition von einer Faltung und eine Faltung ist eine Operation, bei der zwei Funktionen übereinandergeschoben werden, wenn man sich das bildlich vorstellt und da unsere Verteilungsfunktion eine Normalverteilung ist, ist das Ganze relativ gut berechenbar, wenn wir einfach unsere Funktionen mit einer Normalverteilung falten nachher und man kann sich das Ganze auch dann geometrisch plötzlich vorstellen, was da passiert. Das werden wir uns gleich nochmal anschauen. Und zwar jetzt. Und zwar haben wir hier eine Gausglockenkurve, die mit sehr, sehr wenigen Samples nur gerendert wurde oder nicht gerendert, sondern überhaupt. Also was wir in der Praxis machen, ist, wir nehmen keine kontinuierlichen Funktionen, sondern wir diskretisieren alles, wenn der Computer besser berechenbar ist, wir keine Funktionen bilden müssen und wir auch das Problem haben, dass unsere Nutzenfunktion, dieses u von x, in der Regel keine geschlossene Funktion ist, sondern wir einfach aufgrund von Messwerten schätzen für jedes Omega, was da wohl die Nutzenfunktion ist. Und dementsprechend müssen wir diskretisieren. Und hier wurde jetzt eine Gauskurve genommen, das hier sind Eingabendaten, die simuliert wurden, die sollen sowas Laserscannerartiges darstellen und da sieht man ganz charakteristisch, ist, dass man als Mensch sehr, sehr gut erkennen kann, dass wir hier eine zusammenhängende Linie haben, dann ist hier irgendwie ein Sprung, dann ist hier wieder was zusammenhängendes, ein Sprung nach oben zusammenhängt und hier drüben geht es ganz runter. Allerdings, der Laserscanner hat das Problem, dass er halt öfters mal verrauscht ist und nach oben oder unten falsch abweicht und hier in der Mitte sind Nullwerte, weil der Laserscanner dort gar kein Hindernis sieht und dann gibt er Nullwert zurück und dadurch werden unsere Funktionswerte so erstmal unbrauchbar und wenn wir nämlich direkt jetzt hier drauf gucken würden, in welche Richtung können wir gut fahren, dann würde er vielleicht gar nicht tatsächlich hier so in der mitten Richtung rausfinden. Wenn wir einen unglücklichen Fall haben, würde er ein bisschen weiter rechts oder sogar mal ganz extrem weit rechts gehen, weil er nur den einzig besten Wert hat. Und wenn man den Erwartungswert davon bildet, kriegt man ja das, was wahrscheinlich oder was erwarteterweise die längste Distanz ist, wenn man das nur auf dem Laserscanner macht und wenn ich das jetzt mal ausführe, sehen wir hier wie die Werte die ganze Zeit flackern. Hier unten wurde das jetzt einmal gefaltet oder da wurde jetzt unser Erwartungswert gebildet, der aber, wie wir gerade gesehen haben, nur eine Faltung ist. Das heißt, hier wurde es einmal mit einer Gauskurve gefaltet und die Faltung mit einer Gauskurve macht weiter als eine Glättung durchzuführen. Und das Ganze kann man mehrmals falten. Man kann den Gausfilter größer machen. Das kann ich mir gerade noch demonstrieren. Indem ich hier die Standardabweichung nicht nur auf zwei Sätze, sondern auf ich nehme mal 10, da muss ich über meine Samples auch hochdrehen. Und jetzt sehen wir, wenn ich einen breiteren Gauskörnel nehme, wenn mein Roboter zum Beispiel ein bisschen ungenauer ist oder meine Laserdaten einen großen Winkelfehler haben, dann werden meine Datensätze deutlich korrigiert und ich habe keine Probleme mehr mit den Nullwerten, die wir hier sehen können. Die werden komplett eliminiert. Also, nein, nicht komplett, wir haben hier immer noch diese kleinen Spitzen. Da ist es in der Praxis dann hilfreich, nicht nur mit einer Gausglättung das Ganze zu machen, sondern vorher diese Nullwerte, die komplett ungültige Werte sind, rauszufiltern und durch die Faltung können wir das Rauschen der Sensordaten rauszukriegen, weil die Nullwerte sind genau genommen gar kein statistischer Fehler, sondern diesen systematischer Fehler. Und das heißt, dadurch, dass wir den hier als statistischen Fehler approximieren, können wir die in den Enddaten immer noch sehen, was halt ungünstig ist. Aber für die Demozwecke hier soll das ausreichen. Und das heißt, wir haben jetzt gesehen, dass den Erwartungswert zu bilden von der Funktion in dem Fall bei unserem Roboter eigentlich nichts weiter ist als eine Faltung, also in der Regel eine Glättung mit einem speziellen Körnel. Und der Körnel kann unterschiedlich aussehen. In vielen Fällen kann das ein Gauskörnel sein. Vielleicht hat der Roboter auch mal eine andere Ansteuerungsart, dann ist es keine Gausglockenkurve mehr, sondern irgendwas Wilderes, dem sind keine Grenzen gesetzt. Also was haben wir damit gesehen? Durch den Erwartungswert wird unsere Strategie robust, wobei wir jetzt noch von der Strategie reden können. Wir haben erstmal nur gesehen, dass wir unsere Eingabedaten robust gegen Fehler machen können, indem wir sagen, dass wir die Vorauschendaten filtern und also den Erwartungswert nehmen und das entspricht ja einer Filtrierung. Was wir noch nicht gesehen haben, ist wie das überhaupt eine Lösung des Problems ist und wie das zusammengesetzt ist. Weil ich bisher noch kein einziges Wort über unsere Nutzenfunktionen verloren habe. Und die Nutzenfunktion, das ist hier jetzt eine etwas unformale Definition, eine formale Definition würde relativ wenig helfen. Eine Nutzenfunktion beschreibt den Nutzen, den ein Roboter davon hat, in Richtung Omega zu fahren. Das heißt, auf gut Deutsch, wie zielführend ist es Richtung Omega zu fahren. Bringt mich das meinem Ziel näher dorthin zu fahren oder bringt es mich meinem Ziel nicht näher. Und wenn wir jetzt uns überlegen, wir haben den Laser Scanner, wir haben den, die GPS-Position, wir haben die OSM-Route und wir haben unsere Kamera. Dann ist es z.B. zielführend, wenn ich bei der Kamera in eine Richtung fahre, in der mit hoher Wahrscheinlichkeit Weg ist. Wenn ich in Richtung fahren, der mit hoher Wahrscheinlichkeit kein Weg ist, ist es für meine Aufgabenstellung nicht mehr zielführend, weil ich dann von der Straße affiziert wäre, weil ich von der Straße abgekommen bin. Oder vielleicht im Worst Case sogar in den Flussfahrer, wie wir vorhin im Bild gesehen haben. Und mit dem Laser Scanner, der gibt einem ja die Entfernung zu den Hindernissen, da kann man es jetzt so sehen, dass man sagt, naja, wenn der Laser Scanner misst, dass wir eine große Distanz fahren können, dann ist das sehr zielführend, weil wir dann mit hoher Wahrscheinlichkeit gegen nichts gegenfahren, sondern irgendwo lang fahren, wo halt nichts im Weg ist. Und wenn der Laser Scanner sagt, wir haben hier nur noch 5 cm Platz, dann ist diese Richtung, in der wir 5 cm Platz haben, nicht mehr sonderlich zielführend, weil naja, wir können noch genau 5 cm fahren und dann können wir keinen cm fahren. Und jetzt sieht man vielleicht schon so ein bisschen, dass man das irgendwie in die Nutzenfunktion einbauen können will. Und die Nutzenfunktion bisher ist sie ein großes U von Omega. Wir wollen die aber irgendwie so modular haben, dass wir die ganzen Sachen einzeln formulieren können, wie ich es gerade beschrieben habe mit dem Lieder und der Kamera und dem GPS. Und eine Möglichkeit, das zu machen ist, dass wir unsere Nutzenfunktion irgendwie als eine multiplikative Funktion von weiteren Funktionen, also von kleineren Nutzenfunktionen nehmen. Was bedeutet das jetzt? Also wir nehmen ein U1, ein U2 da können wir ganz viele von haben, wir können unendlich, okay, nicht unendlich viele, aber eine feste Anzahl, die beliebig ist an Nutzenfunktionen haben und die werden alle einfach miteinander multipliziert. Warum multipliziert? Weil wir dadurch so was machen können, wie das, wenn eine Funktion sagt, es hat 0 Nutzen in diese Richtung zu fahren, dann ist meine gesamte Nutzenfunktion 0. Und wenn mein Laser Scanner sagt, in diese Richtung kann ich 0 cm fahren, kann ich auch auf gar keinen Fall in diese Richtung fahren. Weil ich weiß, dass mein Laser Scanner sich absolut sicher ist, dass dann eine Wand ist. Auf der anderen Seite hat es auch die Bedeutung, dass ich meine Nutzenfunktion für die einzelnen Teilgebiete so bauen muss, dass sie auf gar keinen Fall 0 sind, wenn ich aber in diese Richtung eigentlich fahren könnte. Weil wenn ich eine Nutzenfunktion habe, die fälschlicherweise 0 ist, entscheidet der Roboter sich immer gegen diese Richtung, weil die 0 halt alles ausradiert. Und das heißt eine mögliche Nutzenfunktion in unserem Fall ist ja so aus, dass wir den Nutzen, den wir aus dem Leder bestimmen, der einfach die Distanz ist, die wir fahren können, den Nutzen, der sich aus der Kamera bestimmt, der werde ich gleich nochmal zu was zeigen, und den Nutzen, der sich aus GPS und OSM bestimmt miteinander multiplizieren. Und man kann noch weitere Terme ran multiplizieren. Man könnte sich zum Beispiel vorstellen, dass man dem Roboter eine gewisse Trägheit programmieren möchte. Das heißt, dass der Roboter nicht die ganze Zeit irgendwie Schlangenlinien fährt, sondern möglichst gerade ausfährt. Das ist jetzt vielleicht fraglich, ob das für die Aufgabenstellung notwendig ist, aber es sieht einfach besser aus, wenn der Roboter nicht wie ein besoffener fährt, sondern ein bisschen gemächtlicher. Und da kann man halt durch weitere Terme, kann man das Verhalten des Roboters beeinflussen. Es kann man sich so ein bisschen so vorstellen, wie der Mensch, der, wenn er von A nach B läuft, einen Nutzen ist es nicht gegen eine Laterne zu laufen. Also habe ich eine Nutzenfunktion, die mir sagt, sie ist null, wenn da eine Laterne direkt vor mir ist in der Richtung, und für alle anderen Richtungen ist sie eins, weil es ihr egal ist. Dann habe ich eine Nutzenfunktion, die wäre jetzt so, wie wir es auch tatsächlich mit dem GPS und dem OSM gemacht haben, dass ich mir vorher auf Google Maps angucke, in welche Richtungen ich laufen muss. Und dann sage ich für jedes Segment, okay, jetzt muss ich Richtung Osten laufen, dann bin ich in der Lage, mich Richtung Osten zu halten, aber um diese Baustelle rumzulaufen. Und genau das kann man dadurch halt modellieren. Dass diese einzelnen Teilfunktionen einen sozusagen in eine Richtung ziehen, weil die Funktionen für GPS und OSM, zum Beispiel ihren ihr Maximum eher ein bisschen links gerichtet hat, dann kriege ich bei einem anderen Constrains das möglichst linke, was geht, wenn man sich das versucht vorzustellen. Gut, also nochmal zusammengefasst, was sind diese Teilnutzenfunktionen gewesen? Wir haben die Kamera, die den Befahrbahnuntergrund messen konnte. Damit können wir Nutzen aufstellen. Dann haben wir den Laser Scanner, der die Hindernisse findet, ist auch direkt eine Nutzenfunktion, allein durch die Distanz. Da müssen wir keine große Transformation durchführen. Dann haben wir das GPS und OSM. Das klingt relativ einfach, wenn man sagt, na ja, wir müssen die Richtung rausfinden, in die wir global gerade aktuell fahren wollen. In der Praxis stellt man da leider fest, dass das oftmals ein bisschen tricky ist. Und zwar muss man rausfinden, wenn ich ein Segment entlang fahren muss und ob ich jetzt am Ende des Segments angekommen bin und dann schon wechseln muss in, ich möchte nach rechts abbiegen, aber man möchte nicht zu früh wechseln und das ist in der Praxis noch ein Problem, was relativ schwierig ist. Wir haben das nur, müssen wir ehrlich zugeben, mithilfe von magischen Zahlen geschafft, indem wir einfach so lange rumgespielt haben am Parameter, bis das funktioniert hat. Wobei man hier auch bei GPS und OSM ja gleich einen Moment kann man auch noch andere Verfahren ansetzen, wie zum Beispiel SLAM, das auch ein probabilistisches Problem ist, womit man seine Position genauer kennt und dadurch das Problem der Ungenauigkeit von GPS umgehen kann. Ja? Es gibt aber Segmente, also es gibt tatsächlich schon eine Route, wo ich lang fahren muss, es kann nicht sein, dass ich nach rechts vor den Langgangs immer da stehe, weil ich nur 2 Nutz stehe. Ah, so her stimmt, ich muss die Frage wiederholen. Die Frage war, wenn ich, also es gibt Segmente eine Route, und wenn ich da irgendwie, es kann nicht vorkommen, dass ich in eine Situation komme, dass meine GPS-Route mir besagt, dass ich keinen Nutzen mehr finde. War das die Frage? Ja, also ob es eine Route gibt, wenn ich denke, oder ob ich nur einen Endpunkt habe und irgendwie ein Weg was innen muss. Okay. Ich beantworte die Frage mal direkt, dann ist es auch glaube ich klar, wie sie gestellt wurde. Also die Aufgabenstellung gesagt, dass es nur den Endpunkt gibt. Allerdings ist erlaubt, dass man OSM, also OpenStreetMaps benutzt und aufgrund meiner aktuellen Position, die ich durch das GPS kenne, der Karte und der Zielposition, kann ich mir ja wie Google Maps zum Beispiel eine Route berechnen, die ich entlangfahren muss. Und diese Route besteht üblicherweise nicht nur aus Fahrer geradeaus, sondern aus mehreren Segmenten, die ich der Reihe nach abfahren muss. Genau. Und das ist auch im Prinzip erklärt, warum hier GPS plus OSM steht, warum die beiden kombiniert sind, um einen Nutzen daraus ziehen zu können. Und was dabei auch vielleicht noch zu erwähnen ist, dass es tatsächlich vorkommen kann, dass man aufgrund dieser Planung in eine Situation kommt, wo der Nutzen vielleicht nicht mehr so ganz sinnvoll ist. Da werde ich am Ende auch noch einen kurzen Video zeigen. Ja? Aber wenn der GPS zum Beispiel kurzzeitig auskommt oder in dem Moment einfach kein GPS verfügt, weil zum Beispiel eine Straße bei den zwei Ruhrhäusern sind, wo einfach die Position absolut kein GPS-Signal zustande kommt, ist der Messer dann nuller, also es praktisch GPS dann, weiß ich nicht, da ist es praktisch kein Nutzen mehr oder ist dann der Kompass, der noch ein bisschen Press nutzen hat, aber damit das Buch das Ganze so geht. Okay, die Frage war, ob wenn das GPS mal keine Informationen gibt, weil das irgendwie abgedeckt ist durch Häuser oder andere Sachen, ob dann der Nutzen des GPS null ist oder ob man das durch den Kompass oder so ausgleichen kann. Und die Antwort darauf ist, dass das GPS im Prinzip nur benutzt wird, um zu wählen, in welchem Streckensegment wir uns befinden. Diese Wahl merkt sich der Roboter und dann hat er aufgrund dieses Streckensegment, das er ausgewählt hat, weiß er, in welche Richtung das Streckensegment zeigt und tut darauf basierend dann mit dem Kompass bestimmen, in welche Richtung der Nutzen ist. Und das heißt, so umgeht man diese Problematik, dass es tatsächlich vorkommen kann, dass man mal für 2-3 Sekunden kein GPS hat. Was allerdings damit nicht umgangen wird, ist, wenn man irgendwie mit dem Roboter durch ein Tunnel mit mehreren Abzweigen fahren muss, der viele Kilometer lang ist, wobei solche Tunnel doch zum Glück relativ selten noch sind. Das Problem kann man damit nicht lösen, weil ich mit GPS auswählen muss, in welchem Segment ich befinde. Man könnte mit etwas komplizierteren Algorithmen auch das Problem wieder lösen, aber es geht hier in dem Vortrag eigentlich darum, wie man es umgehen kann, solche komplizierten Lösungen zu finden und das möglichst mit einfachen Bausteinen sich alles zusammenbauen kann. Gut, genau, die Trägheit brauche ich glaube ich nicht groß was zu sagen, habe ich vorhin schon erklärt. Und das heißt, im Prinzip haben wir schon eine komplette Lösung. Sie, so sieht es zumindest aus. Wir haben eine robuste Strategie, dank Erwartungswert, der dafür sorgt, dass es robust ist. Wir haben eine ungenau und unschaufformulierung der Lösung. Das heißt, wir können unsere Nutzenfunktion im Prinzip frei definieren, wie wir wollen und so wie sie sinnvoll sind. Und wir haben den Vorteil, dass die Nutzenfunktion nicht exakt formuliert sein müssen. Wir können auch, wie zum Beispiel bei der GPS-Navigation, einfach nur diesen Richtungsvergleich machen und daraus eine Präferenz, so würde ich es nennen, für eine Berichtung haben oder eine Tendenz in eine bestimmte Richtung zu fahren. Und, naja, wir haben eine zusammengesetzte Formulierung der Lösung, weil wir jedes Teil Problem einzeln lösen können. Und naja, jetzt nochmal als Zusammenfassung. Die Aufgabe war, dass wir zu einer Zielkoordinate reißen und diese Zielkoordinate war per GPS gegeben. Dann muss eine Route berechnet werden, zunächst, wie wir da hinkommen und diese Route dann abgefahren werden. Dabei können unterschiedlichste Sachen passieren, wie die Passanten, die aber im Moment zumindest noch erstaunlich viel Respekt vor Robotern haben und denen nicht direkt vor die Füße springen, außer sie wollen ausprobieren, ob der Roboter anhält. Das ist übrigens ein Problem, was mit der Technik, die ich vorgestellt habe, nicht gelöst wird. Zumindest nicht so direkt. Wir können nur nutzen Funktionen machen, die alles 0 setzt und definieren, was passiert, wenn mein Nutzen insgesamt 0 ist. Aber das ist etwas, was man noch mehr explizit berücksichtigen muss, dass der Roboter mit dieser Strategie nur die ideale Richtung wählt, aber nicht wählt, wie schneller in diese Richtung fahren kann oder sollte. Genau, dann haben wir hier unterschiedlichste Situationen. Auch besonders hier rechts bei dem Bild sieht man, dass eine Straße manchmal irgendwie ein bisschen schwerer sehen kann, wenn wir hier so einen Quersigment haben, was einfach orange gefärbt ist. Oder wir hatten auch während dem Wettbewerb eine Situation, wo ein eine Art Ruli, also so ein SICKER Ding quer über die komplette Straße war und das halt braun war und sehr viele Roboter, die direkt auf der Bildverarbeitung gefahren sind, dann gedacht haben, ok, da kann ich nicht rüberfahren, davor nach links abgedreht haben, wo die Seite der Straße gefahren sind, wo dann kein Gully mehr war und erst dann wieder in die richtige Richtung fahren konnten. Und gegen sowas ist der Ansatz auch robust, weil er einfach im Bild die Spalten jeweils aufsummiert und dann da die wahrscheinlichste Richtung nimmt in der Straße ist. Und auch hier unten diese Situation können wir lösen mit dem Ansatz, die können wir lösen dadurch, dass der Laserscanner in der Lage ist, hier immer mal wieder diese einzelnen Linien zu sehen. Er sieht sehr viel zwischen den Linien, was unendlich weit sichtbar ist, aber er sieht immer wieder die Linien und die durch die Gausfilterung dafür sorgen, dass da, wo er tatsächlich einzelne Segmente erkennt, dort ist die Wahrscheinlichkeit, dass er dort hinfahren will, geringer, als wenn er hier gerade auswählt, wo gar keine vereinzelten Streuwerte sind. Und wir haben auch gesehen, wie wir hier rechts die Situation mit dem Fluss, zumindest in der Theorie sein können, indem wir einfach in unserer Bildverarbeitung annehmen, dass für den Fluss eine Nutzen von Null entsteht und sie sagt, wir wollen nicht in den Fluss fahren. Gut. Und jetzt nochmal zur Wiederholung mit dem Erwartungswert, damit man das Ganze dann auch tatsächlich umsetzen kann. Braucht man, haben wir uns dazu entschieden, unsere Nutzenfunktion mit der Verteilungsfunktion zu falten, die unseren Fehler modelliert und dadurch das Ganze zu robust zu machen gegen einzelne Messfehler, dann haben wir hier unten unsere Nutzenfunktion eine mögliche und die Nutzenfunktion beschreibt wirklich nur wie zielführend es in Richtung ist. Das ist alles, was entscheidend ist bei der Nutzenfunktion. Es geht wirklich nur darum, die Zielführend, also die zu formulieren, wie zielführend etwas ist. Und das macht das Problem halt so schön einfach zu lösen an dem Endeffekt, dass man sich dann auch formulieren können muss, wie zielführend sie ist. Und wir haben gesehen, wie wir aus unseren Sensoren unterschiedliche Arten von Nutzen herleiten können. Man kann sich vorstellen, dass man aus der Kamera theoretisch auch noch andere Informationen als nur den fahrbaren Untergrund als Nutzen herleiten kann. Man könnte auch irgendwie noch Menschen in Kamerabildern erkennen, aber wir haben den Laserscanner dafür gehabt. Und genau, so haben wir eine robuste Befarberierung. Und jetzt möchte ich nochmal kurz zeigen mit dem Kamerabild, wie man daraus den Nutzen letztendlich formuliert. Weil das noch ein bisschen unklar gelassen hat bisher. Und zwar sehen wir hier noch das Kamerabild, wie das dann aus der Bildverarbeitung kommt, die erkennt, wo befahrbare Regionen sind und wo keine befahrbaren Regionen sind. Und darunter sehen wir jetzt eine Aufsummierung der Spalte im Bild, wie viele Pixel in dieser Spalte weiß sind. Die Überlegung dahinter ist, dass eine Kamera in der Regeln- und Öffnungswinkel hat von so 45 Grad ungefähr oder je nach Kameramodell unterschiedlich 90 Grad, nicht 45 oder bei manchen Kameras auch mehr. Und die Pixel, die sich in einer Zeile befinden, entsprechend ungefähr, nicht ganz korrekt, aber eine Richtung. Und somit haben wir dann für jede Richtung wie weit in diese Richtung befahrbare Untergrund ist. Und das unabhängig davon, ob zwischendrin Sektionen sind, in denen kein befahrbar Untergrund ist oder nicht. Es gibt allerdings ein Problem dabei, was ich wunderbar verschwiegen hab noch, ist, dass wenn wir mal eine Sektion haben zwischendrin, die wirklich nicht befahrbar sein sollte, dann geht der Algorithmus aufgrund seiner Struktur davon aus, dass das nur ein Fehler in der Detektion ist und fährt einfach drüber. Also es ist keine perfekte Lösung. Es ist eine Lösung, aber es ist vielleicht nicht eine perfekte Lösung noch. Und hier sehen wir jetzt dann weiter unten noch, wie diese Nutzenfunktion aussieht, wenn sie geglättet wurde. Wenn sie, also wenn man nur diese Kameranutzenfunktion nimmt und hier sehen wir das ganze jetzt nochmal projiziert in den 2-Dimensionalen Raum, in den der Roboter tatsächlich schaut. Das heißt, hier können wir jetzt tatsächlich sehen, dass der Roboter glaubt, der Weg hat ungefähr diese Form vor ihm vermutlich. Also das sind die Richtungen, in die er fahren kann. Und wenn wir uns das Bild hier oben anschauen, stimmt das tatsächlich so ungefähr über ein. Und das funktioniert weitestgehend robust. Wobei das Interessante ist, dass selbst wenn das Bild hier unten, wenn man es zurückprojiziert, nicht gut aussieht und irgendwie naja etwas zerklüftet ist, ist das Gesamtergebnis immer noch gut, weil wir ja nicht normalerweise nicht nur die Nutzenfunktion der Kamera in den Erwartungswert geben, sondern die Mischung aus allen Nutzenfunktionen. Und jetzt möchte ich dann noch ein Video zeigen, wo man sieht, wie das Ganze in der Realität aussah. Das ist der Wettbewerb, von dem ich gesprochen habe. Und da sehen wir jetzt, wie unser Roboter im Testrun fährt. Und da haben wir tatsächlich, hätten wir in dieses eine Tor reinfahren sollen, dann hat unser Roboter irgendwann gemerkt, dass die Richtung um 180 Grad falsch ist, hat sich umgedreht und ist wieder in die richtige Richtung gefahren. Dann ist er leider vom Weg abgekommen. Da hat die Bilderkennung nicht ganz geblieben, da der Laserscanner auf den Boden geschaut hat, weil es halt eine Böschung runter ging. Und der Laserscanner auf eine schräge Böschung geschaut hat, hat der Laserscanner festgestellt, wenn ich mich eher links halte, weil die Böschung so ein bisschen so schräg abhängt nach links war, bin ich da besser und hat damit dann sich dafür entschieden, den Weg zu fahren, wo weniger Hindernisse sind, weil er halt in Boden geschaut hat. Das sind auch so Sachen, wo die Hindernisse noch ein bisschen problematisch sind. Hier sieht man jetzt den ersten tatsächlichen Lauf. Da hatten wir das Pech, dass aufgrund eines Softwarefehlers unser Roboter direkt beim Start abgestürzt ist. Hier sehen wir jetzt den Lauf am Fluss. Da ist unser Roboter immerhin losgefahren, aber auch hier ist der Code wieder abgestürzt, weil wir den Fehler noch nicht gefunden hatten. Das heißt, unser Roboter wäre noch nicht in der Lage, ohne zu fahren. Allerdings jetzt sehen wir, nachdem wir den Fehler gefunden und gelöst hatten, wieso unser Code abgestürzt ist, wie der Roboter einen Lauf als einziger Roboter bei dem Wettbewerb von Start bis Ende durchfährt. Und wir sehen hier, dass er bei der Wand sich dazu entschieden hat, den Weg zu fahren, wo er am längsten keine Hindernisse hat und der zusätzlich auch mit ungefähr mit der Richtung ist, die durch das GPS bestimmt wurde, über einen Stimm. Auch hier entscheidet der Roboter sich wieder für die richtige Richtung, weil das GPS ihm vorgibt, welche Richtung korrekt ist und der Aufgrund der Liederdaten die längste Strecke fährt. Ich lasse das einfach mal kurz noch laufen. Das ist vielleicht ganz interessant zu sehen, manche Stellen. Und hier sehen wir jetzt in der Situation, da war ein Übergang, wo wir jetzt für den Durchfahrt durch diesen Unterführung keinen GPS zum Beispiel hatten und nur dadurch weiterfahren konnten, weil wir den Kompass hatten. Jetzt sehen wir, wie der Roboter mit Menschen interagiert und auch wieder dadurch, dass wir einfach formuliert haben, als Nutzen, dass er mit dem Laser-Scanner möglichst gerade ausfährt, kann er Menschen ausweichen, ohne dass wir da nochmal extra was umsetzen mussten. Und jetzt kommt ein ganz erschwarmen Menschen entgegen und der Roboter hält sich automatisch am Wegrand, ohne dass wir ihm explizit einprogrammieren mussten, dass er sich am Wegrand halten soll. Er hat einfach durch die Formulierung des Nutzen festgestellt, dass das die beste Lösung ist, noch auf dem Weg zu bleiben, aber so weit rechts wie möglich, weil die Fußgänger links gelaufen sind. So, jetzt kommt der Roboter am Ziel des Laufs an und hat gepiepst und ist fertig. Das war dann der vierte Lauf. Da haben wir es leider nicht ganz bis zum Ziel geschafft. Da werden wir am Ende noch eine interessante Situation sehen, die auch ein bisschen problematisch sein kann. Also es ist manchmal etwas lang sein im Roboter-Rennen, wobei wir uns doch recht schnell schon abgesetzt haben. Wir sind in den Testläufen übrigens doppelt so schnell gefahren, hatten allerdings einmal dann ein unvorhergesehenes Problem, wo unser Roboter ins Schwingen gekommen ist und dann mit voller Geschwindigkeit gegen eine Bordsteinkante gefahren ist und deswegen haben wir uns entschieden, danach dann etwas langsamer zu fahren. Hier sehen wir, dass der Roboter auch in der Lage ist, zwischen nach Hauswand und einem Auto problemlos vorbeizufahren. Natürlich ist der Assistent ganz nah dran, drücken zu können, aber es ist alles gut gegangen. Und da hat man auch bei dem Auto gesehen, dass der Roboter es für am sichersten erachtet, nicht möglichst knapp nur am Auto vorbeizufahren, weil das ja theoretisch reichen würde, sondern auch mit einem Sicherheitsabstand am Auto vorbeizufahren und die Mitte zwischen Auto und Wand zu wählen. Hier sehen wir das Problem Laterne. Auch kleine Kinder sind kein Problem. Und jetzt sind wir hier in der Situation, wo unser Roboter sich aufgrund der Speed Maps dazu entschieden hat, in eine etwas merkwürdig anmutende kleine Seitenstraße zu fahren, weil das eben der kürzeste Weg zum Zielpunkt war. Jetzt sieht man hier rechts einen Restaurant und in dieses Restaurant oder durch dieses Restaurant durch hätte laut Open Speed Maps die Route zum Zielpunkt geführt, welche auf der anderen Seite des Hauses, was wir da sehen könnten, stand. Und was hier jetzt rausgekürzt wurde, ist, dass der Roboter dann vor der Wand die ganze Zeit auf- und abgefahren ist, weil seine Kameraerkennung und der Laserscanner ihm gesagt hat, dass er nicht durch dieses Restaurant durchfahren kann, allerdings seine Navigation ihm gesagt hat, dass er durchfahren muss und er dann immer Richtung Restaurant gefahren ist, dann abgedreht hat, vor der Wand stand, dann hatten wir vor der Wand die Routine, dass wenn er nicht mehr weiter kommt, fährt er rückwärts ein Stück und probiert es nochmal. Und das Problem beim einfach nur rückwärts fahren ist, dass sich die Ausgangssituation meistens nicht so sehr ändert. Und dementsprechend haben wir dann Luftlinie 10 Meter vom Ziel entfernt, aber leider auf der falschen Seite der Häuser von festgesteckt. Und so kann man im Prinzip so kann man im Prinzip den Roboter modellieren, indem man einfach nur Interessen modellieren kann. Ich danke für eure Aufmerksamkeit und stehe jetzt noch für Fragen zur Verfügung. Ja, haben wir vielleicht doch ein Mikrofon für die Fragen jetzt? Oder sollen die nicht aufgenommen werden? Ich glaube, weil jetzt ist es dann besser mit Mikrofon. Da oben war die Frage. Wie weit reicht denn das Lieder um den Roboter oben? Also wenn er rückwärts fährt, weiß er dann, ob dahinter jemand steht oder fährt er dann gegen den Mensch dagegen? Wir haben einen Laserscanner, der hat 270 Grad Öffnungswinkel. Also ich kann nochmal gerade im Video hier sehen. Hier sieht man den Roboter von vorne. Da sieht man den Lieder. Der ist zentral vorne am Roboter angebracht. Und der hat nur einen Öffnungswinkel von 270 Grad. Wobei, wenn er mehr Öffnungswinkel hätte, würde es uns auch nichts bringen, weil wir uns nur selber sehen würden und dadurch keine Information mehr gewinnen würden. Allerdings haben wir noch einen etwas kleineren, leistungsschwächeren Lieder auf der Rückseite. Der hat 70 Grad Öffnungswinkel. Das heißt, wir haben eine Rundumsicht. Allerdings sind es zwei unterschiedliche Sensoren, was es in der Praxis bei der Verwendung ein bisschen haarig macht. Gibt es noch weitere Fragen? Auf dem Roboter ist immer so eine Trommel drauf. Ist das ein Benzin-Kinester oder transportiert er dort Getränke? Es war ein Wettbewerb in Tschechien, dem Land des Bieres. Zumindest die haben das Bier erfunden. Und dementsprechend musste bei dem Wettbewerb ganz realistisch der Roboter Bierfesser ausliefern. Da ging es darum, das Bierfass immer an die Zielkoordinate zu bringen. Das Lustige an dem Wettbewerb war, dass die Zielkoordinate ganz am Ende tatsächlich sogar vor einem Restaurant, also der anderen Seite des Restaurants, vor dem wir standen, das war ein Restaurant, die End-Zielkoordinate. Das sieht man bei uns, bei den anderen auch. Ein Team hatte eine sehr kreative Lösung. Die haben das Fass im Anhänger transportiert, weil die nur ein kleines Modellauto als Zugfahrzeug hatten. Die hatten allerdings mechanische Probleme und sind im Kopfsteinpflaster hängen geblieben mit ihren Rädern. Ich habe jetzt noch eine Frage in der Mitte vorne. Mich würde noch interessieren, wie wir von diesem Kamerabild auf dieses schwarz-weiß Bild kommen. Sind es einfach nur Filter oder läuft da irgendwie die KI oder würde man das mit maschinellen Lernen vermutlich lösen? Wir haben allerdings so eine menschliche Analyse gemacht. Wir haben uns Histogramme angeschaut von Regionen, in denen wir fahren konnten und Regionen, in denen wir nicht fahren konnten. Hier sieht man, wir sind dann hergegangen, haben im Bild die Intensität festgesetzt, weil die Intensität den Schatten hauptsächlich darstellt und somit egal war. Vorher das Bild ein bisschen geblurt, damit wir das ganze Bildrauschen loswerden, das bei den Kameras drin sind. Und im Anschluss daran wird das Bild wieder ein bisschen geschärft, damit wir klare Kanten haben, wobei das vermutlich sogar nicht zu besseren Ergebnissen beigetragen hat, sondern vollkommen egal ist. Und dann haben wir hier eine In-Range-Operation von OpenCV angewendet, wo wir geschaut haben, dass die Sättigung unter 40 ist. Wir haben dann geguckt, befahrbare Regionen im Bild sind besonders die Regionen, in denen die Sättigung sehr gering ist. Und das haben wir einfach rausgefunden, indem wir uns Videos angeschaut haben, da markiert haben, wo eine befahrbare Region ist, dass Histogramm davon angeschaut haben und festgestellt haben, es sind irgendwie die Sättigung, die entscheidend ist. Also keine komplexen Algorithmen dafür, das war ganz trivial. Ich hätte zwei Fragen, einmal, was die Bilderkennung angeht. Wie verhält es sich sich bewegenden, also plötzlich auftauchen sich bewegenden Hindernissen? Und wie reagiert das Ganze, wenn die Sichtverhältnisse sich deutlich verschlechtern, beispielsweise durch Rauch, Nebel oder Ähnliches? Rauch, Nebel oder Ähnliches haben wir nie berücksichtigt, weil, also wir müssen sagen, der Wettbewerb war, hat halt im Herbst stattgefunden und also im frühen Herbst oder spät Sommer meistens recht stabile Wetterverhältnisse. Das heißt, man konnte die Kamera vorher kalibrieren, bevor der Wettbewerb losging und dann hatte man eigentlich recht stabile Verhältnisse in der Bilderkennung. Zu plötzlich auftauchenden Hindernissen in unseren Testvideos, also auf der tatsächlichen Fahrt können wir es natürlich nicht sagen, da konnten wir die Daten nicht reinschauen, aber bei den Testvideos hatten wir teilweise Fahrradfahrer, die durchs Video gefahren sind. Diese sind dann entweder gar nicht sichtbar gewesen, weil sie befahrbar aussahen für den einfachen Algorithmus mit der Sättigung oder sie wurden tatsächlich als nicht befahrbar angesehen, weil sie irgendwelche grüne Hose an hatten oder sowas und dann ist natürlich in der entsprechenden bei dem entsprechenden X-Wert in unserer Verteilungsfunktion, die wir daraus generiert haben, ein geringerer Wert aufgetreten. Und dieser geringere Wert, unsere Bildverarbeitung wurde auch deshalb so einfach gehalten, dass man eben mit voller Geschwindigkeit der Kamera mitlaufen kann. Und da sind dann auch die schnell bewegenden Objekte kein Problem. Also solange die Kameras erfassen konnten, konnte auch unser Algorithmus das erfassen. Eure Mathematik ist ja irgendwie ein bisschen geeignet, ein Stück Magie auch zu modellieren, vielleicht. Wie sehr konntet ihr die Handlungen des Roboters vorher sagen oder habt sie im Nachhinein verstanden? Also ich muss zugeben, dass der Vortrag, wie ich es hier vorstelle, im Prinzip im Nachhinein wie erst die Mathematik verstanden haben, sondern im Vorhinein einfach diese Nutzenfunktionen modelliert hatten, dann das ein bisschen gefiltert haben und dann damit unser Ergebnis hatten, in welche Richtung wir fahren. Und im Nachhinein haben wir uns dann irgendwie zwei, drei Monate lang den Kopf zerbrochen, wieso das überhaupt funktioniert, uns letztendlich in der probabilistischen Robotik fündig geworden, dass das eben dieser Erwartungswert ist, den ich vorgestellt habe über die Nutzenfunktion. Und ja, es ist ein Stück weit verträglich für Magie, weil man eben in dieser Nutzenfunktion diese kleinen runtergebrochenen Segmenten nur beschreiben muss. Beantwortet es die Frage? Okay. Ganz hinten. Wie groß ist der Rechenaufwand, um einmal die Nutzenfunktion zu berechnen? Um eine, was für eine Funktion? Die Nutzenfunktionen ergeben sich ziemlich direkt aus den Sensor-Daten. Also hier sehen wir zum Beispiel von der Kamera ist genau diese Funktion zu dem Zeitpunkt hier die Nutzenfunktion. Die beläuft sich auf die Bildverarbeitung, die mit OpenCV relativ kosteneffizient geht. Zumindest da wie in unserem Fall nur eine In-Range-Operation, die eine günstige CV-Operation ist. Und im Nachhinein wurde hier mit diesem Image-to-Distribution lediglich gezählt für jede Spalte im Bild wie viele Pixel weiß und wie viele schwarze. Das heißt, der Aufwand beläuft sich beim Bild, um das in Nutzenfunktion zu bringen auf Breite des Bildes, Malhöhe des Bildes und dann halt noch das, was OpenCV kostet. Und wir haben unsere Bilder nicht mit FullHD oder so aufgenommen, sondern in der Robotik ist es üblich, dass man sagt, na ja, irgendwie so 20x240 Pixel reichen uns im Endeffekt aus. Und wir haben unser Bild daher vom Anfang erst mal stark runter skaliert und dann nur noch auf diesen Mini-Bild gearbeitet, weil das enthält immer noch die Informationen, die wir suchen, und zwar wo Weg ist. Wir brauchen ja keine Schrift zu lesen, wo irgendwelche Werbeschriftzüge oder so draufstehen. Das heißt, es ist sehr günstig. Bei den Laser-Daten war es so, dass die Laser-Daten-Nutzenfunktion in der Richtung erfordert, weil wir einfach direkt die Entfernungen vom Laser-Scanner, also der Laser-Scanner gibt die Entfernung zu den Hindernissen zurück, für jeden Winkel die Entfernung. Und wir haben dann diese Daten einfach direkt als Nutzendfunktionen genommen, weil es ja unserer Meinung nach dem Roboter viel nützt, in Richtung zu fahren, in der er lange fahren kann, wo wenig Hindernis ist. Und das heißt, da war die Nutzendfunktion zum Beispiel trivial zu bestimmen, indem man einfach die Nutzendfunktion direkt als Nutzendfunktion modelliert. Wohingegen beim GPS das Ganze etwas aufwendiger eventuell ist. Also weil wir uns ja zunächst im OpenStreetMaps Graf die kürzeste Route finden, da weiß ich gerade nicht auswendig, wie aufwendig das ist. Und dann muss man das Segment checken, in dem man ist und darauf dann den Winkel vergleichen. Aber prinzipiell ist das ein bisschen günstig, so eine Art der Modellierung. Bei dem Winkel, den ihr dann rausbekommt, im Endeffekt, fragt ihr für jeden Winkel ab, wie hoch ist mir hier da Nutzen, sozusagen. Habt ihr da auch eine Beschränkung drin, dass ihr sagt, ich brauche ein Fenster von fünf Grad oder was, dass ich da überhaupt durchpasst, oder wird da wirklich nur das Maximum genommen? Also wenn man eine entsprechend breite Gaußkurve nimmt, dann wird das ja schon bei der Bildung des Erwartungswerts berücksichtigt, weil das so breit wie Gewichte nebendran eingewichtet. Das wäre die mathematisch sinnvollere Variante, das zu bestimmen. Allerdings haben wir uns dann aus Sicherheit dafür entschieden, wir machen es noch komplizierter. Und zwar gibt es da noch ein Konzept namens HPD Regions, heißt Posterior Density Regions. Das heißt, wir haben unsere Nutzenfunktion nachher als eine posteriore Dichte gesehen. Also wir haben gesagt, dass der Nutzen irgendwie auch entspricht, wie wahrscheinlich es ist, wenn wir in diese Richtung fahren, dass wir den am Ziel ankommen oder den Wettbewerb gewinnen und haben das dann im Prinzip als eine posteriore Dichte angenommen. Und dann darin die Regionen gefunden, bei denen die posteriore Dichte am höchsten ist. Und von diesen Regionen haben wir die breiteste ausgewählt und sind in der Mitte gefahren. Das Interessante ist, der Ansatz klingt zwar viel komplizierter, aber brauche in der Theorie nur N-Lock um den zu berechnen. Woin gegen die Faltung N² Aufwand benötigt. Das heißt, es ist sogar lustigerweise praktischer, das so auszurechnen, als es mit der Faltung auszurechnen. Allerdings wollte ich das hier jetzt nicht erklären, weil es noch ein komplett neues Fachgebiet ist. Gibt es noch weitere Fragen? Dann bedanke ich mich für eure Aufmerksamkeit. Wenn ihr noch Fragen habt, könnt ihr entweder mich noch aufsuchen während der GPN. Wir sitzen direkt in der Ecke. Wenn man von hier Richtung GPN wieder läuft, sitzen wir direkt vorne links in der Ecke, direkt, wo man dran vorbeiläuft. Oder ihr könnt mich auch per E-Mail erreichen, wenn ihr zu dem Thema irgendwas machen wollt. Ihr könnt auch bei uns in der Hochschulgruppe, wenn ihr Studenten seid, aus Karlsruhe vorbeischauen und damit uns reden. Also wenn es euch interessiert, kommt ruhig auf uns zu. Wir haben keine Angst. Wir freuen uns, wenn sich jemand anderes findet. Viel Spaß auf der GPN noch.