Infrarot Näherungssensoren

Es ist schon einige Zeit her, dass ich mein Vehikel an den Seiten vorne und hinten mit Näherungssensoren ausgestattet habe. Deren Erforderlichkeit hatte sich recht schnell aus meinen ersten Navigationsversuchen ergeben. Ich hatte zunächst mit einigem Aufwand versucht, während einer Drehung aus den verschiedenen vom Echolot gemessenen Entfernungswerten den Winkel, den das Vehikel aktuell zur Wand hat, zu bestimmen. Daraus hätte man dann eine neue Bewegungsrichtung von der Wand weg ableiten können. Das ist leider nur in der Theorie einfach, in der Praxis multiplizieren sich verschiedene Unzulänglichkeiten derart, dass im Falle meines Vehikels dieses Verfahren zwar manchmal, aber längst nicht immer funktioniert. Ich habe gerade keine Lust, auf Details einzugehen, im Endeffekt zeigte sich, dass ich eine Wand, die nahe und tendenziell parallel zum Vehikel verläuft, nicht sicher aus der Echolotinformation erkennen kann. Damit war klar, dass ich an den Seiten Näherungssensoren benötigte, wobei ich allerdings eine binäre Information über den Abstand für ausreichend erachtet habe (Wand oder nicht Wand, das ist hier die Frage). Ich habe mich für eine Infrarot-Variante auf Basis des IS471F (Datenblatt: [link], relativ günstige Bezugsquelle: [link]) entschieden. Der Sensorbaustein enthält neben einem IR-Detektor dessen Auswertungselektronik und die Ansteuerungselektronik für eine extern benötige IR-LED (hier verwendet: Siemens LD274, Datenblatt: [link]). Das Licht einer angeschlossenen LED wird von der sensorinternen Logik mit ca. 8 KHz moduliert, nur reflektiertes Licht dieser Modulation wird von dem Sensor als Signal aufgefasst, im Ergebnis ist er somit recht immun gegen Fremdlicht. Um einstellen zu können, ab welchem Abstand der Sensor schaltet, habe ich den Vorwiderstand für die LED als Spindeltrimmer ausgeführt. Somit kann ich den LED-Strom, damit deren Leuchtstärke und also auch die vom Hindernis reflektierte Lichtmenge variieren. Leuchtet die LED heller, werden also schon weiter entfernte Hindernisse erkannt. Wie sich bei Versuchen zeigte, führt der recht große Öffnungswinkel des Sensors dazu, dass auch Hindernisse detektiert werden, die sehr schräg zur Fahrzeugseite verlaufen. Um dieses Phänomen einzuschränken, habe ich die Sensoren mit kleinen Kappen versehen, die den Sensor seitlich etwas abschatten. Den konkreten Aufbau am Vehikel zeigen die folgenden drei Fotos.
Ergebnisse des ganzen Aufwandes? Naja. Ich habe zwischenzeitlich begonnen, mit der kamerabasierten Navigation zu spielen (dazu bald mehr), weshalb die Experimente mit dem Ultraschall- und den IR-Sensoren vorerst in den Hintergrund getreten sind. Ich kann deshalb nur in aller Kürze von einigen Problemen berichten, die die IR-Sensorik hat. Ein (vorhersehbares) Problem, das ich (dennoch) erheblich unterschätzt habe, ist die Abhängigkeit der Detektionsleistung der Sensoren von der spektralen Reflektanz („Farbe“) der Hindernisoberfläche. Wenn man die Sensoren anhand einer weißen Fläche auf eine Entfernung einstellt, kann eine blaue Fläche dazu führen, dass der Sensor sich nochmal um 50% der Strecke nähern muss, um zu schalten. Außerdem verfügt der Sensor über eine Hysterese, die in vielen Fällen zwar sicherlich sinnvoll ist, mich hier aber eher stört. Im Ergebnis schaltet er bei Annäherung bei einem bestimmten Abstand, bei anschließender Entfernung in der gleichen Achse aber erst deutlich später wieder zurück.

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.

Basisstation im 19-Zoll-Einschubrahmen (Kameraempfänger und Netzteil)

Jetzt sind auch die anderen beiden Module, Netzteil und Funkkameraempfänger, fertig. Die Bilder unten zeigen somit den vorläufigen Endzustand meiner Basisstation. Zu den beiden neuen Modulen ist wenig zu sagen. Der Kameraempfänger befand sich ja funktionsfertig in einem geschlossenen Gehäuse, ich habe dieses Gehäuse nur auf eine Eurokarte geschraubt und diese dann mit einer mit passenden Löchern versehenen Frontplatte verbunden. Die Antennenbuchse des ursprünglichen Gehäuses ragt direkt durch die Frontplatte hindurch. Da der Videoausgang sich auf der der Antenne gegenüberliegenden Seite befindet, habe ich diesen per Kabel zur Frontplatte verlängert. Ich habe mir in diesem Falle die Mühe gespart, ein Netzteil selbst zu bauen, ich habe mir ein billigst (3,95 €) Schaltnetzteil von Pollin besorgt (klassischer Restposten, gibt’s schon nicht mehr), und auch dieses auf eine Eurokarte geschraubt. Es liefert mir -5V, 5V und 12V mit ausreichender Belastbarkeit. Mit einer Frontplatte, einem Hauptschalter, einer Betriebs-LED und dem entsprechenden Wannenstecker für den Bus versehen, habe ich somit ein geeignetes Netzteilmodul.

