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, Kann Lücken ohne Probleme
da ein großer Spielraum erkennen.
vorhanden ist.

Nachteile Nicht zu unterscheiden ob Verliert die Linie recht

der Roboter sich in einer schnell da wenig
Lücke befindet oder auf der Toleranzbereich vorhanden
Linie. 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:

L Ml MR R

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

Wenn

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

Dann

FahreGeradeAus;
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)

FFaktor

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:

L M R

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.
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

7
6
9 5

1
3

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.
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 – Programmierung und Design des Kr-Mega Pad’s
14.03
(ca >20h)
15.03 Arbeit an der Facharbeit