Vertiefung Prozessdatenverarbeitung SS Steuerung eines Asuro-Roboters. von Patrick Deuster Nicole Meuser Alexander Piel

Transkript

1 Vertiefung Prozessdatenverarbeitung SS 2007 Steuerung eines Asuro-Roboters von Patrick Deuster Nicole Meuser Alexander Piel

2 Inhaltsverzeichnis 1 Projektbeschreibung 3 2 Grundlagen Asuro Atmega8L Weitere Elemente Fototransistoren Odometriesensoren Infrarot - Schnittstelle Entwicklung Entwicklungsumgebung Linienverfolgung Zugrundeliegender Regelalgorithmus Zustand 1: Geradeaus Zustand 2: Rechtskurve Zustand 3: Linkskurve Eigentliches Asuro - Programm Überlegung zur Streckenzeichnung Odometriedaten Motoransteuerungsdaten Zeichnung der Strecke Allgemeiner Zeichenalgorithmus Winkelberechnung

3 3.4.3 Bestimmung der Zeitdauer Kurvenzeit Vektorerstellung Weitere Funktionen des rgraphers Probleme Oberäche des Programms rgrapher Fazit und Bewertung 23 Listings 24 Abbildungsverzeichnis 25 Literatur 26 2

4 1 Projektbeschreibung Ziel dieses Projekts der Vertiefungsveranstaltung Prozessdatenverarbeitung SS2007 bei Prof. Dr. Linn war es, einen Asuro - Roboter (siehe Abbildung 1 unten) zu programmieren. Dieser sollt selbständig einer Linie folgen können, auf welche er gesetzt wird. Ohne fremde Einüsse soll er diesen Parcours abfahren. Als Zusatzaufgabe versuchten wir dann später die gefahrene Strecke des Asuro auf dem PC nachzeichnen zu können. Diese Zeichnung der Strecke wurde von uns in Echtzeit realisiert. Für dieses Projekt war ein zeitlicher Rahmen von 4 Monaten vorgegeben. Wir erhielten einen bereits zusammengebauten Asuro und konnten direkt mit der Feinjustierung der Elektronik und mit der Programmierung beginnen. Abbildung 1: Asuro 3

5 2 Grundlagen 2.1 Asuro Der Asuro - Roboter (Another Small and Unique Robot from Oberpfaenhofen) wurde vom Institut für Robotik und Mechatronik am Deutschen Zentrum für Luft- und Raumfahrt (DLR) in Oberpfaenhofen entwickelt. Programmieren kann man diesen Roboter mit Hilfe von C, unter Verwendung einer speziellen Bibliothek, welche Funktionen zur Ansteuerung der einzelnen Komponenten des Asuro beinhaltet. Der Asuro ist mit einem Atmel Mikrocontroller (ATmega8L) ausgestattet. Des weiteren besitzt der Asuro folgende Komponenten: Motorik 2 Motoren, deren Geschwindigkeit und Richtung bestimmt werden kann. Jeder dieser Motoren hat eine Nennspannung von 12V, eine Leerlaufdrehzahl von Upm und einen Wirkungsgrad von 30% Sensorik 2 Lichtsensoren an der Unterseite (vorne) 6 Tastsensoren an der Vorderseite 2 Lichtsensoren für die Odometrie Sonstiges 4 Leuchtdioden zur Statusanzeige Batteriehalterung für 4 AAA - Batterien oder Akkus an der Rückseite 8 - bit Mikrocontroller ATmega8L 8 kb Flash Speicher bidirektionale Infrarot Schnittstelle Für weitere technische Details und Beschreibungen verweisen wir auf die Internetseite 4

6 2.2 Atmega8L Dieser RISC - Mikroprozessor, welcher von der Firma Atmel entwickelt wurde, arbeitet nach der Harvard - Architektur. Dem entsprechend sind Daten und Instruktionen speichertechnisch voneinander getrennt. Alle Instruktionen werden in dem 8kB Flash - Speicher abgelegt. Dieser Speicherbereich ist in zwei Teile unterteilt. Es gibt zum einen die boot section in welcher sich der Bootloader bendet und zum anderen die application section, worin das eigentliche, auf den Asuro geashte, Programm des Programmierers und alle konstanten Daten dieses Programms enthalten sind. Der ATmega8L kennt insgesamt 130 verschiedene Befehle. Alle weiteren Daten werden in einem 1kB groÿen RAM (Random Access Memory) gehalten. Dieser läuft mit vollem Prozessortakt, was 16 MHz entspricht. Des weiteren verfügt der Mikrocontroller über 3 Counter (2x8-bit Counter, 1x16-bit Counter). Der 16-bit Counter wird für die Ansteuerung der Motoren mit Hilfe der Pulsweitenmodulation (PWM) verwendet und deshalb in zwei 8-bit Counter zerteilt. Einer der 8-bit Counter ist für die Verwendung de seriellen Schnittstelle notwendig und der zweite kann vom Programmierer frei verwendet werden. 2.3 Weitere Elemente Fototransistoren Wie bereits erwähnt ist der Asuro mit zwei Fototransistoren an der Vorderseite ausgestattet (siehe Abbildung 2). Die rote LED, welche sich zwischen diesen Fotoransistoren benden, ist zur Beleuchtung des Untergrunds vorgesehen. Die Fototransistoren verarbeiten das reektierte Licht und liefern dem Mikrocontroller einen Wert zwischen 0 (dunkel) und 1023 (hell). Idealerweise rechnet man mit Dierenzen und nicht mit den Absolutwerten der Fototransistoren, da man so besser gegen äuÿere Lichteinüsse abgesichert ist. Abbildung 2: Fototransistoren 5