Basisstation im 19-Zoll-Einschubrahmen (PC-Interface)

Nachdem ich die letzten eineinhalb Wochen für den Besuch zweier Tagungen verwendet habe, komme ich jetzt endlich wieder dazu, an meinem Roboter-Projekt weiter zu arbeiten. Ich habe heute den Umbau des PC-Interfaces der Basisstation abgeschlossen. Wie die Bilder zeigen, befindet sich das Interface jetzt - wie geplant - in einem 19-Zoll-Einschubrahmen. Das rechte Bild gibt einen Eindruck vom Aufbau. Die Platine ist mittels „Klötzchentechnik“ mit der Frontplatte verbunden – nicht schön aber selten. Ich habe darauf verzichtet, die einzelnen Module auf der Rückseite über die für dieses Gehäusesystem eigentlich vorgesehenen Stecker zu verbinden, stattdessen verwende ich einfache Wannenstecker. Die entsprechenden Gegenstücke gibt es als Quetschverbinder für Flachbandkabel, und da ich natürlich mehrere Verbinder auf ein Kabel setzen kann, ergibt sich somit eine einfache Möglichkeit ein Bussystem aufzubauen. Nach dem jetzigen Stand findet über diesen Bus nur die Verteilung der Versorgungsspannungen statt. Die beiden noch fehlenden Module (Kameraempfänger und Netzteil) sind in Arbeit und hoffentlich auch im Verlauf der nächsten Woche fertiggestellt.

Ultraschall

Das Ultraschallmodul zur Abstandsmessung ist mittlerweile da, montiert, angeschlossen und in Funktion. Die mechanische und elektrische Integration war denkbar simpel. Ich verwende das SRF05 Modul von Devantech [link], in Deutschland vertrieben durch robotikhardware.de [link]. Die Fotos zeigen, wie ich das Modul angebaut habe: es ist auf eine Lochrasterplatine geschraubt, in die Platine sind rechts und links oben zwei Elemente einer doppelreihigen Buchsenleiste gelötet. Auf der Hauptplatine befinden sich als Gegenstücke entsprechend zwei gewinkelte Pfostenstecker. Über die Kontakte der einen Seite ist das Ultraschallmodul elektrisch mit der Hauptplatine verbunden. Da das Modul leicht und keinerlei mechanischen Belastungen ausgesetzt ist, ist dies eine praktikable Befestigung, ich kann das Modul somit einfach abziehen. Sollte ich doch mal den Akku wechseln wollen, wäre das von Vorteil, dieser ist nämlich (ohne Rumgeschraube) nur von vorne zugänglich. Wie ich das Antwortsignal des Moduls softwareseitig auswerte, wird man in Bälde dem Quellcode entnehmen können. Schonmal in Kürze: der Objektabstand wird von dem Ulstraschallmodul in der Länge eines Antwortpulses kodiert. Also löse ich bei jedem Flankenwechsel dieses Signals einen Interrupt aus, und messe mit Timer0 des AVR (ja, ist nur ein 8 Bit Timer, reicht aber an Genauigkeit für meine Zwecke) den Abstand zwischen den Interrupts (d. i. Flankenwechseln). Erfreulicherweise verhält sich das Modul einigermaßen linear, sodass ich die gemessene Zeit schlicht über einen (empirisch ermittelten) Faktor in den Abstand umrechnen kann. Das Ergebnis verschicke ich dann per Funk an die Basis. Funktioniert prima.

Basisstation

