hier ist lange nichts passiert. Das liegt zum Einen an meinem zweiwöchigen USA-Aufenthalt und zum Anderen am schönen Wetter draussen.

Dennoch: Die nächsten Schritte sind klar: Tracking der Fahrbefehle, Ansteuern von bestimmten Koordinaten, Rekalibrierung der durch die Akkumulation kleiner Fehler entstehenden Koordinatendifferenzen.

Die ersten beiden Punkte sind einfach, der letzte nicht.

Möglichkeit 1. Auf das Fahrzeug kommt ein Mikrokontroller, der über WLAN ansprechbar ist und die Servomotoren mit gängiger PWM (Pulsweitenmodulation) anspricht. Dagegen spricht: Eine ähnliche Variante hatten wir bereits mit dem ersten LEGO-Auto. Letztlich muss das Auto viel zusätzliche Hardware transportieren und mit Strom versorgen. Eine TCP/IP Kopplung ist für Echtzeitanwendungen auch nicht unbedingt prädestiniert. Diese Variante scheidet also aus.

Möglichkeit 2. Man nutzt die vorhandene Fernbedienung, und bringt sie dazu das zu senden, was man möchte. Wie tut man dies? Ich habe absichtlich eine billige Fernbedienung gekauft, in der Hoffnung, die verbaute Technik ist simpel. Und das ist sie auch. Die Fernbedienung ist ein 40MHz  FM Sender. Gesendet wird ein sogenannter PPM-Code. Dies steht für Pulse Position Modulation. Über die Länge von Pausen zwischen zwei Impulsen werden die einzelnen Kanäle (und somit Servostellungen) sequentiell über eine 40MHz Frequenz gefunkt. Die Impulse selbst sind immer gleich lang. Synchronisiert wird über eine überlange Pause am Anfang/Ende der Sequenz. Ein Frame ist dabei ca 20ms lang.

 Hierbei ist zu beachten: In der Literatur findet sich auch eine andere Beschreibung von PPM. Hier wird über die Länge von Pulsen moduliert, ein überlanger Startpuls dient als Synchronisation und die Abständer zweier Pulse ist immer gleich. Diese beiden Beschreibungen sind identisch, wenn man Puls und Pause vertauscht.

Jeder, der schon einmal eine Windows/Linux-Anwendung programmiert hat und versucht hat dabei einen Timer zu verwenden, der Millisekundengenau auflöst und dabei kläglich gescheitert ist, wird sich jetzt fragen: Wie soll so etwas funktionieren? Gängige Timer unter Windows/Linux lösen nur 16ms auf. Weiterhin kann das Multitasking einem einen Strich durch die Rechnung machen, in dem es einfach mal einen Prozess ein paar Millisekunden aussetzen lässt. Die Lösung ist dennoch denkbar einfach: Man nimmt die Soundkarte! Eine Soundkarte feuert bei einer Samplingrate von 44.1kHz (CD-Qualität) 44100 Samples in einer Sekunde auf die Lautsprecher. Dabei sind die Soundkarten bestrebt, dies so gut wie möglich zu machen, damit einem beim Hören einer CD nicht die Ohren abfallen. Ein PPM-Frame umfasst etwa 20ms. In 20ms kann eine Soundkarte bei CD-Qualität 20ms*44.1Samples/ms = 882 Samples losschicken.  In diesen 882 Samples kann ich nun meine Kanäle modulieren. Für einen Kanal steht etwa 1ms zur Verfügung, dies entspricht damit 44.1 Stufen pro Kanal. Dies ist nicht sonderlich gut, aber ausreichend und vor allem in Echtzeit und ohne zusätzlichen Hardwareaufwand. Also wurde die Fernbedienung kurzerhand auseindergebaut und das PPM Signal auf einem Oszilloskop betrachtet. Dann wurde dieses Signal über die Soundkarte nachgebaut.

Intern habe ich DirectX, bzw genauer XAudio2 (Nachfolger von Direct Sound) verwendet und einen PPM-Frame mit einer Streamingvariante über zwei abwechselnde Audiobuffer abgespielt. Soweit so gut, man kann also PPM über eine Soundkarte ausgeben. Hören kann man das somit natürlich auch. Aber wie kommt das Signal nun zum Auto? Die FM-Modulation auf die 40MHz Trägerfrequenz übernimmt weiterhin die Fernbedienung. Hierzu musste man lediglich kurz vor der Hochfrequenzeinheit der Fernbedienung das Signal der Soundkarte einspeisen. Damit ich meine Fernbedienung nicht gleich vernichte, hat mein Vater wieder einmal den Lötkolben geschwungen und nun hat meine Ansmann W3 Fernbedienung eine Stereobuchse bekommen. Musik sollte man hier jedoch nicht einspielen, das Auto interpretiert diese Signalfolgen nämlich ebenfalls als PPM und versucht dann zur Musik passend zu tanzen!