7 2.3.2 Odometriesensoren Mit Hilfe der Daten der Odometrie kann die Drehzahl der Räder des Asuro bestimmt werden. Zwei Lichtsensoren können dazu benutzt werden, dem Prozessor zu melden, ob sich gerade ein heller oder ein dunkler Bereich in dem Abtastfeld bendet. Hierfür gibt es verschiedene Encoderscheiben mit 8 bzw. 12 Sektoren. Der von uns verwendete Asuro hat eine Encoderscheibe mit 6 schwarzen und 6 weiÿen Feldern, also 12 Sektoren. Der Prozessor misst über einen AD - Wandler die Spannung, welche an den Lichtsensoren gerade anliegt. Wenn die Encoderscheibe 5 Umdrehung geschat hat, so hat auch das Rad eine Umdrehung zurückgelegt. Dies entspricht dann 60 Impulsen (schwarz - weiÿ - Übergängen) pro Reifenumdrehung. Abbildung 3: Odometriesensoren Infrarot - Schnittstelle Der Asuro verfügt über eine bidirektionale Infrarot Schnittstelle. Hierüber kann ein am PC geschriebenes Programm auf den Speicher des Asuro geashed werden, zum anderen können aber auch Daten an den PC zurückgesendet werden. Auf der Seite des PCs benutzen wir eine RS232 - Infrarotschnittstelle, welche an die serielle Schnittstelle angeschlossen werden kann. Über einen Seriell - USB Adapter kann diese ebenfalls verwendet werden, jedoch funktionierte dieser in unserem Projekt aus unerklärlichen Gründen nicht um ein Programm auf den Asuro zu ashen, sondern nur um in die andere Richtung mit dem Asuro zu kommunizieren. Da in der Internet - Gemeinde sehr oft gelesen werden kann, dass dieser RS232 - Receiver nicht ordnungsgemäÿ funktioniert, kann man sich noch zusätzlich einen Infrarot USB Transceiver kaufen. Bei unserem Projekt war dies jedoch nicht notwendig, da unser RS232 voll funktionstüchtig war. Abbildung 4: Infrarot - Schnittstelle 6

8 3 Entwicklung 3.1 Entwicklungsumgebung Für die Programmierung des Asuro, stand uns eine C - Bibliothek zur Verfügung. Diese mitgelieferte Bibliothek stellt eine Sammlung von Funktionen zur Verfügung, welche das Programmieren des Asuro vereinfachen sollen. Ebenfalls mitgeliefert wurde das Tool Programmers Notepad 2, mit welchem wir die Programme für den Asuro entwickelt haben. Programmers Notepad ist die Standard Entwicklungsumgebung, die bei WinAVR mitgeliefert wird. Beim Kompilieren des Codes für den Asuro, entsteht eine hex-datei. Diese Datei muss dann in des Speicher des Roboters geladen werden. Dafür haben wir das Flash-Tool verwendet. Dieses Tool überträgt die Datei über die Infrarot - Schnittstelle an den Asuro. Für die Streckeneichnung wurde Ruby, Gtk2 und die Serial Port Extension eingesetzt. Die Wahl viel nicht zufällig auf Ruby. Die Serialport Extension ermöglicht das Auslesen der Infrarot - Schnitstelle auf einfachste Weise. Da Ruby, unserer Meinung nach, auch noch eine schöne Sprache ist, entschieden wir uns das Zeichenprogramm so zu implementieren. 3.2 Linienverfolgung Um die Aufgabenstellung der Linienverfolgung zu lösen, benötigt der Asuro ein spezielles Programm. Dieses Programm muss die Werte der Fotosensoren an der Vorderseite des Asuro auswerten und dementsprechend die beiden Motoren ansteuern, damit der Roboter einer vorgegebenen Linie folgt. Hier im folgenden sollen nun dieses Programm des Asuro und der zugrunde liegende Algorithmus der Linienverfolgung detailliert erläutert werden Zugrundeliegender Regelalgorithmus Der Asuro besitzt, wie bereits erwähnt, zwei Fototransistoren, welche in einem gewissen Abstand voneinander an der Vorderseite platziert sind. Dem von uns realisierten Algorithmus der Linienverfolgung liegen zwei Prinzipien zugrunde. Zum einen gibt es die Vorraussetzung, dass die Linie, auf welcher sich der Asuro bewegen soll, immer dunkler sein muss, als deren Hintergrund (Beispiel: schwarze Linie auf weiÿem Papier). Des weiteren gehen wir davon aus, dass die Linie immer breiter ist, als der Abstand zwischen den beiden Fototransistoren. Beide Annahmen wurden von uns so getroen und können schnell geändert werden, indem einige Vergleichsoperatoren in unserem Programm umgedreht werden. Im folgenden wird jedoch von dem Normalfall ausgegangen. Die Werte beider Fototransistoren werden vom Asuro also eingelesen und miteinander vergli- 7