Auch wenn ich hier jetzt schon länger nichts habe von mir hören lassen, habe ich natürlich dennoch fleißig weitergearbeitet. Zu sehen gibt es heute mal ein Bild von meiner "Basisstation", also dem Interface zwischen PC und Vehikel. Der Aufbau ist aktuell noch provisorisch, bei Zeiten werde ich alles (Netzteil, Basisstation, Funkkameraempfänger) zu Modulen für ein 19-Zoll Einschubgehäuse umbauen.
Die bidirektionale Kommunikation zwischen Vehikel und PC funktioniert mittlerweile, das Prinzip dabei ist folgendes: Der PC sendet per RS-232 an die Basisstation Datenpakete à 16 Byte. Darin sind bisher die Schrittfrequenz für beide Motoren und die Stellung der Kamera kodiert (ich habe also noch einige Bytes übrig, um anderes zu übertragen). Die Basisstation sendet ein empfangenes Paket dann per Funk weiter an das Vehikel. Das Vehikel reagiert entsprechend der Befehle und antwortet seinerseits mit einem 16 Byte großen Datenpaket. Dieses wird wiederrum von der Basisstation über die serielle Schnittstelle an den PC übertragen. Darin enthalten sind "sensorische" Informationen, zum einen über die Akkuspannung, bald außerdem das Signal eines Ultraschallsensors, mit dem ich den Abstand zu Hindernissen messen möchte. Ein Vorteil dieser einfachen Kommunikationsform ist, dass die Updaterate der Datenpakete vom PC bestimmt wird: ich kann viel oder wenig Pakete pro Zeit verschicken. Da die Antwort des Vehikels durch den Empfang eines Paketes getriggert wird, ist somit auch die Antwortrate definiert. Im Moment arbeite ich mit einer Rate von etwa 100 Hz, d.h. ich verschicke ca. 100 Datenpakete pro Sekunde (man stelle sich das mal per Post vor...), und bekomme also auch 100 zurück. Daraus resultiert somit eine Reaktionslatenz des Vehikels von maximal etwa 10 ms - meiner Einschätzung nach ausreichend für die Maximalgeschwindigkeit, von der ich z. Zt. ausgehe. Um auf die Schnelle mal eine einfache Ansteuerung per Computer zu realisieren, habe ich ein paar kleine Matlab-Funktionen geschrieben, die mir die jeweils gewünschten Befehle per RS232 verschicken und die Antwortpakete einlesen und auswerten. Auf die Dauer ist Matlab natürlich zu lahmarschig, mittelfristig werde ich also auf eine andere Entwicklungsumgebung umsteigen. Wenn die Software insgesamt (also auch der Bascom-Code für Vehikel und Basisstation) "rund" ist, werde ich alles hier veröffentlichen – noch ist der Code definitiv zu schmutzig (ich bin da etwas gênant).
Neben der Computersteurung beitet die Basisstation außerdem einen "manuellen Modus", bei dem ich das Vehikel per Hand unabhängig vom PC steuern kann - nur für den Fall, dass die autonome Navigation irgendwann mal in eine Sackgasse geführt hat. Dazu habe ich zwei Joysticks (so Billigdinger für Gamecontroller) verwendet, allerdings benutze ich pro Steuerkreuz nur eine Dimension, mit der ich dann jeweils ein Rad aktiviere. Ich hatte erst eine Version mit nur einem Joystick aufgebaut, weil die Dinger aber sehr unpräzise sind, mangelte es dabei etwas an "Freude am Fahren". Jetzt steuert man das Vehikel wie einen Panzer - zumindest glaube ich als alter Zivi, dass man einen Panzer so steuert.
Noch ein paar Worte zur Technik: als µC verwende ich in hier einen AVR Mega162. Da dieser keine A/D-Wandler hat, digitalisiere ich das Joysticksignal mittels eines PCF8591, der über I2C am AVR hängt. Das sieht auf den ersten Blick etwas ungeschickt aus, schließlich hätte ich ja einfach einen Mega32 mit integrierten ADCs verwenden können. Der Grund, es dennoch so zu machen, ist schlicht: den Mega162 hatte ich noch rumliegen, außerdem wollte ich seit längerem mal was mit dem PCF8591 machen, so bot sich diese Variante an.
So, jetzt warte ich nur noch, dass der Ultraschallsensor endlich bei mir eintrifft, dann kann’s weitegehen. Langsam wird’s spannend…

Funky!

Die Funkverbindung steht. Zwar habe ich noch kein endgültiges Protokoll entwickelt, bin aber immerhin schon mal sehr zufrieden, dass ich beliebige Daten drahtlos zwischen Vehikel und Basisstation übertragen kann – und zwar bidirektional. Es existieren im Netz mittlerweile einige BASCOM-Codefragmente, die die Ansteuerung der RFM12-Module bewerkstelligen. Die Software für meine erste Testfunkstrecke habe ich aus solchen Beispielprogrammen zusammengestöpselt, es waren nur kleinere Anpassungen an meinen Aufbau nötig. Wer einfach nur an Beispielcodes interessiert ist, bemühe google mit der entsprechenden Suchanfrage [link], so habe ich es auch getan.
Hier dann auch gleich mal ein paar Bilder vom jetzigen Aufbau. Für das RFM12-Modul habe ich mir eine kleine Adapterplatine gemacht, weil dessen Anschlüsse im Rastermaß 2 mm angeordnet sind. Die Antenne für das Modul habe ich mir aus dem obersten Glied einer alten Teleskopantenne gebastelt, ich habe dieses auf λ/4 ≈ 173 mm (f=433 MHz entspricht ca. λ=0.69 m) gekürzt und in einen dazu aufgebohrten M3 Sechskantbolzen gelötet. Wie man sieht, ragt aus der Platine eine M3 Schraube, auf die die Antenne geschraubt werden kann. Über eine Lötfahne auf der Platinenunterseite ist die Schraube - und damit die Antenne - an den Antennenpin des Moduls angeschlossen. Ansonsten befindet sich auf der Platine mittlerweile ein zweizeiliges LCD und ein PCF8574 über den ich (bisher nur) zwei Tasten abfrage. Der Aufwärtswandler, den ich für das Kameramodul aufgebaut habe, ist aus weiter unten genannten Gründen unbenutzt, ich werde ihn vorerst nicht abreißen, denn man weiß ja nicht, wozu man den nochmal zu gebrauchen kann.