Es wurden einige Versuche gemacht, die Fahrzeugbewegungserfassung mit Hilfe des optischen Flusses zu verbessern. Ich habe hierzu noch das ein oder andere Paper gelesen, welche allesamt vielversprechend klangen, aber in der Praxis kaum eine Verbesserung brachten. Optischer Fluss bleibt immer eine Schätzung. Eine präzise Ableitung einer Bewegung kann nicht alleine mit optischem Fluss realisiert werden. Die Ergebnisse, die es in der Praxis gibt, sind allerdings bereits in der Horn/Schunk Variante so gut, dass die bisherigen Paper, die ich gelesen und teilweise implementiert habe, diese kaum verbessern können. Daher bleibe ich bei dieser Variante, nicht zuletzt weil sie die einfachste Variante ist.

Folgende Versuche wurden unternommen um die Verfolgung zu optimieren:

•  Ein Wohnungsmodell wurde auf Basis eines vorhandenen Grundrisses erstellt. In das Modell wurden absichtlich keine Möbelstücke eingezeichnet, da dies erstens zu viel Aufwand ist, und zweitens sich diese Möbelstücke zum Teil zu verschiedenen Zeiten an verschiedenen Orten befinden können (z.B. Stühle, Couchtisch etc). Berechnet man nun ein Tiefenmodell dessen, was das Modellfahrzeug in der Modellwohnung sehen müsste, so kann man die gewonnenen Tiefen mit dem Tiefenbild der Webcam vergleichen. Da in dem Modell allerdings die Möbel fehlen, so hat man es selbst bei einer perfekten Tiefenberechnung der Webcambilder immer mit Abweichungen zwischen Modell und Wirklichkeit zu tun. Eine Situation kann hiermit jedoch halbwegs sinnvoll verbessert werden: Sieht das Fahrzeug mit der Webcam z.B. eine Tiefe von 4m in der Mitte des Bildes, und zeigt das Modell eine Tiefe von 3m an dieser Stelle, so muss das Fahrzeug eine Korrektur nach hinten erfahren. Andersherum gilt dies nicht, da Möbelstücke einen geringeren Tiefeneindruck als die des Modells bewirken. Einen weiteren Vorteil durch das Modell hat man: Das Fahrzeug kann nicht durch Wände fahren. Fährt das Modell durch eine Wand so kann hier vorher eingegriffen werden und das Modell seitlich verschoben werden, in die Richtung, die besser zu dem Tiefenbild der Webcam passt. In der Praxis führt dies zu Sprüngen des Fahrzeugs innerhalb seiner 3D-Welt. Allerdings können somit auch längere Fahrten gemacht werden, ohne dass sich das Fahrzeug völlig verirrt. Dies kann natürlich nie ausgeschlossen werden, denn die korrigierenden Eingriffe sind einfachster Natur und können die Situation durchaus auch verschlechtern.

• Reifentracking. Da der optische Fluss eine Schätzung ist und das zu Grunde liegende Material beliebig komplex sein kann, habe ich versucht das zu Grunde liegende Bildmaterial zu vereinfachen. Die Kamera wurde auf die Vorderreifen des Modells ausgerichtet. Der optische Fluss des Stollenprofils der Reifen sollte Testweise genutzt werden um die Fahrzeugbewegung zu verfolgen. Das Tracking gelingt auf Anhieb erstaunlich gut. Der Fluss des Stollenprofils der Reifen ist gut geeignet um verschiedene Geschwindigkeiten und Lenkeinstellungen präzise zu ermitteln. Leider gibt es bei diesem Verfahren ein Problem. Überschreitet das Fahrzeug eine bestimmte Geschwindigkeit kehrt sich der optische Fluss des Stollenprofils um und das Fahrzeug invertiert seine Geschwindigkeit. Dies ist ein Phänomen, welches wohl jedem Zuschauer von Glücksrad bekannt sein dürfte. Die optische Wirkung der Drehrichtung kehrt sich bei hohen Geschwindigkeiten plötzlich um. Leider liegt diese Kipp-Geschwindigkeit hier bereits bei 1/3 der maximalen Geschwindigkeit des Fahrzeugs. Des weiteren geht sehr viel Bildeindruck verloren, da die Reifen einen Großteil des Bildes einnehmen. Aus diesen Gründen wurde dieses Verfahren nicht weiter verfolgt.