9 chen. Unser Regelalgorithmus unterscheidet nun drei verschiedene Zustände: 1. Fahre geradeaus 2. Fahre eine Linkskurve 3. Fahre eine Rechtskurve Je nachdem in welchem Zustand sich der Asuro bendet, steuert er die beiden Motoren der Räder an. Es handelt sich hier also um einen Dreipunktregler, da es drei verschiedene Zustände gibt. Näheres zu den verschiedenen Zuständen wird nun im weiteren hier erläutert Zustand 1: Geradeaus Der Asuro bendet sich im Zustand Geradeaus, wenn die Dierenz der Helligkeitswerte beider Fototransistoren kleiner einer vorgegebenen Konstante ist. Die Helligkeitswerte der Transistoren ist nie genau identisch, da sie hierfür von ihrer Genauigkeit her einfach nicht ausgelegt sind. Aus diesem Grunde wurde ein gewisser Delta - Bereich (DELTA_GERADEAUS) festgelegt, für den festgesetzt wurde, dass hier beide Fototransistoren dieselbe Farbe sehen und sich somit beide Transistoren exakt aus der Linie benden. Die folgende Abbildung zeigt dies noch einmal deutlich. Abbildung 5: Asuro fährt geadeaus In diesem Fall müssen beide Räder mit der gleichen Geschwindigkeit angesteuert werden und der Asuro fährt geradeaus. Die Motoren beider Räder werden hier mit dem Wert der Konstanten MAX_SPEED, also der maximalen Geschwindigkeit, angesprochen. 8

10 3.2.3 Zustand 2: Rechtskurve Ist der Wert des linken Fototransistors heller, als der des rechten Transistors, so muss der Asuro eine Rechtskurve fahren. Der linke Transistor ist in diesem Fall sozusagen von der Linie abgekommen und auf den hellen Untergrund gestoÿen. Die folgende Abbildung verdeutlicht dies noch einmal. Abbildung 6: Asuro fährt eine Rechtskurve In diesem Fall haben wir zunächst versucht, das linke Rad mehr zu beschleunigen und das rechte Rad unangetastet zu lassen. Nach einigen Überlegungen sind wir jedoch von diesem Lösungsweg abgekommen. Dieser Weg würde bedeuten, dass unser Asuro in einer Kurve mindestens genauso schnell wäre, wie auf einer Geraden, eher würde er noch weiter beschleunigen. Dies ist nicht besonders ezient, da enge Kurven mit diesem Algirthmus gar nicht erst gefahren werden können und der Roboter hier aus der Kurve iegen würde. Deshalb haben wir uns für den Weg entschieden, in einer Rchtskurve das rechte Rad abzubremsen. Die Leistung des Motors des linken Rades wird auf den maximale Wert (MAX_SPEED) gesetzt und der Roboter fährt somit eine Rechtskurve. In einer Kurve fährt der Asuro dementsprechend langsamer als auf einer Geraden, genauso wie es (hoentlich) auch jeder Autofahrer tut. 9

11 3.2.4 Zustand 3: Linkskurve In diesem Zustand wird der Asuro ähnlich wie bei der Rechtskurve angesprochen, nur mit genau umgedrehten Werten. In diesem Fall wäre der Wert des linken Fototransistors weitaus kleiner, als der des rechten Transistors. Dies ist der Fall, da der links Transistor noch auf der dunklen Linie ist, sich der rechts Transistor jedoch abseits der Linie auf hellem Untergrund bendet (siehe Abbilung). Abbildung 7: Fahrt einer Linkskurve Dementsprechend bremsen wir hier das linke Rad ab und erhöhen die Geschwindigkeit des rechten Rades auf den Maximalwert (Max_SPEED). Zu beachten ist hier noch, dass die Geschwindigkeit des linken Rades hier um einen festgesetzten Delta - Wert (BREMS_DELTA) verringert wird, bis sie irgendwann den Wert 0 erreicht. Dasselbe gilt auch für die oben erklärte Rechtskurve und das rechte Rad. 10