Maximale Autonomie :)

Hier mal ein erstes kleines Video meines Vehikels in Bewegung. Das Vehikel ist im Moment in höchstem Maße autonom, es fährt stumpf seinen Weg ab, ohne sich auch nur im geringsten um seine Umwelt zu kümmern... im Ernst: ich habe es zum Testen so programmiert, dass es 500 mm geradeaus fährt und dann eine 90° Wende macht. Daraus resultiert das Verhalten, das man in der rechten Bildhälfte des Videos sehen kann. Die linke Bildhälfte zeigt den ganzen Vorgang parallel aus Sicht der Vehikelkamera - dies ist also die eigentlich interessante Information. Die Bildqualität ist im Original etwas besser als der Film vermuten lässt - aber trotzdem noch schlecht genug.

Nur der Vollständigkeit halber.

Es ist nun nichts besonderes, aber ich poste trotzdem noch schnell ein Bild (jaja, ich weiss, die Qualität ist mies...) von dem In-System-Programming (ISP) Interface für mein Vehikel. Ich verwende die STK200/300 kompatible Variante für den Druckerport, der Schaltplan findet sich z. B. hier [link]. Da beim Mega32 die Pins für das ISP-Interface direkt nebeneinander liegen, habe ich die Pins für mein Interface ebenso angeordnet - das minimiert den Verdrahtungsaufwand am Controller. Das Bild zeigt den fertigen Programmieradapter, oben links sind zwei Aufnahmen von der Schaltung, bevor ich sie mit Schrumpfschlauch eingepackt habe. Der Aufbau war simpel genug, um auf Anhieb zu funktionieren.

Umwege.

Immerhin habe ich jetzt schon mal einen Videostream der Vehikel-Kamera in meinem Computer. Das Bild unten zeigt, wie sich mein Vehikel in einem anderen Zimmer im Spiegel betrachtet - das eitle Ding. Die Bildqualität ist recht mittelmäßig, etwas besser könnte sie noch durch optimalere Beleuchtung werden. So weit, so gut. Der Weg hierhin war aber wiedereinmal steinig: Weil das Stromversorgungskabel zur Kamera unverhältnismäßig dick ist (...dafür, dass nur 9 V bei 70 mA drüber sollen) und außerdem so einen seltsamen sperrigen Knubbel hat (zu sehen im Posting vom 24.07. [link]), den ich für eine Filterdrossel hielt (von wegen HF...), habe ich das Kabel gegen ein dünneres getauscht. Das allein war schon mal nichts für schwache Nerven, ich warne Neugierige! Denn im Gehäuse sind Kamera- und Funkeinheit als separate Module enthalten, die durch eine abenteuerliche fliegende Verdrahtung verbunden sind. Ich war die ganze Zeit in Sorge, mir könnte beim Hantieren ein Kabel abreißen, ohne dass ich dann rekonstruieren könnte, wo es abgerissen ist. Mit der nötigen Vorsicht ist diese Operation aber sogar geglückt. Nach dem kleinen Umbau wollte ich testen, ob ich die Kamera (Nennspannung 7,5 – 12 V) stabil an den 7,2V des Akkus betreiben kann. Seltsam, irgendwie funktionierte der Gaincontrol dann nicht mehr richtig, hielt ich die Kamera ins Licht, übersteuerte sie total. Also habe ich die Kamera zum Vergleich wieder über das entferne Kabel an das mitgeliefertes 9 V-Netzteil angeschlossen. So funktionierte sie tadellos. Was schließe ich daraus? Ist doch glasklar: der Gaincontrol funktioniert erst bei Nennspannung, die ich ja um ca. 300 mV unterschritten habe. Also baue ich mir einen kleinen Aufwärtsschaltregler (auf Basis des TL497 [link], nettes Ding, braucht wenig externe Beschaltung), der mir aus meinen 7,2 V des Akkus 9 V macht. Der Wandler funktionierte auf Anhieb - aber der Gaincontrol der Kamera trotzdem nicht. Genaueres Messen und Nachdenken (eine Kombination, die in zahlreichen Lebenslagen wahrlich Wunder wirkt) ergab dann: der Knubbel im Kabel war keine Drossel, sondern ein Spannungsregler, der die ungeregelten 9 V des zur Kamera gehörigen Steckernetzteils auf exakt 5 V abregelt. Ich habe die Kamera also nicht mit Unter- sondern mit Überspannung betrieben, deshalb funktionierte der Gaincontrol nicht richtig. Schon mal nett, dass sie’s überhaupt überlebt hat. Im Ergebnis hätte ich mir also meinen schönen Aufwärtsregler sparen, und schlicht die 5 V, die ich für die Digitaltechnik sowieso schon habe auch zur Versorgung der Kamera verwenden können - was ich jetzt auch getan habe.

