Werner- von- Siemens- Gymnasium Magdeburg

Schuljahr 2006/2007

Fach: Technik

Betreuer: Herr Dux

Bearbeiter:

Marcel Bassüner

Thema:

Robocup Rescue League 2007

Gliederung

1. Einleitung

2. Aufgabenstellung

3. Probleme und Lösungen

1. Starker Antrieb

2. Linie Verfolgung

3. Lücken Bewältigung

4. Opfer Erkennen

5. Hindernis Überwinden

4. Probleme des Wettbewerbes

5. KR-Mega Pad

1. Aufbau und Funktion

2. Ausstehendes, bzw. Geplantes

6. Tagesplan

1. Einleitung

Diese Facharbeit beschäftigt sich mit der Teilnahme am RoboCup, den Aufgaben und den

damit verbundenen Lösungen. Die Ausarbeitung stellt einen Erfahrungsbericht dar und soll

verschiedene Möglichkeiten zur Lösung der Problematik RoboCup bieten. Als Grundlage

dient die Teilnahme am RoboCup 2006 und 2007. Zusätzlich zur Erläuterung der

Aufgaben und deren Lösung (vorrangig die Programmierung), wird eine selbst entwickelte

Programmierumgebung vorgestellt und der Umgang mit dieser Beschrieben. Die

Facharbeit hat die Aufgabe neue Teams für den RoboCup vorzubereiten und ihnen

alternative Lösungsvorschläge zu bieten. Um dies zu erreichen wurden folgende

Problemfragen erstellt:

� Wie können die „Standard“ Lösungen des RoboCups verbessert werden?

� Welche unerwarteten Probleme treten beim Wettbewerb auf?

2. Aufgabenstellung

Verbale Formulierung

Im Rahmen des Technikunterrichtes bekommt jeder Schüler die Aufgabe sich mit einer

bestimmten Thematik praktisch zu befassen. Unter Anderen steht die Teilnahme an einem

Wettbewerb zur Wahl. Einer dieser Wettbewerbe ist der RoboCup. Dieser Wettbewerb ist

für eine Herausforderung für jeden „Technik-Fan“. Somit beinhaltet die Teilnahme, die

Konstruktion eines regelkonformen Roboters, die Konzeptionierung und die Herstellung

von Leistungsstarken Sensoren und letztendlich die Programmierung des Ganzen.

Zweck der Aufgabe

Auf Grund des Komplexität der Aufgabe wird nicht nur das logische Denken gefördert,

sondern auch die Arbeit im Team. Im Laufe der Vorbereitungen werden die Gruppen

immer wieder auf Probleme stoßen bei denen auf Team- und Zusammenarbeit nicht

verzichtet werden kann. Des Weiteren spielt natürlich nicht nur der soziale Aspekt eine

Rolle, sondern vorrangig der Technische. Beim bearbeiten der Aufgabenstellungen wird es

schnell nötig die Grundkenntnisse des Lötens und das erstellen von eigenen Platinen zu

erlernen. Zusätzlich wird erwartet das sich die Teams über mögliche Getriebearten und

Sensoren informieren. Das Wichtigste stellt am Ende die Programmierung dar. Abhängig

von der Roboter-Technik sollte vorher Material über mögliche Parallel Programmierung

besorgt werden.

3. Probleme und Lösungen

Als erstes muss die Aufgabenstellung in die verschiedenen Anforderungen zerlegt werden.

Der zu bauende Roboter sollte folgende Bedingungen erfüllen:

� Starker Antrieb

� Linien Verfolgung

� Lücken Bewältigung

� Opfer Erkennung

� Hindernis Überwindung

Im kommenden Teil der Arbeit werden die beschriebenen Probleme genauer analysiert

und anschließend mögliche Lösungen dargestellt.

3.1 Starker Antrieb

Um sich in der Arena bestmöglich fort zu bewegen ist es nötig dem Roboter einen staken

Antrieb zu verpassen. Das größte Hindernis des „Gebäudes“ stellt die Rampe dar.

Als erstes stellt sich die Frage ob die Kraft durch Räder oder durch einen Kettenantrieb auf

