Bau eines autonomen Lichtfinder-Robots

ArticleCategory: [Choose a category, translators: do not translate this, see list below for available categories]

Hardware

AuthorImage:[Here we need a little image from you]

TranslationInfo:[Author + translation history. mailto: or http://homepage]

AboutTheAuthor:[A small biography about the author]

Katja ist die deutsche Redakteurin von LinuxFocus. Sie mag Tux, Computergraphik, Film, Fotografie und das Meer. Ihre Homepage befindet sich hier.

Guido ist ein langj�hriger Linuxfan und er mag Linux, weil es einem Wahlm�glichkeiten und Freiheit gibt. Man kann L�sungen entsprechend seinen eigenen Bed�rfnissen w�hlen und entwickeln.

Abstract:[Here you write a little summary]

In diesem Artikel beschreiben wir, wie man einen autonom handelnden Roboter mit Microcontroller baut, der immer versucht, zum hellsten Punkt zu laufen.

ArticleIllustration:[One image that will end up at the top of the article]

ArticleBody:[The main part of the article]

Einf�hrung

Vor zwei Jahren haben wir in LinuxFocus einen "Linux gesteuerten gehenden Roboter" vorgestellt. Er war besonders in seinem Design, da er auf Beinen lief und keine konventionellen Motoren besa�. Dies war ein sehr interessanter Aspekt dieses Roboters, er war jedoch sehr langsam, verbrauchte viel Strom und erforderte viele spezielle Teile und F�higkeiten, um ihn zu bauen.

Das Design unseres neuen Roboters ist ganz anders. Er ist billig und man kann ihn mit Teilen bauen, die es fast �berall auf der Welt geben sollte. Es ist ein autonomer Roboter, der von einem AVR Microcontroller gesteuert wird. Als ein autonomer Roboter (der nicht von einer Person gesteuert wird), haben wir ihn so programmiert, da� er zur hellsten Stelle in einem Raum rennt.

Die Mechanik

Der kleine Getriebemotor von conrad

Ein modifizierter Standardservomotor, um als Motor arbeiten zu k�nnen. Dies ist wahrscheinlich die beste L�sung, aber wir hatten die Idee erst, als der Roboter schon fertig gebaut war.

Der Roboter hat nur zwei R�der, die von zwei unabh�ngigen Motoren angetrieben werden. Das dritte Rad ist ein Tischtennisball. Dies erm�glicht es dem Roboter, sich auf der Stelle zu drehen. Wir haben Gummir�der von altem Spielzeug benutzt, aber du mu�t nicht dein altes Spielzeug auseinander nehmen. Der Deckel eines Marmeladenglases mit einem Gummi drum, gibt ebenfalls ein sehr nettes Rad.

F�r einen autonomen Roboter ist es nat�rlich wichtig, da� er mit Batterien arbeiten kann. Da der Microcontroller mit 4.5V l�uft, m�ssen die Motoren auch mit 3-4.5V arbeiten. Sie d�rfen auch nicht zu viel Strom ziehen, da sonst die Batterien und die Elektronik zu gro� und zu schwer werden. F�r das Design haben wir einen integrierten Motortreiberchip namens l293d benutzt. Der l293d Motortreiberchip kann Spitzenstr�me bis zu 0.5A verkraften. Die Motoren sollten deshalb im schlimmsten Fall weniger als 0.5A verbrauchen.

Wir haben zwei kleine Getriebemotoren von Conrad (www.conrad.de, Teilenummer: 242802) benutzt, aber du kannst auch jeden anderen kleinen Motor mit Getriebe benutzen. Tats�chlich denken wir jetzt, da� die beste L�sung ein Standard-Servomotor gewesen w�re, so wie sie f�r Fernsteuerungen von kleinen Booten, Autos oder Flugzeugen benutzt werden. Normalerweise k�nnen diese Servomotoren sich nur in einem bestimmten Winkel drehen, aber man kann die Getriebebox des Servos �ffnen, den Stopper herausnehmen und das Potentiometer und die Elektronik entfernen. Es ist ein perfekter kleiner starker Motor und Servomotoren sind leicht zu bekommen.

Um den Roboter zu bauen, montiere die Motoren unter ein kleines Holzbrett (12cm x 9cm) und bringe sie in der Mitte an, so da� die Hauptlast auf den beiden Achsen liegt. Das dritte Rad, der Tischtennisball, darf nur einen kleinen Teil des Gewichts des Roboters �bernehmen, damit er leicht in seiner "Halterung" gleiten kann (siehe Abbildungen).

[motor on wooden board 1]

Die Halterung des Tischtennisballs ist der Deckel einer kleinen Plastikflasche, die gerade exakt die richtige Gr��e hatte.
[pill box]

Damit der Roboter l�uft, haben wir drei AAA Batterien verwendet. Bringe die Batteriehalterungen wie unten gezeigt an. Die Batterien sind recht schwer, pa� auf, da� die Hauptlast auf den R�dern liegt und nur ein kleiner Teil auf dem Tischtennisball. Man kann einen An-/Ausschalter f�r den Roboter irgendwo an der Seite anbringen.

[position of the batteries]

Sensoren

Wir geben unserem Roboter zwei Typen von Sensoren:

Ber�hrungssensoren: auf diese Weise wei� der Roboter, wenn er an ein Objekt gesto�en ist
Lichtsensoren: damit der Roboter die hellste Stelle finden kann

Die Ber�hrungssensoren sind einfache Schalter aus Stahldraht. Wir haben sie so gebogen, wie im Bild unten zu sehen ist:
[steel wire]

Die vier Ber�hrungssensoren werden mit einer Schraube an den Ecken des Holzbretts befestigt.

Wenn der Roboter an ein Objekt st��t, dann ber�hrt der Stahldraht (2, siehe die Abbildung unten) einen zweiten Draht an dem Brett (3) und dies schlie�t eine elektrische Verbindung zwischen Stahldraht und Draht auf dem Holzbrett.

Um zu verhindern, da� der Stahldraht sich verbiegt, wenn der Tischtennisball nicht in seiner Halterung ist, haben wir ein kleines Holzst�ck (1) unter dem Brett hinzugef�gt. Dieses Holzst�ck mu� 5mm �ber den Boden sein, wenn der Tischtennisball in seiner Halterung sitzt.
Der Stahldraht sollte 5-7mm �ber dem Boden enden.
[touch sensors]

Die Lichtsensoren sind drei Fotowiderst�nde. Wir haben Pappe zwischen die Fotowiderst�nde gestellt, so wie im Bild unten gezeigt. Die Pappe erzeugt Schatten auf den Widerst�nden, wenn das Licht von der Seite kommt. Nur wenn das Licht genau von oben kommt, liefert es einen gleichen Betrag an Licht auf alle drei Sensoren. Durch Vergleichen der Werte der drei Sensoren kann der Roboter entscheiden, in welche Richtung er gehen soll.

Du kannst die drei Fotowiderst�nde auf ein kleines Experimentierbrett (diese Bretter mit vielen L�chern) l�ten und das ganze mit einer einzigen Schraube auf dem Roboter befestigen.

Wie man die Sensoren und die zwei Motoren mit der Schaltung und dem Microcontroller verbindet, wird weiter unten erkl�rt. Jetzt, wo die mechanischen Teile fertig sind, la�t uns das "Gehirn" des Roboters anschauen.

Die Schaltung

Wir benutzen einen AT90S4433 Microcontroller als "Gehirn" unseres Roboters, aber das "Gehirn" kann nicht direkt genug Kraft liefern, um die Motoren anzutreiben. Das ist der Punkt, wo der L293D Motortreiberchip ins Spiel kommt. Der Chip enth�lt vier digitale Ausgangsverst�rker mit Extra-Schutzdioden, um gegen hohe, durch Spulen eines Motors induzierten Spannungen zu sch�tzen. Jeweils zwei dieser Ausgangsverst�rker k�nnen benutzt werden, um einen Motor anzutreiben. Auf diese Weise ist es m�glich, den Motor links und rechtsrum zu drehen.
l293d

Wir packen einen Motor zwischen output 1 und output 2 und den anderen zwischen output 3 and output 4. Die enable pins des Chips k�nnen zur Steuerung der Geschwindigkeit der Motoren verwendet werden, wenn wir Pulse von variabler L�nge an die enable pins senden.

Der Rest der Schaltung ist sehr einfach: Wir benutzen wieder den Atmel AT90S4433 Microcontroller. Du kennst den Microcontroller bereits aus fr�heren LinuxFocus-Artikeln. Seine analogen Eing�nge k�nnen zum Messen des Lichts der Fotowiderst�nde benutzt werden und die Ber�hrungssensoren k�nnen direkt mit den digitalen Eingangsleitungen verbunden werden, wie unten gezeigt.

Mehr Informationen �ber die Details des Microcontrollers finden sich in Guidos M�rz 2002 Artikel: Programmierung des AVR Microcontrollers mit GCC.

Die Schaltung arbeitet mit 4.5V. Drei AAA Batterien sind deshalb ausreichend, um den Roboter zum Laufen zu bringen.

Jetzt w�re die Schaltung unseres autonomen Roboters fertig. Was machst du jedoch, wenn er nicht so l�uft, wie erwartet, weil etwas mit der Software nicht stimmt? Du kannst nichts sehen. Du kennst die Werte der Lichtsensoren nicht, du wei�t nicht, warum die Robotersoftware die eine oder andere Entscheidung getroffen hat. Was wir brauchen. ist eine Art Ausgabebildschirm oder -anzeige, um zu verstehen, was unser Roboter macht. Die RS232 Schnittstelle ist f�r diesen Zweck gut geeignet. Wir k�nnen die Werte von Variablen ausdrucken und k�nnten sogar mit dem Roboter kommunizieren. Wir wollen es nicht die ganze Zeit anschlie�en, aber wir brauchen es zum Debuggen. Es macht deshalb Sinn, den max232 und andere Teile, die f�r die RS232 Verbindung gebraucht werden, auf ein separates Board zu packen und nur dann anzuschlie�en, wenn es gebraucht wird:

Die kompletten Eagle Schaltungsdiagramme und Boardlayouts k�nnen am Ende des Artikels zusammen mit der Software f�r den Roboter heruntergeladen werden. Wir beschreiben das Boardlayout hier nicht. Du kannst es in Eagle sehen. Die Schaltung ist klein genug, so da� sie zwischen die Batterien pa�t.

Unten ist eine Zeichnung, wo du sehen kannst, welcher Ber�hrungssensor auf welcher Seite des Roboters mit welchem Pin in der Schaltung verbunden ist. Die Zeichnung zeigt auch, wie man die Motoren verbindet. Die Polarit�t der Motoren ist so gew�hlt, da� der Roboter vorw�rts laufen w�rde (in die Richtung des Pfeils), wenn +3V am "+"-pin angeschlossen w�ren und Erde (GND) am "-"-pin. 1y bis 4y sind die Namen der Pins auf dem l293d.

Die Software

Wir wollen hier nicht gro� ins Detail gehen. Das Hauptprogramm kann in der Datei linuxrobot.c (Download der Software am Ende des Artikels) gefunden werden. Das Programm enth�lt eine Menge Kommentare und sollte f�r einen C-Programmierer leicht zu lesen sein. Die Hauptschleife �berpr�ft zuerst die analogen Werte der Fotowiderst�nde durch dreimaliges Laufenlassen des internen analog zu digital Umwandlers des Microcontrollers in single shot Conversionsmode. Danach werden die Ber�hrungssensoren �berpr�ft. Wenn einer der Ber�hrungssensoren angesto�en worden ist, bekommen er Priorit�t �ber die Lichtsensoren, weil der Roboter wahrscheinlich auf ein Hindernis gesto�en ist. Der Roboter dreht den Motor f�r einige Millisekunden in die entgegengesetzte Richtung zu dem Ber�hrungssensor, der angesto�en ist. Wenn kein Ber�hrungssensor angsto�en ist, dann werden die Fotowiderst�nde miteinander verglichen. Dieser Vergleich wird in der Funktion compare_with_tol() durchgef�hrt, wo wir einen Wert gegen einen Durchschnittswert von zweien vergleichen. Um zu vermeiden, da� wir von zu viel "Rauschen" beeinflu�t werden, sagen wir, da� zwei Werte gleich sind, wenn ihr Unterschied weniger als 5% betr�gt.

Basierend auf dem Vergleich der Fotosensoren k�nnen wir dann entscheiden, welcher Motor gedreht werden mu�. Da wir nur zwei R�der haben, k�nnen wir den Roboter auf der Stelle drehen durch das schnellere Drehen eines Motors oder durch das Drehen in die entgegengesetzte Richtung. Da der Microcontroller die Messung sehr schnell einige Male pro Sekunde wiederholt, erscheint die Bewegung des Roboters als kontinuierlich, auch wenn wir einen Motor f�r einen Bruchteil einer Sekunde anhalten, um ein bi�chen nach links ode rechts zu drehen.

Alles zusammensetzen

Wenn du die Elektronik zusammenbaust, ist es immer eine gute Idee, sie schrittweise zu testen. Auf diese Weise kann man leicht m�gliche Fehler eingrenzen.

Es sind drei verschiedene Testpogramme im linuxrobot Softwarepaket (Download am Ende des Artikels) dabei. Das Programm ledtest l��t die zwei LEDs blinken. Du l�dst es mit dem Befehl "make ledtestload". Dies kompiliert das Programm und l�dt es in den Microcontroller. Die zwei LEDs sollten sofort anfangen zu blinken, sobald das Programm geladen ist. Wenn dieser Test erfolgreich ist, kannst du sicher sein, da� der Microcontroller mit seinem Oscillator und die Verbindung zum ladene der Software funktioniert.

Als n�chstes kommt das Motortestprogramm. Dieses Testprogramm implementiert einen "elektronischen Gummiball". Du l�dst es mit dem Befehl "make motortestload". Das Motortestprogramm �berpr�ft die ganze Zeit die Ber�hrungssensoren und wenn einer von ihnen angesto�en wurde, bewegt sich der Roboter etwas von dem angesto�enen Sensor weg. Wenn du den Roboter mit deiner Hand an einer Seite anst��t, springt er zur�ck. Lege deine Hand hinter den Roboter und er springt zwischen deinen zwei H�nden vor und zur�ck, wie ein Gummiball. Wenn der Roboter diesen Test besteht, dann ist alles au�er den Lichtsensoren und der RS232 Verbindung getestet.

Das letzte Testprogramm hei�t adctest (kompiliere und lade es mit make adctestload). Das Programm testet die RS232 Verbindung, die da ist, um den Roboter zu debuggen und es testet den ADC (analog zu digital Wandler) mit den drei Fotowiderst�nden. Lade das Programm in den Microcontroller und verbinde dann den Adapter f�r die RS232 Schnittstelle zu deinen PC. Danach la� die folgenden drei Befehle in einer Shell laufen:

make ttydevinit
./ttydevinit /dev/ttyS0
cat /dev/ttyS0

Der Roboter sollte periodisch die Werte der Lichtintensit�t, die er an den Fotowiderst�nden gemessen hat, ausdrucken.

Wenn alle Tests bestanden wurden, kannst du das eigentliche Programm mit "make load" in den Roboter laden. Der beste Testplatz f�r die ersten Tests ist ein Raum mit nur einer einzigen Lampe in der Mitte. Der Roboter sollte einfach gerade in die Richtung der Lampe laufen und dort anhalten.

Es ist wirklich lustig zu sehen, wie der Roboter sich dreht, wenn du ihn mit dem R�cken zur Lichtquelle gewandt auf den Boden stellst und wie er Schatten vermeidet.

Probleme und Verbesserungsm�glichkeiten

Wir haben diesen Roboter als kleines Experiment gestartet. Es hat Spa� gemacht, einen autonomen Roboter zu bauen, der selber Entscheidungen treffen kann und keine Datenverbindung zu einem PC braucht. Das Programm, da� im Linux-Roboterpaket enthalten ist und du weiter unten im Artikel herunterladen kannst, ist immer noch klein und einfach, aber es macht, was wir wollten: Der Roboter l�uft zur hellsten Stelle.

Wir w�rden gerne ein paar Dinge erw�hnen, die als Ausgangspunkt f�r die weitere Entwicklung genommen werden k�nnten:

Die Ber�hrungssensoren werden nur in eher gro�en Intervallen (ein paar ms) �berpr�ft, was die Antwortsm�glichkeiten des Roboters begrenzt. Sie sollten �fter �berpr�ft werden.
Wenn einer der Ber�hrungssensoren gedr�ckt ist, dann erh�lt dies Priorit�t �ber alle anderen Dinge und der Roboter bewegt sich f�r ein paar 100 Millisekunden in die entgegengesetzte Richtung. Wenn ein anderer Sensor w�hrend dieser Zeit gedr�ckt wird, wird dies momentan ignoriert.
Die Sensitivit�t der Fotowiderst�nde nimmt in schlechten Lichtverh�ltnissen ab. Dies kann zu dem Effekt f�hren, da� die gemessene Differenz zwischen den Sensoren unter der im Programm hartcodierten Schwelle von 5% liegt und der Roboter denkt, da� alle Sensoren die gleiche Menge Licht bekommen. Die Lichtwerte, die aus dem ADC kommen, k�nnten durch eine nicht-lineare Filterkurve korrigiert werden, um diesen Effekt zu kompensieren.

Momentan ist das linuxrobot Programm klein und einfach, du solltest daher in der Lage sein, es zu verstehen und vielleicht weiterzuentwickeln. Es braucht nur 50% des Speichers des 4433 Microcontrollers, d.h. du kannst noch eine Menge Dinge hinzuf�gen.

Das Gute an diesem Roboter ist, da� die Hardware recht generisch ist: Es sind einfach zwei Motoren und einige Sensoren, befestigt an einem Microcontroller. Alle Logik ist in der Software implementiert. Das bedeutet, da� du durch Ver�ndern der Software fast alles, was du willst, ver�ndern kannst.

Hier ist ein Bild des Roboters in Testposition. Wir haben einige post-it Bl�cke untergelegt, damit er nicht wegl�uft. Die rs232 Verbindung ist zu Debuggingzwecken verbunden:

... und der fertige Roboter, wie er nach Licht sucht....:

Referenzen

LinuxFocus M�rz 2002 Artikel 231: Programmierung des AVR Microcontrollers mit GCC
linuxrobot-0.1.tar.gz: Die Software und Schaltbilder im Eagleformat
Downloadseite f�r diesen Artikel : Das Datenblatt f�r den l293d und m�gliche zuk�nftige Updates der linuxrobot Software finden sich hier.