Ich fasse also noch einmal für all jene zusammen, die die Pollin Funkkamera auch verwenden wollen: man kann sie problemlos an 5 V betreiben, wenn man das Kabel tauscht. Eben dieser Umbau ist aber nichts für Anfänger. Achja, man kann die Kamera auch mit Überspannung betreiben ohne sie zu schrotten, dann funktioniert aber der Gaincontrol nicht mehr. ;)

Etappe zwei von drei

An dieser Stelle will ich kurz umreißen, was das Ziel der nächsten Etappe ist. Um es knapp zusammenzufassen: das Vehikel des jetzigen Zustandes soll nun zunächst zu einem funkferngesteuerten Auto mit Kamera werden – ja, also auch hier noch keine „Autonomie“. Dazu werde ich zunächst mal die Elektronik in ihren unproblematischen Aspekten aufbauen. Einiges ist ja schon im vorigen Posting angedeutet: Ein Atmel AVR Mega32 [link] wird als zentraler Microcontroller dienen, ein 16x2-Zeichen LCD als Ausgabeeinheit, einige Taster als Eingabeeinheit. Dabei sollten noch genügend Ports am AVR für spätere Erweiterungen - zusätzliche Sensoren neben der Funkkamera - übrig bleiben. Neuland werde ich mit der Funkverbindung betreten, ähnliches habe ich noch nie gemacht. Ich möchte RFM12 Module von HopeRF [link] verwenden. Gerade in Verbindung mit AVR µC findet man im Netz dazu schon einiges an Vorarbeiten, es wäre schön, wenn ich davon für meine Anwendung profitieren könnte. Als „straight forward“ Entwicklungsumgebung für AVRs habe ich mich sehr mit BASCOM von MCS Electronic [link] angefreundet, meiner jetzigen Planung nach werde ich es auch hier einsetzen.

So weit, so gut...

Die erste angestrebte Etappe ist erreicht: ich habe einen "fahrbaren Untersatz". Wenn der Weg dahin auch nicht ganz geradlinig war, bin ich mit dem Zwischenergebnis doch recht zufrieden. Ich habe weitere sechs Bilder gemacht, die den aktuellen Zustand dokumentieren. Wie die ersten beiden Fotos (man entschuldige die etwas dürftige Qualität) zeigen, habe ich jetzt auf das Chassis die zukünftige "Hauptplatine" montiert, die vorerst natürlich noch unbestückt ist. Hier wird sich dann bald ein AVR Mega32 befinden, sicherlich auch ein kleines LCD und ein paar Taster um verschiedene Betriebsmodi anwählen zu können, und – wichitg – ein RFM12 Funkmodul [link], über das das Vehikel mit einem PC kommunizieren soll (aber so weit sind wir noch lange nicht...). Ich habe dem Roboter bereits jetzt schon eine Funkkamera gegönnt (sehr mittelmäßiges Ding, dafür aber günstig bei Pollin [link]), um mir später all zu aufwendige Umbauten zu sparen – denn dass ich irgendwann eine Kamera wollen würde, ist völlig klar :). Die Kamera ist auf einem Miniservo montiert, damit mein Vehikel auch Augenbewegungen durchführen kann. Dieser Aufbau ist nach meinem Geschmack noch nicht optimal, ich werde sehen, ob das unter Funktion so bleiben kann.
Auch das "tiefergelegte" Hinterrad sei hier nochmal gezeigt. Das Tiferlegen habe ich einfach mit zwei PVC-Platten realisiert. In dem sich ergebenden Zwischenraum hat jetzt die Steckverbindung von Akku und Elektronik Platz.
Außerdem gibt es noch zwei Bilder vom Getriebe. Das erste zeigt im wesentlichen den Aufbau: Eine Alu-Grundplatte ist über vier Sechskantbolzen (hier kaum zu sehen) am Chassis befestigt, an dieser Platte ist der Schrittmotor angeflanscht. Wie man sieht, ist das rechte Loch der Motorbefestigung ein Langloch, um später den Eingriff des Ritzels in das Zahnrad justieren zu können. Das Hauptzahnrad sitzt auf einer 4mm-Achse, diese läuft in zwei gesinterten Buchsen, eine in der genannten Grundplatte, eine in der Deckplatte, die über vier Abstandsbolzen das Getriebe zum Rad hin abschließt. Ich hatte zwischenzeitlich das Problem, dass unter Last die Achsen in den Klemmbuchsen der Räder durchdrehten. Um das zu verhindern ist die Achse jetzt geschlitzt, und ein kleines Blechstück sperrt sie mittels eines glücklicherweise in den Rädern vorhandenen Schlitzes (Fischertechnik ist wirklich gut durchdacht!) – dies ist auf dem letzten Bild zu sehen.

Läuft!