den Boden übertragen wird. Räder bieten den Vorteil das diese sehr Schnell sind und

haben eine geringe Reibung. Dies jedoch stellt auch schon den Nachteil von Rädern dar.

Auf Grund ausreichender Erfahrungen können Räder als nur schlecht verwendbar

eingestuft werden. Des weiteren ist bei ihnen ein großes Problem das Rollen. Wenn der

Roboter auf der Rampe zum stehen kommt werden die Motoren meist nicht blockiert, es

liegt einfach keine Spannung mehr an. Durch die Masse des Gefährts rollt es nun

rückwärts wieder hinunter. Auch wenn Ketten eine höhere Reibung aufweisen, besteht bei

ihnen trotzdem das Problem des Rollens.

Aus diesem Grund muss sich nun mit einer „Roll-Blockade“ auseinander gesetzt werden.

Bei dem von mir benutzten Roboter stellte sich ein Schnecken-Rad Antrieb als sehr

vorteilhaft heraus. Da bei diesem Antrieb eine automatische Blockade hervorgerufen wird.

Wenn eine Bewegung von den Rädern ausgeht (wie es beim Rollen der Fall ist) blockiert

das Getriebe.

3.2 Linien Verfolgung

Im Regelwerk ist die Linienbreite mit 1-2cm verankert. Um diese nun verfolgen zu können

gibt es im Allgemeinen zwei Herangehensweisen:

1. Die Sensorik wird seitlich der Linie platziert. Sobald einer der beiden Empfänger

über der Linie ist, wird gegen gelenkt.

2. Die Sensorik wird direkt über der Linie angebracht, nachdem einer der Sensoren

die Linie verlassen hat wird der Roboter wieder auf die Linie zurück gedreht.

Beide Varianten haben verschiedene Vor- und Nachteile:

1. Seitlich der Linie 2. Auf der Linie

Vorteile Verliert die Linie nahezu nie,

da ein großer Spielraum

vorhanden ist.

Kann Lücken ohne Probleme

erkennen.

Nachteile Nicht zu unterscheiden ob

der Roboter sich in einer

Lücke befindet oder auf der

Linie.

Verliert die Linie recht

schnell da wenig

Toleranzbereich vorhanden

ist.

Nun ist auf Anhieb zu erkennen, dass beide Varianten beinahe die kompletten

Gegensätze darstellen. Dem zu Folge ist die einzig mögliche Konsequenz die Kombination

beider Methoden:

Die Programmierung könnte nun mit einfachen abfragen organisiert werden:

Wenn

(ML=AufLinie) und (MR=AufLinie)und (L=AufWeiß)und (R=AufWeiß)

Dann

FahreGeradeAus;

L Ml MR R

usw…

Trotzdem sind noch zwei weitere Dinge zu Beachten:

1. Der Roboter wird bei einer Lücke nie mit Beiden MittenSensoren gleichzeitig auf

weiß kommen.

2. Wenngleich nun vier Sensoren am Roboter sind wird die Linien Verfolgung dennoch

sehr ruckelig ablaufen.

Auch für diese zwei Probleme gibt es hier eine Lösung:

1. Dies ist recht einfach über wait(); zu regeln. Es wird überprüft ob MR von der Linie

ist und nach eine Pause ob nun zusätzlich auch ML von der Linie ist.

Das zweite Problem ist eigentlich nur ein Schönheitsfehler. Jedoch wenn man genau hin

schaut geht durch das ruckelige fahre auch ein wenig Zeit verloren dem nach muss das

Ganze etwas geschmeidiger ablaufen. Nun ein kleiner Denkanstoß:

2. Nun werden nicht mehr alle Sensoren einzeln abgefragt, sie werden

zusammengeschlossen. Dies geschieht mittels einer Wertung. Wobei die Beiden

äußeren eine höhere Wertung bekommen als die innen. Zusätzlich zu beachten ist

das Rechts und Links über das Vorzeichen zu unterscheiden sind. Jedoch dürfen

zum Beispiel ML und L auch nicht das Selbe Vorzeichen haben das sonst