12 3.2.5 Eigentliches Asuro - Programm In dem Programm, welches auf den Asuro geashed wird, wird dieser Status des Motors wie oben erläutert ermittelt. Das nachfolgende Listing zeigt einen Teil dieses Programms, mit allen Konstanten. Die Abfrage des Status wird in einer Endlosschleife immer wiederholt, damit der Asuro endlos lange einer Linie folgt. Listing 1: Linienverfolgung 1 # define MAX_SPEED 150 // max. Geschwindigkeitsansteuerung der Motoren # define DELTA_ GERADEAUS 20 // bei welcher Differenz fährt er geradeaus # define BREMS_ DELTA 25 // welchen Wert er beim Bremsen abzieht int main ( void ) { unsigned int data [ 2]; // Speicher für Fototransistoren bereitstellen unsigned int speedlinks = MAX_ SPEED ; // Geschwindigkeit links... unsigned int speedrechts = MAX_ SPEED ; //... und rechts Init () ; FrontLED ( ON ); // Linienbeleuchtung einschalten MotorDir ( FWD, FWD ); // beide Motoren auf vorwärts while (1) { // Endlosschleife LineData ( data ); // aktuelle Werte der Transistoren lesen if ( abs ( data [0] - data [1]) < DELTA_GERADEAUS ) { // Geradeaus speedrechts = MAX_ SPEED ; speedlinks = MAX_ SPEED ; BackLED ( OFF, OFF ); else { if ( data [0] > data [1] ) { // Rechtskurve bremse (& speedrechts, & speedlinks ); // bremse rechts BackLED ( OFF, ON ); else { // Linkskurve bremse (& speedlinks, & speedrechts ); // bremse links BackLED (ON, OFF ); MotorSpeed ( speedlinks, speedrechts ); // Geschwindigkeit setzen return 0; 11

13 Fährt der Asuro eine Links- oder eine Rechtskurve, so wird das innere Rad mit Hilfe der selbst geschriebenen Funktion bremse abgebremst. Diese kommentierte Funktion bendet sich in dem folgenden Listing. Das innere Rad wird hier um den Wert von BREMS_DELTA abgebremst, bis es komplett auf 0 steht. Der Wert des äuÿeren Rades wird auf MAX_SPEED zurückgesetzt. Listing 2: Linienverfolgung 2 // Bremse ein Rad ab und setze das andere auf MAX_ SPEED void bremse ( unsigned int * bremsrad, unsigned int * beschleunigungsrad ) { if (* bremsrad >= BREMS_ DELTA ) { else { * bremsrad -= BREMS_ DELTA ; //... weniger Gas geben * bremsrad = 0; * beschleunigungsrad = MAX_ SPEED ; // anderes Rad auf max. Geschw. Die beiden oberen Listings zusammen genommen, ergeben unser komplettes Programm, welches zur Steuerung des Asuros auf diesen geashed wird. Hinzu kommt nur noch das Zurücksenden von Daten an den PC, was in den nachfolgenden Kapiteln näher erläutert wird. Wie man sieht ist es ein sehr kleines und äuÿerst kompaktes Programm, was auch viel Sinn macht, da die kleine CPU des Asuro mit möglichst wenig rechenaufwendigen Prozessen belastet werden sollte. 12

14 3.3 Überlegung zur Streckenzeichnung Zur Streckenzeichnung müssen Werte des Asuros an den PC zurückgeschickt werden. Hierbei sind wir auf zwei verschiedene Möglichkeiten gestoÿen: 1. Odometriedaten zur Positionsbestimmung 2. Motoransteuerungsdaten zur Positionsbestimmung Hier werden nun beide Möglichkeiten kurz erläutert und gesagt, wieso wir uns für eine von beiden entschieden haben Odometriedaten Odometrie ist die Wissenschaft der Positionsbestimmung eines Fahrzeuges anhand der Beobachtung seiner Räder. Ein Ziel dieses Projektes ist es die Strecke, die der Asuro fährt, nachzuzeichnen. Da der Asuro über Odometriesensoren verfügt, kann man mit deren Hilfe feststellen, wie sich die Räder bewegen bzw. wann ein Rad eine Umdrehung geschat hat, um dann letztendlich auf dem Laptop die Drehzahl zu berechnen und damit die Strecke nachzuzeichnen. Als Musterscheiben für die Messung der Odometriewerte haben wir folgende verwendet: Abbildung 8: Odometrie Musterscheiben Wie bei dieser Abbildung zu sehen ist, gibt es dort 12 Schwarz - Weiÿ - Übergänge. Weiterhin kann man feststellen, dass, wenn sich das Zahnrad mit der Musterscheibe 5 mal gedreht hat, sich das Rad des Asuros 1 mal gedreht hat. Somit kann man erkennen, dass das Rad bei 60 Schwarz - Weiÿ - Übergängen eine Umdrehung geschat hat. Die Odometriesensoren liefern beim Auslesen Werte zwischen 0 und 1023, je nach Helligkeit. Hier steht der Wert 0 für die maximale Helligkeit und 1023 für die maximale Dunkelheit. Diese beiden maximalen Werte werden jedoch normalerweise nie erreicht. 13