Ich bin gerade mit dem aktuellen Umbau fertig geworden. Und weil ich direkt ein bisschen begeistert davon bin, dass mein Vehikel sich jetzt immerhin vernünftig über den Boden bewegen kann, veröffentliche ich doch direkt und auf die Schnelle mal ein paar Bilder. Weitere Detailaufnahmen und Erläuterungen folgen dann in Kürze.
Auch wenn jetzt alles recht schlicht aussieht, war der Bau des Getriebes durchaus nicht ganz trivial - aber dazu wie gesagt bei Zeiten mehr. Da ich für die Vorversion des Antriebes die Ritzel von den Motoren gezogen habe, habe ich mir für diesen Aufbau neue Motoren bestellt. Geeignete Zahnräder für mein Getriebe waren ausnahmsweise mal schnell und kostenoptimal (=umsonst) gefunden: in der Krims-Krams-Kiste kullerten schon seit längerem zwei wirklich schöne, sehr präzise gesinterte Metallzahnräder gleichen Moduls wie die Motorritzel herum. Sie entstammen wie mein Hinterrad (ehemals Papierandruckrolle) einem zerlegten Drucker.
Die Motoren haben ihre Position zum Chassis zwar nicht verändert (auch wenn sie jetzt anders aufgehängt sind), die Radachse ist aber nun um etwas mehr als den Radius des neuen Zahnrades nach unten verschoben. Dieses hat den positiven Nebeneffekt, dass mein Vehikel nun an Bodenfreiheit gewonnen hat. Diese Erhöhung des Chassis erforderte es natürlich auch, dass das Hinterrad „tiefer gelegt“ werden musste.

Zwei Schritte vor, einen zurück...

Der Akku, zwei Ladebuchsen und ein Schalter sind eingebaut. Dazu ist nun nicht viel zu sagen: der Schalter (1 x Um) schaltet je nach Stellung den Pluspol des Akkus entweder auf die Elektronik oder auf die rote Ladebuchse, der Akkuminuspol liegt parallel auf dem Minuspol der Elektronik und der schwarzen Ladebuchse. Damit setzt der Schalter in einer Stellung die Elektronik unter Strom, schaltet das Vehikel also ein. In der anderen Stellung ist die Elektronik ausgeschaltet, dafür kann dann der Akku über die Buchsen geladen werden, ohne dass er aus dem Vehikel herausgenommen werden muss. So weit, so unproblematisch.
Probleme habe ich mit dem Antrieb. Die ersten Tests verliefen nicht so beglückend. Erst drehten die nur geklemmten Motorachsen in den Klemmbuchsen der Räder durch, nachdem ich das im Griff hatte, zeigte sich, dass das Drehmoment der Motoren sehr hart an der Grenze für den jetzigen Aufbau ist. Zwar fährt das Vehikel ganz ordentlich über glatten Boden, sobald aber kleine Hindernisse auftauchen oder aber der Boden "ungünstiger" wird (z. B. Teppich), bleibt das Vehikel zeitweise stehen und fängt an zu zappeln, weil die Motoren ihre Schritte nicht sauber durchführen können. Und wenn Dinge so in der Grauzone zwischen gut und schlecht rumeiern, neige ich im allgemeinen dazu, sie als "schlecht" zu disqualifizieren. So auch hier. Und das heißt dann: noch mal von vorne. Ich werde den gleichen Motortyp noch mal verwenden (ich bestelle allerdings neue, sie kosten ja fast nix), dabei diesmal aber über eine Untersetzung auf das Rad gehen. Das bedeutet, dass ich zwei kleine Getriebe anfertigen muss. Genaueres weiß ich noch nicht. Kommt Zeit, kommt Rad... äh... Rat.

Hinterrad, Version Zweipunktnull

Jetzt ist das neue Hinterrad endlich montiert. Das Prinzip ist das gleiche wie bei der vorigen Version: an der Akkuwanne (ich nenne diesen Teil des Chassis jetzt mal so...) ist zunächst eine Auslegerplatte montiert. Ich habe dafür Aluminium von drei Millimetern Stärke verwendet, damit es nicht zu Instabilitäten kommt. Die Platte ist mit Messingklötzchen befestigt, wie ich sie auch schon bei der Akkuwanne eingesetzt habe (s.u.). In der Auslegerplatte befindet sich ein präzises Loch, in dem sich der Schaft einer Schaftschraube leichtgängig drehen kann - dieses stellt die Lagerung der Gabel dar. Der Gewindeteil der Schaftschraube greift in einen PVC-Block, an dem zwei Aluminiumschenkel befestigt sind und somit die Gabel bilden, in der das Hinterrad gelagert ist. Bei dieser Version sind die Schenkel deutlicher gegen den Lagerpunkt der Gabel verschoben als bei der Vorversion. Relativ zum Chassis liegt der Lagerpunkt übrigens so, dass das Rad seine Orientierung um 360° ändern kann, ohne ans Chassis anzuecken.
Die Realisierung des Hinterrades könnte dem einen oder anderen als kleiner Tipp dienen. Ich habe als Rad eine Andruckrolle aus einem alten Drucker verwendet, gleichartige Rollen habe ich schon in diversen Druckern gesehen, sie sollten also leicht zu bekommen sein. Sie haben zunächst mal den Vorteil, dass sie materialbedingt eine gute Bodenhaftung aufweisen. Meistens sind sie auf sehr präzise – aber zöllige – Achsen aufgepresst, in diesem Falle war es eine 7,93 mm dicke Achse (gemessen, ich war bisher zu faul nachzusehen, was das "nominal" für ein Maß ist). Das Loch in der Rolle hat somit auch einen Durchmesser von knapp unter acht Millimetern. Ich habe dieses Loch nun mit einer präzisen Maschinenreibahle auf 8 mm aufgerieben. Durch eine minimale Menge Fett läuft das Rad dadurch nun ganz hervorragend auf der 7,93 mm Achse. Also habe ich mir ein Stück von der Achse abgesägt, die Enden abgedreht und mit Bohrungen versehen. Somit hatte ich ein hervorragend gelagertes Hinterrad. Das kurze Stück Achse, zu erkennen auf dem letzten Bild, sitzt fest zwischen den Schenkeln der Gabel. Anlaufscheiben rechts und links verhindern, dass das Rad durch die Gabel gebremst wird.
Auf die Auslegerplatte habe ich nun auch schon mal die Motortreiberplatine montiert, die Befestigung für die – ebenfalls noch nicht vorhandene – Hauptplatine steht noch aus.
Außerdem habe ich die Akkuwanne auch noch etwas gekürzt, damit das Vehikel nicht allzu lang wird, es ist jetzt schon etwas größer geworden, als ich geplant hatte.
Achja, so ganz ausdrücklich hatte ich es ja noch garnicht gesagt: das Hinterrad funktioniert jetzt sehr zufriedenstellend, es richtitet sich immer brav auf die aktuelle Fahrtrichtung aus. Schön.