Viel besser werden die Ergebnisse zwar nicht, aber dafür hat man mehr CPU Power für andere Dinge übrig. Ich werde sie versuchen weise einzusetzen :-)

Das Schlimme an der Vielzahl der Paper ist: Ein Author eines Papers würde nie einen Algorithmus vorstellen um hinterher im Ergebnisteil seines Papers zu schreiben, dass der Algorithmus totale Grütze ist, eine gigantische Rechenzeit benötigt und die Ergebnisse nur unter Laborbedingungen brauchbar sind.

In der Informatik lernt man, dass manche Problemstellungen einfach so schwierig sind, dass man keine brauchbare Lösung finden kann, wenn man die Aufgabenstellung nicht spezialisiert. Es ist in der Regel einfacher einen Algorithmus für ein spezielles Problem zu schreiben, als einen Algorithmus für ein Allgemeines. So bin ich nach dem Studium einiger Paper und der Implementierung eines der vielversprechensten Paper (welches grandios versagt hat!) dazu gekommen, mir eine eigene Lösung auszudenken. Wenn man nicht alles selber macht....

Zunächst gilt, dass das Fahrzeug den Boden vor sich sieht. Jetzt kann man davon ausgehen, dass alles, was sich direkt vor dem Fahrzeug befindet kein Hindernis ist, da das Fahrzeug ja grundsätzlich nicht vor ein Hindernis vorfahren soll. Also liegt es nahe, dass alles, was ausgehend vom Fahrzeug so aussieht, wie das, was sich direkt vor einem befindet, Boden und somit kein Hindernis ist. Welche Informationen kann man verwenden um die Ähnlichkeit zweier Elemente im Bild zu vergleichen? Die Auswahl der Informationen wird Feature genannt. Verwendet werden folgende Features:

• Änderung einzelner Farbkanäle (,,)
• Änderung von Farbton, Farbsättigung und Farbhelligkeit (,,)
• Änderung der Texturenergien ( mit  Helligkeitsinformationen und Laws Texturmasken, )

Die eingeführten Funktionen und Abkürzungen bedeuten folgendes:

• Rotkanal, Grünkanal,  Blaukanal 
• Farbton (Hue), Sättigung, Helligkeit (Value)
•  Helligkeitsinformationen, Laws Texturmasken (Dies sind kleine Masken, mit denen man ein Bild falten kann, um entsprechende Merkmale des Bildes feststellen zu können.
• ist die Umgebung um die Polarkoordinaten
• Texturenergie

Das hier verwendete Koordinatensystem ist ein Polarkoordinatensystem. Es werden letztlich Strahlen vom Bodenursprung ( Kartesisch) in einem Kreisförmigen Bogen verfolgt. Sollten sich auf dem Strahlenweg obige Constraints zu stark ändern, so hat man ein Hindernis gefunden. Die Länge des Strahls entspricht dabei der approximierten Entfernung. Die Strahlgeraden ergeben sich dabei durch

Und hier wie gewohnt das zugehörige Video...

• Die Szene muss mehr oder weniger statisch sein. Falls die Szene nicht statisch ist, dürfen sich bewegende Elemente nicht zum Tracking verwendet werden. Sich bewegende Elemente können relativ leicht erkannt werden (der optische Fluss weicht hier von dem Rest der Szene ab), aber ein Herausrechnen dieser Elemente führt mindestens zu kleinen Fehlern.
• Bildrauschen der Kamera führt zu kleinen Fehlern.
• Bildelemente ohne Struktur führen bei der optischen Flussberechnung zum Fill-In-Effekt. Hier erben Bildelemente Flussvektoren von strukturierteren umgebenden Bildbereichen. Der Effekt hält einige Zeit an, auch wenn der Ursprung des optischen Flusses bereits völlig andere Werte angenommen hat. Die Flussvektoren dieser Elemente können herausgerechnet werden, je mehr Flussvektoren hier jedoch herausgerechnet werden, desto ungenauer wird der akkumulierte Gesamtfluss für Rotation und Geschwindigkeit.
• Fehler, die sich Bild für Bild einschleichen akkumulieren sich. Je länger das Tracking läuft, desto unpräziser wird es.

Der Algorithmus vollzieht Bild für Bild folgende Schritte:

• Schärfen (einfache Faltung mit einem Schärfungsfilter). Dies bewirkt, dass beim Verkleinern das resultierende Bild nicht nurnoch Matsch ist.
• Berechnung der mittleren Helligkeit des Gesamtbildes und Anhebung/Absenkung der Helligkeit auf den Mittelwert des Definitionsbereiches. Dieser Schritt verhindert, dass eine plötzliche Helligkeitsanpassung der Kamera zu Fehlern im Fluss führt. Dieser Effekt kann Rauschen verstärken (beim Anheben) oder vermindern (beim Absenken).
• Blockmittelung. Einzelne Pixel werden zu Blöcken zusammengefasst (hier 5x5 Pixel). Dieser Effekt vernichtet Details (leider) und Rauschen (juhu). Insgesamt kommt der Gesamtalgorithmus mit deutlich weniger Rechenzeit aus.
• Berechnung des optischen Flusses des gesamten Bildes auf Basis des aktuellen und des letzten Bildes. Der Algorithmus verwendet 5 Iterationen des Gauss Seidel Algorithmusses um den Fluss smooth zu halten und den Fill-In-Effekt zu mindern. Die letzte Schätzung des Flusses ist gleichzeitig Ausgangsbasis des Flusses des Folgebildes. Somit kann die Anzahl der Iterationen gering sein. Eigentlich wären viel mehr Iterationen erforderlich, nämlich halb so viele Iterationen wie das Bild Pixel breit ist. (Bei einem 320x240 Bild mit 5x5 Blöcken also 32 Iterationen).
• Klassifizierung der Flussvektoren in gut und schlecht. Ein guter Flussvektor ist einer, dessen Bildblock zu seinem Nachbarblock einen "sichtbaren" Helligkeitsunterschied aufweist. Dies wirkt dem Fill-In-Effekt nochmal entgegen.
• Betrachtung einer Teilmenge der guten Flussvektoren im oberen Bildbereich zur Bestimmung der Rotation. Exponentielle Glättung des resultierenden Vektors.
• Betrachtung einer Teilmenge der guten Flussvektoren im unteren Bildbereich zur Bestimmung der Geschwindigkeit. Exponentielle Glättung des resultierenden Vektors.

Die letzten beiden Schritte verwenden zur Stabilisierung eine Tiefenabschätzung jedes einzelnen Blocks. Die Tiefeneinschätzung wird durch Rückprojektion eines Blocks von einer 2D in eine 3D Koordinate erreicht. Dabei wird zunächst abgeschätzt wie viel "Boden" es vom Fahrzeugursprung bis zur Höhe des Blocks gibt. Das Verfahren ist schnell, leider aber auch schlecht. Zur Stabilisierung der letzten beiden Schritte ist es aber ausreichend. Und jetzt.....So sieht das ganze aus, wenns läuft. Eine Fahrt von meinem Büro ins Wohnzimmer, ein Wendemanöver und die Rückkehr ins Büro. Der Fahrweg beträgt etwa 22m. Das Tracking liefert hier eine Genauigkeit bis auf 30cm.

Was hat das mit diesem Projekt zu tun? Gar nichts. In meiner Wohnung gibt es weder Steigungen noch unwegsames Gelände (naja, wenn ich meine Klammotten mal wieder überall rumliegen lasse schon...). Allerdings sind diese Fahrzeuge durch ihr Einsatzgebiet auch für zwei Dinge besonders ausgelegt: Langsames und Präzises Fahren. Dies wiederum kommt meiner Applikation nahe.

Nach einiger Beratung in Foren, welches Fahrzeug (als Bausatz oder als Kit), mit welchem Motor (Brushless oder nicht), welche Steuerung (2.4GHz oder 40MHz), welchen Akku (Lipo oder NiMh), welches Ladegerät (mit Schnickschnack oder ohne), welche Servos (Metallgetriebe oder nicht) usw... habe ich mich für den Kyosho Rock Force entschieden. Ein Bausatz. Jede Schraube einzeln. Na das war ein Spass.

Insgesamt bedanke ich mich für die freundliche Beratung durch den Internetshop http://www.monster-hopups.de (Ja, es gibt Internetshops mit Beratung!!) und dem http://www.final-rc.de Forum.

 
Und hier in Groß

• Aluminium Chassis
• Aluminium Links
• Stahlkardanwellen
• Allradantrieb (optional Allradlenkung)
• Schneckenantrieb
• Hohe Achsverschränkung
• Vollgefedert
• Brushless 18.5 Turn Sensored Crawler - Motorset
• und und und...