Code III - Navigationsalgorithmus in Matlab

So, hier nun der Rest des Codes. Es gilt auch hierfür das bereits Gesagte: möglicherweise sind noch einige Schönheitsfehler in den Funktionen.

• init.m
• procfrm.m
• cog.m
• bav.m

Code II - Basisstation

Und hier nun der Bascom Code für die Basisstation. Tatsächlich habe ich nicht die Sorgfalt beim Aufräumen des Programms walten lassen, die ich eigentlich für angemessen halte. Im Ergebnis könnte es somit sein, dass noch eine ganze Menge Müll im Code rumliegt - etwa Dimensionierungen von Variablen, die dann doch niemals benutzt werden. Wie auch immer, voilà:

• vh1_basisstation.bas

Code I - Fahrzeug

Jetzt habe ich es endlich mal geschafft, zumindest das erste Drittel des Quellcodes meines vehikel[eins] Projektes aufzubereiten. Unten ist der Bascom-Code für das Fahrzeug verlinkt. Das Programm für die Basisstation sowie der Matlab-Code für die Bildverarbeitung fehlen noch. Leider habe ich zur Zeit ziemlich viel zu tun, ich werde trotzdem versuchen, den Rest zügig nachzureichen.

• vh1_fahrzeug.bas

vehikel[eins] als kamerabasierter Linienfolger

Kaum muss man ein paar Tage nicht arbeiten, schon kommt man endlich mal richtig zum arbeiten… Wie ja bereits angedeutet, waren meine Spielereien mit Ultraschall- und Infrarothindernisortung alles in allem etwas ernüchternd. Und da ich dieses Thema ja ohnehin nicht übermäßig spannend finde, habe ich es vorerst ad Acta gelegt und mich der meinem Geschmack nach wesentlich interessanteren Problematik der kamerabasierten („visuellen“) Navigation zugewandt. Mein erstes Projekt ist ein Linienfolger, also ein Fahrzeug, das eine auf dem Boden befindliche Line abfährt. Abgesehen von der recht simplen Algorithmik, eignet sich dieses Projekt gut zum Einstieg, weil es die verlässliche Funktion der gesamten, mittlerweile doch etwas komplex gewordenen „Infrastruktur“ des Systems erfordert, ich hier also zum ersten Mal alles „closed-loop“ betreiben muss - incl. Bildverarbeitung. Als neue Komponente dafür ist eine Frame-Grabber-Karte in meinen PC gekommen. Der Grabber digitalisiert das Videosignal vom Kameraempfänger und stellt es als einzelne Frames in MATLAB zur Verfügung, ich kann dann darauf rechnen und die extrahierten Informationen per RS-232 an meine Basisstation geben. Diese reicht die Steuerbefehle per Funk an das Vehikel weiter, das sich dann – wenn alles klappt – entsprechend verhält und dadurch wiederum den visuellen Input des Systems verändert.
Das über dem Bild verlinkte Video zeigt zum einen von oben, wie das Vehikel einen kleinen Parcours, den ich mit weißem Klebeband auf schwarze Pappe geklebt habe, „autonom“ abfährt. Das linke Bild des unteren Bilddrittels zeigt die Fahrt parallel aus Sicht des Vehikels. Um den zum „Erkennen“ der Linie verwendeten Algorithmus zur erleutern, sind noch ein paar weitere Dinge in dem Video dargestellt, die sogleich zur Sprache kommen sollen. Nach Spielereien mit wesentlich komplizierteren Ansätzen bin ich zu einem erstaunlich simplen Verfahren gekommen, um die Aktivierung der Motoren zu regeln. Nachdem ich per Schwelle ein 8-bit Graustufenframe von der Kamera in ein 1-bit Schwarzweißbild übersetzt habe, bestimme ich die Koordinaten des Schwerpunktes (center of gravity, COG) dieses Bildes und rechne dann die x-Koordinate des COG in die Aktivierung der Motoren um. Eine Abweichung der x-Koordinate des COG nach rechts von der Bildmitte führt dabei zu einer proportionalen Erhöhung der Drehgeschwindigkeit des linken Rades und einer proportionalen Verminderung Drehgeschwindigkeit des rechten Rades. Eine Abweichung des COG nach links von der Bildmitte hat entsprechend die umgekehrte Konsequenz. Befindet sich der COG in der Mitte der x-Dimension des Bildes, drehen beide Motoren gleich schnell. Links unten im Video ist nun die 1-bit Repräsentation des aktuellen Frames zu sehen, in grün eingezeichnet der COG, durch eine Linie verbunden mit der Mitte des unteren Bildrandes. Das original Kamerabild rechts zeigt in gleicher Weise den COG, dessen Koordinaten sind in den ersten beiden Zeilen angegeben, darunter die daraus errechnete Aktivierung des rechten und linken Motors in Prozent der Maximalgeschwindigkeit. In ein paar Tagen werde ich den BASCOM und MATLAB Quellcode posten.