Ein Satz mit x...

... das war wohl nix. Wie die Bilder zeigen, habe ich die Hinterradaufhängung mittlerweile fertiggestellt. Das einzige Problem dabei: die Sache funktioniert nicht. Wie man insbesondere auf dem rechten Bild sehen kann, habe ich die Drehachse der Gabel (gebildet von der Schaftschraube, deren Kopf man auf der Auslegerplatte erkennen kann) und die Drehachse des Rades gegeneinander verschoben (genaugenommen 10 mm) . Die Idee dabei war, dass das Rad sich dadurch besser auf eine neue Fahrtrichtung des Vehikels einstellen kann. Genau das funktioniert aber nicht, sprich: die 10 mm sind augenscheinlich zu wenig. Wenn ich das Hinterrad per Hand um 90° gegen die Fahrzeuglängsachse verdrehe und danach das Vehikel dann geradeaus ziehe, stellt sich das Rad nicht wieder auf die Fahrzeuglängsachse ein, sondern verharrt in seiner 90°-Stellung und radiert über den Boden. Unschön. Die Lagerung der Gabelachse ist zwar nicht perfekt, aber nicht so schlecht, dass das Problem dort seine Ursache hätte. Es liegt also ziemlich sicher an dem zu geringen o. g. Versatz.
Ich werde das Ganze jetzt noch mal aufbauen und dabei die Drehachsen des Rades und der Gabel noch weiter auseinanderziehen, außerdem werde ich ein kleineres Rad verwenden – mal sehen ob’s hilft. Dann an die Arbeit...

Das vierte Rad am Wagen...

Nachdem ich mich gedanklich noch mal mit den Hinterrädern meines Vehikels auseinandergesetzt habe, bin ich zu dem Entschluss gekommen, hinten doch nur ein Rad vorzusehen - das dann natürlich mittig zum Fahrzeug angeordnet sein wird. Ich glaube nämlich mittlerweile, dass zwei unabhängig aufgehängte Hinterräder nur dann einwandfrei funktionieren würden, wenn sie auch einzeln gefedert sind. Sind sie starr aufgehängt, können geringe Unebenheit des Bodens dazu führen, dass das Rad mit schlechterer Bodenhaftung anfängt zu „schlackern“ (zu beobachten an jedem durchschnittlichen Einkaufswagen). In gewissem Maße federn zwar die Reifen, aber ich bin mir nicht sicher, ob das genügen würde, um dem Effekt vorzubeugen. Und da es mir vorerst zu aufwendig erscheint, für jedes Rad eine eigene Federung zu realisieren, werde ich das Vehikel jetzt als Dreirad aufbauen. Somit haben alle Räder immer Bodenkontakt - zumindest solange sich das Ding nicht auf die Seite oder den Rücken gelegt hat. Dieses halte ich aber für einigermaßen unwahrscheinlich, weil das Fahrwerk vorne relativ "breitbeinig" aufgebaut ist und zusätzlich der Schwerpunkt sehr tief liegt.

Schrittmotorsteuerung