[(ML=AufLinie) und (L=AufLinie)] eine höhere Bewertung bekäme als

[(ML=AufWeiß) und (L=AufLinie)]. Die Systematik dafür wäre:

L ML MR R

-F F/2 -F/2 F

Position = (L*(-F))+(ML*(F/2))+(MR*(-F/2))+(R*F)

F�Faktor

Der Faktor muss für die Nutzung an die Höchstgeschwindigkeit angepasst werden damit

die Position sofort für einen genauen Geschwindigkeitswert für die Motoren zu gebrauchen

ist.

Während die Test mit diesem Prinzip laufen wird das Hindernis auftreten, dass die

Sensorwerte alle unterschiedlich sind und somit sich nicht zum direkten vergleich für die

Position anbieten. Deshalb muss eine kleine Transformation geschehen:

• Sensorwertnormierung: Dazu werden für jeden Sensor die spezifischen

Ergebnisse für weiß und schwarz aufgenommen. Nun wird für jeden Sensor eine

mathematische lineare Funktion aufgestellt. Die Sensorwerte bilden die X-

Koordinate und die zu erreichenden Werte die Y-Koordinate somit hat man zwei

Punkte der Funktion und die Funktionsgleichung kann aufgestellt werden. Ein

Beispiel ist in der Exel-Datei Linie.xls zu finden.

3.3 Lücken Bewältigung

Die Lücken Überquerung wirft nicht nur das Problem der zeitlich verschobenen Sensoren

auf, zusätzlich wird die Aufgabenstellung noch durch die Kombination verschiedener

Probleme mit der Lücke kombiniert. Dies finde insbesondere Anwendung bei den

Hindernissen (3.5).

Wenn der Roboter nun die Linie verlassen hat und eindeutig erkannt hat, dass es sich um

eine Lücke handelt, sollte ein gesonderter Algorithmus abgearbeitet werden. Dies erwies

sich als Vorteilhaft da es möglich ist, dass der Roboter die Linie schief verlässt und somit

den Anschluss an die Linie nicht wieder erlangt. Vorgeschlagen wird hier die sinusförmige

Bewegung der Sensoren. Dabei wird der größte Bereich der Lücke gescannt. Dabei

benötigt der Roboter eine Vorwärtsbewegung verbunden mit einer Regelmäßigen

Drehung.

3.4 Opfer Erkennung

Bei der Opfer Erkennung wird davon ausgegangen, dass die Klebestreifen (stellen Opfer

dar) grün und silbern sind. Auch hier stehen abermals zwei Lösungen zur Verfügung:

1. Die Verwendung eines Farbsensors. Jedoch sind Farbsensoren sehr teuer und

stehen somit nicht jedem Team zur Verfügung. Es gibt die Möglichkeit einen

Farbsensor selbst herzustellen. Dazu nimmt man einen Fototransistor und ordnet

um ihn eine rote, grüne und blaue Lichtquelle. Die Lichtquellen müssen zwei

Forderungen erfüllen:

• Sie sollten sehr hell damit die Reflektion des Bodens ausreicht um ein Signal zu

messen können.

• Zusätzlich müssen die Lichtquellen einen großen Spektralbereich abdecken, da

die Reflektionsfrequenz des Bodens enthalten sein muss.

2. Eine weitere Möglichkeit ist die Nutzung der Breiten Eigenschaft der Opfer. Sie

werden durch Klebestreifen, die quer über die schwarze Linie geklebt sind,

realisiert. Somit könnten drei einfache Helligkeitssensoren Positioniert werden:

Nun kann einfach überprüft werden ob sich alle drei Sensoren auf dem Opfern

befinden. Jedoch muss darauf geachtet werden das es zumeist dazu kommt, dass

weiß und silbern nur schwer unterschieden werden können.

L M R

3.5 Hindernis Überwindung

Nun zur letzten Problematik der Aufgabenstellung die Überwindung von Hindernissen. An

diese Herausforderung kann auf viele verschiedene Weisen heran gegangen werden. Zum