15 Für das Auslesen der Odometriedaten gibt es die Funktion OdometrieData(unsigned int *data). Dieser Funktion muss ein Speicherbereich von 2 Integerwerten übergeben werden, welcher dann mit den Werten des linken und rechten Fototransistors gefüllt wird. Das gröÿte Problem beim Auswerten der Odometriedaten war zunächst festzustellen, wann ein Schwarz - Weiÿ - Übergang stattgefunden hat, da die Werte, die vom Asuro geliefert wurden, recht nah beieinander lagen. So haben wir den Asuro zu Beginn ein Stück weit fahren lassen, um einen Maxwert und einen Minwert der Odometriewerte zu ermitteln, woraus schlieÿlich ein Mittelwert gebildet werden kann. Listing 3: Odometrie-Min-Maxwert Bestimmung /* Zuerst die Raeder einmal rund drehen lassen, um maxhell und maxdunkel der Odometriescheiben zu messen */ MotorSpeed (120, 120) ; tmpstartzeit = Gettime () ; while ( aktzeit - tmpstartzeit < 2000 ){ OdometrieData ( odo_data ); links. farbeneu = odo_data [0]; if ( links. farbeneu > maxfarbel ) maxfarbel = links. farbeneu ; if ( links. farbeneu < minfarbel ) minfarbel = links. farbeneu ; rechts. farbeneu = odo_data [1]; if ( rechts. farbeneu > maxfarber ) maxfarber = rechts. farbeneu ; if ( rechts. farbeneu < minfarber ) minfarber = rechts. farbeneu ; aktzeit = Gettime () ; /* Mittelwert der Scheibenfarbe berechnen */ links. farbemittelwert = ( maxfarbel + minfarbel ) / 2; rechts. farbemittelwert = ( maxfarber + minfarber ) / 2; Dieser Mittelwert dient dazu, um feststellen zu können, ob ein Hell - Dunkel - Übergang stattgefunden hat. Liegt ein Messwert unterhalb des Mittelwertes, wird ein heller Wert gemessen. Wird als nächstes wieder ein Wert gemessen, der zwar von dem ersten Wert abweicht, aber immernoch unterhalb des Mittelwertes liegt, hat noch kein Übergang stattgefunden, sondern die Messwerte liegen immernoch im hellen Bereich. Folgt dann irgendwann ein Wert, der oberhalb des Mittelwertes liegt, hat ein Übergang stattgefunden und dieser kann somit gezählt werden. Die gleiche Prozedur gilt auch für die Messung dunkler Werte. 14

16 Listing 4: Odometrie Übergänge void drehzahlberechnung ( struct umdrehung * rad, int identifier ){ // identifier 0 = linkes Rad, 1 = rechtes Rad OdometrieData ( odo_ data ); // Odometrie auslesen fuer das linke Rad if ( rad - > uebergaenge == 10) { /* Scheibenrad dreht sich 5 mal ( 5* 12 Übergänge ) wenn das groÿe Rad sich einmal dreht */ rad - > uebergaenge = 0; /* nach jeder Viertelumdrehung wird eine Information an den PC geschickt */ if ( identifier == 0) SerWrite (( unsigned char *) "L", 1) ; else SerWrite (( unsigned char *) "R", 1) ; /* Odometriesensorwert */ rad -> farbeneu = odo_data [ identifier ]; /* Feststellen und Zählen der hell - dunke - Übergänge */ /* Übergang nur zählen, wenn Rad vorher im entgegengesetzten Helligkeitsbereich war */ if (( rad -> farbeneu > rad -> farbemittelwert ) && ( rad -> flag == DUNKEL )){ rad - > uebergaenge += 1; rad -> flag = HELL ; else if (( rad -> farbeneu < rad -> farbemittelwert ) && ( rad -> flag == HELL )){ rad - > uebergaenge += 1; rad -> flag = DUNKEL ; 15

17 3.3.2 Motoransteuerungsdaten Im Endeekt haben wir uns, nach einigen Testläufen jedoch dafür entschieden, die Positionsbestimmung des Asuro mit Hilfe der Motoransteurungsdaten zu realisieren. Diese Daten sind die Werte, mit denen die Motoren, je nach Status der Linienverfolgung, angesprochen werden. Dies sind Werte zwischen 0 und MAX_SPEED (hier bei uns 150). Die Gründe warum wir uns für diese Art der Positionsbestimmung und icht für die Odometriedaten entschieden haben, sind hier im folgenden aufgelistet: Odometriedaten sind extrem ungenau Odometriedaten sind zu sehr von externen Einüssen abhängig (z.b. Licht) Motordaten sind bereits berechnet worden, Asuro - Programm bleibt klein Die Motordaten werden innerhalb der Endlosschleife, in welcher sich der Asuro bendet, per Infrarot an den PC gesendet. Dies geschieht mit den folgenden Zeilen Code: // Motorspeed senden if (( Gettime () - tmpsendezeit ) >=50) { Listing 5: Senden der Motorwerte sprintf ( ausgabe, "% d :% d :% ld \n", speedlinks, speedrechts, Gettime () - tmpstartzeit ); SerWrite ( ausgabe, strlen ( ausgabe )); tmpsendezeit = Gettime () ; Sendezeit wird hier benutzt, damit die Werte nicht bei jedem Schleifendurchlauf abgesendet werden. Dies würde zuviel Rechenzeit des Prozessors des Asuro benötigen und er hätte nicht mehr genügend Zeit, um seinen Regelalgorithmus kontrolliert und sicher durchzuführen. Aus diesem Grund wird nur alle 50ms der Wert der Motoren an den PC gesendet. Dieses Senseintervall kann auch anders gewählt werden, mittls Testreihen sind wir jedoch auf die 50ms gestoÿen. Bei diesem Intervall ist die Regelung noch kontrolliert möglich und es werden möglichst oft Daten an den PC geschickt. Diese Daten werden dann in dem Format linkesrad:rechtesrad:timestamp versendet. Der Timestamp gibt an, wie viel Zeit seit dem letzten Sendevorgang vergangen ist. Die Nachricht wird in unserem Programm, welches auf dem empfangenden Rechner läuft, auseinander geparst und zur Zeichnung der Strecke weiter verwendet. Wie dies passiert, darauf wird in dem folgenden Kapitel eingegangen. 16

18 3.4 Zeichnung der Strecke Allgemeiner Zeichenalgorithmus Zunächst werden zwei Attribute des Asuros deniert. Wir nehmen an dass der Asuro eine bestimmte Position hat, die seinen Aufenthaltsort in X und Y - Koordinaten bestimmt. Ebenso besitzt er eine Ausrichtung, die, in Form eines Winkels angibt, in welche Richtung er fährt. Zuerst gilt es vernünftige Startwerte für die Attribute zu nden. Hier macht es Sinn den Asuro an der Position starten zu lassen, welche die Mitte des Bildschirms bestimmt. So kann er sich in jede Richtung gleich weit bewegen, ohne aus dem Bildschirm herauszufahren. Als Startwert des Winkels nehmen wir 0 an, dass entspricht auf dem Bildschirm einer Bewegung nach rechts. Um die Ausrichtung des Asuro zu bestimmen ist es notwendig die Werte der Motorsteuerung zu verarbeiten. Der Maximalwert der Ansteuerung beträgt 150 und der Minimalwert 0. Wie bereits im vorherigen Kapitel erläutert, wird vom Asuro ein solcher Wert für den linken und einer für den rechten Motor an den PC geschickt. Wir können also annehmen, dass, wenn der eine Motor steht und der andere mit 150 angesteurt wird, sich der Asuro nach einer Zeitdauer t um 90 drehen wird. Diese Zeitdauer t ist im Algorithmus von zentraler Bedeutung. Des weiteren nehmen wir an, dass, wenn beide Motoren genau gleich angesteuert werden, sich die Ausrichtung des Asuros nicht ändert und er in gerader Richtung weiter fährt. Mit Hilfe all dieser Annahmen kommen wir dann zu unserem Algorithmus der Winkelberechnung Winkelberechnung Der Winkel der Ausrichtung lässt sich also aus der Dierenz der beiden Motoransteuerungswerte bestimmen. Eine Dierenz von 150 bedeutet eine 90 Drehung in einer Zeit t. Eine Dierenz von 0 bedeutet eine 0 Drehung in einer Zeit t. Da die Werte dazwischen linearer Natur sind, lassen sie sich mit einem einfachen Dreisatz bestimmen DELTA (90 DELTA) 150 Da die Winkelfunktionen von Ruby jedoch einen Winkel in Rad, anstelle von Deg, erwarten, ersetzen wir 90 durch PI/2: 150 PI 2 DELTA ((PI 2) DELTA) 150 PI

19 3.4.3 Bestimmung der Zeitdauer Nachdem die vermeindliche Ausrichtung des Asuro so bestimmt wurde, muss noch die Zeitdauer in Betracht gezogen werden. Diese ist wichtig, da, sobald sich die Motoransteuerung ändert, der Asuro nicht sofort diesen Winkel fährt. Er braucht dafür eine gewisse Zeit. Nehmen wir an der Asuro braucht für einen 90 Winkel t Sekunden, dann berechnet sich der Winkel, um welchen sich die Ausrichtung tatsächlich ändert, ebenfalls in einem Dreisatz und die folgende Formel entsteht: W inkel_mit_zeit = (W inkel Kurvenzeit) V ergangene_zeit Kurvenzeit Die Variable Vergangene_Zeit bekommt man von dem Asuro geschickt. Das Problem ist das Festlegen der Kurvenzeit. Diese Kurvenzeit ist keine Magische Zahl, sie ergibt sich daraus wie lange der Asuro für diesen Winkel eigentlich brauchen würde. Angenommen diese Zeit ist gleich der vergangenen Zeit, so wurde dieser Winkel wirklich gefahren. Aus der Formel ist das gut erkennbar: Ist die Kurvenzeit gleich der vergangenen Zeit, kürzen sich die Zeiten raus und nur der Winkel bleibt übrig. Da die Kurvenzeit aber für unterschiedlich groÿe Winkel verschieden ist, haben wir zusätzlich noch nach einem Weg gesucht den Algorithmus zu verbessern. Der Gedanke hierbei war der, die Kurvenzeit etwas variabler zu gestalten. Für gröÿere Winkel soll sie gröÿer sein, was ja Sinn macht, da für einen groÿen Winkel der Asuro mehr Zeit braucht als für einen kleineren. Dazu rechnen wir nicht mehr mit einer Kurvenzeit sondern mit vier verschiedenen. Eine für jeden der folgenden Winkelbereiche: Winkel von 0 bis 22.5 Winkel von 22.5 bis 45 Winkel von 45 bis 67.5 Winkel von 67.5 bis 90 In Tests fanden wir heraus, dass die vier Kurvenzeiten voneinander abhängen. Die erste Kurvenzeit ist immer die kleinste. Umso gröÿer der Winkel wird, desto gröÿer wird auch die Kurvenzeit. Dies kam uns sehr gelegen, da wir dann anhand der ersten Kurvenzeit die anderen drei ausrechnen lassen können, um den Benutzer nicht mit zusätlichen Eingaben zu verwirren. Bei dem erweiterten Algorithmus sieht die Berechnung des Winkels dann wie folgt aus: 18

20 kurvenzeiten = Listing 6: ] # Index des Winkels berechnen index = ( Winkel * 2 / Math :: PI ) * kurvenzeiten. size Winkel_ mit_ Zeit = Winkel / kurvenzeiten [ index ] * Vergangene_ Zeit Die Werte mit denen die Kurvenzeit vergröÿert wird, wurden in einer aufwendigen Testreihe ermittelt. Zweierpotenzen schienen immer bessere Ergebnisse zu liefern als jede andere Erhöhung. Somit wurde die zweite Kurvenzeit im Vergleich zur ersten um den Wert 0.02, die dritte im Vergleich zur zweiten um 0.04 und die vierte im Vergleich zur dritten um den Wert 0.08 erhöht (Vergleiche Zeile 1 des obigen Codes) Vektorerstellung Hat man diesen Winkel erst berechnet, so ist der Rest des Algorithmus einfacher. Der nächste Schritt ist der, einen Vektor zu erstellen, welcher der aktuellen Geschwindigkeit entspricht. Dies ist notwendig, um zusätzlich ein Maÿ für die Geschwindigkeit zu haben. Der Vektor wird einfach mit der Geschwindigkeit als X - Komponente und als Y - Komponente 0 gewählt. Die Geschwindigkeit ergibt sich aus den beiden Motoransteuerungswerte. Also z.b. ( ) 2. Nun addiert man den ausgerechneten Winkel auf die Ausrichtung des Asuro und rotiert den ausgerechneten Winkel um diese Ausrichtung. Wird dieser Vektor nun auf die Position des Asuros draufaddiert so erhält man seine aktuelle Position. Implementiert sieht der komplette Algorithmus dann folgendermaÿen aus: Listing 7: Zeichenalgorithmus n_winkel = ( right. to_f - left. to_f ) * ( Math :: PI /300.0) # Index des Winkels berechnen index = (( n_winkel *2/ Math :: PI )* kurvenzeiten. size. to_f ). to_i # Winkel mit der Zeit verrechnen n_winkel_t =( n_winkel / kurvenzeiten [ index ]) *(( time ) /1000.0) # Sich den aktuellen Timestamp merken für die start_ time = time # Winkel auf die Ausrichtung des Asuros ausrichtung += n_ winkel_ t # Damit der Winkel nicht gröÿer als 360 wird 19

21 @ausrichtung % (2.0* Math :: PI ) # Geschwindigkeitsvektor erstellen und rotieren speed = Vector2D. new ( ( left + right ) /2, 0 ). rotate ) # Vektor auf die Position addieren und leicht pos += speed / Weitere Funktionen des rgraphers Das von uns geschriebene Programm rgrapher bietet nicht nur die Möglichkeit die Strecke während der Fahrt des Asuro zu zeichnen, sondern auch die Funktion die gefahrene Strecke abzuspeichern. Drückt man im Menü auf Speichern wird in dem Verzeichnis, in welchem rgrapher ausgeführt wurde, eine Datei mit aktuellem Zeitstempel erzeugt. Sie enthält alle Werte die der Asuro geschickt hat. Die Datei kann nun dazu genutzt werden, sich eine echte Replay von der Fahrt anzuschauen. Wird die Datei vom Menü aus mit einem Klick auf Replay geönet, so sieht man genau die Fahrt des Asuros die aufgezeichnet wurde, in genau derselben Zeitspanne. Dies war nicht nur beim Testen hilfreich, da der Eindruckt erzeugt wird der Asuro würde echt in diesem Moment fahren. Wenn nötig kann vor oder sogar während einer Replay die Kurvenzeit abändern, sodass man sehen kann, wie die Zeichnung mit einem anderen Wert aussieht. Neben Replay gibt es ebenso noch das Redraw. Dabei wird die Zeit, die der Asuro für die Strecke gebraucht hat, auÿer Acht gelassen. Das bedeutet, dass die Zeichnung viel schneller erstellt wird und nicht mehr in Echtzeit, in welcher der Asuro die Strecke abgefahren ist Probleme Das Problem das sich bei unserem Algorithmus bietet ist, dass die Kurvenzeit von vielen verschiedenen Faktoren abhängt, welche nicht immer klar ersichtlich sind. So hängt sie zum Beispiel vom Ladestand der Batterien ab, da bei vollen Batterien ein Ansteuerungswert von 150 viel stärker ist als bei schwachen Batterien. Diesen und ähnliche Freiheitsgrad kann man dann jedoch sehr gut über unsere Kurvenzeit, in Verbindung mit der Replay - Funktion, beheben. Die Kurvenzeit gibt eben die Zeit an, die der Asuro für eine 90 Kurve benötigt. Diese ist bei schwachen Batterien höher zu wählen. Als weiteres Problem ist zu nennen, dass die Kurvenzeit auch davon abhängt, ob die Strecke steile oder schwache Kurven beinhaltet. Für steile braucht der Asuro weniger Zeit, als für schwache Kurven. Doch auch dieses Problem wurde durch die Einführung der vier verschiedenen Kurvenzeiten bestmöglich behoben. 20

22 3.4.8 Oberäche des Programms rgrapher Hier soll nun ein kleiner Einblick auf die grasche Benutzeroberäche des von uns geschriebenen Programms rgrapher gegeben werden. In dem ersten Bild sehen sie die allgemeine Oberäche. Oben bendet sich das Menü, wo verschiedene Einstellungen zu Replays und Kurvenzeiten etc. festgelegt werden können. Der linke Teil der Oberäche ist dafür verwendet worden, die Werte der Motoren grasch auszugeben. In der oberen Hälfte des linken Teils werden die Werte des linken Motors, in der unteren Hälfte die des rechten Motors angezeigt. Auf der rechten Seite des Fensters wird die gefahrene Strecke nachgezeichnet. Zufällig ist hier gerade auf Einstellungen > Kurvenzeit geklickt worden und somit ist das kleine Eingabefenster für den Wert einer der vier Kurvenzeiten sichtbar. Die anderen drei werden durch das Hinzuaddieren von 0.02, 0.06 und 0.14 zu diesem Wert errechnet. Abbildung 9: Oberäche von rgapher 21

23 In der nachfolgenden Abbildung sehen sie bereits wie ein Replay abgespielt wurde. Diesem Replay wurde hier noch zusätzlich ein Bild hinzugefügt, welches als Hintergrund angezeigt wird. So können die wirklich gefahrene und die aufgezeichnete Strecke miteinander verglichen werden und die Kurvenzeit dementsprechend angepasst werden, bis beide annähernd übereinstimmen. Abbildung 10: Zeichnung eines Replay Die Regelung des von uns implementierten Regelalgorithmus kann anhand der Zeichnung im linken Teil des Fensters sehr schön nachvollzogen werden. 22

24 4 Fazit und Bewertung Zunächst einmal muss man sagen, dass die Sensorik des Asuro extrem schlecht ist. Die Odometriedaten kann man fast gar nicht benutzen. Dies liegt z.b. daran, dass die Odometriescheibe sehr stark wackelt und dass der Abtastbereich viel zu groÿ ist. Hier wäre ein Lichtschranken - Sensor um einiges besser gewesen. Hier ist eben zu bedenken, für welche Zwecke der Asuro vom Deutschen Zentrum für Luft- und Raumfahrt (DLR) entwickelt wurde, wobei hier dem Anschein nach nicht die eektive Messung von Odometriedaten der ausschlaggebende Punkt war. Abgesehn davon ist der Asuro nach einigen Feinjustierungen jedoch ein sehr guter Roboter und bietet einen sehr guten Einstieg in die Robotik. In unserem Projekt haben wir die Schwäche der Sensoren doch bestmöglich umgehen können und einen anderen, viel eektiveren Weg gefunden die Strecke zu zeichnen. Während der Projektarbeit ist uns immer wieder deutlich geworden, wie in der Prozessdatenverarbeitung gearbeitet wird und welche Probleme hier auftreten können. Vor allem die Realisierung der Streckenzeichnung in Echtzeit hat uns sehr motiviert, da dies ein hoch gestecktes Ziel war, welches jedoch am Ende sehr gut funktioniert hat. Es war ein sehr motivierendes Projekt und vor allem die Tatsache, dass uns immer wieder neue Ideen gekommen sind, welche weiteren Funktionen wir unserem Asuro noch geben können, hat die Sache sehr interessant gemacht. 23

25 Listings 1 Linienverfolgung Linienverfolgung Odometrie-Min-Maxwert Bestimmung Odometrie Übergänge Senden der Motorwerte Winkelberechnung Zeichenalgorithmus

26 Abbildungsverzeichnis 1 Asuro Fototransistoren Odometriesensoren Infrarot - Schnittstelle Asuro fährt geadeaus Asuro fährt eine Rechtskurve Fahrt einer Linkskurve Odometrie Musterscheiben Oberäche von rgapher Zeichnung eines Replay

27 Literatur [1] [2] 26