Benutzer-Werkzeuge
Seitenleiste
Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
Projektdokumentation
Ihr habt einen sehr ordentlichen ersten Ansatz eingereicht, dann aber leider auf unsere Korrekturvorschläge nicht weiter reagiert.
Die eingereichte Fassung deckt alle geforderten Bereich ab und hat die geforderte Grundstruktur. An einigen Stellen wurden Informationen vermischt, die zu getrennten Abschnitten gehört hätten. Die vorhandenen Zeichnungen sind gut oder sehr gut, es fehlt jedoch insbesondere eine Skizze, in der die Winkelbeziehungen zwischen Ball, Roboter und Tor erklärt werden. Die Erklärung des Algorithmus zur Farbmarkerfindung geht in die richtige Richtung, ist aber noch an vielen Stellen nicht exakt genug. Insbesondere fehlen Formeln und deren Herleitung völlig - darum werdet ihr euch in einer ingenieurswissenschaftlichen Laufbahn auch in Zukunft nicht drücken können…
Die Angaben im Fazit können so nicht stehen bleiben, ohne dass das zu deren Ermittlung verwendete experimentelle Protokoll und die so gewonnenen Daten angegeben werden. Das ist unverzichtbare Basis wissenschaftlichen Arbeitens. Der Verdacht, dass es sich bei den Zahlen um nicht belegbare Schätzungen nach Bauchgefühl (am Rande einer wissenschaftliche Fälschung) handelt, wiegt schwer und verhindert eine „gute“ Bewertung.
Befriedigend mit guten Tendenzen (9/15)
Felix Bonowski
Hermann Pöhler, Eric Beier, Maximilian Schulz
Seit Beginn seiner Entwicklung versucht der Mensch sein Leben durch Hilfsmittel zu erleichtern, was heutzutage in der Erschaffung von intelligenten Robotern gipfelte. Ein noch größeres Verlangen hat der moderne Mensch jedoch nach ENTERTAINMENT. Jeder kennt es, jeder liebt es – Frank Robory, der Fußballroboter.
Inhaltsverzeichnis
- Themenbeschreibung
- Regelwerk
- Konstruktionsaufbau
- Aufbau
- Materialien
- Bildverarbeitung
- Fahrfunktion
- Datenübertragung
- Endergebnis
- Nachspielzeit
- Links
Themenbeschreibung
Frank Robory ist ein Roboter, der das Finden eines Balles mittels einer Kamera sowie das Ansteuern und Schießen (bzw. Schieben) von jenem ermöglicht. Zielstellung ist es, den Ball in das Tor des Gegenübers zu befördern.
Roboter bewegt sich auf einem rechteckigen Feld, welches durch Holzbalken abgetrennt ist und ca. 180cm x 250cm misst.
Eine Holzplatte dient als Grundplattform. An ihr sind zwei ansteuerbare, motorisierte Räder sowie eine Mauskugel, welche als Stütze dient, befestigt. Die Grundplatte ist bis auf die Vorderseite rund. An dieser befindet sich eine ebene Fläche, um den Ball zu schieben. Die Deckplatte ist mit 2 verschiedenfarbigen Punkten versehen. Durch eine über dem Spielfeld angebrachte Kamera ist es so möglich den Roboter, seine Fahrtrichtung sowie den Spielball zu lokalisieren. Durch Anwendung von Winkelbeziehungen und linearer Algebra errechnet er so den Weg zum Ball und bewegt ihn. Die von der Bildverarbeitung errechneten Informationen werden mithilfe von W-LAN an den Roboter übermittelt. Weiterhin sind auf der Grundplattte ein Arduino Mega, welcher die zentrale Steuerungseinheit des Roboters darstellt sowie ein AKKU, der die Motoren und Arduino mit Strom versorgt, befestigt.
Regelwerk
Das Spielfeld
Zwei Kameras sind in einer Höhe von 190cm an einem Stativ aus einem vorherigen Projekt befestigt, wodurch ein Sichtfeld von 180cm x 250cm auf dem Boden entsteht. Die Kameras sind die Playstation–Eye von der Firma Sony, welche zum Sortiment der Playstation 3 gehören. Jede Kamera ist durch ein langes Kabel mit einem Computer verbunden. Das Sichtfeld der beiden Kameras ist die Begrenzung des Spielfeldes. Durch eine Holzbarriere aus 2,5cm starken Holzleisten wird der Ball daran gehindert bei einem Spiel das Kamerasichtfeld zu verlassen. Ein Teppich dient als Untergrund, auf dem der Roboter sich bewegt und durch seine Beschaffenheit die Fahrtüchtigkeit der Räder nicht einschränkt. Die graue Farbe des Teppichs stört die Farberkennung der Kamera nicht, da seine RGB-Werte keine Ähnlichkeit zu der Farbe des Balles und den Farben auf dem Roboter besitzt.
Roboter
Die Grundplatte hat einen Durchmesser von 30cm und darf nur an eine flache Seite besitzen. Des Weiteren dürfen die Räder nur mit einfachen Elektromotoren im Plastikgehäuse betrieben werden. Es dürfen keine Funktionen eingebaut werden, die den gegnerischen Roboter vorsätzlich in seiner Funktionalität behindern oder ihm schaden. Es muss zu jeder Zeit möglich sein, dass der Gegner mit dem Ball interagieren kann. Weiterhin muss der Roboter zu 100% selbständig arbeiten – jegliche Einwirkung des Besitzers während einer Partie ist untersagt.
Ball
Als Spielgerät dient ein orangefarbener Gummiball, mit der Größe eines Tennisballs, welcher auch beim internationalen Robocup verwendet wird. Seine Beschaffenheit macht ihn zu einem perfekten Spielball. Er rollt schnell und ist nicht in der Lage zu springen. Seine Farbe unterstützt die fehlerfreie Farberkennung durch Processing.
Konstruktion
a) Aufbau
b) Materialien
| Bauteil | Anzahl |
|---|---|
| Rad (d = 6 cm) | 2 |
| Stützrad (Computermauskugel) | 1 |
| Gleichstrommotor mit Plastikgetriebe | 2 |
| PLaysation Eye-Kamera | 1 |
| LiPo-Akku 7,4V | 2 |
| Arduino Mega | 1 |
| MotoMama | 1 |
| LiPo Guard | 1 |
| WLan Modul RN-XV | 1 |
| Physis (Gehäuse) |
|---|
| Holz |
| Schrauben |
| Muttern |
| Gewindestangen |
| Farbe |
| Pappe |
| Klettband |
| Kabelbinder |
Bildverarbeitung
- „unkonstant“ ist etwas ungenau - was ändert sich da?
- Das Gleiche gilt für die für „Lichteinwirkung“: Verändern sich die Farben, wenn sie kontinuierlich der Sonne ausgesetzt sind (dafür wäre das der richtige Begriff), oder verändern sich die gemessenen RGB-Werte, wenn sich die Lichtverhältnisse im Raum verändern?
Da sowohl der Ball als auch der Roboter farblich markiert sind, können so beide lokalisiert werden. Damit nicht nur die Position, sondern auch die Fahrtrichtung des Roboters ermittelt werden kann, sind auf seiner Oberfläche 2 bunte Punkte angebracht (Vorderseite ist mit Punkt markiert).
Jeweils zwischen dem Farbpunkt des Balles und dem Mittelpunkt des Roboters sowie zwischen den zwei robotereigenen Farbpunkten werden nun Vektoren aufgespannt. So ist es möglich die Route vom Roboter zum Ball mit der reellen Fahrtrichtung abzugleichen.
Fahrfunktion
Um die Abweichung zwischen idealem und tatsächlichen Fahrweg zu errechnen, wird die atan2 – Funktion benutzt. Diese errechnet den Winkel zwischen den zwei, von der Bildverarbeitung erstellten, Vektoren. Weiterhin gibt sie durch das Vorzeichen des Ergebnisses an, ob sich der Ball links oder rechts vom Roboter befindet.
Zunächst war geplant, den Roboter um sich selbst drehen zu lassen, bis alle drei Punkte auf einer Gerade waren und ihn dann Fahren zu lassen. Jedoch stellte sich heraus, dass diese Methode nicht nur langsam, sondern auch sehr fehleranfällig war. Da die Farberkennung nicht immer perfekt funktioniert (Erkannte Werte schwanken) erkannte das Programm oft nicht, dass der Roboter in perfekter Position war und ließ ihn so mehrere Male um 360° drehen.
Stattdessen werden nun die Winkel in Geschwindigkeiten umgerechnet, die als Parameter an die Motoren übergeben werden. Im Diagramm dargestellt sind die Geschwindigkeiten, welche die Räder je nach gemessenem Winkel annehmen. Je größer der Winkel zu Idealroute ausfällt, desto schneller bewegt sich das Rad, welches zum Ausgleich benötigt wird. Parallel wird das gegenüberliegende Rad proportinial zum winkel langsamer.
Datenübertragung
Um die Daten von dem Processingprogramm des Computers zu dem Roboter, welcher mit einem Arduinoprogramm läuft zu übermitteln, benutzen wir W-LAN. Auf dem Roboter ist das Wifly-Modul (RN-XV, rechts) durch das MotoMama Board mit dem Arduino verbunden. Die Datenübertragung vom Wifly -Modul zum Arduino erfolgt über die Pins, beziehungsweise die Eingänge der beiden Geräte. Das Wifly-Modul ermöglicht es dem Arduino, über einen Router mit dem Computer und somit auch mit Processing zu kommunizeren. Beide Geräte müssen mit dem Router verbunden sein. Durch den Austausch von der IP-Adresse und einem dazugehörigen Passwortes sind die beiden Geräte gekoppelt. Die Koppelung ermöglicht es Nachrichten von Processing zu Arduino zu übermitteln. Die Bildverarbeitung liefert entsprechend der errechneten Geschwindigkeiten verschiedene Nachrichten,welche die Parameter an den Arduino Mega übergeben. Diese Nachrichten werden mit Hilfe des Wifly-Moduls vom Arduino empfangen. Abhängig von der empfangenen Nachricht führt der Arduino bestimmte Funktionen aus.
Pinliste Arduino
| Bauelement | Pin |
|---|---|
| Motor_rechts_1 | 12 |
| Motor_rechts_2 | 13 |
| Motor_rechts_Geschwindigkeit | 11 |
| Motor_links_1 | 8 |
| Motor_links_2 | 9 |
| Motor_links_Geschwindigkeit | 10 |
| Wify-Anschluss | TX3;RX3 |
Für die Motoren benötigt man jeweils 3 pins. Die pins 8 und 9 bzw. 12 und 13 sind dafür verantwortlich in welche Richtung sich die Räder drehen sollen. Sie werden mit analogWrite angesteuert. Die Pins 10 und 11 werden hingegen mit digitalWrite angesteuert. Hier kann man die Geschwindigkeit bestimmen, indem man Werte zwischen 0 und 255 eingeben kann. Bei 0 werden natürlich 0 Volt und bei 255 dann 5 Volt in die Motoren geleitet.
Pinliste Motomama-Bourd
| Bauelement | Pin |
|---|
| Motor_rechts_1 | OUT3 |
| Motor_rechts_2 | OUT4 |
| Motor_links_1 | OUT1 |
| Motor_links_2 | OUT2 |
| Accu_1 | GND |
| Accu_2 | +5V |
| Wify-Anschluss | Braek out Zone |
Endergebnis
Zur Zeit der Erstellung dieser Dokumentation findet und schiebt der Roboter in ca. 40% den Ball. Das Tor trifft er mit einer Wahrscheinlichkeit von etwa 15% noch recht selten.
Die Motoren des Roboters lassen sich wie gewünscht ansteuern und lenken Frank Robory so in die gewünschte Richtung. Das Hinterrad (Mauskugel) weist leichte Abnutzungserscheinungen auf, die die Bewegung allerdings nicht einschränken.
Die angwandten mathematischen Prinzipien im Programmcode funktionieren wie angedacht. Von Processing gesendeten Nachrichten werden ohne Fehler an den Arduino gesendet, die Aktionen gemäß dieser ausgeführt.
Das Problem, welches zur hohen Fehlerquote des Roboters führt und ihn somit oft im Kreis fahren lässt, ist die Farberkennung. Oft werden die zu findenen Farben nur teilweise oder gar nicht erkannt. Auslöser dafür ist die schwankende Helligkeit auf dem Spielfeld, welche die Farberkennung den real konstanten Farben, je nach Lage auf dem Spielfeld, teilweise drastisch abweichende RGB-Werte zuweisen lässt.
Weiterhin bleibt Frank Robory oft an de Abgrenzung des Spielfelds hängen, was durch eine nicht implementierte Funktion zur Vermeidung der Spielfeldränder zu erklären ist.
Torerfolg
...Und ein Misserfolg
Nachspielzeit
Die erste und wohl wichtigste Verbessrungsmöglichkeit stellt der Ausbau der Farberkennung dar, da somit gewährleistet wäre, dass der Roboter wie gewünscht funktioniert. Denkbar ist eine dynamische Anpassung der zu findenen Farben (z.b. durch Referenzfarben an den Spielfeldenden), welche die, durch Helligkeitsunterschiede, verursachten Fehler eindämmen würde.
Zudem wäre das Finden des gegnerischen Tores ein essentieller Bestandteil zum Gewinnen eines Matches. Zur Zeit der Entstehung dieses Dokuments ist eine solche Funktion bereits in Arbeit, jedoch noch nicht funktionsfähig.
Auch das Vermeiden der Banden oder eine Verteidigungsfunktion sind denkbar. So könnte sich Robory nicht mehr am Spielfeld aufhängen und im Tor positionieren, wenn der Ball im hinteren Teil der eigenen Hälfte liegt.
Links
Kompletter Programmcode:
Libaries und Programme zur Benutzung von Kamera und Co.:
Seiten-Werkzeuge