eine wäre da die einfachste aber auch unprofessionellste Lösung der Zeitschaltung: Nach

dem der Roboter das Hindernis erkannt hat durchläuft er einen bestimmten Algorithmus

wodurch er einen Bogen um die Barriere fährt. Diese Methode ist sehr unsicher da die

benötigten Zeiten stark variieren können. Somit wäre die direkte Orientierung am

Hindernis eine bessere Variante. Dabei besteht die Möglichkeit sich optisch oder physisch

am Objekt zu navigieren. Bei allen Umsetzungen muss jedoch darauf geachtet werden,

dass das Objekt nicht solange umfahren wird bis der Roboter die Linie wieder gefunden

hat. Dies ist zu beachten da sich Hindernisse auch in Lücken befinden können. Den

Ausweg könnte ein Magnetfeldsensor bieten:

• Wenn der Roboter das Hinderns erkennt wird die aktuelle Drehrichtung anhand

des Magnetfeldsensors gespeichert, der Roboter kreist nun solange um das

Hindernis biss er sich 90° weiter gedreht hat. Danach richtet er sich wieder wie

bei der gespeicherten Orientierung aus und fährt nun weiter. Wenn der Roboter

nun immer noch nicht auf der Linie ist soll er die Lücken Prozedur ausführen.

4. Probleme des Wettbewerbes

Die Wettbewerbs Räumlichkeiten sind meist große gut ausgeleuchtete mit ebenso großen

Fenstern ausgestattete Messehallen. Eben darin besteht die Gefahr: Nicht nur in der

Decken Beleuchtung, die 100% von der Test-Beleuchtung (der letzten arbeitsamen

Wochen) abweicht. Somit müssen die Sensoren völlig neu kalibriert werden hinzu kommt,

das meist auch die Beschaffenheit der Strecke abweicht. Um dem drohenden

Schlamassel zu entgehen könnten die Sensoren während des Laufes immer wieder neu

eingestellt werden, da die Lichtwerte auch auf verschiedenen Abschnitten der Bahn

differieren. Jedoch dürfen dazu natürlich keine Änderungen am Roboter gemacht werden

also muss dies automatisch geschehen. Dadurch das sicher ist, dass mindestens 1er der

4 Liniensensoren auf der weißen Fläche sein muss können ständig neue werte für

schwarz und weiß aufgenommen werden. Dennoch sollte beachtet werden, dass die

Werte nicht Schlag auf Schlag geändert werden sollten, da immer wieder Fehler auftreten

können. So wäre es dann vielleicht möglich, dass weiß und schwarz denselben Wert

haben.

Der aktuelle Wert sollte eine bestimmte Wichtung zwischen 0 und 1 bekommen. Mit

diesem Gewicht fließt dann der neue Wert in den vergangenen ein:

Wertneu = Wertalt * (1 - Wichtung) + Wertaktuell * Wichtung

Wertalt = Wertneu

Neue Überprüfung

5. Kr-Mega Pad

Das Kr-Mega Pad ist eine selbst entwickelte Programmierumgebung speziell auf die Kr-

Mega Bibliothek. Das Pad soll die Programmierung eines Atmel-Board erleichtern und

bietet dazu etliche Funktionen und Hilfsmittel die dies ermöglichen. Im Folgenden werden

Grundlegende Ansätze und spezielle Features des Programms erläutert. Im Anschluss

werden aktuelle Defizite der Umgebung aufgezeigt und kommende Veränderungen

beschrieben.

5.1 Aufbau

Die Programmierumgebung ist in 3 Grundlegende Abschnitte aufgeteilt: Der Helper

(9,1,2), die Steuerung und Überwachung (6,7,8,4), die Programmierbereich (5,3).

Der Helper

Der Helper ist Objekt welches den Umgang mit der Kr-Mega Bibliothek erleichtern soll.

Darin sind alle verfügbaren Befehle der Bibliothek enthalten. Zusätzlich können vom

Benutzer eigene Kommandos hinzugefügt werde. Der Helper ist in 3 Teile unterteilt:

(9) Dies ist die Steuerungsleiste. Hier können die Befehle des Helpers bearbeitet werden