Um Codec Probleme zu vermeiden, habe ich das Filmchen als Blogger Video eingebunden - trotz der durch die hohe Kompression miesen Qualität. Hier ist zusätzlich aber auch noch ein Link zu einem avi mit etwas besserer Qualität:

Video: [link]

Echolot

Soweit es meine Zeit zuließ, habe ich an meinem vehikel[eins] Projekt weitergearbeitet. Die Hardware ist ja mittlerweile fertiggestellt, sodass ich beginnen konnte, auf dem PC, der mit meiner Basisstation verbunden ist, erste simple Steueralgorithmen zu basteln. Ich verwende dafür nach wie vor Matlab, einfach weil ich es ziemlich stumpf runter schreiben kann – zum Experimentieren also genau das richtige. Ich habe mir zunächst die Routinen gebaut, die die Kommunikation mit dem Vehikel bewerkstelligen. Nachdem das akzeptabel funktionierte, habe ich begonnen, kleine Navigationsalgorithmen zu schreiben, die die über das Echolot gewonnenen Entfernungsinformationen verwenden. Einige Kleinigkeiten funktionieren schon, zufrieden bin ich damit allerdings längst nicht. Leider ist die Signalqualität des Ultraschallsensors nicht ganz so doll – aber zugegeben, mehr war auch realistisch gesehen wohl nicht zu erwarten. Um mal ein Gefühl für den Sensor zu bekommen, habe ich ein einfaches Experiment gemacht, dessen Ergebnis ich hier kurz vorstellen möchte. Ich habe mein Vehikel mittig (also auf dem Punkt x=y=40 cm) in einer 80 * 80 cm großen Box eine 360°-Wende machen lassen. Dabei habe ich die zum PC gefunkten gemessenen Entfernungen zur Wand während der Drehung mit den theoretischen (also aus dem Drehwinkel errechneten) Entfernungen verglichen. Das Ergebnis zeigt das unten stehende Bild. Da der Sensor einige Zentimeter vor dem Drehpunkt des Vehikels liegt, sind gemessene und berechnete Entfernung kleiner als 40 cm. Dass die gemessenen Peaks deutlich schärfer als die berechneten sind, zeigt, dass die Entfernung teilweise unterschätzt wird. Ich bin mir nicht im Klaren warum – die Box war zumindest wirklich quadratisch. Auch die „Asymmetrie“ der Antwort ist für meinen Geschmack größer, als es eine Ungenauigkeit in der anfänglichen Positionierung des Vehikels erklären kann. Was außerdem unangenehm auffällt, ist die teilweise Zerklüftung der gemessenen Peaks (siehe z. B. bei 135°, also der zweiten Ecke der Box). Die insgesamt etwas grobe Quantisierung in der Entfernungsdimension rührt daher, dass ich nur ein Byte für die Kodierung der Entfernung verwende und ein LSB dabei 1 cm entspricht – ggf. werde ich hier noch anders Skalieren. Auf jeden Fall wird deutlich, dass mögliche Orientierungsalgorithmen Mittelungen über einen gewissen Drehwinkel verwenden müssen, sonst gibt’s Gezappel. Daran bastel ich gerade… Quellcodes, BASCOM und Matlab, poste ich dann in kürze auch endlich mal, ich will sie vorher noch aufräumen.