Es ging nicht sonderlich gut voran, aber immerhin ist heute die Platine zur Ansteuerung der Schrittmotoren fertig geworden. Technisch gesehen ist die Schaltung "klassisch": ich verwende für die Motoren jeweils einen L297 und L298, die Beschaltung enspricht dabei im wesentlichen dem Vorschlag aus dem Datenblatt. Man hätte die Ansteuerung natürlich auch einfacher (und platzsparender) aufbauen können, diese Variante hat aber doch einge Vorteile. Die Motoren werden stromgesteuert betrieben, was sich positiv auf das Drehmoment auswirkt. Außerdem kann ich durch setzen von einzelnen Pins einfach die Richtung und Halb-/ Vollschrittbetrieb ändern. Auch das Auslösen eines Schrittes ist softwareseitig so über einen einzelnen Pin möglich. Das alles wird den Programmieraufwand für die Ansteuerung erheblich mindern.
Auf dieser Platine befindet neben den Motortreibern ein Spannungsregler, der den 5 V-Kreis für die Digitaltechnik speist. Da mein Akku nur 7,2 V liefert, habe ich einen L4940V5 verwendet, der hat eine Dropout-Spannung von max. 500 mV. Er liefert bis 1,5 A - was für die Elektronik (hoffentlich) genügen wird. Die Schrittmotoren hängen ohnehin direkt im 7,2 V-Kreis.
Wie man wohl nicht zuletzt an der etwas abenteuerlichen Anordnung der Stromsensor-Widerstände sieht, ging es mir darum, die Schaltung möglichst kompakt aufzubauen. Das machte das Verdrahten teilweise etwas anspruchsvoller, aber im Endeffekt ist es halbwegs gelungen.
Der Grund dafür, diese Platine von der (noch nicht vorhandenen) Hauptplatine zu trennen, ist, dass ich diese Baugruppe unter allen Umständen für dieses Chassis benötige, während ich den Rest variabel gestalten kann - evnt. werde ich die Hauptplatine auswechselbar machen, dann könnte ich unterschiedliche Projekte mit dem Chassis aufbauen.
Die Schnittstelle zur Hauptplatine fehlt im Moment noch. Ich weiss noch nicht genau, ob ich da ein Flachbandkabel verwende oder ein Stecksystem - mal sehen...

Einige Details

Das linke Bild zeigt im Detail, wie mittels kleiner Messingklötze die Bleche miteinander verbunden sind. Die Motoren sind mit Sechskantbolzen an den Blechen befestigt. Auf dem rechten Bild sind alle bisher verwendeten Einzelteile zu erkennen.

Der Anfang...

Die beiden Bilder zeigen den aktuellen Stand. Wie unten beschrieben befinden sich die Räder direkt an den Motoren, die Motoren sind am Chassis montiert. Man erkennt außerdem die Konstruktion der Wanne aus drei Einzelblechen. Auf den Blechen ist bisher noch die Schutzfolie, die mache ich ab, wenn alle Löcher gebohrt sind. Das linke Bild zeigt die recht geringe Bodenfreiheit des Vehikels - wie gesagt, hoffentlich kein Problen in den Umgebungen, in denen sich der Roboter bewegen soll.

Konzept

Seit langer Zeit spiele ich mit dem Gedanken, einen möglichst weitreichend autonomen Roboter zu bauen. Nachdem ich jetzt ein solches Projekt begonnen habe, möchte ich für mich in diesem Blogs dessen Entwicklung dokumentieren und festhalten.
Um die Komplexität meines ersten Projektes nicht gleich auf mehreren Ebenen bis ins Unbeherrschbare zu übersteigern, wollte ich versuchen, mit einem mechanisch einigermaßen simplen Konzept zu beginnen. Meine Wahl fiel deshalb auf ein vierrädriges System. Die Drehgeschwindigkeiten der beiden Vorderräder werden dabei unabhängig voneinander steuerbar sein. Daraus resultiert die Lenkbarkeit des Vehikels, ohne dass die Stellung der Räder zum Fahrzeug (mal abgesehen von deren Rotation...) verändert werden muss. Die Hinterräder sind einzeln drehbar aufgehängt, und stellen sich dadurch passiv auf die aktuelle Bewegungsrichtung des Roboters ein.Um den Aufwand gering zu halten, werden die Vorderräder ohne Untersetzung direkt von einem Schrittmotor angetrieben. Ich habe dazu zwei relativ kräftige Motoren preiswert bei Pollin erstanden. Die verwendeten Räder stammen aus meinem alten Fischertechnik-Bestand (der leider seit vielen Jahren auf dem Dachboden verstaubt). Praktisch ist, dass sie direkt auf eine 4 mm Achse geklemmt werden können. Die Schrittmotoren haben 4 mm Achsen, sodass ich nur die Ritzel von den Motoren abziehen musste, um die Räder montieren zu können. Leider sind die Räder nur wenig größer als die Motoren, wodurch sich nur eine geringe Bodenfreiheit des Roboters ergibt. Da er sich aber vornehmlich in artifiziellen Umgebungen bewegen soll, habe ich diesen Nachteil in Kauf genommen. Das Chassis des Vehikels bildet eine Wanne, die aus 1.5 mm starken eloxierten Aluminiumblechen aufgebaut ist. In dieser Wanne wird sich später ein 7.2V/ 3.3 Ah NiMh-Akku befinden, wodurch der Fahrzeugschwerpunkt günstigerweise recht tief liegen wird.