und andere hinzugefügt werden.

(2) Hier werden Informationen zu dem ausgewählten Befehl angezeigt diese Informationen

können falls sie noch nicht gesetzt worden noch geschrieben werden jedoch steht keine

Bearbeitungsfunktion zur Verfügung damit Festgelegt Informationen nicht

fälschlicherweise verändert werden können.

(1) Die Anzeige wird durch ein TreeView realisiert, wodurch die Kommandos in bestimmte

Gruppen unterteilt werden können. Sobald ein Befehl ausgewählt ist wird die

dazugehörige Information im unteren Teil angezeigt.

1

2

3

9 5 6 7

4

8

Die Steuerung und Überwachung

An dieser Stelle könne bestimmte Einstellungen vorgenommen werden die die Umgebung

an den Nutzer Anpassen. Zusätzlich besteht die Möglichkeit vorgefertigte

Quelltextkonstrukte geladen werden. In der unteren Anzeige (4) werden

Konsolenausgaben angezeigt.

Der Programmierbereich

Hier werden die verschiedenen Quelltextfenster angezeigt. Die Fenster sind mit einem

Syntaxhiglightning ausgestattet. Es werden alle Befehle von C und die Befehle des

Helpers markiert. Mit Hilfe der Steuerleiste (5) kann zwischen den Fenstern gewechselt

werden.

5.2 Ausstehendes, bzw. Geplantes

Im Großen und Ganzen ist das Grundkonstrukt der Programmierumgebung fertig jedoch

fehlen noch viele Kleinigkeiten, wie zum Beispiel die vervollständigung des Menüs und die

Fertigstellung der Steuerungsicons.

Ein wesentlich wichtiger Punkt der im Programm noch fehlt ist die Integration der Tools der

Kr-Mega Bibliothek. Dies bis jetzt noch nicht Möglich gewesen da einige Probleme bei

dem Abfangen der Konsolenausgabe aufgetreten sind.

Neue Versionen der Programmierumgebung werden der Schule in der folgenden Zeit zur

Verfügung gestellt. Bei Fragen oder Vorschlägen wendet euch bitte an:

• Marcel.Bassuener@web.de

6. Tagesplan

Datum Aktivitäten

21.12 Erste Tests der Farberkennung mit Fotodioden, Fototransistoren und

Fotowiderständen über farbigen Papierstreifen � Entscheidung für

Fototransistor

11.01 Studieren des Datenblattes einer Vielfarb-LED zur korrekten

Ansteuerung und Bestückung/ Provisorischer Aufbau des Farbsensors

auf Testplatine/ erste Vorbereitungen zur Übernahme auf Uniplatine

(Fräsen)

18.01 Tests mit Farbsensor � Feststellung von Problemen, da Ausschlag

sehr schwach � Anpassung des Widerstandes vor dem Fototransistor,

so dass Veränderungen merkliche Spannungsschwankungen

hervorrufen

25.01 Erster Testaufbau eines Helligkeitssensors im IR-Bereich auf

Testplatine/ Beginn eines finalen Aufbaus auf Uniplatine

01.02 Bestückung und Fertigung der Krause Board Platine

02.02 Fertigstellen der Krause Board Platine und Montage auf dem Roboter

Auseinandersetzung mit der Programmiersprache

15.02 Reparaturarbeiten am Helligkeitssensor

22.02 Einbau der IR- und Farbsensoren in den Roboter

23.02 Programmierung und Sensor Justierung (1h Schlaf)

24.02 Programmierung und Sensor Justierung

1. Wettbewerbslauf: Nicht Angetreten (Sensorik nicht Funktionstüchtig)

Planung eines neuen Aufbaus -> Bau in Auftrag gegeben

Neue Sensorik in Auftrag gegeben

Neue Programmierung (5 ½ h Schlaf)

25.02 2. Wettbewerbslauf

Auswertung

01.03 Kr-Mega Pad Konzept begonnen

02.03 –

14.03

(ca >20h)

Programmierung und Design des Kr-Mega Pad’s

15.03 Arbeit an der Facharbeit