Home

Lernende, autonome Fussballroboter -Endbericht-

1. Controller Area Network vgl www can bosch com 16 2 3 MOTORCONTROLLER KAPITEL 2 HARDWARE Abbildung 2 8 Das Motorcontroller Board Kameleon 3765BC Quelle www k team com Mikrocontroller MC68376 RAM 1 MByte Flash Speicher 1 MByte Spannungsversorgung 8 5 20 V Leistungsaufnahme lt 1 Watt Kommunikation RS 232 K Net MMA Tabelle 2 2 Auswahl technischer Daten zum Kameleon 376SBC Durch die Bereitstellung verschiedener Bussysteme wie SXB CXB oder IXB bietet das Board vielf ltige Erweiterungsm glichkeiten insbesondere ist die Zusammenschaltung mehrerer Kameleon Boards m glich Der firmenspezifische Bus K Net erm glicht den Anschluss vorgefertigter Sensormo dule Auf dem Board selbst l uft ein echtzeitnahes Betriebssystem das den Zugriff auf alle Ressourcen ber BIOS Aufrufe erlaubt Ein kostenlos bereitgestellter Crosscompiler erm glicht das Erzeugen eigener Anwendungen die anschlie end in einem nichtfl chtigen Speicher auf dem Board gespeichert werden k nnen ber einen DIP Schalter lassen sich verschiedene Boot Modi einstellen einer von ihnen erm glicht die Ausf hrung eines vorher im Flash gespeicherten Programms und ein anderer die Nutzung eines fest einprogrammierten Kommunikationsprotokolls ber die serielle Schnittstelle Der Steuerrechner kann im zweiten Boot Modus somit direkt Befehle an das Board senden und so Motorgeschwindigkeiten setzen oder Sensorinformati
2. herstellen Als Ergebnis dieser Umformungen erh lt man aus dem Panoramabild ein perspektivisch korrektes Bild Wie in Abbildung B 1 zu sehen wird ein Zylinder dargestellt der als geometrisches Grundger st die Projektion wiedergeben soll In der x yp Ebene wird der parabolische Spiegel und parallel zu ihm 89 B 2 ANSCHLUSSPLAN ANHANG B HARDWARE in der x y Ebene die Kamera genauer das aufgenommene Bild dargestellt Die beiden abgebildeten Winkel 0 und Y k nnen mit Hilfe von geometrischen Formeln umschrieben werden Z 0 cos y 2p Up 2p tan 2 B 2 B 1 Tp Nach einige Umformungen erh lt man als Werte f r z und y zi p sin 0 cos B 3 yi p sin 0 sin B 4 wobei BEER OSUEN 2 1 cos Anhand dieser Formel erh lt man den Bildpunkt p mit den Komponenten x und y Durch eine Projektion des sin bzw cos auf die Koordinatenachsen erh lt man Formel B 3 Im ersten Schritt wird mit sin 0 die Skalierung p in die p yp Ebene projiziert Im zweiten Schritt wird mit cos 6 bzw sin 6 die xi bzw y Komponente des aufgenommenen Bildes bestimmt Hierdurch erh lt man letztendlich eine Beziehung zwischen einem Weltpunkt und einem Bildpunkt B 2 Anschlussplan Wie schon in Kapitel 2 erw hnt besteht die Roboterelektronik im Wesentlichen aus dem Kamera system dem Steuerrechner und dem Motorcontroller Hinzu kommt z B die Stromversorgung f r die Firewire Kamera durc
3. Andere Vergleiche zwischen Sensoren sind m glich z B Distanzen zu den Fu punkten beim Torwart oder Winkel zu den Eckfahnen Algorithmus 6 void CHohensyburg validateParticlesBySensors SelfLocalisation Quality 0 535462 FT use BG Feat direct Angles _ use Poles _ use YG Feat Headinv Angles use AnalyseJu FT use Dist Turn Particles useLines I add EQ dist Calew Med ngle Abbildung 3 12 Beispiel der Verteilung der Partikel nach einem Integrationsschritt und bekannter Entfernung zu den Fu punkten des blauen Tors 40 3 4 STRATEGIE KAPITEL 3 SOFTWARE 3 4 Strategie Bei einem Fu ballfeld mit den sich darauf bewegenden Objekten wie Ball Mit und Gegenspielern handelt es sich um eine sehr dynamische Umgebung Hinzu kommt eine hohe Anzahl von Spiel situationen also Konstellationen von Ball und Spielerpositionen in denen ein stets angepasstes Verhalten n tig ist Ein System was sich in einer solchen Umgebung zurechtfinden und vern nftige Entscheidungen treffen soll muss vor allem schnell reagieren k nnen Daher wurde in diesem Projekt Wert darauf gelegt eine Programmschleife mit einer m glichst kurzen Zyklus Zeit zu realisieren Die Hauptrechenzeit geht dabei zu Lasten der Verarbeitung der Sensorendaten und der darauf aufbau enden Selbstlokalisation Nur einen kleinen Teil der Rechenzeit verwenden im Vergleich dazu die Routinen der strategischen Entscheidungsfindung und Bahnplanun
4. 3 Schusseinheit 3 Pneumatikzylinder mit Feder an Aluminiumhebel 65 4 3 SCHUSSEINHEIT KAPITEL 4 SYSTEMTESTS Abbildung 4 5 Schusseinheit bestehend aus einem Pneumatikzylinder ohne Feder 4 Schusseinheit 4 Pneumatikzylinder ohne Feder an Aluminiumhebel Abbildung 4 6 Schusseinheit bestehend aus einem Pneumatikzylinder mit ohne Feder an einem Aluminiumhebel e Testaufbau und Durchf hrung Der Ball wird direkt an der Schusseinheit anliegend durch Ausl sen der Schusseinheit beschleunigt Gemessen wird die Zeit die der Ball ben tigt um eine Distanz von 5m zur ckzulegen Daraus wird die durchschnittliche Geschwindigkeit des Balls berechnet Jeder Aufbau wurde f nfmal getestet und aus diesen Werten der Mittelwert berechnet e Testergebnisse Zeit s Geschwindigkeit m s SE1 4 25 1 17 SE2 3 15 1 58 SE3 15 3 33 SEA 1 9 2 56 Tabelle 4 1 Verschiedene Schusseinheiten mit Zeit und durchschnittlicher Geschwindigkeit auf 5m Bei diesen Ergebnissen f llt auf dass zwar Schusseinheit 2 den Ball st rker beschleunigt als Schusseinheit 1 da der Pneumatikzylinder ohne Feder einen gr eren Hub hat dieser Vorteil je 66 4 4 WETTBEWERBE KAPITEL 4 SYSTEMTESTS doch durch die Verwendung eines Hebels aufgehoben wird Durch den Hebel wird die Zeit in der der Ball beschleunigt wird erh ht so dass hier nicht mehr der Hub des Zylinders entscheidend ist sondern die Geschwindigkeit der Aus
5. Abbildung 3 9 Gleichverteilung der Partikel zu Beginn des Algorithmus Um das Kidnapped Robot Problem zu l sen beobachtet man ob die Partikelwahrscheinlichkeiten sehr gering sind um dann eine neue Gleichverteilung durchzuf hren alternativ wird zus tzlich einen Teil gleichverteilter Partikel eingestreut um eine eventuell bessere Position zu finden Zur Partikelrepr sentation dient die Klasse CParticle die einen zweidimensionalen Vektor als Position einen Winkel als Ausrichtung und eine Flie komma Zahl als Gewicht Wahrscheinlichkeit enth lt Die Klasse CHohensyburg enth lt ein Array aus Instanzen der Klasse CParticle um die Verteilung Bel l d o zu repr sentieren Im Folgenden werden die einzelnen Methoden der Klasse CHohensyburg vorgestellt e run ein Schleifendurchlauf des Partikelfilters e equalDistributeParticles Gleichverteilung der Partikel ber den gesamten Feldbereich siehe Abbildung 3 9 e moveParticlesByOdometry Verschieben und Verrauschen der Partikel um die Odometrieda ten vgl Algorithmus 5 e validateParticlesBySensors Neugewichtung der Partikel durch Vergleich Sensorwert erwarteter Wert vgl Algorithmus 6 e resampleParticles Neuziehung der Partikel gem ihrer Wahrscheinlichkeit Als Ausgabe des Algorithmus kann der Partikel mit der gr ten Wahrscheinlichkeit oder das gewichtete Mittel der Partikelverteilung benutzt werden beides wird in der Methode validate ParticlesBySensors ber
6. BEDIENUNGSANLEITUNG ber die Checkboxen im unteren Bereich des Fensters lassen sich die folgenden Einstellungen vornehmen e Use BG Feat das Blue Goal Feature f r die Selbstlokalisation de aktivieren e Use YG Feat analoge Bedeutung zu Use BG Feat e Use Dist ance die Abst nde von den Torpfosten flie en in die Selbstlokalisation mit ein e Use EQ Dist ributed Particles einstreuen gleichverteilter Partikel um eine bessere Position zu finden e direct Angles die Winkel zur Berechnung der Position werden direkt in der Bildverarbeitung gemessenen und unabh ngig voneinander zur Bewertung der Wahrscheinlichkeit eines Partikels verwendet e HeadInv Angles von der Ausrichtung unabh ngige Winkel verwenden z B Winkel zwischen 2 Torpfosten e Turn Particle die Partikel an den Features ausrichten e CalcW MedAngle die Partikelausrichtung aus dem Mittelwert aller Ausrichtungen berechnen e Use Poles Die Eckfahnen des Spielfeldes f r die Selbstlokalisation de aktivieren Wenn diese z B nicht korrekt erkannt werden w rden sie die Selbstlokalisation verf lschen und k nnen deshalb deaktiviert werden e Use Analyse Jumps Herausfinden ob die Selbstlokalisation stark schwankt und in diesem Fall automatisch ganz auf Odometrie umschalten Achtung diese Funktion funktioniert auf dem Feld ganz gut im Tor aber so gut wie gar nicht Als weitere Funktion die die Oberfl che der Selbstlokalisation bietet kann man ber den Regler im
7. Daten arbeiten zu lassen neue Ans tze sind so besser vergleichbar mit bisherigen Benchmark Aufwendige Tests mit realer Hardware wobei auftretende Probleme oft schlecht reproduzierbar sind k nnen mit solchen Testdaten bequem erforscht werden Im letzten Schritt wurde eine Aufzeichnung der Bilder der omnidirektionalen Kamera erm glicht wodurch sowohl Bildverarbeitung als auch Selbstlokalisation offline getestet werden k nnen 64 4 3 SCHUSSEINHEIT KAPITEL 4 SYSTEMTESTS Abweichung der Selbstlokalisation Fehler 600 F A 500 F Abweichung mm 300 F T J7 ES ES tF ea cn de HEE M HE 200 E N iS fi To sl Bt id 100 F eg 0 l 1 l l l l l 0 2000 4000 6000 8000 10000 12000 14000 16000 Zeit ms Abbildung 4 3 Abweichungen der Selbstlokalisation von der idealisierten Bewegung mit 0 5 m s 4 3 Schusseinheit Zur Weltmeisterschaft sollten alle Roboter mit einer neuen Schusseinheit ausgestattet werden Voraus setzung hierbei war die Nutzung des Pneumatikzylinders und des Luftdruckbeh lters vgl Abschnitt 2 4 Getestet wurden verschiedene Aufbauten sowie Komponenten der Schusseinheit Ziel dabei war es die mittlere Geschwindigkeit des Balls zu maximieren Folgende Kombinationen wurden getestet 1 Schusseinheit 1 Pneumatikzylinder mit Feder Abbildung 4 4 Schusseinheit bestehend aus einem Pneumatikzylinder mit Feder 2 Schusseinheit 2 Pneumatikzylinder ohne Feder
8. Defend2 Der Verteidiger deckt die linke Seite vor dem eigenen Tor ab Defend3 Der Verteidiger darf beide Seiten abdecken befahren GoalieNew Weiterentwicklung des Paderborn Torwarts nicht perfekt er verf gt ber eine bessere Selbst lokalisation GoalieNewRel Die Torwart entspricht weitestgehend dem GoalieNew mit dem Unterschied dass dieser relativ f hrt d h er muss beim Start genau mittig vor dem Tor platziert werden GoalieYMove Der Torwart bleibt auf einer Linie vor seinem Tor und bewegt sich ausschlie lich in y Richtung also links rechts GoalieMixed Erste Version des Padua Torwarts mit guter Selbstlokalisation und fast perfektem Stel lungsspiel A 5 2 Direktwahl Tasten Taste Bedeutung Taste Bedeutung i Aufruf Bildverarbeitungsfensters l Aufruf Selbstlokalisationsfensters p Aufruf Pathfinder Fensters o Aufruf Odo SL Fensters S Starten der Main Loop h Stoppen der Main Loop g Starten des Roboters CTRL g Homepositionen anfahren CTRL y Beenden der Tribots Anwendung SPACE sofortiges Stoppen des Roboters Tabelle A 1 Direktwahltasten in der Tribots Anwendung 86 A 6 PROBLEMBEHEBUNG ANHANG A BEDIENUNGSANLEITUNG A 6 Problembehebung Dieser Abschnitt beschreibt m gliche Probleme beim Betrieb des Roboters und Bedienungsfehler des Tribots Programms und deren L sung Nat rlich k nnen die beschriebenen Probleme auch vielf ltige andere Ursachen
9. Selbstlokalisation berpr fen Um b se berraschungen nach dem Start des Roboters zu vermeiden ist es ratsam auch noch einen Blick auf die Selbstlokalisation zu werfen Wird die Position des Roboters dort nicht ein wandfrei erkannt liegt das in der Regel an einer mangelhaften Einstellung der Bildverarbeitung also zur ck zu Punkt 5 Fahrbefehle starten ber Go bzw ber die Kommunikationssoftware die Fahrbefehle aktivieren Bei Problem mit der Kamera bitte beachten Eines der wenigen Probleme die hierbei auftreten k nnen ist dass die Kamera nicht gefunden wird kein gr nes Signal hinter dem Kamera Modul oder abst rzt In beiden F llen sollte die Tribots Anwendung beendet die Stromzufuhr der Kamera kurz unterbrochen und sudo firewire restart ausgef hrt werden Die Tribots Anwendung anschlie end wieder starten im Normalfall sollte die Kamera dann korrekt arbeiten 85 AS KURZREFERENZEN ANHANG A BEDIENUNGSANLEITUNG A 5 Kurzreferenzen A 5 1 Playertypen Goalie Dies ist der Paderborn Torwart m ig stark aber immer f r berraschungen gut Attackl Der Angreifer darf sich ausschlie lich im gegnerischen Spielfeld aufhalten und wartet dort bis er in Ballbesitz ist in Ballbesitz gelangen kann Attack2 Der Angreifer darf sich in beiden Spielfeldh lften bewegen und steuert bei Ball Besitz umgehend das gegnerische Tor an Defend1 Der Verteidiger deckt die rechte Seite vor dem eigenen Tor ab
10. buchsta ben und falls n tig weiteren Zahlen bzw Literalen die durch Kommata getrennt werden Abgeschlos sen werden Befehle mit einem Linefeed oder Carriage Return Die Antwort des Kameleonboards auf diesen Befehl beginnt mit dem gleichen Buchstaben in klein und falls n tig folgen weitere durch Kommata getrennte Zahlen oder Literale Dieses Protokoll war f r einfache Anwendungen ausreichend f r unser Projekt bedurfte es aber einiger Modifikationen Der Basisbefehl der bisher aus einem Zeichen bestand wurde auf zwei Zei chen erweitert z B gab es f r den bisherigen Befehl D lt Motor gt lt Speed gt zum Setzen der Mo torgeschwindigkeit eines Motors nun zwei neue Befehle DA lt Motor gt lt Speed gt und DB lt SpeedO gt lt Speed1 gt lt Speed2 gt lt Speed3 gt Der eine ahmte den Befehl des Original Protokolls nach und der andere erhielt als Parameter die Soll Motorgeschwindigkeiten aller Motoren Dieses Vorgehen wurde m glichst konsistent bei allen Befehlen durchgesetzt Das Grundger st f r das neue Protokoll LPRSerCom lieferte John Sweeney Laboratory for Perceptual Robotics UMASS Amherst Massachusets dem an dieser Stelle besonderer Dank gilt Aus eigenen Messungen konnte festgehalten werden dass die Kommunikation ber das selbstent worfene Protokoll Laufzeitvorteile mit sich brachte Begr nden l sst sich dies durch die verminderte Anzahl an Verbindungsaufbauten zwischen Steuerrechner und Motorcontroller Um bei
11. die der Torwarts trifft stark von der Ballbewegung abh ngt Aktionsraum Vor dem eigenen Tor wird ein Kreisbogen definiert auf dem sich der Roboter be wegen soll Der Aktionsraum des Torwarts ist dadurch auf den Bereich den die Torlinie mit dem Kreisbogen einschlie t beschr nkt vgl Abbildung 3 21 Abbildung 3 21 Aktionsraum des Torwarts Der Aktionsraum des Torwarts liegt innerhalb des farblich hervorgehobenen Bereichs Normalerweise bewegt er sich auf dem einge zeichneten Kreisbogen In Ausnahmef llen darf dieser Bereich verlassen werden etwa dann wenn der Torwart den Ball von hinten anfahren muss um ihn von der Torlinie zu bef rdern oder auch wenn sich der Ball seit mehreren Sekunden in Strafraumn he befindet um den Ball dort zu entfernen In jedem Fall aber wird der Torwart nie links und rechts ber die Pfosten hinaus fahren Diese Einschr nkung tr gt wesentlich zur Robustheit bei da so die Kollision mit den Pfosten und eine damit verbundene Delokalisation vermieden wird So gab es beispielsweise bei den Weltmeisterschaften 2003 in Padua keinen durch ein solches Problem bedingten Ausfall des Torh ters 48 3 4 STRATEGIE KAPITEL 3 SOFTWARE Ballbeobachtung Die relativen Ballkoordinaten bekommt der Torwart in jedem neuen Zyklus aus der Bildverarbeitung kombiniert mit seiner aktuellen Position auf dem Spielfeld kennt er damit die Ballposition Bildet man den Vektor von der letzten Ballposition zur aktuellen so
12. e 49 Tribots Control a 8 3842 a A ne A A Ai 52 Komponenten eines Robotermoduls und deren Realisierung 53 Zeit zum Setzen der Motorgeschwindigkeiten Kameleon 54 Zeit zum Setzen der Motorgeschwindigkeiten TMC 2 2 2222 55 Kommunikationsschema von RT Linux Co En 56 ABBILDUNGSVERZEICHNIS ABBILDUNGSVERZEICHNIS 3 28 Modifikation eines Ansteuerungsbefehl durch das Beschleunigungsmodul 59 3 29 Oberfl che des Robocup Simulators SimSrv e 61 4 1 Anfahrt auf einen Ball mit konstanter Geschwindigkeit 63 4 2 Fahrt des Roboters quer ber das Spielfeld 2 2 0 o 64 4 3 Abweichungen der Selbstlokalisation von der idealisierten Bewegung mit 0 5m s 65 4 4 Schusseinheit bestehend aus einem Pneumatikzylinder mit Feder 65 4 5 Schusseinheit bestehend aus einem Pneumatikzylinder ohne Feder 66 4 6 Schusseinheit bestehend aus einem Pneumatikzylinder mit ohne Feder an einem Aluminiumhebel 20 a ers A tn er na 66 4 7 Vorrundenspiel der German Open gegen Clockwork Orange 2 22 22 68 4 8 WM Padua Zwischenrundenspiel gegen Uni T bingen o 69 A 1 Hauptfenster der Tribots Anwendung 2 2 2 En rn nn 75 A 2 Kontextmen der Tribots Anwendung 2 2 2 2 m nr nn 76 A 3 Bildverarbeitungsfenster der Tribots Anwendung 2 22 2 a nn nenn 77 A 4 Selbstlokalisationsfenster der Tribots Anwe
13. genden wird detailliert beschrieben wie die Kalibrierung vorzunehmen ist worauf zu achten ist und wie man eine m glichst gute Qualit t bez glich der Bilderkennung erreicht Abbildung A 3 zeigt zur besseren Verdeutlichung einen Screenshot des Fensters Die Bildverarbeitung muss im Robocup die Farben orange Ball gr n Spielfeld gelb Tor blau Tor schwarz Hindernisse und wei Linien und Torpfosten erkennen Alle sechs Farben k nnen deshalb separat ber die graphische Oberfl che eingestellt werden und besitzen hierf r einen eigenen Kalibrierungsbereich mit je drei Schiebereglern Neben den Konfigurationsbereichen enth lt das Fenster das aktuelle segmentierte Kamerabild Auf fallend bei dem Bild sind drei Kreise zwei im u eren Bereich einer im inneren Bereich des Bildes sowie die vom Mittelpunkt des Bildes sternf rmig ausgehenden Linien X ImageProcessing m Particles Bildmitte ament whit weiss Rot Abbildung A 3 Bildverarbeitungsfenster der Tribots Anwendung Alles was sich im inneren Kreis befindet wird nicht segmentiert da hier die Bilderkennung zu ungenau ist bzw das Kameraobjektiv als Hindernis erkannt w rde Der u ere Kreis sollte das obere Drittel der Torpfosten der mittlere Kreis das untere Drittel der Torpfosten durchlaufen Nachfolgend ist nun eine Auflistung der einzelnen Funktionsbereiche zu finden e Save Button speichert die aktuellen Einstellungen Segment ON OFF schaltet die Anzei
14. rielle Schnittstelle e ROB_WHEEL_RADIUS_DEF Raddurchmesser eines omnidirektionalen Rades m e ROB_GEAR_PARAM_DEF Untersetzungsverh ltnis des Motorgetriebes e ROB_PULSES_PER_TURN_DEF Impulsanzahl des Encoders pro Umdrehung e TMC_COM SPEED Kommunikationsgeschwindigkeit der seriellen Schnittstelle Baud Wertebereich 9600 19200 57600 e TMC_WORKINGMODE Arbeitsmodus des TMC200 Wertebereich 0 2 e TMC_ANSWERMODE Antwortmodus des TMC200 Wertebereich 0 5 e TMC_2ENCRES Doppelte Encoderaufl sung Wertebereich 0 5000 e TMC_MAXV Maximale Motordrehzahl Leerlaufdrehzahl D Wertebereich 0 20000 e TMC_DELTADIST Distanz nderung pro Encoderschritt Wertebereich 0 5000 um Schritt e TMC_CMAX maximaler Anlaufstrom 10mA Schritte Wertebereich 0 1000 e TMC_CNOM Dauerlaststrom 10mA Schritte Wertebereich 0 1000 e TMC_MAX_TEMP maximal erlaubte Motorwicklungstemperatur C Wertebereich 0 1000 95 B 4 KONFIGURATIONSDATEIEN ANHANG B HARDWARE TMC_MIN_TEMP Abschalttemperatur der Strombegrenzung C Wertebereich 0 1000 TMC_P Proportional Anteil des PID Reglers Wertebereich 0 1000 TMCI Integral Anteil des PID Reglers Wertebereich 0 1000 TMC_D Differential Anteil des PID Reglers Wertebereich 0 1000 KAM_COM_SPEED Kommunikationsgeschwindigkeit der seriellen Schnittstelle KAM _P Proportional Anteil des PID Reglers KAM I Integral Anteil des PID Reglers KAM
15. 10 ms was f r unsere Zwecke nicht ausreichend war Unter der Verwendung von 56 3 6 ROBOTERMODUL KAPITEL 3 SOFTWARE RT Funktionen wurde eine Aufl sung von 1 ms erreicht Mit Hilfe dieser beiden Funktion wird ein sehr genauer Timer angeboten mit dem ein Benutzerprozess zeitgesteuert werden kann block sendet ber den Kommando FiFo die Wartezeit delta_t daraufhin wird im Ker nel Space der Timer gestartet und beim berschreiten des Zeitlimits ein Signal auf dem Signal FiFo in den User Space gesendet auf welches wait_for_deblock wartet Controller Modul Nachdem durch das Kommunikationsmodul ein rudiment res System zum Nachrichtenaustausch etabliert wurde ist es nun notwendig eine Controller spezifische Befehlsim plementierung vorzunehmen Jede der neuen Funktionen benutzt das Kommunikationsmodul und insbesondere die Funktion rt_talk zum Nachrichtenaustausch mit dem Controllerboard Jeder der eingesetzten Controller hat seine eigenen Besonderheiten so dass die Schnittmenge der gemeinsamen Funktionen unterhalb der Controllerboards recht klein ist Im Wesentlichen beschr nkt sie sich auf das Setzen von Geschwindigkeiten PID Parametern und dem Auslesen von Daten aus den Inkrementalencodern der Motoren Einige dieser allgemeinen Funktionen sowie einige spezifische werden nachfolgend n her beschrieben e kam set_motor_V kam_data_type data int nMotor int speed setzt die Geschwindigkeit des Motors nMotor auf den Wert spe
16. 3 4 Eingabe absolutes Weltmodell robozentrische Regionen der Bildverarbeitung Anweisungen des zentralen Kommunikationsrechners zum Rollenwechsel Im Strategiemodul werden passend zur aktuellen Situation die Aktionen berechnet die der Roboter durchzuf hren hat um ein bestimmtes Ziel zu erreichen Dabei wird die Rolle wie Verteidiger Angreifer oder Torwart ber cksichtigt Dazu geh rige Ziele sind beispielsweise Ver teidigung des Torraums Verteidigung der eigenen H lfte oder Angriff auf das gegnerische Tor Eine w hlbare Aktion k nnte sein dass ein Verteidiger in seiner H lfte patrouilliert um an greifende Gegner abzuwehren Dabei ist in Abh ngigkeit von den Eingabedaten zu beachten Wenn die G te der Selbstlokalisation unter einen Schwellwert f llt kann das Weltmodell nicht als Eingabe zur Berechnung einer Aktion akzeptiert werden Statt dessen werden die Regionen der Bildverarbeitung benutzt Aus den vorliegenden Informationen zur Umgebung Richtung und Entfernung zu Hindernissen Toren und Ball und den lokalen Randbedingungen des Roboters wie Maximalgeschwindigkeit wird ein Fahrbefehl berechnet Falls der zentrale Kom munikationsrechner einen Rollenwechsel verlangt so flie t dies ebenfalls bei der Berechnung der Ansteuerung mit ein Ausgabe Ansteuerungsbefehl Kommunikationsmodul siehe Abschnitt 3 5 Eingabe Anweisung zum Rollenwechsel Das Kommunikationsmodul kommuniziert mit einem zentralen Rechner der zus tzlich z
17. 60 l l l l l 1 l 0 50 100 150 200 250 300 350 400 Winkel Abbildung 3 7 Aufgenommene Daten der Distanzkalibrierung Die einzelnen Linien entsprechen dem Pixelabstand der verschiedenen Marker von der Bildmitte bei der Distanzkali brierung Anhand des Kurvenverlaufs l sst sich erkennen dass Spiegel und Kamera nicht optimal aufeinander ausgerichtet sind unterst tzt eine sehr genaue Objekterkennung ber eine l ngere Bildfolge Die erste Positionsbe stimmung eines Objektes in einem Bild kann durchaus noch ungenau sein wenn diese Position ber mehrere Bilder verfeinert wird Dieses Verfahren eignet sich besonders f r die Verfolgung kleinerer Objekte in der Entfernung dabei betr gt beispielsweise die Ballgr e ab etwa f nf Meter nicht viel mehr als 2 3 Pixel Als Ausgangspunkt wird in jedem Schritt entweder das Ergebnis des letzten Schleifendurchlaufes oder die grobe Aufteilung nach dem Durchlauf des seedSearch Algorithmus siehe Algorithmus 2 benutzt Bei den Toren werden Pixel die in der Suchphase dem Tor zugeordnet wurden fortge pflanzt indem je 500 Nachfolger aus den gefunden Pixeln erzeugt werden Die Nachfolger befinden sich bei den Toren und Eckfahnen direkt radial versetzt um 20 Beim Ball werden sie um 20 Pixel horizontal und vertikal versetzt gew hlt Die Idee des Algorithmus besteht darin dass wirklich zum Tor geh rende Pixel bzw dem zu verfolgenden Objekt geh rende besonders viele Nachbarn haben die di
18. Bereich was f r zeitkritische Anwendungen wie unsere zu hoch ist Im Gegensatz dazu erreicht unser selbstentwickeltes Protokoll einen Durchschnitt von 8ms mit Ausrei ern im Bereich von 15 bis 30 ms An den Abbildungen 3 25 sieht man die zeitliche Differenz noch einmal verdeutlicht Neben dieser Verbesserung wurden noch weitere Befehle in das Protokoll integriert Unter anderem waren dies ein Notstop Befehl der sofort alle Motorgeschwindigkeiten auf Om s gesetzt hat und ein Befehl zum Sperren der Schusseinheit auf die im Abschnitt 2 4 genauer eingegangen wird TMC Das TMC200 ist ebenso wie das Kameleonboard frei programmierbar jedoch ist der daf r erforderliche Crosscompiler nicht kostenlos verf gbar Als Konsequenz hieraus wurde das durch das Fraunhofer Institut vorgegebene Protokoll bernommen Gl cklicherweise ist das Protokoll noch in der Entwicklungsstufe so dass nderungsw nsche von unserer Seite mit integriert worden sind Neben der RS 232 Schnittstelle kann die Anbindung an den Steuerrechner ebensogut ber den CAN Bus geschehen zum jetzigen Zeitpunkt ist dieser Teil aber noch nicht implementiert Alle wichtigen Parameter wie Reglerkonstanten Motorgr en und Arbeitsmodi k nnen ber die jeweilige Kommunikationsschnittstelle eingestellt werden Die Kommunikation zwischen Steuerrechner und Controller l uft gr tenteils analog zum Kame leonboard der Rechner bernimmt die Rolle eines Masters und das TMC die Slave Rolle wobei n
19. Control TribotsControl registriert den Ausfall der Spielerrole und errechnet aus den noch verf gbaren Spielern die ideale Aufstellung So muss z B zu jedem Zeitpunkt genau ein aktiver Torwart verf gbar sein TribotsControl sendet an die Roboter ihre aktualisierten Roles und diese Anweisung wird un mittelbar von den Robotern umgesetzt Es ist erw nscht dass ein Roboterausfall m glichst fr h erkannt wird um n tige Ma nahmen rechtzeitig zu ergreifen Aufgrund der physikalischen Belastung der Kamera kann es zu einem Absturz des Kameramoduls kommen der von der Roboter Software registriert wird Das Kommunikationsmodul sendet den Ausfall des Roboters an TribotsControl und ein Wechsel der Rollen wird berpr ft und falls n tig an die Roboter kommuniziert Analog zu einem Spielerausfall wird auch bei einer Spielereinwechselung evtl ein Rollenwech sel n tig Dies ist z B der Fall wenn der dedizierte Torwart wieder zur ck ins Spiel kommt und der momentane Torwart wieder seine alte Rolle einnehmen muss Auch hier nimmt TribotsControl automatisch alle ben tigten Wechsel vor 5l 3 5 KOMMUNIKATION KAPITEL 3 SOFTWARE 3 5 3 TribotsControl TribotsControl ist zum einen die zentrale Kommunikationsschnittstelle der Tribots Architektur zum anderen stellt es eine graphische Schnittstelle zur Administration und berwachung der Roboter be reit Die Roboter k nnen remote gestartet gestoppt und zur Homeposition beordert werden Role TargetGo
20. D Differential Anteil des PID Reglers tribots cfg CamDummy 0 1 Kamera wird angesteuert es werden Bilddaten aus einer Datei eingelesen CAM_FILENAME Datei die Bilddaten enth lt im YUV Format TEST_MODE_ACTIV 0 1 schaltet die Testroutinen an aus TEST_TAKT Dauer eines Schleifendurchlaufs aller Module in ms TEST _KICK 0 1 schaltet Test der Kickeinheit an aus TEST_ODO 0 1 schaltet Test der Odometrie an aus TEST_LINE SL 0 1 schaltet Selbstlokalisationstest auf einer Linie fahren an aus TEST_LINE_SL_SPEED Geschwindigkeit f r den Test in m s TEST_LINE_SL_DISTANCE Distanz die gefahren wird in m TEST _SIDE_ACC 0 1 schaltet den Test seitwaertsfahren an aus TEST_SIDE_ACC_PASSES Anzahl von seitw rtsbewegungen TEST_APPROACH_POINT 0 1 schaltet den Test auf Punkt fahren an aus TEST_APPROACH _POINT1_X X Koordinate des 1 Punktes TEST_APPROACH_POINT1_Y Y Koordinate des 1 Punktes TEST_APPROACH POINT2_X X Koordinate des 2 Punktes TEST_APPROACH POINT2_ Y X Koordinate des 2 Punktes TEST_APPROACH_POINT3 lt X X Koordinate des 3 Punktes TEST_APPROACH_POINT3_Y X Koordinate des 3 Punktes TEST_APPROACH_POINT4_X X Koordinate des 4 Punktes 96 B 4 KONFIGURATIONSDATEIEN ANHANG B HARDWARE TEST_APPROACH_POINT4_Y X Koordinate des 4 Punktes TEST FOLLOW HALSBAND 0 1 schaltet den folge Halsband Test an aus DISTANCE CALIBRATION 0 1 schaltet Disatnzkalibreirung an aus wird nicht b
21. Differenz zwischen dem Rot und dem Gr nwert eines Pi xels mindestens sein muss damit der Pixel als Rot erkannt wird RotGr nDifferenz wie gro der Rotwert eines Pixels mindestens sein muss damit der Pixel als Rot erkannt wird BallEinstellungen und wie gro die Differenz zwischen Rot und Blauwert eines Pixels sein muss damit der Pixel als Rot erkannt wird RotBlauDifferenz Am Anfang sollten also alle Regler niedrig eingestellt sein Durch Heraufsetzen der Regler l sst sich die Erkennung einschr nken e Wei Kalibrierung Die Regler geben an wie gro der Rotwert eines Pixels mindestens sein muss damit der Pixel als Wei erkannt wird Wei Rot wie gro der Gr nwert eines Pixels mindestens sein muss damit der Pixel als Wei erkannt wird Wei Gr n und wie gro der Blauwert eines Pixels sein 78 A 2 TRIBOTS ANWENDUNG ANHANG A BEDIENUNGSANLEITUNG muss damit der Pixel als Wei erkannt wird Am Anfang sollten alle Regler niedrig eingestellt sein Durch Heraufsetzen der Regler l sst sich die Erkennung einschr nken Gr n Kalibrierung Die Regler geben an wie gro der Gr nwert eines Pixels mindestens sein muss damit der Pixel als Gr n erkannt wird Gr nGr n wie gro der Rotwert eines Pixels h chstens sein darf damit der Pixel als Gr n erkannt wird Gr nRot und wie gro der Blauwert des Pixels h chstens sein darf damit der Pixel als Gr n erkannt wird Gr nBlau Am Anfang sollte Gr nGr n niedr
22. Kommunikationsprotokoll Der Kommunikation zwischen einem Steuerrechner und dem Motorcontroller muss ein wohldefiniertes Protokoll zugrunde liegen wobei Befehle klar strukturiert gleichzeitig aber so knapp wie m glich gehalten werden sollten Die einfache Erweiterbarkeit des Protokolls um weitere Befehle ist ein Merkmal eines durchdachten Ansatzes Wie bei jeder anderen 53 3 6 ROBOTERMODUL KAPITEL 3 SOFTWARE Kommunikation zwischen zwei Endpunkten gibt es selbstverst ndlich den Bedarf an Zuverl ssigkeit d h auf dem bertragungsweg sollten Nachrichten nicht verloren gehen oder ver ndert werden Sollte wider Erwarten trotzdem eine bertragung modifiziert werden dann muss ein Mechanismus diesen Fehler erkennen Beide Motorcontroller bieten die M glichkeit der direkten Kommunikation durch das Senden bzw Empfangen von ASCH Nachrichten ber die RS232 Schnittstelle Die dabei verwendeten Protokolle weichen voneinander ab und werden in den folgenden Abschnitten separat beschrieben Kameleon Das integrierte Protokoll SerCom des Kameleonboards erlaubt die komplette Kontrolle der Boardfunktionalit t ber die serielle Schnittstelle Eine genaue Beschreibung der einzelnen Be fehle findet sich unter Anhang A in 9 Durch den Einsatz des REB siehe Unterabschnitt 2 3 1 erweitert sich der Befehlssatz um die in Anhang B von 10 beschriebenen M glichkeiten Ein Befehl wird ausschlie lich vom Steuerrechner abgesetzt und besteht aus einem Gro
23. P Lima T Nakamura F Ribeiro and T Schmitt Middle size robot league rules and regulastions for 2003 M rz 2003 J R Carpenter P Clifford and P Fearnhead Sampling strategies for monte carlo filters of non linear systems 2000 Arnaud Doucet On sequential monte carlo sampling methods for bayesian filtering 1998 S P Engelson and D V McDermott Error correction in mobile robot map learning In IEEE International Conference on Robotics and Automation pages 2555 2560 Nizza Frankreich Mai 1992 Roland Hafner Reinforcement Lernen auf mobilen Robotern Diplomarbeit Universit t Karls ruhe 2002 Fraunhofer Institut TMC Handbuch Bonn 2003 Sascha Lange Tracking of color marked objects in a 2 dimensional space Bachelor Arbeit Universit t Osnabr ck 2001 maxon motor AG Quick Assembly Two and Three Channel Optical Encoders April 2000 K TEAM S A Kameleon 3765BC User Manual Lausanne 1999 K TEAM S A Kameleon Robotics Extension User Manual Lausanne 2001 Sony Technical Manual Ver1 0 English 2001 S Thrun D Fox W Burgard and F Dellaert Robust monte carlo localization for mobile robots Artificial Intelligence 128 1 2 99 141 2000 101
24. Port eingesetzt werden F r das Ziel eines autonomen Roboters verbietet sich die L sung durch Standard PCs aus mehreren Gr nden so dass verst rkt nach Notebooks gesucht wurde welche den Anforderungen 14 2 2 STEUERRECHNER KAPITEL 2 HARDWARE gen gten Kritikpunkte waren u a diese e Stromversorgung Auf dem Roboter selbst befinden sich zwei getrennte Stromkreise einer mit 12V DC und einer mit 24V DC Moderne Rechner sind mit sog ATX Boards ausgestattet Setzt man solche ein dann erfordert dies die Bereitstellung weitaus vielf ltigerer Spannungen wie 3 3 V 5 V 5 V 12 V sowie 12 V und einen erh hten Hardwareaufwand Gleichzeitig wird mit dem ATX Board ein neuer Verbraucher an die Akkumulatoren geh ngt dessen Leis tungsaufnahme im Bereich zwischen 150 und 250 Watt liegt Verglichen mit den maximal 20 Watt pro Motor l sst sich die Unverh ltnism igkeit der Mittel schnell erkennen e Ma e Die Ma e eines ATX Boards belaufen sich auf ca 30 5x24 4 cm LxB Als Referenz dient das K7S5A Mainboard der Firma Elitegroup auf aktuelleren Boards sind bereits Grafikkarten integriert womit die Gesamth he einer ATX L sung mit nicht mehr als 5 cm abgesch tzt wird Der Einsatz eines off the shelf Notebooks w rde zu den gleichen Ausma en f hren jedoch sofort das Problem der Stromversorgung l sen e Peripherie wird eine L sung durch Standard PCs verfolgt so ergibt sich zwangsl ufig die Frage welche weiteren periphere
25. Projektgruppe wurden zus tzlich zu der selbst entwickelten Software weitere Werkzeu ge eingesetzt die das Programmierer Leben erleichtern sollten Neben einer IDE zur Quellcode Erzeugung wurden z B noch ein Dokumentationswerkzeug und eine Quellcode Verwaltung f r sinnvoll gehalten Die kommenden Abschnitte erl utern welche speziellen Werkzeuge zum Einsatz kamen 3 7 1 Tools Zur Verwaltung unseres Projekts setzten wir cvs ein F r eine ausf hrliche Dokumentation verweisen wir auf www cvs org Die Entwicklungsumgebung die von uns am meisten genutzt wurde war KDevelop Einige ver wendeten Emacs aber die meisten Bestandteile wurden mit KDevelop entwickelt Das Programm und die dazugeh rige Dokumentation findet man unter www kdevelop org Die Qt Bibliothek zu finden unter www trolltech com ist eine stabiles und zugleich einfach zu verwendendes Framework f r grafische Applikationen jedoch nicht ausschlie lich Es unterst tzt Techniken wie TCP IP Threads uvm Doxygen nutzten wir zur Erstellung von Programm Dokumentationen Es stellt verschiedene Aus gabeformate wie HTML RTF Postscript PDF und Unix man pages zur Verf gung Doxygen und seine Dokumentation ist unter www doxygen org zu finden Die Kamera wurde ber die Bibliothek cvtk 7 angesteuert Dabei nutzt cvtk die oben erw hnten Schnittstellen 1ibdc1394 und libraw1394 vgl Abschnitt 3 2 cvtk kann aber nicht nur die Kamera ansteueren sondern bietet zudem die M glichke
26. Schusseinheit untersch tzt wurde Am zweiten Tag zahlten sich die nderungen bereits aus die Leistung verbesserte sich erheb lich Dem bis dahin f hrenden Team der eigenen Gruppe IUT Persia aus dem Iran konnte ein 1 1 abgerungen werden Dieses Team war auch erst kurz dabei und verfolgte einen komplett anderen Ansatz Man hatte einen einzigen funktionierenden Roboter der jedoch sehr schnell war den Ball gut f hren konnte und zudem noch eine leistungsf hige Schusseinheit besa die er in alle Richtungen abfeuern konnte Man konnte diesem Ein Mann Sturm mit einer geordneten Abwehr und einem we sentlich st rkeren Torwart entgegentreten Die Anf lligkeit der Hardware und die St rmerleistungen Inttp borneo ais fraunhofer de G0 2003 67 4 4 WETTBEWERBE KAPITEL 4 SYSTEMTESTS Abbildung 4 7 Vorrundenspiel der German Open gegen Clockwork Orange verhinderten jedoch dass dieses Spiel gewonnen werden konnte Im n chsten Spiel gegen das etablierte Team Clockwork Orange aus Holland zeigte sich dass das eigene Team trotz wesentlich k rzerer Entwicklungszeit schon einen gro en Schritt getan hatte Die holl ndische Mannschaft wurde mit 2 0 besiegt dabei erwiesen sich besonders Abwehr und Tor wart als besser als die der Veteranen deren Roboter leicht beh big wirkten Dies lag aber auch an dem wesentlich lteren Konzept mit Differential Fahrwerk und einem recht schweren Aufbau F r das attraktive Spiel mit einer guten Strat
27. Tors Es l sst sich erkennen dass sich die Partikel durchsetzen die in der Entfernung zum Tor mit den gemessenen Werten m glichst gut bereinstimmen 39 3 3 WELTMODELL KAPITEL 3 SOFTWARE 1 2 3 4 5 for i 0 to i lt m_NumberO f Particles do x y p Gauss es werden 3 Gau verrauschte Variablen erzeugt m_Particles i m_particleOdometry new C Particle x y py i end for Die Odometrieinformation ist in der Partikelstruktur m_particle0dometry gespeichert da auch sie Position und Ausrichtung beinhaltet Algorithmus 5 void CHohensyburg moveParticlesByOdometry for i 0 to i lt m_NumberO f Particles do validateValue 1 if linker und rechter Torpfosten sichtbar then validateV alue Prob Winkel zwischen den Pfosten ist m glich an der Partikelposition end if Pr fe weitere m gliche Kombinationen aus Landmarken Partikelgewicht m_Particle i m_Probability validateV alue i end for normalisiere m_Particle i m_Probability so dass X om Particle i m Probability 1 Als PDF wurde die Funktion 180 x gew hlt Nach Normierung des Ergebnisses auf Das Intervall 0 1 ergibt sich f r den Winkelunterschied 0 eine Wahrscheinlichkeit von 1 und mit dem Winkelunterschied 180 ergibt sich 0 Dieser Vergleich kann f r jeweils 2 Winkel mit der Funktion compareAngles s1 s2 vs1 vs2 effizient durchgef hrt werden wobei auch eine alternative PDF benutzt werden kann
28. Um die Versorgungsspannung von 24V bereitzustellen die f r die Motoren und f r eine Art des Steuer boards n tig sind sind zwei dieser Akkupacks zusammengeschaltet Der dritte 12 V bereitstellende Akkupack liefert den f r den Betrieb der Kamera n tigen Strom Abgesehen von der Stromversor gung ber diese Akkupacks besitzt der Roboter ebenfalls noch einen Netzanschluss ber den 12 V 11 2 1 BERBLICK KAPITEL 2 HARDWARE und 24 V eingespeist werden um bspw eingesetzte Akkus zu schonen Der generelle Aufbau des Fahrwerks besteht aus entsprechend zugeschnittenen bzw mit den ent sprechenden Winkeln versehenen Aluminiumprofilen an denen sich mittels Einschubm glichkeiten weitere Anbauteile befestigen lassen So ist beispielsweise das Steuer und Kontrollmodul das oben auf dem Fahrwerk aufsetzt derart befestigt Abbildung 2 3 Fahrwerk Draufsicht Erkennbar sind die im 120 Winkel zueinander stehenden Motoren die die au en stehenden omnidirektionalen R der gr n antreiben 2 1 3 Steuer und Kontrollebene Die Steuer und Kontrollebene dient dazu um alle abgesehen von der Kamera f r den Betrieb und die Steuerung des Roboters n tigen Komponenten aufzunehmen Aufgebaut ist dieses Modul aus drei Armen die aus je zwei Aluminiumstreben bestehen Diese ruhen am unteren Ende in mit dem Fahrwerk verschraubten Halterungen Zun chst laufen diese Arme vertikal nach oben um nach ca 10 cm in einem 60 Winkel nach inne
29. bei den German Open verzeichnen konnte zeigten dass der Fokus grunds tzlich richtig gelegt wurde Mit Ausnahme von einigen Hardwareausf llen erf llten die Roboter ihre zugewiesenen Aufgaben Hervorzuheben ist dabei dass bedingt durch die zuverl ssige Objekterkennung fast 100 der Zeit alle relevanten Objekte wie Ball Tore und Hindernisse erkannt wurden Somit konnte der St rmer immer am Ball bleiben Dass dies nicht selbstverst ndlich ist zeigt sich daran dass bei anderen Teams zu beobachten war dass sich die Bilderkennung sehr leicht durch Schuhe F e oder Hosen von Zuschauern am Spielfeldrand die f r einen Ball gehalten wurden verwirren lie In den meisten F llen kommen solche Verwechslungen von einer unsorgf ltig eingestellten Farbsegmentierung Durch die einfache Einstellung der Segmentierungsparameter konnte die Bildverarbeitung auch w hrend ei ner Auszeit eines Roboters sehr schnell nachgeregelt werden um akute Probleme zu beseitigen Die Roboter konnten sich bei den German Open gut mit einer Genauigkeit von ca 30 cm lokali sieren F r alle Roboter ist es wichtig eine m glichst robuste Selbstlokalisation zu besitzen um die zugewiesenen Rollen zu erf llen So war es f r unsere Roboter m glich die Startposition selbst ndig einzunehmen wodurch man eine korrekte Kalibrierung berpr fen konnte Alle gegnerischen Teams waren darauf angewiesen ihre Roboter per Hand zu setzen um so der Selbstlokalisation eine An
30. communication wird der Datenverkehr mit dem Roboter und von eben diesem angezeigt Das gr ne Blinken stellt die eingehenden bzw ausgehenden 82 A 3 TRIBOTSCONTROL ANWENDUNG ANHANG A BEDIENUNGSANLEITUNG Reflektor Bender Megatron WLAN m WLAN m Outgoing Communicati m Outgoing Communicat tion E Outgoing Communication m Outgoing Communication E Incoming Communication E Incomin y Communicat tion E Incoming Communication E Incoming Communication E Active E Active E Active KickOff N A KickOff N A KickOff N A KickOff N A Role N A Target N A Role N A Target N A Role N A Target NA Fole N A Target N A z _Home Defend 1 2 Home Defend 2 Home Goalie z _Home Blue d B 3 Ele d B a ie B 3 Eue 33 Init Player Stop Init Player _Start _Stop Int Player _Start_ _Stop Init Player _ Start _Stop p Game Control Start All F Anstoss e Stopa C Anstoss Away E Penaliy HomeAl F Freekick Connect A 77 ARC on off Active Players 0 no game running Abbildung A 7 Graphische Oberfl che von TCPE Localisation Main Log 12502 Oy is Frise Potato Abbildung A 8 Player Panel von TCPE Datenpakete innerhalb der Kommunikation mit dem Roboter dar Das Signal Active leuchtet griin falls der Roboter eingeschaltet und betriebsbereit sein sollte rot wenn dieser Zustand nicht erreicht wurde Die dre
31. der oben beschriebenen Ballanfahrtsroutine den Ball einmal zwischen die beiden F hrungsh rnchen gebracht muss er ihn nun in eine m glichst g nstige Schussposition dribbeln Die wichtigste Grundregel f r dieses Dribbeln des Balls ist dass jede gr ere Abnahme der Fahrt geschwindigkeit den Verlust des Balls bedeutet da dieser ja kontinuierlich weiterrollt Der Roboter muss also w hrend er den Ball vor sich her schiebt m glichst dauernd beschleunigen oder zumindest mit konstanter Geschwindigkeit fahren Obstacle Avoidance Genau dieses Verhalten wird mit der oben beschriebenen reaktiven Vektor feldmethode nicht gef rdert Jedes Zunahekommen an ein Hindernis bedeutet eine Drosselung der Geschwindigkeit Aus diesem Grund wird f r den Fall dass der Roboter den Ball besitzt und f hren soll eine Modifikation der reaktiven Vektorfeldmethode vorgenommen Dazu werden s mtliche Hin dernisse im Algorithmus au er Acht gelassen D h es wird lediglich der Basisvektor in Richtung Ziel berechnet welcher dann direkt als neuer Fahrtvektor benutzt wird Mit diesem Fahrbefehl w rde der Roboter nun s mtliche Hindernisse rammen Um dies zu vermeiden wird f r die Obstacle Avoidance eine alternative Methode eingesetzt Da die F hrungsh rnchen und im brigen auch die Schusseinheit nur an einer Flanke des Roboters angebracht sind kann der Roboter den Ball folglich auch nur in diese Richtung dribbeln Um nun eine Kollision beim Dribbeln zu vermeiden
32. des Ventils sind zur Entl ftung des Zylinders A und R verbunden dies ist die Standardstellung der Kolben des Zylinders ist eingezogen Befindet sich das Ventil in der anderen Stellung so sind die Ventil ffnungen P und A verbunden Der Zylinder f llt sich mit Druckluft welche den Kolben nach vorn treibt Wie oben angedeutet handelt es sich hierbei um ein Magnetventil die von au en einwirkende Gr e ist eine elektrische Spannung 24V DC Durch Anlegen bzw Abschalten der Spannung wan dert der Magnet innerhalb des Ventils zwischen den definierten Positionen Der eingesetzte Rundzylinder besitzt einen Kolben mit R ckholfeder Das Einfahren des Kol bens bei der Zylinderentl ftung erfolgt somit rein durch Federkraft Im Gegensatz hierzu gibt es zweifachwirkende Zylinder bei denen f r Ein und Ausfahren jeweils Druckluft verwendet wird Un ter Verwendung dieses Zylindertyps h tte sich die Anzahl der m glichen Sch sse und die jeweilige Schusskraft stark reduziert Die aktuelle L sung ist bei weitem nicht optimal bei einem Schuss bremst das Spannen der R ckholfeder den beschleunigenden Kolben ab Die maximale Schussgeschwindigkeit wird damit nie erreicht Zur Ausl sung der Schusseinheit sind mehrere M glichkeiten in Betracht gezogen und getestet worden die nachfolgend in ihrer zeitlichen Reihenfolge beschrieben werden 20 2 4 SCHUSSEINHEIT KAPITEL 2 HARDWARE e Mikroschalter Als Drucksensoren befestigten wir zwei M
33. erreichen m sste beispielsweise die bersetzung der Getriebe ge ndert werden Damit die Roboter dadurch ihre Orientierungsf higkeit nicht einb en bliebe zu testen ob die Frequenz in der die Applikation arbeitet f r eine h here Geschwindigkeit ausreichend ist Anstelle des bisher berwiegend reaktiven Systemverhaltens k nnte zuk nftig mehr geplant wer den D h der Roboter f hrt beispielsweise zu einem Punkt an dem er den Ball im n chsten Zyklus 72 5 2 AUSBLICK KAPITEL 5 FAZIT erwartet Dies l sst sich durch den fest eingestellten Takt im Programmablauf relativ leicht realisie ren Die Schusskraft sollte weiter verbessert werden um auch aus gr erer Entfernung auf das Tor schie en zu k nnen Weiterer Ansatzpunkt k nnte die Verbesserung des Roboterverhaltens durch Einsatz von Lern verfahren sein Statt Ausprogrammierung des Balldribblings k nnte dies gelernt werden Bisher hat die Mannschaft aus Zeitmangel nur implizites Teamspiel genutzt und auf die Ausnutzung weiterer M glichkeiten wie die Erstellung eines gemeinsamen Weltbilds verzichtet Da das bisherige Bildver arbeitungssystem bedingt durch den verwendeten Spiegel den Ball nicht ber das gesamte Spielfeld hinweg verfolgen kann k nnten sich die Roboter gegenseitig mitteilen wo der Ball gesehen wird Nat rlich bringt ein solcher Ansatz wieder neue Schwierigkeiten mit sich die gel st werden m ssten falls die Selbstlokalistion falsch w re w rde de
34. es wichtig die Bilddaten eindeutig und schnell weiterzuverarbeiten 3 2 1 Bildsegmentierung Vorgehensweise Die Weiterverarbeitung der Bilddaten unterteilt sich in Segmentierung zur Klas sifizierung der Bilddaten und der eigentlichen Objekterkennung Zur Segmentierung lassen sich ver schiedene Verfahren wie Kantendetektion Kontrastbilder und Farbsegmentierung verwenden Prinzip Da innerhalb der Robocup Umgebung die wichtigen Objekte fest definierte Farben ha ben entschieden wir uns f r eine Farbsegmentierung d h der Einteilung aller betrachteten Pixel in bestimmte Farbklassen 1 2 3 Die Segmentierung findet im RGB Farbraum statt was eine Umrechnung der Pixel von YUV 4 2 2 in RGB erfordert F r jede Farbklasse in unserem Fall oran ge blau gelb gr n wei und schwarz wird ein Unterraum im RGB Farbraum definiert Da diese Unterr ume nicht disjunkt sein m ssen wird zus tzlich eine Priorit t vergeben welche die Reihen folge der Zugeh rigkeitstests bestimmt Betrachtet man einen Pixel so wird f r diesen berpr ft ob seine RGB Werte im Unterraum einer Farbklasse liegen dies wird f r jede Farbklasse angefangen mit dem Unterraum der h chsten Priorit t gepr ft bis der Pixel einer Farbklasse zugeordnet werden konnte Da nicht unbedingt der gesamte RGB Farbraum durch Farbklassen abgedeckt ist k nnen m glicherweise einzelne Pixel keiner Farbklasse zugeordnet werden Solche werden zur einfacheren Verarbeitung in einer Re
35. fangsposition vorzugeben In diesem ersten Test unter realen Bedingungen lernten wir vieles was wir unter Laborbedingun gen nicht einbeziehen konnten Beispielsweise ist es dringend notwendig Distanzen einsch tzen zu k nnen um zu wissen ob der Spieler im Ballbesitz ist da davon sein Verhalten ma geblich bestimmt wird Ein weiterer Faktor f r den Erfolg im Spiel ist die F higkeit eine L cke zwischen nahe beieinan der stehenden Robotern zu finden um durch diese zum Beispiel direkt auf das Tor spielen zu k nnen Zwar funktionierten die Roboter auf den German Open schon mit einer Distanzfunktion aus Basis einer berechneten e Funktion diese war jedoch bedingt durch den Kameraaufbau nur schwer zu kalibrieren und deswegen sehr ungenau Viele Chancen in den Spielen konnten nicht genutzt werden 71 5 2 AUSBLICK KAPITEL 5 FAZIT weil der eigene angreifende Roboter keinen Weg zum Tor finden konnte Ebenso sollten Kollisionen weitestgehend vermieden werden da diese einen klaren Regelversto darstellen Hierzu musste die Hindernisvermeidung verbessert werden So wurde von Gegnern oftmals nur eine hintere Ecke erkannt was in Kombination mit der damaligen Distanzeinsch tzung den Eindruck hervorrief der Weg sei frei Ein weiteres Problem lag in der Stabilit t der Hardware So st rzten die Kameras aufgrund von Firewireproblemen mehrfach ab und der Kameleon Motorcontroller offenbarte seine Schw chen Die betroffenen Roboter mussten kur
36. haben hier sollen aber nur ein paar Ursachen herausgestellt werden die im prakti schen Betrieb der Roboter aufgefallen sind e Problem Durch Starten der Komponenten s wird die Kamera nicht gestartet m gliche Ursache Kamera Akku leer L sung Akkus berpr fen und ggf wechseln m gliche Ursache Kabelverbindungen zur Kamera locker L sung Firewire Kabel berpr fen m gliche Ursache Kamera wurde nicht korrekt initialisiert L sung Programm beenden und per sudo firewire restart Kameramodule neustarten danach Tribots Programm erneut aufrufen und die Komponenten starten s Tritt das Problem erneut auf die Stromzufuhr der Kamera kurz unterbrechen per Schalter am Roboter und erneut starten e Problem Starten der Komponenten s schl gt fehl es liegt aber kein Kameraproblem vor m gliche Ursache ein Akku ist leer oder schwach L sung alle Akkus berpr fen und ggf wechseln m gliche Ursache Board ist aus L sung alle Schalter am Roboter einschalten Netz oder Batteriebetrieb e Problem Trotz laufendem Programm bewegt sich der Roboter nicht m gliche Ursache viele Ursachen m glich L sung bewegt sich der Roboter wenn man auf Go klickt liegt der Fehler m glicherweise an der Kommunikation z B W LAN Tut er dies nicht alle Akkus pr fen ggf das Programm sowie Board und Kamera neustarten e Problem Roboter bewegt sich seltsam tendiert dabei zum gelben Tor m gliche Ursache Im gelben Tor wird rot segme
37. in sp teren Abschnitten dieses Kapitels in die detaillierte Beschreibung der Software einsteigen geben wir an dieser Stelle einen kurzen berblick ber die einzelnen Module aus denen sich die Steuerungssoftware der Roboter aufbaut Wir betrachten deren Funktionsweise sowie den Kontrollfluss in der Applikation siehe Bild 3 1 und zeigen auf welche Komponenten von welchen Ausgaben anderer Komponenten abh ngig sind Anschlie end betrachten wir die Program mablaufsteuerung 3 1 1 Aufbau und Funktionsweise der Module Die einzelnen Module der Software arbeiten wie in Abbildung 3 1 dargestellt zusammen Die Kompo nenten werden jeweils sequentiell d h nacheinander abgearbeitet Dabei bauen zeitlich sp ter arbei tende Module auf den Ausgaben der zeitlich vorher liegenden Module auf Abbildung 3 2 beschreibt wie Daten zwischen den Modulen bei der sequentiellen Abarbeitung durchgereicht werden An vor derster Stelle wird immer die Bildverarbeitung durchgef hrt da die Kamera Sensorinformationen die Grundlage f r alle weiterf hrenden Berechnungen bilden Die Funktionalit t der einzelnen Module mit den zugeh rigen Eingabedaten und Ausgabedaten ist dabei wie folgt Beschleunigungs modul Bild verarbeitung Weltmodell Kamera Controller Abbildung 3 1 Sequentieller Kontrollfluss in der Softwarearchitektur 22 3 1 BERBLICK KAPITEL 3 SOFTWARE e Bildverarbeitung siehe Abschnitt 3 2 Eingabe B
38. m glich den Roboter auf dem Spielfeld zu man vrieren und dabei gleichzeitig den Ball vor sich herzudribbeln Zusammenfassung Man ist nun in der Lage den Roboter in jeder denkbaren Spielsituation beliebig anzusteuern und zwar grunds tzlich unabh ngig von der Geschwindigkeit Ausrichtung und Position des Roboters W hlt man dennoch sehr harte Parameter aus z B zwei aufeinanderfolgende v llig entgegengesetzte Zielko ordinaten die angedribbelt werden sollen werden diese Eingaben in realisierbare Man ver umgesetzt Wann welche der beiden vorgestellten Man vrier Methoden angewendet wird entscheidet sich lediglich dadurch ob der Roboter im Besitz des Balls ist oder nicht Dieses Kriterium wird aufgrund der N he des Balls zum Roboter in einem bestimmten Winkelbereich vor seiner Dribbel Einheit bestimmt siehe Abb 3 17 Die Grundf higkeiten m ssen nun allerdings noch sinnvoll angewendet werden F r diese Aufgabe existiert eine weitere Klasse die die h heren F higkeiten des Systems implementiert 45 3 4 STRATEGIE KAPITEL 3 SOFTWARE Ballbesitz kein Ballbesitz Abbildung 3 17 Unterscheidungskriterium Ballbesitz 3 4 2 H here F higkeiten Aufbauend auf den Grundf higkeiten die es erm glichen dem Roboter in jeder erdenklichen Lage einen gezielten Ansteuerungsbefehl zu geben ist es nun n tig solche Ansteuerungsbefehle zu finden die taktisch und spieltechnisch m glichst sinnvoll sind Dabei ist zu ber cksicht
39. mithilfe von frei programmierbaren Plugins eigene Roboter Modelle in den Simulator zu integrieren war es innerhalb relativ kurzer Zeit m glich unser omnidirektionales Fahrwerk und die von uns entworfene Schusseinheit in einem Plugin zu modellieren und so eine Software Kopie unseres Roboters im Simulator zu testen Als Eingangssensor wurde das an der Universit t Freiburg entwickelte Plugin f r die von uns verwendete Kamera Sony 16 integrated development environment integrierte Entwicklungsumgebung Tnttp kaspar informatik uni freiburg de simsrv 60 3 7 FREMDE SOFTWARE KAPITEL 3 SOFTWARE sims f aa Eile Display Game Robot Simulation Referee Window Help PYEr IS Up al dermen 1 13 230 Ibb S6 POL 11ULo waiting for clients s are here Bots are here Bots are here Bots are here Abbildung 3 29 Oberfl che des Robocup Simulators SimSrv DFW500 11 verwendet und um das Feature zur Erkennung von Hindernissen erweitert Die Anbindung des Freiburger Simulators an unsere Software ist in Abschnitt 3 7 3 beschrieben 3 7 3 Simulatorplugin Zur Anbindung der Tribots Software an den Freiburger Simulator siehe Unterabschnitt 3 7 2 wurde die Klasse CDortmundClient entwickelt Anstelle der realen Bilddaten aus der Kamera und den realen Odometriedaten aus dem Control ler Board erh lt man bei angeschlossenem Simulator die simulierten Kamera und Odometriedaten die denselben Schnittstellenspezifikatione
40. nur bedingt m glich da sich z B Schuhe durchaus in diesem Bereich aufhalten k nnen Hindernisse Die Hindernisse also Roboter sind am leichtesten durch ihre schwarze Farbe zu erkennen Ihr Aufenthaltsbereich entspricht in etwa dem des Balls Allerdings sind die schwarzen Hindernisse meistens so hoch dass sie sich ber gro e Teile des Bilder erstrecken und dabei Land marken oder den Ball verdecken k nnen Da es immer mehrere Hindernisse gibt benutzen wir zum Erkennen und Verfolgen von Hindernissen einen etwas anderen Ansatz Hindernisse werden mit Hilfe von ca 50 Scanlinien erkannt die radial vom Roboterradius in Richtung Feldgrenze verlaufen Wird auf einer dieser Scanlinien ein bergang von der Feldfarbe Gr n Wei zu Schwarz festgestellt so wird in diesem Winkel ein Hindernis weitergegeben Die Entfernung des Hindernisses l sst sich hier bei aus der durch die Distanzfunktion umgerechneten Pixelentfernung errechnen da der bergang Feld Hindernis am Boden stattfindet Bei dem Algorithmus der den bergang feststellt werden Schwellwerte eingesetzt um die schwarzen Marker auf dem Boden Bildst rungen oder Schatten des Balls nicht als Hindernis erscheinen zu lassen 29 3 2 BILDVERARBEITUNG KAPITEL 3 SOFTWARE Abbildung 3 5 Schema des sichtbaren Bereichs im Spiegel grau Objekt Gr e im Bild Maximale Entfer Anzahl m glicher Objek nung te nah fern Ball gro verschwindend ca 4 5m 1 Tore se
41. wird in jedem Zyklus gepr ft ob der Korridor in Richtung Ziel frei ist siehe Abb 3 15 links Hinderniss Hinderniss gt gt Fahrtvektor Fahrtvektor temp Ziel Abbildung 3 15 Obstacle Avoidance In jedem Zyklus wird berpr ft ob der Korridor in Richtung Ziel frei ist Ist der Korridor nicht frei wird solange ein verlagertes tempor res Ziel angefahren bis er frei ist Ist der Korridor durch ein Hindernis blockiert wird ein tempor res Ziel als Ausweichpunkt seit lich des Hindernisses ermittelt Dieser neue Zielpunkt wird solange angesteuert bis das Hindernis umfahren und der Korridor in Richtung des urspr nglichen Ziels wieder frei ist siehe Abb 3 15 rechts Dribbling Eine weitere Grundf higkeit ist das schnelle Dribbeln des Balls ber das Spielfeld Mit der oben beschriebenen Ballf hrungseinheit ist ein Dribbeln des Balls bei Geradeaus Fahrt relativ problemlos Schwierig ist hingegen das Halten des Balls bei Kurven Fahrten Hierzu wurde ein spe zieller Dribbel Algorithmus entwickelt Dieser berechnet abh ngig von der Winkeldifferenz zwischen 44 3 4 STRATEGIE KAPITEL 3 SOFTWARE Orientierung und Ziel einen Auslenkungspunkt der neben dem Ball liegt Dieser wird bei gleichzei tiger Rotationsbewegung des Roboters angesteuert und f hrt zu einem Man ver das die Tr gheit und das Rollverhalten des Balls beim Fahren ber cksichtigt und verhindert dass der Ball verloren geht Bei einer s
42. 0 4 m recht gut dar ber hinaus nur schlecht messbar Die Messung gr erer Distanzen kann durch Robotervibrationen und durch einen unpr zisen Kame raaufbau w hrend des Fahrens stark schwanken Der Torwart erkennt die Fu punkte der Torpfosten sowie deren Distanzen gut Sie werden f r die Selbstlokalisation vor dem Tor und im Tor benutzt Die einzelnen Sensorinformationen der Bildverarbeitung und der Odometriesensoren werden durch einen Monte Carlo Particle Filtering Ansatz fusioniert So kann die Roboterposition und ausrichtung global bestimmt und lokal verfolgt werden 2 12 Monte Carlo Particle Filtering Das Grundprinzip des Verfahrens liegt darin das Modell der Aufenthaltswahrscheinlichkeit durch Sensordaten und Odometriedaten zu aktualisieren Ziel ist die Zentrierung der Aufenthaltswahr scheinlichkeit um die aktuelle Roboterposition wobei die entsprechende Wahrscheinlichkeitsdichte durch ein Sampleset von Partikeln repr sentiert wird 36 3 3 WELTMODELL KAPITEL 3 SOFTWARE Die Wahrscheinlichkeitsdichte Bel l d o repr sentiert die Position ly des Roboters also seine x und y Koordinate und seine Ausrichtung y zum Zeitpunkt t wenn alle Daten d bekannt sind Die Daten bestehen aus Odometrieinformationen a und Sensoreingaben s Es gilt Bel L p li St 0 1 811 042 80 3 1 Durch Anwendung der Bayes schen Regel und Ber cksichtigung eines Markovprozesses erster Ordnung l sst sich die Rekursionsgle
43. 2 2222 22222 30 Aufbau eines Nachrichten Strings 2 2 En En nn rn 50 Verschiedene Schusseinheiten mit Zeit und durchschnittlicher Geschwindigkeit auf 5m 66 Direktwahltasten in der Tribots Anwendung 2 2 CE En nn nn 86 Kapitel 1 Einleitung 1 1 Allgemeines Im Rahmen der Projektgruppe 425 Lernende autonome Fu ballroboter die im Wintersemester 2002 03 und Sommersemester 2003 stattfand sollte ein Roboter in die Lage versetzt werden Fu ball zu spielen Aus Sicht der Informatik und speziell der K nstlichen Intelligenz ergaben sich f r uns als zentrale Probleme die Bildverarbeitung Vision als unser prim rer Sensor das Erstellen eines internen Weltbildes das Planen und Ausf hren von Aufgaben Navigationsplanung und die Mani pulation von realen Objekten z B die Bewegungs nderung des Fu balls F r die Konstruktion eines Fu ballroboters sind ebenso elektrotechnische und mechanische Ans tze von Bedeutung Unser Ziel war der Entwurf eines ausfallsicheren fu ballspielenden Roboters mit einer robus ten und stabilen Bildverarbeitung Wir haben uns fr h entschieden nicht nur einen Fu ballroboter zu konstruieren und zu programmieren sondern ein ganzes Team das an den German Open 2003 in Paderborn teilnehmen sollte auf die Beine zu stellen Zur Robocup Weltmeisterschaft 2003 in Padua Italien haben wir unsere Erfahrungen aus den German Open genutzt um in f r uns wichti gen Teilaufgaben wie Schussgeschwindi
44. 4 24V DC r Kameleon 376SBC RS2372 Da ATI 5 14 a te N E 5 8 3 3 a i la E a y D a te PortO Portl Por2 Port3 Abbildung B 3 Stromkabel zwischen den Roboterkomponenten Kameleon r Informationen ber die Radbewegung bzw deren Inkremente bertragen f r die genaue Verschaltung siehe 8 9 B 2 2 TMC WLAN Sony Kamera Adapter Joystick 15661394 USH ESE 1EEE1394 Repester 1EEE1394 6ET 33al 3 s sg 121 Einspeisung Tuc 200 185231 24V Einspeisung 24 DC Poto Potl Port2 Abbildung B 4 Datenkabel Konverter und Adapter zwischen den Roboterkomponenten TMC Anders als beim K376SBC arbeitet das TMC200 nur mit einer einzigen Versorgungsspannung von 24 V DC siehe Abbildung B 5 Auf dem Roboter gibt es damit zwei Spannungskreise deren Massen nicht verbunden sind Daraus entstehen u U Massendifferenzen zwischen den beiden Kreisen und somit ein nichtbeabsichtigter Stromflu Zur L sung dieses Problems wurden die Massen zusammen auf ein gemeinsames Potential gezogen Daten und Stromleitungen der Motoren werden strikt voneinander getrennt d h die bisherige L sung eines Flachbandkabels wie beim K376SBC muss modifiz
45. AN nach IEEE 802 11b im lizenzfreien 2 4GHz Band mit einer maximalen bertragungsrate von 11 MBit pro Sekunde brutto Der effektive Durchsatz liegt deutlich darunter jedoch sind die zu bertragenden Datenmengen f r unseren Einsatzzweck erwartungsgem im niedrigen KByte Bereich angesiedelt so dass diese Technologie unsere Anforderungen erf llt Die verl ssliche bertragung der Daten wird mittels verbindungsorientierten TCP Verbindungen si chergestellt Die Kommunikation der Roboter untereinander findet in einer Stern Topologie statt die TCP Verbindungen bestehen ausschlie lich zwischen je einem Roboter und dem TribotsControl Rechner unmittelbar untereinander bauen die Roboter keine Verbindung auf Dieses Konzept hat zwei Vorteile gegen ber der n n Verbindung e eine geringere Anzahl an aufgebauten Verbindungen 4 gegen ber 10 bei der n gt n Relation e dasn 1 Konzept beschreibt die zentrale Administrations und berwachungsrolle des Tribots Control Rechners effektiver und logischer Dieses wird in den n chsten beiden Unterpunkten n her erl utert Die Verbindungen zwischen TribotsControl und den Robotern werden von TribotsControl ausge hend initiiert TribotsControl sendet eine Verbindungsanforderung an den Roboter um eine Verbin dung aufzubauen Wenn der Roboter online ist d h das WLAN Modul funktioniert und das Tribots Programm l uft akzeptiert er die Verbindung und best tigt diese durch eine R ckverbindung auf
46. Dauer des Spiels ist diese Methode nicht ausreichend Fehler durch Kollisionen oder Schlupf der R der werden hierbei aufsummiert und f hren zu immer gr er werdenden Abweichun gen der wahrgenommenen von der tats chlichen Position In diesem Zusammenhang wird auch das Kidnapped Robot Problem 4 beobachtet ein Roboter wird von Hand umgesetzt ohne dass seine 35 3 3 WELTMODELL KAPITEL 3 SOFTWARE Sensoren dies feststellen k nnen Dies f hrt zum totalen Positionsverlust der durch lokale Lokalisati on nicht wahrgenommen werden kann Ein Roboter der das Kidnapped Robot Problem l sen kann muss diese Orts nderung erkennen und sich global neu lokalisieren Globale Lokalisation Zur Feststellung der aktuellen Roboterposition ist es sinnvoll die Position von fest definierten Landmarken der Robocup Umgebung zu erkennen und als Orientierungshilfe zu nutzen Hierzu z hlen beispielsweise die Tore die Eckfahnen und die wei en Linien Es ist m glich die Position des Roboters mit Hilfe von Triangulation direkt zu berechnen doch aufgrund der teil weise sehr ungenauen oder falschen Bildverarbeitungsinformation ist es schwierig die daf r n tigen Landmarken sinnvoll auszuw hlen Deswegen wurde ein Monte Carlo Ansatz zur Fusion der Sensor information eingesetzt der auch verrauschte Informationen verarbeiten kann Sensoren Der Beobachtungssensor zur globalen Lokalisation ist der omnidirektionale Kameraauf bau Die Landmarken sind aufgrund i
47. Grundfunktionen die ber Main zu erreichen sind sind e Starten der Module ber Start Main Loop Stoppen der Module ber Stop Main Loop e Starten des Roboters ber Go Roboter erh lt Fahrbefehle Notstopp des Roboters ber Stop woraufhin keine Fahrbefehle mehr verarbeitet werden e Homeposition auf dem Spielfeld anfahren ber Go Home Beenden und Verlassen des Programms ber Exit Start Main Loop Stop Main Loop H Go G Stop Space Go Home Ctri G Exit Ctre Y Abbildung A 2 Kontextmen der Tribots Anwendung Zwei Sonderfunktionen die in der Regel nur selten ben tigt werden aber trotzdem nicht weni ger wichtig sind sind unter dem Men punkt Specials zu finden Zum einen kann man hier ber Distance Calibration die Funktion kalibrieren die f r die Entfernungsmessung zust ndig ist zum anderen l sst sich hier der Debug Modus aktivieren ber den eine komfortable Fehlererkennung bei Softwareabst rzen o m glich ist Distance Calibration muss im Optimalfall f r jede Umgebung nur ein einziges Mal durchgef hrt werden 76 A 2 TRIBOTS ANWENDUNG ANHANG A BEDIENUNGSANLEITUNG A 2 2 Bildverarbeitungsfenster Das Bildverarbeitungsfenster dient zwei prim ren Aufgaben Zum einen kann man sich jeder Zeit anzeigen lassen wie gut die Objekterkennung aktuell funktioniert und wie gut die Segmentierung eingestellt ist zum anderen ist sie das wichtigste Werkzeug zur Kalibrierung der Software Im Fol
48. Pneumatik Elemente 20 Sequentieller Kontrollfluss in der Softwarearchitektur 22 2 22 a nn 22 Datenfluss in der Softwarearchitektur 22 2 2 CC a a 25 Zyklusdauer der Hauptschleife von Tribots 2 2 22 2 Con nennen 25 Bildverarbeitungsfenster mit Segmentierung aller Farbklassen 28 Schema des sichtbaren Bereichs im Spiegel 2 2 2 2 En nn nn 30 Schema der Umgebung f r eine Distanzmessung 2 2 2 e 31 Aufgenommene Daten der Distanzkalibrierung 32 Ergebnisse einer Distanzmessung nach der Distanzkalibrierung 33 Gleichverteilung der Partikel zu Beginn des Algorithmus 38 Demonstration eines Kidnap Vorganges CE m Emm 39 Schema der Verschiebung von Partikeln durch Odometrieinformation 39 Beispiel der Verteilung der Partikel nach einem Integrationsschritt 40 Einfluss von Hindernissen auf den Fahrtvektor 2 2 2 2 2 En onen 42 Anfahrtsvektorfeld des Balls 222 Co oo on nen 43 Obstacle Avoidance m onen 44 Dribbling Algorithmus 2 22 CC on nn 45 Unterscheidungskriterium Ballbesitz 2 22 2 2 Em mom a 46 Standard Aufstellung des Teams 2 2 22 2 Co nommen 46 Haupt ste des bin ren Entscheidungsbaums der Strategie 2 2222220 47 Einteilung des Spielfelds f r Angriffsman ver beim Spiel auf das gelbe Tor 48 Aktionsraum des Torwarts oaoa 48 Wirkungsweise des Ballfilters 2 222 22 Coon nn e
49. RDWARE CPU Pentium III M 800 MHz Hauptspeicher 256 MByte Festplatte 30 GByte Schnittstellen USB IEEE1394 PCMCIA Tabelle 2 1 Technische Daten des JVC MP XP7210 2 3 Motorcontroller Der Motorcontroller bildet das Herzst ck des Roboters er ist verantwortlich f r die Ansteuerung der einzelnen R der Man k nnte einwenden dass der Steuerrechner die Fahrbefehle ausgibt jedoch sind etliche der Motorcontroller programmierbar so dass f r einfache Aufgaben wie das Abfahren einer Figur ein Steuerrechner komplett entfallen kann da die Fahrbefehle auf dem Motorcontroller selbst erzeugt und verarbeitet werden k nnen Die Komponenten auf den diversen Controllern variieren je nach Preisklasse in Qualit t und Anzahl z B zus tzliche M glichkeiten zur Verarbeitung von E A oder die Regelg te bei einer Dreh zahlregelung Einige Komponenten sind aber auf fast allen Motorcontrollern wiederzufinden e Kommunikationsschnittstelle die auf dem Motorcontroller vorhandene Rechenkraft ist sehr stark begrenzt aufwendigere Aufgaben wie Odometrieberechnungen und Pfadplanung lassen sich damit nur unzureichend l sen Eine externe Quelle z B ein Laptop bernimmt diese Aufgabe und schickt die daraus resultierenden Ergebnisse bzw Fahrbefehle an den Motorcon troller F r die Kommunikation zwischen den beiden Ger ten gibt es mehrere M glichkeiten im einfachsten Fall ist es eine drahtgebundene Kommunikation ber eine serie
50. Torfarbe gemeint abzulesen Weiterf hrend kann der Anwender mit der Kon trolloberfl che dem Roboter rudiment re Kommandos geben die sp ter noch n her erl utert werden Nachdem das Programm ber die Shell mit dem Befehl tcpe gestartet wurde erh lt der Anwender den Startbildschirm vgl Abbildung A 7 Deutlich zu erkennen sind die 5 verschiedenen Teilbereiche der Oberfl che In der oberen H lfte des Bildschirms befinden sich die einzelnen Controlpanels f r die jeweiligen Roboter Die untere H lfte ist f r allgemeine Befehle und Informationen aller vier Spieler reserviert A 3 2 Kommunikation mit einzelnen Robotern Jedem Roboter steht ein Messagefield zur Verf gung indem allgemeine Statusmeldungen des je weiligen Spielers angezeigt werden k nnen Es wird ausgegeben ob der Spieler sich verbunden hat in welchem Modus er sich befindet oder ob er noch mit dem TCPE in Verbindung steht Statusmeldun gen innerhalb dieses Feldes k nnen u a Roboter connected oder connection closed sein Hinzu kommen Meldungen bei Rollenwechseln z B new Role DEFEND2 oder auch Fehlermeldungen wie z B Failure Report Worldmodel Crash Unterhalb des Messagefield sind 4 Signalanzeigen zu sehen die den Status der vier wichtigsten Funktionen des Roboters anzeigen Das Signal WLAN zeigt eine vorhandene WLAN Verbindung an falls es gr n leuchtet und eine unterbrochene oder nicht vorhandene wenn es rot markiert ist Mit outgoing communication und incoming
51. TribotsControl Zur Implementierung nutzen wir die QSocket und QServerSocket API aus dem QT 3 0 5 Toolkit Auf der Anwendungsschicht haben wir als Protokoll einen CSV String definiert der aus sieben Datenbl cken besteht TIMESTAMP RECEIVER SENDER MESSAGECODE DATAX DATAY DATAZ QTime QString QString int float float float Tabelle 3 4 Aufbau eines Nachrichten Strings TIMESTAMP enth lt den genauen Zeitstempel zur Verifikation der Datenaktualit t dies ist z B n tig bei der Synchronisation der Selbstlokalisationspositionen RECEIVER und SENDER enthalten die Absender bzw Empf ngeradresse Zur besseren Zuordnung der Roboter werden diese intern im TribotsControl mit einer ID 1 4 angesprochen und vor dem Senden automatisch auf die Empf nger IP abgebildet Der MESSAGECODE beschreibt die Bedeutung der n chsten drei Datenbl cke DATAX DATAY und DATAZ In der aktuellen Version gibt es 22 unterschiedliche Befehle und Meldungen die ber die Kommunikationsschnittstelle ausgetauscht werden k nnen Zur Illustration sei folgender String gegeben 17 34 33 3 129 217 57 183 207 6 2 3 TIMESTAMP ist selbsterkl rend RECEIVER ist die ID 3 der n chste Datenblock gibt die IP des Sen ders wieder Der MESSAGECODE 207 entspricht sending CURRENT ROLE TARGET GOAL and KICKOFF PRESET TribotsControl empf ngt diesen String und teilt ihn in sieben nach Kommata getrennte Datenbl cke ein Der gesamt
52. Universitat Dortmund Fachbereich Informatik Projekteruppe 425 Lernende autonome Fu ballroboter Endbericht M Arbatzat S Freitag M Fricke C Heermann K Hegelich A Krause J Kr ger H M ller J Schanko M Schulte Hobein M Theile S Welker 24 September 2003 Inhaltsverzeichnis 1 Einleitung 6 1 1 Allgemeines lnea iaa A ARA a e aata 6 1 23 ROBOCUP pun Madana Seas a ae de a a O ds 6 1 3 Projektverl uf aci cl a do E a a A ker 7 AD a A A a A a a ae an en 8 2 Hardware 10 DA berblicke u IA A A E AA e DB 10 2 2 Steuerrechner a er a A E A AI N 14 233 Motorcontrollers hs 3 trau 8 Sea seat a a a ie it a ae 16 254 Schussein heit a a su a en ee a Br ee ee rn 19 3 Software 22 IL berblick ia e a Arte a Da ar a td ee DIE 22 3 27 Bildverarbeitung 2 4 0 2 0 a an ta a 27 3 31 Weltmoadell 3 2 2 A ne ea ee ns Bit 35 3 4 Btrate ien m ai aaa er e a a de e e A a 41 3 8 Kommunikation ii 2 3 2 D Se ee en e a 50 3 6 R obotermoduli 2 29 a ss Ba a ee aan 53 37 Fremde Software s one 2 2 2 a hen ae ee 60 4 Systemtests 63 dal Bildverarbeitung eirge Ye Dre IA A Beta a a 63 4 2 Selbstlokalisation mn nn ren 64 4 3 Schusseinheit A 65 Ad Wettbewerbe 8 82 2 a a ee a en a 67 5 Fazit 71 Dell RESUME wurd dr irn as ada ee ra tr ed ad ne id da ee 71 5 2 Ausblick odia a a ata DA atar ta 72 A Bedienungsanleitung 74 NEL IV OLWOBO corso a a Det debe a A a rio tes FE 74 A2 Tribots Anwen
53. YTest mit amp Test PositiveBall Partikel 2 x 2 Blur und YT es PositiveBallPartikellz y YBlur 5 if getPixelColor ttest Ytest BALL then 6 F ge Partikel Trest Ytest zu PositveBallPartikel hinzu 7 end if 8 end for Algorithmus 4 propagate_step Funktion die gefunden Partikel ber Zeit propagiert 34 3 3 WELTMODELL KAPITEL 3 SOFTWARE 3 3 Weltmodell Die Wahrnehmung der Umwelt hat unmittelbaren Einfluss auf unsere Handlungen visuelle Informa tionen werden im menschlichen Gehirn zu Objekten und assoziierten Aktionen umgesetzt Je pr ziser die gewonnenen Informationen sind desto besser ist die Aktionsauswahl m glich Der Roboter an sich verf gt ber keine eigenst ndige Wahrnehmung Abh ngig von seinem Ein satzgebiet wird entschieden welche Gr en in seiner Umgebung relevant sind und wie er darauf reagieren soll Tr gt man die erkannten Objekte in eine Umgebungskarte ein die den n heren Be reich des Roboters beschreibt repr sentiert sie ein Modell der Welt wie sie f r den Roboter zu sein scheint Das Weltmodell soll dabei eine sehr detaillierte in Echtzeit berechenbare Darstellung sein um dem Strategiemodul eine optimale Grundlage f r eine Entscheidung zu bieten 3 3 1 Repr sentation der Umwelt Im Rahmen der Projektgruppe entsprach die Roboterumgebung vel 1 einem Fu ballfeld mit 1 wei en Spielfeldmarkierungen 2 jeweils einem blauen sowie einem gelben Tor 3 vier Eck
54. al und Kick0ff Preset k nnen f r jeden Roboter eingestellt werden Die Roboter senden fortlaufend ihre aktuelle Position die auf einem virtuellen Spielfeld graphisch dargestellt wird Fehler in der Selbstlokalisation und damit zusammenh ngende Verhaltensfehler k nnen so schnell registriert werden Die Statusmeldungen und die aktuellen Einstellungen Role TargetGoal KickOff Preset wer WLan E Outgoing Communic ation E incoming Communication Active Kiskot wA Kickof wA Role NA Target N A Role N A Target WA Abbildung 3 23 Tribots Control den f r jeden Roboter einzeln und bersichtlich angezeigt LEDs zeigen den Verbindungsstatus zu den Robotern an TribotsControl informiert ber berechnete notwendige Rollenwechsel und deren erfolgreiche oder fehlerhafte Durchf hrung Vor Spielbeginn und in einer Spielunterbrechung k nnen verschiedene Ansto varianten und Spielsituationen gesetzt werden diese sind KickOff HomeTeam KickOff AwayTeam und Penalty Grunds tzlich gibt es zwei Modi die das Verhalten von TribotsControl kennzeichnen Der aktive Modus ist abh ngig davon ob zum aktuellen Zeitpunkt ein Spiel l uft oder nicht Nach dem Anpfiff des Schiedsrichters werden die Roboter ber den Knopf Start All gestartet Jetzt ist TribotsControl solange im Modus GameRuns bis der Knopf Stop A11 gedr ckt wird und damit die Roboter und das Sp
55. andeten unhaltbar im Tor so dass das Spiel ungl cklich mit 0 2 verloren ging Damit schied das Team trotz einiger knappen Spiele und einem abschlie endem 5 0 Sieg gegen T bingen im Achtelfinale aust Nach nur einem Jahr zu den besten 16 Teams der Welt zu geh ren und im Achtelfinale der Weltmeisterschaft sehr ungl cklich auszuscheiden war dennoch eine tolle Leistung Die Ergebnisse der WM im Vergleich zu den anderen Teams http 1s1 www cs uni dortmund de merke robocup results ms_wm2003_bscolor html 70 Kapitel 5 Fazit 5 1 Resum e Zu Beginn der Projektarbeit d h nach der Orientierungsphase stand die Gruppe vor der Wahl ent weder Lernans tze auf einen Roboter zu bringen hierbei w re dann noch zu spezifizieren gewesen was genau h tte gelernt werden sollen oder aber ein vollst ndiges Team von autonomen Fu ball spielenden Robotern zu erstellen um am Wettbewerb German Open teilzunehmen Nach der Ent scheidung f r die German Open wurde mit den Erfahrungen aus der 1 Phase und einer Seminarphase das Hauptaugenmerk darauf gerichtet ein ausfallsicheres schnelles Team aufzubauen Im Vordergrund standen zuverl ssige Farbsegmentierung Objekterkennung Objekttracking und Monte Carlo Selbstlokalisation Hinzu kam eine reaktive Strategie die sich aus einfachen Bewe gungsf higkeiten zusammensetzte um schnell gute Resultate bei der Ansteuerung des Roboters auf dem Spielfeld zu erzielen Die Erfolge die das Team
56. besitz Abbildung 3 19 Haupt ste des bin ren Entscheidungsbaums der Strategie spezielles Yerhalten Roboter hat Ballbesitz Diese vier Situationen verlangen ein spezielles Verhalten von jedem Spielertyp So f hrt zum Beispiel der St rmer beim eigenen Ansto den ersten Ballkontakt aus w hrend die Defensiv Spieler weiter hinten im Feld auf Abwehrstellung gehen hnlich unterschiedliche Verhaltensweisen liegen in den anderen Standardsituationen vor F r alle anderen Spielsituationen greift der Algorithmus auf die Man ver der Basis Taktik zur ck Dieser ebenfalls als bin rer Entscheidungsbaum implementierte Teil der Entscheidungsfindung un terscheidet auf oberster Ebene ob der Roboter im Ballbesitz ist oder nicht Danach richtet sich sein Verhalten Ballbesitz Besitzt der Roboter den Ball verh lt er sich auch wenn er eigentlich ein Verteidiger ist grunds tzlich wie ein St rmer und versucht den Ball ins Tor zu bringen Es werden dabei die oben beschriebenen Routinen f r das Man vrieren mit Ball verwendet Das Spielfeld ist in verschiedene Bereiche eingeteilt siehe Abb 3 20 Abh ngig davon in welchem dieser Bereiche der Roboter den Ball ergattert hat verwendet er unterschiedliche Man ver um den Ball in die gegnerische H lfte zu bringen bzw ein Tor zu schie en Zum Beispiel f hrt er zun chst auf die rechte gegnerische Torh lfte zu wenn er den Ball auf der rechten Seite des Bereich 1 oder Bere
57. bis zu drei Gleichstrommotoren mit einer maximalen Leistung von 200 Watt konzipiert Den Boardkern bildet ein 16 Bit Mikrocontroller von Infineon Durch den einge bauten PID Regler ist eine Drehzahlregelung mit hohen Anforderungen an Gleichlauf und geringen Drehmomentschwankungen m glich Eine Besonderheit ist der eingebaute thermische Motorschutz durch eine 1 T Strombegrenzung Die Rotorwicklungstemperatur ist von au en nicht messbar und wird ber ein thermisches Modell berechnet berschreitet die Temperatur einen kritischen Wert droht ein Wicklungsbrand der den Motor zerst rt Innerhalb des Motorcontrollers wird dazu das thermische Modell als nebenl ufiger Prozess ausgef hrt der beim berschreiten der kritischen Wick lungstemperatur eine Strombegrenzung aktiviert Die bisherige Obergrenze f r den zul ssigen Strom wird vom Anlaufstrom abgesenkt auf den motorspezifischen maximalen Dauerstrom gleichzeitig be ginnt die Abk hlung des Motor auf seine Nenntemperatur bzw je nach Belastungsgrad auf einen niedrigeren Wert Erreicht die Modelltemperatur eine bestimmte untere Grenze so wird die Strom begrenzung deaktiviert so dass dem Motor erneut der Anlaufstrom als Obergrenze zur Verf gung steht Ein frei nutzbarer 10 Bit E A Port dient zum Anschluss eigener Sensorik wobei Sensorik und Ports am besten optisch entkoppelt sind Die Kommunikation mit dem Steuerrechner erfolgt im Moment ausschlie lich ber die serielle Schnittstelle durch den A
58. bjektsuche Um interessante Objekte im Bild zu finden ist es sehr hilfreich das Bild in Bereiche einzuteilen und nur dort zu suchen wo sich das gew nschte Objekt aufhalten kann Dies bringt Geschwindigkeits vorteile denn es m ssen nicht alle Pixel im Bild betrachtet werden da sich bestimmte Objekte nur in bestimmten Bereichen im Bild aufhalten k nnen Hierzu muss man sich zuerst den Aufbau eines omnidirektionalen Bildes vom Spielfeld verdeutli chen um Regeln zu finden wo sich regions of interest f r einzelne Objekte befinden Mittig sitzt das Kameraobjektiv Wenn ein Spiegel mit einer sehr stark gew lbten Mitte oder einer Spitze verwendet wird dann kann das Objektiv sogar verschwinden Dies ist w nschenswert denn so stehen mehr Pixel im Bild f r interessante Fl chen zur Verf gung Nach dem Kameraobjektiv schneidet die Sichtlinie der Kamera direkt den Boden der untere Rand des Roboters wird nicht wahrgenommen hier entsteht ein toter Winkel der aber zu klein ist um den Ball ganz zu verdecken vgl Abbildung 3 5 Die Entfernung des Schnittpunktes mit dem Boden nimmt bei steigendem Pixelabstand im Bild immer st rker zu bis sie am Horizont die Unendlichkeit erreicht die Sichtlinie verl uft dann parallel zum Boden In diesem Bildbereich liegen alle Objekte die sich auf der gleichen H he der Kamera befinden Tore und Eckfahnen Die Horizontlinie schneidet die wichtigen Objekte Tor und Eckfahne distan zunabh ngig von jedem Punkt a
59. ckgeliefert Dabei benutzt man z B Potentiometer wobei jede Radposition einen eindeu tigen Widerstand erzeugt e inkrementelle Messwertgeber entspricht einer Impulsfolge jedesmal wenn sich das Rad etwas dreht ndert sich der Zustand von HIGH auf LOW bzw umgekehrt Die Anzahl der Impulse pro Zeiteinheit entspricht der Umdrehungsgeschwindigkeit des Rades Die Sensoren k nnen zur Messung der Translations und Rotationsbewegung verwendet werden theoretisch bestimmt die Integration dieser beiden Werte die aktuelle Roboterposition Koppelna vigation dead reckoning Zum Einsatz kamen bei uns die inkrementellen Messwertgeber sowie das Runge Kutta Verfahren zur Integration Nach der Integration erfolgt das Verschieben der Verteilung der Aufenthaltswahrscheinlichkeit des Roboters um den Weg x y und die Rotation y im Weltmodell Hierbei werden sowohl durch Ansteuerungen erfolgte Raddrehungen wie auch erzwungene Raddrehungen erfasst und zum Robo termodul zur ckgeschickt Dadurch kann man auch ein Verschieben des Roboters von Hand in der Positionsberechnung ber cksichtigen Leider k nnen durchdrehende R der nicht erkannt werden die se k nnen sowohl durch zu gro e Ansteuerungs nderungen beim Beschleunigen und Abbremsen als auch durch Kollisionen verursacht werden 3 6 3 Beschleunigungsmodul Das Beschleunigungmodul ist die Schnittstelle zwischen Strategie und Robotermodul Alle Ansteue rungsbefehle werden hier verarbeitet und anschlie en
60. d Kameras angewiesen Das Spielfeld und die Spieler sind farblich so markiert dass eine klare Unterteilung zu erkennen ist Die Spieler m ssen gr tenteils schwarz sein und eine Banderole tragen Diese Banderole tr gt eine Zahl und eine spezifische Farbe violett f r die eine t rkis f r die andere Mannschaft Gespielt wird auf einem gr nen 9m 5m gro en Feld mit einem orangefarbenen Ball der den FIFA Regeln entspricht Das Spielfeld ist nur von einer ca 10cm hohen Bande umgeben womit ein weiterer Faktor hinzukommt der z B bei der Bildverarbeitung oder der Selbstlokalisation ber cksichtigt wer den muss Die Markierungen auf dem Feld sind wei und entsprechen denen eines gew hnlichem Fu ballfeldes Die Tore sind 2m breit und 1m hoch sowie farblich von einander getrennt das eine ist blau und das andere gelb jeweils mit wei en Pfosten In den Spielfeldecken stehen Eckfahnen mit einer H he von Im und einem Durchmesser von ca 30 cm Die Eckfahnen des blauen Tors sind blau gelb blau gef rbt die Eckfahnen des gelben Tores entsprechend gelb blau gelb Ein Spiel dauert 2 10 Minuten Die Spieler sind soweit autonom dass sie nur beim Anpfiff und bei regelkonformen Unterbrechungen gesteuert werden d rfen ansonsten besteht w hrend des Spiels keine Interakti onsm glichkeit mit Menschen Die Spieler k nnen jedoch untereinander Informationen austauschen Ist ein Spieler ausgefallen oder soll er ausgewechselt werden kann dieser nach Absp
61. d an das Robotermodul weitergeleitet Ein An steuerungbefehl besteht aus einem Translationsvektor z B 0 1 bedeutet der Roboter soll mit 1 m s nach vorne fahren und einem Rotationswert mit welchem man die Eigendrehung steuert m w rde bedeuten drehe dich in einer Sekunde um 180 In jedem Takt erh lt das Beschleunigungsmodul einen neuen Ansteuerungsbefehl und berpr ft ob er das physikalische Modell des Roboters nicht verletzt Dadurch ist ein ruckelfreies weiches Fahren gew hrleistet Folgende Einschr nkungen bringt das physikalische Modell mit sich e Die Maximalgeschwindigkeit beim geradeaus Fahren betr gt 1 5 m s beim seitlichen Fahren 1 1 m s e Es kann mit 2m s2 beschleunigt und mit 3 m s2 gebremst werden 58 3 6 ROBOTERMODUL KAPITEL 3 SOFTWARE Ein neuer Fahrbefehl kann selten unkorrigiert an das Robotermodul weitergeleitet werden Rich tungs nderungen bei hoher Geschwindigkeit k nnen nicht in einem Taktschritt umgesetzt werden In diesem Fall wird der alte Fahrbefehl weich in den neuen bergeleitet Dies geschieht in dem man den alten Fahrbefehl so lange rotiert und skaliert bis der neue Fahrbefehl erreicht wird alter Ansteuerungsbefehl neuer Ansteuerungsbefehl an das Robotermodul gesendete Ansteuerungsbefehle Abbildung 3 28 Modifikation eines Ansteuerungsbefehl durch das Beschleunigungsmodul 59 3 7 FREMDE SOFTWARE KAPITEL 3 SOFTWARE 3 7 Fremde Software Innerhalb der
62. den Kontrollfluss im Programmablauf wurde die ge naue Zeitmessung des RTLinux eingesetzt Damit wurde erreicht dass zwischen zwei vollst ndigen Durchl ufen der Schleife in der Regel A 60 ms vergehen Sofern der Durchlauf schon vor Ablauf der eingestellten Zykluszeit fertig ist wird auf den Ablauf eines gesetzten Timers gewartet Diese Einschr nkung an den Programmfluss wird bisher haupts chlich f r die Berechnung der Ballge schwindigkeit beim Torwart siehe Unterabschnitt 3 4 3 eingesetzt Andere Module benutzen diese Informationen implizit Beispielsweise m ssten die Einstellungen des Beschleunigungsmodul adap tiert werden wenn sich die Zykluszeit ndert Der Motorcontroller des Roboters kann in einer Zeit von A 60 ms gefahrlos andere Geschwindigkeitsdifferenzen ausregeln als in einer Zeitspanne von A 100ms Entsprechend wird der Roboter bei unterschiedlichen Fahrman vern ungew nschtes Verhalten zeigen das durch das Beschleunigungsmodul abgefangen werden muss Zykluszeiten des Schleitendurchlauts 90 80 Dauer 60 50 40 30 20 Dauer in ms 0 200 400 600 800 1000 1200 1400 1600 1800 2000 lterationen Abbildung 3 3 Zyklusdauer der Hauptschleife von Tribots Ein Durchlauf von dem Holen und Verarbeiten des Bildes bis zum Ansteuern des Roboters dau ert also in der Regel nicht mehr als A 60ms In Bild 3 3 sind kleinere Ausschl ge gegen ber der 60 ms Linie zu sehen Es ist bisher unbekannt woher diese Ungenauigke
63. df higkeiten Ein Ziel f r das Strategie Modul ist die Bereitstellung von robusten Grundf higkeiten Dazu geh ren 1 zuverl ssiges Man vrieren auf dem Feld mit und ohne Ball 2 stabile Ball Anfahrt 3 Hindernis Kollisions Vermeidung Obstacle Avoidance 4 schnelles Ball Dribbling Diese F higkeiten besitzt der Roboter aus jeder Spielsituation heraus unabh ngig von seiner Po sition Ausrichtung Geschwindigkeit und Fahrtrichtung Da die Positionen des Balls und der Hindernisse stets relativ zum Roboter vorliegen funktio nieren die oben genannten Grundf higkeiten prinzipiell auch bei schlechter oder sogar ausgefallener Selbstlokalisation Die Verwendung eines omnidirektionalen Fahrwerks verschafft diverse z T auch taktische Vorteile z B k rzerer und direkterer Ballanfahrtsweg Diese sollten bei der Umsetzung der Grundf higkei ten genutzt werden 41 3 4 STRATEGIE KAPITEL 3 SOFTWARE Zur Realisierung der o a Aufgaben kommen zwei Ans tze zum Tragen Zentrales Unterschei dungskriterium ist dabei der Ballbesitz Besitzt der Roboter den Ball nicht d h liegt dieser nicht direkt vor seiner Ballf hrungseinheit und der Roboter muss diesen nicht vor sich her f hren kann er mit ganz anderen Mitteln auf dem Spielfeld man vrieren als mit Ball Man vrieren ohne Ball F r das Man vrieren ohne Ball sind die Grundf higkeiten ausschlie lich auf Basis eines reaktiven Vektorfeldes realisiert Es werden dazu in jedem R
64. die Qualit t zu niedrig ist wird ein ruhender Ball angenommen und der Torwart positioniert sich so dass der offene Torraum links und rechts seitlich bzw hinter ihm minmale Angriffsfl che f r einen auf die Tormitte zurollenden Ball bieten w rde Diese Position sei P Bei einem rollenden Ball wird berechnet an welcher Stelle er die Kreislinie vor dem Tor passieren w rde bezeichnet mit P2 Abh ngig von der Ballgeschwindigkeit und Balldistanz wird nun eine Zielposition berechnet welche zwischen P und P liegt Ansteuerung Da der Torwart in der Lage sein muss schnell und pr zise Positionen anzufahren und sich nicht um eine Hindernisvermeidung bem hen braucht wird nicht das in Unterabschnitt 3 4 1 beschriebene Vektorfeld zur Ansteuerung benutzt sondern ein eigens daf r entwickeltes Modul Als Eingabe dient der in der Entscheidungsfindung berechnete Zielpunkt Abh ngig von der Ent fernung vom Torwart bis zum Zielpunkt und der maximalen Anfahrts und Bremsbeschleunigung es kann schneller gebremst als beschleunigt werden wird die erlaubte Maximalgeschwindigkeit f r den n chsten Ansteuerungsbefehl berechnet Diese wird an das Beschleunigungsmodul geschickt und von da aus letztendlich an den Roboter 49 3 5 KOMMUNIKATION KAPITEL 3 SOFTWARE 3 5 Kommunikation 3 5 1 Protokoll und Schnittstellen F r ein effektives Roboterverhalten ist die Kommunikation untereinander unerl sslich Die von uns eingesetzte Technologie ist das WL
65. duns 4 22 a A e a eg 74 A 3 TribotsControl Anwendung 2 2 CE on nn 81 AA Tribots Programiastatt ana rar a e 85 A5 Kurzreferenzen a A a a A E A A a a a 86 A 6 Problembehebung m Emm nn 87 INHALTSVERZEICHNIS INHALTSVERZEICHNIS B Hardware 89 B 1 Projektion eines Weltpunktes auf einen Bildpunkt 89 B 2 AnscHlussplamos sita daa re a It ee a d e oR E 90 B 3 Ansteuerung Schusseldheit CC m nm n nenn 93 B 4 Konfigurationsdateien 2 2 22 oo nn nn 95 B 5 Kameleon Kommunikationsprotokoll 2 22 2m Emm nn 98 Abbildungsverzeichnis 2 1 2 2 2 3 2 4 2 5 2 6 2 1 2 8 2 9 2 10 2 11 2 12 3 1 3 2 3 3 3 4 3 5 3 6 3 7 3 8 3 9 3 10 3 11 3 12 3 13 3 14 3 15 3 16 3 17 3 18 3 19 3 20 3 21 3 22 3 23 3 24 3 25 3 26 3 27 Roboteraulba amp ta a 2 A A A A A A he 10 Omnidirektionales Rad on nee 11 Fahrwerk Dr ufsicht s o 22 22 a ern aan ko us an ERSA 12 Komponenten der Steuer und Kontrollebene 2 2 2 2 2 Emm nennen 13 Montierte Spiegel Tr gerplatte a 14 Befestigung des Kameramoduls 2 CC mn n nn 14 Der Steuerrechner JVC MP XP7210 e 15 Das Motorcontroller Board Kameleon 376SBC 2 2 En nn 17 Das Robotic Extension Board f r das Kameleon 376SBC 2 22222200 18 Der Motorcontroller TMC200 aoaaa nn 19 Mechanischer Aufbau der Schusseinheit 22 22 22 cn n mn nn 20 Schematische Darstellung des Zusammenspiels der
66. e so verschluckt er die ersten w hrend der R ckkehr in den aktiven Modus B 2 1 Kameleon Be 24Y Einspeisung Abbildung B 2 Datenkabel Konverter und Adapter zwischen den Roboterkomponenten Kamele on Den Motorcontroller K376SBC speist ein separater Akkupack mit 12 V DC die Verbindung zwi schen ihnen ist ber ein AMP Steckersystem aus dem Modellbau Bereich realisiert Dieses bietet einen Verpolungsschutz F r den Betrieb des REB existiert ein separater Stromkreis Elektronik und Motorkreis sind damit getrennt ein R ckflie en von Motorstr men in die Elektronik ausge schlossen Zwei 12V DC Akkupacks ber das AMP Steckersystem in Reihe geschaltet gen gen dem REB um die drei Motoren anzutreiben Die Massen der zwei verschiedenen Stromkreise sind intern auf dem Kameleonboard zusammen geschalten Ein 10 adriges Flachbandkabel verl uft zwischen REB und jedem angeschlossenen Motor Je drei Adern liegen auf 12 V DC bzw Masse und sind direkt mit den Motorpolen verbunden die restlichen vier Adern mit dem Motorencoder Somit ist eine Regelung m glich ber diese vier Kan le werden Robotic Extension Board 91 B 2 ANSCHLUSSPLAN ANHANG B HARDWARE 12V Akkupack 24V Akkupack Digi Power Out 9 me 1EEE1394 5V DC elektr au Ventil Repeater amp g 34V DC l Taaaz 1EEE139
67. e String bedeutet dekodiert Roboter 3 spielt als DEFEND3 12 Transport Control Protocol 13 comma separated value 50 3 5 KOMMUNIKATION KAPITEL 3 SOFTWARE DATAX 6 auf das blaue Tor DATAY 2 mit dem KICKOFF PRESET 3 DATAZ 3 Das aufgestellte Kommunikationsprotokoll bietet Flexibilit t weil unterschiedliche Datentypen int float QTIME ber einen CSV String bertragen und auf der Empf ngerseite wieder dekodiert werden k nnen Der Nachrichtencode ist variabel und kann jederzeit leicht angepasst und erweitert werden um weitere Daten zu bertragen Diese Flexibilit t produziert gegen ber einem minimierten Protokoll Daten Overhead Aufgrund der zur Verf gung stehenden ausreichenden Band breite der zugrundeliegenden Technologie sind dadurch jedoch keine Nachteile zu erwarten Die Verbindung zwischen Roboter und TribotsControl besteht blicherweise w hrend des gesam ten Spiels Unmittelbar nach Verbindungsaufbau senden die Roboter ihren aktuellen Status Role TargetGoal Kick0ff Preset an TribotsControl Alle 300 ms senden die Roboter zudem ihre ak tuelle Selbstlokalisationsposition Sofern ein Fehler etwa der Absturz des Kameramoduls auftritt und bei nderung der Einstellungen zu Role oder TargetGoal wird sofort eine Nachricht an Tri botsControl verschickt Hier werden alle Daten geb ndelt aufgearbeitet und die n tigen Ma nahmen ergriffen Trotz der Nutzung von TCP Paketen kann es jedoch u a durch erh hten Ve
68. e ersten beiden Teams gegen die angetreten wurde hatten eine schon etwas l ngere oder genau so lange Entwicklungszeit hinter sich wie unser Team trotzdem hatten diese mehr Probleme Es ging gegen das Team der Uni T bingen und gegen Mostly Harmless aus Graz Die Roboter dieser Teams waren kaum in der Lage sich zu lokalisieren und bewegten sich nur sporadisch Die eigenen Roboter jedoch bewegten sich registrierten ihre Position und die des Balls so dass die Spiele mit 3 0 und 4 0 recht klar gewonnen wurden Im weiteren Verlauf zeigten jedoch einige Gegner die bis dahin noch vorhandenen Schw chen auf so wie das Team vom Fraunhofer Institut AIS die wesentlich schneller und agiler waren sowie eine dynamische Rollenverteilung hatten Das dritte Spiel ging mit 10 0 an sie Leider erwiesen sich die eingesetzten Steuerboards vom Typ Kameleon 376SBC als nicht beson ders zuverl ssig daher mussten die Roboter fter als erwartet vom Feld genommen werden um sie neu zu initialisieren Zudem fielen in diesem Spiel strategische Fehler auf die am gleichen Abend noch verbessert wurden z B wurde der Torwart sowie die Hinderniseinstellung stark verbessert Die Strategie wurde insofern berarbeitet dass die Verteidiger aggressiver zu Werke gingen Besonders wichtig war dass ein schwerwiegender Fehler im gesamten Ablauf der Software gefunden wurde der das Programm stark verlangsamt hatte Au erdem wurde offensichtlich dass beim Bau der Roboter die Wirkung der
69. e gleiche Bedingung erf llen Deswegen berleben diesen Fortpflanzungsschritt haupts chlich Pixel die in den gr ten zusam menh ngenden Farbfl chen wie Tor und Ball zu finden sind Die Mittelpunkte dieser Objekte werden durch Mittelung der zugeh rigen Pixelpositionen berechnet Durch die gewonnene Zeit bei der Suche k nnen im Programm dessen Laufzeit sich dadurch ebenfalls verk rzt mehr Bilder bearbeitet werden es ergeben sich schnellere Bildfolgen So werden Bewegungen im Bild nur durch kleine nderungen von Bild zu Bild sichtbar Schnelle Objekte wie der Ball werden in jedem Bild allein durch den Fortpflanzungsschritt und durch die Information aus dem letzten Bild erfasst und so effektiv verfolgt werden ohne einen neuen Suchschritt zu ben tigen Eine schematische Implementierung des Tracking Algorithmus wie er f r den Ball die Tore und 32 3 2 BILDVERARBEITUNG KAPITEL 3 SOFTWARE 7000 1 Meter entfernt 1 70 Meter entfernt x 6000 J 5000 J 4000 J 5 N E S an 2 3000 J 2000 J 1000 POE O RR EREEREER E E 200 150 100 50 0 50 100 150 200 Winkel Grad Abbildung 3 8 Ergebnisse einer Distanzmessung nach der Distanzkalibrierung die Eckfahnen eingesetzt wurde besteht aus den beiden Teil Algorithmen sample_step vgl Algo rithmus 3 und propagate_step vgl Algorithmus 4 Beim sample_step Algorithmus wird eine festgelegte Pixelanzahl Anzahl Ball Partikel im Such raum auf e
70. e technischen Schwierigkeiten bei der korrekten Ausrichtung von Kamera auf Spiegel und dieser Einheit auf die Umgebung ist es nicht m glich ein Bild zu erzeugen in dem die Verzerrung 30 3 2 BILDVERARBEITUNG KAPITEL 3 SOFTWARE des Spiegels in alle Richtungen gleichf rmig ist Dadurch werden vor allem Distanzmessungen stark beeinflusst welche aber f r Teile des Entscheidungsablaufs im Programm wie die Ballanfahrt und die Obstacle Avoidance essentiell wichtig sind so dass notwendigerweise diese Messungen bez glich der aktuellen Spiegeleinstellungen umgerechnet und korrigiert werden Zur Aufstellung der Distanzfunk tion wurde eine Messtechnik verwendet die die Realdistanz zu jedem auf dem Boden befindlichen Punkt im Bild berechnen kann Abbildung 3 6 Schema der Umgebung f r eine Distanzmessung Kalibrierung Zur Messung ist eine geeignete Umgebung n tig in der festgelegte Marker m glichst verwechslungsfrei erkannt werden Abbildung 3 6 beschreibt die benutzte Umgebung sie besteht aus dem Ball drei wei en DIN A4 Seiten und dem blauen Tor jeweils in definierten Entfernungen Dem Distanzmessungsalgorithmus dient der Ball als Referenzpunkt er kann in jedem Bild zweifelsfrei erkannt werden Der Algorithmus sammelt folgende Farb berg nge als Messdaten e Ball bergang des Balls zum Boden e Marker berg nge von Markern zum Feld e Tor bergang vom Feld zum Tor Wurde der Ball gefunden und der Distanzmessungsalgorithmus in de
71. ec aktiviert bzw deaktiviert die Ansicht der Vektoren 80 A 3 TRIBOTSCONTROL ANWENDUNG ANHANG A BEDIENUNGSANLEITUNG X PathFinder alm xj Info Tools Robot Position WM FrameNo Rei Robot Speed Robot mMoveOrder ta Move Mode J Clr Log Ld Log p vecs Abbildung A 5 Pathfinder Fenster der Tribots Anwendung Der Replay Bereich des Fensters enth lt alle Funktionen f r die Wiedergabe einer aufgezeich neten Log Datei Sowohl ber den Schieberegler als auch ber die entsprechenden Kn pfe l sst sich Vor und Zur ckspulen die Wiedergabe stoppen oder im Normalmodus abspielen Wiedergegeben wird das ber den Replay Knopf im Tool Fenster aufgenommene Verhalten des Roboters bzw das der geladenen Log Datei Diese Funktion bietet gute M glichkeiten f r die Analyse des Fahrverhal tens des Roboters Die strategische Spielfeldansicht stellt schlie lich alle aufbereiteten Daten grafisch dar den eigenen Roboter nebst Ausrichtung grauer Kreis mit schwarzer Linie den Ball rot gef llter Kreis das momentane Ziel mit dem dazugeh rigen Einflussradius blauer Kreis alle Hindernisse schwarze Kreise nat rlich das Spielfeld beide Tore und wenn aktiviert die Vektoren Zu beachten ist dass das momentane Ziel vom Ball abweichen kann wenn der Ball z B nicht gesehen wird und deshalb eine alternative Position angesteuert wird A 2 5 Odometrie Selbstlokalisationsfenster Das OdoSL Fenster dient der Kontrol
72. echnet Als Beispiel wird die Implementierung der Methoden moveParticlesByOdometry und validate ParticlesBySensors in Pseudocode aufgef hrt Die Auswirkung dieser verrauschten Verschiebung auf eine Wolke von Partikeln l sst sich auch in der Schemazeichnung siehe Abbildung 3 11 erkennen 1Pprobability density function Wahrscheinlichkeitsdichtefunktion 38 3 3 WELTMODELL KAPITEL 3 SOFTWARE Abbildung 3 10 Demonstration eines Kidnap Vorganges Der Roboter der in Bild 1 rechts vor dem Tor steht wird umgesetzt Durch die zus tzlich mit eingestreuten Partikel werden schnell neue Zentren gefunden und die Verteilung verschiebt sich an die neue Position Abbildung 3 11 Schema der Verschiebung von Partikeln durch Odometrieinformation Sequentielle Ausf hrung einer Verschiebung entlang der x Achse Resampling Nach der Partikelneugewichtung werden die Partikel gem ihrer Wahrscheinlichkeit neu gezogen Resampling Wahrscheinlichere Partikel werden fter gezogen und unwahrscheinliche Partikel sterben aus dadurch geht das Vorwissen des Algorithmus die Verteilung mit in die Positionsberechnung ein Ein einfacher Algorithmus f r die Auswahl l uft in O Nlog N es ist jedoch m glich diese Auswahl in O N zu treffen 3 Als Beispiel f r das Resampling zeigt die Abbildung 3 12 zeigt die Partikelverteilung einen Schritt nach der Gleichverteilung bei bekannter Distanz zu den Fu punkten des blauen
73. ed die Geschwindigkeitseinheit ist Pulse 10ms e kam get_pos kam_data_type data int nMot liest die Position des 32 bit Inkrementalen coders von Motor nMot in der Einheit Pulse oder A D Bits aus e tmc_set_velocity_answermode tmc_data_type data int _mode konfiguriert die Antwort auf einen Befehl zum Setzen der Geschwindigkeit m gliche Werte f r mode sind keine R ckantwort aktuelle Geschwindigkeiten 3 Nachrichtenz hler aktuelle Zyklenzeit Distanz 5 und gr er aktueller PWM Output 0 1 2 aktuelle Str me 3 4 e tmc_get_coilTemp tmc_data_type data liefert f r alle Motoren die durch das thermische Modell berechnete Temperatur zur ck Wrapper Modul Die bisherigen Controller spezifischen Befehle sind f r eine intuitive und ein fache Robotersteuerung nicht ausreichend Die Funktionen der Controller werden erneut gekapselt Motivationen hierf r Die Geschwindigkeitseinheiten der verschiedenen Controller differieren sehr stark z B Pulse 10 ms des Kameleon und der Motorleerlaufdrehzahl des TMC200 nach au en jedoch soll f r alle Control ler eine einheitliche Schnittstelle entstehen ergo m ssen sie alle auf dieselbe Geschwindigkeitseinheit zur ckgreifen Die Entscheidung ist zugunsten von rad s gefallen da sie den meisten gel ufig ist und eine zweckm ige Dimension besitzt Eine analoge Vorgehensweise gibt es f r die Versorgungsspan nung normiert auf Volt und die Motorstr me norm
74. egelzyklus sukzessive die verschiedenen den Pfad beeinflussenden Kr fte aufsummiert Am Ende erh lt man den resultierenden Fahrtvektor Im Ein zelnen werden aufsummiert Basisvektor in Richtung Ziel Vektoren der Hindernisse Anfahrtsvektor Fahrtvektor Der Basisvektor ist der Richtungsvektor von der aktuellen Roboterposition zum Ziel Seine L nge ist stets auf 1 normiert Obstacle Avoidance Jedes Hindernis ist von einem gedachten runden absto enden Kraftfeld umgeben dessen St rke nach au en abnimmt Ger t der Roboter in den Einflussbereich des Hinder nisses wird seine geplante Fahrtrichtung Basisvektor von dem Hindernis beeinflusst siehe Abb 3 13 Er wird vom Hindernis weggedr ckt bzw in mehreren Zyklen herum geleitet Ball Gegner Abbildung 3 13 Einfluss von Hindernissen auf den Fahrtvektor Beeinflussung des Basisvektors a durch den Vektor eines Hindernisses b und neuer resultierender Fahrtvektor c Ball Anfahrt hnlich wie beim Hindernis umgibt auch den Ball ein rundes absto endes Vektorfeld im Folgenden Anfahrtsvektorfeld genannt allerdings mit der Ausnahme dass dieses Vektorfeld an einer Seite eine Schneise aufweist durch die der Roboter an den Ball gelangen kann Man erreicht dadurch dass der Roboter den Ball von einer bestimmten Seite her anf hrt Hier nutzt man im brigen die Eigenschaften des omnidirektionalen Fahrwerks aus das es dem Roboter erlaubt permanent zum gegnerischen Tor ausger
75. egie erntete das eigene Team von allen Seiten Lob und Anerkennung besonders im Hinblick auf die recht kurze Entwicklungszeit Trotz dieser Verbesserungen schied das Team in einem u erst knappen Spiel mit 0 1 ungl cklich im Viertelfinale gegen die Sparrows aus Ulm aus Die Gr nde waren offensichtlich die Hardware verhinderte erneut dass die Roboter lange einsatzbereit auf dem Feld waren Auch das Fehlen einer effektiven Schusseinheit wurde schmerzlich vermisst Weiterhin wurde klar dass eine dynamische Rollenverteilung das Ausscheiden verhindert h tte denn ein ausgefallener St rmer h tte so von einem Verteidiger ersetzt werden k nnen Dennoch konnte das Turnier erhobenen Hauptes verlassen werden einige etablierte Gegner wur den geschlagen und anderen wurden gute Spiele geliefert 4 4 2 Robocup WM 2003 Nachdem kurz nach den German Open die Entscheidung gef llt worden war zur WM in Padua zu fahren wurden die Schwachpunkte unseres Abschneidens aus Paderborn zusammengestellt und begonnen diese in der kurzen Zeit bis zum Beginn des Wettbewerbs m glichst zu beseitigen Besonders die instabile Hardware die Geschwindigkeit der Roboter und die Strategie u a im Hin blick auf den Torschuss mussten verbessert werden Der Torwart sollte komplett berarbeitet werden zudem bekamen alle Roboter eine leistungsstarke Schusseinheit und die dynamische Rollenverteilung wurde implementiert Da im Vorfeld der WM keine Zeit f r aufwendige Benchmar
76. elle zur Ansteuerung der von uns eingesetzten Motorcontroller bereit Die fremden Programme die wir verwendet haben beschreiben wir am Ende 1 4 BERSICHT KAPITEL 1 EINLEITUNG dieses Kapitels Auf die durchgef hrten Systemstests geht Kapitel 4 ein Zum Abschluss werden wir das Erreichte darstellen und Perspektiven aufzeigen Im Anhang findet man die Anleitung f r das Hauptprogramm Tribots und das Remote Programm Tribots Control sowie technische Informationen zur Hardware Kapitel 2 Hardware 2 1 berblick Die erste berlegung die im Hinblick auf das Hardwaredesign im Rahmen der Projektgruppe an gestellt wurde betraf das zu verwendende Bildverarbeitungssystem Zur Diskussion standen zwei grunds tzlich verschiedene Ans tze e eine direktionale Kamera sie besitzt ein begrenztes Sichtfeld in etwa vergleichbar mit dem menschlichen so dass zu einem Zeitpunkt nur ein Bruchst ck der Umgebung wahrgenommen werden kann e eine omnidirektionale Kamera sie nimmt die gesamte Umgebung rund um den Roboter gleich zeitig wahr ein 360 Rundumblick Realisiert wird dieses indem die Kamera auf einen ent sprechend geformten Spiegel blickt in dem sich das gesamte Umfeld widerspiegelt Letzterer Ansatz bietet einen gro en Vorteil bedeutete aber die Inkaufnahme eines direkt damit verbundenen Nachteils nicht lineare Entfernungen im Spiegelbild aufgrund der Spiegelform Nach Meinung der Projektgruppe berwog der Nutzen und sie entsc
77. en werte kann je nach Befehl variieren wobei die Trennung der Werte erneut durch Leerzeichen erfolgt Abgeschlossen wird der Befehl mit CR oder LF Die Antwort des Controllerboards besteht 15Der Antwortmodus wurde so gew hlt wie er in einem Spiel w re 55 3 6 ROBOTERMODUL KAPITEL 3 SOFTWARE e f r Setter aus dem ASCII String OK n e f r Getter aus dem Befehlswort ohne das erste Literal gefolgt von den entsprechend dem Befehl geforderten Parametern jeweils durch Leerzeichen getrennt So setzt z B SV 0 0 O n alle drei Motorgeschwindigkeiten auf 0 m s und GMODE An liefert den aktu ellen Arbeitsmodus zur ck Kommunikationsmodul Zur Umsetzung der echtzeitf higen Kommunikation wurde RTLinux ein Linuxderivat verwendet Der bisherige Betriebssystemkern wird dabei als eigenst ndiger Task in den RT Kernel eingebunden welcher direkt auf die Hardware aufsetzt und erh lt die niedrigste Priorit t Programme die die Echtzeitf higkeit nutzen wollen m ssen aus zwei Teilen bestehen der eine enth lt Echtzeit Aufgaben z B die direkte Kommunikation mit der Hardware und der andere die nicht zeitkritischen Arbeiten wie das Protokollieren der Daten auf Festplatte Die Kommunikation zwischen beiden Teilen wird ber eigens daf r erzeugte Character Devices abgehandelt sog RT FiFos F r einen bidirektionalen Datenaustausch werden insgesamt vier solcher FiFos ben tigt ein Kommando FiFo bertr gt Befehle aus dem User Space
78. en tigt da ber GUI schaltbar MERGE_OBSTACLES 0 1 schaltet zusammenfassen der Hindernisse an aus MERGE_OBSTACLES_OFFSET Bereich in mm in dem Hindernisse zusammengefasst wer den TCN Nummer des Roboters f r TCPE TCPE IP Adresse des TCPE Rechners WRITE IMAGE TO FILE 0 1 schaltet abspeichern der Kamerabilder an aus NUM _SAVED_IMAGES Anzahl der Abzuspeichernden Bilder WRITE _IMAGES_WITH_ SEGMENTATION 0 1 gibt an ob die Bilder segmentiert abge speichert werden SLIDE IMAGES AUTO 0 1 Bilder werden automatisch durchgebl ttert SLIDE IMAGES_MANUAL 0 1 Ein Bild wird solange als INput benutzt bis benutzer weiter schaltet STANDARD_PLAYERTYPE Gibt den Initialisierungswert f r den Spielertypen an 97 B 5 KAMELEON KOMMUNIKATIONSPROTOKOLL ANHANG B HARDWARE B 5 Kameleon Kommunikationsprotokoll B 5 1 Vorbemerkungen In den folgenden Abschnitten steht II f r CR carriage return oder LF line feed sowie T f r CR und LF Ein gesendeter Befehl hat immer das Format CharChar Variable U mit i 0 1 n die dazu geh rige Antwort hat das Format CharChar Variable T wiederum mit 0 1 n B 5 2 Liste der verf gbaren Kommandos AA AB DA DB EA EB FB GA GB Konfiguration eines PID Geschwindigkeitskontrollers Befehl AA Motornummer K K Ka II Antwort aal Konfiguration aller PID Geschwindigkeitskontroller Befehl AB K K Ka Y Antwor
79. eren Kontrollierbarkeit das Thread Konzept durch ein serielles ersetzt n here Informationen liefert Abschnitt 3 1 2 Weitere Verbesserungen wurden in den Bereichen Pfadplanung Selbstlokalisation Bildverarbeitung Ansteuerung der Motoren Kom munikation und Torwart angestrebt da sich bei den German Open u a gezeigt hatte dass sich die Roboter noch nicht schnell genug auf dem Spielfeld bewegten dass in manchen Situationen der Verteidiger zur ck in die eigene H lfte fuhr obwohl das gegnerische Tor leer stand oder dass dieser wegen der fehlenden Schusseinheit kein Tor erzielte Jeder Roboter erhielt konsequenterweise eine Schusseinheit Das Design des Torwarts wurde ver ndert der Kicker des Torwarts wurde im Verh lt nis zu den anderen Spielern breiter und an den Seiten wurden Verstrebungen angebracht so dass der Torwart mehr Raum im Tor einnahm 1 4 bersicht Das Kapitel 2 informiert ber die von uns eingesetzte Hardware und das Design des Roboters Zum Fu ballspielen ben tigt ein Roboter verschiedene Sensoren und Aktoren die seine Wahrnehmungs und Reaktionsm glichkeiten bestimmen Der Sensor der bei uns am h ufigsten genutzt wird ist das Kamerasystem wodurch wir ein 360 Abbild der Umgebung erhalten Der Aufbau und die Funktionsweise der Kamera werden ebenso erl utert wie das omnidirektionales Fahrwerk und die Schusseinheit Diese Komponenten werden vom Motorcontroller angesteuert Der Motorcontroller erh lt Befehle vom Steue
80. erh lt man die Bewegungsrichtung des Balls und die L nge dieses Vektors beschreibt die Ballgeschwindigkeit Allerdings sind die Daten aus der Bildverarbeitung oft verrauscht und ungenau Abhilfe schafft ein gl ttender Filter Es wurde ein eigener Ballfilter entwickelt vgl Abbildung 3 22 der die Linearit t des Weges eines rollenden Balls ausnutzt Ist der Weg den der Ball nimmt ber mehrere Zyklen hinweg konstant entspricht dies einer hohen Qualit t des Ballvektors und der Torwart verl sst sich bei der Entscheidungsfindung auf diese Information Dies ist bei schnellen B llen in der Regel der Fall Ruhende oder langsame B lle haben oft einen springenden Verlauf was zu einer dementsprechend niedrigen Qualit t f hrt Da man sich hier kaum mehr auf die Information des Ballvektors verlassen kann wird der Ball als ruhend betrachtet Die aktuelle Ballposition falls vorhanden wird direkt aus der Bildverarbeitung bernommen gt gt 7l gt 00 0590 N gt gt gt gt 00 05 90 O Abbildung 3 22 Wirkungsweise des Ballfilters Ohne Ballfilter verf lscht eine inkorrekte Informa tion aus der Bildverarbeitung die berechnete Ballbewegung stark oben Nimmt man den Ballfilter hinzu so ist die Berechnung nur leicht verf lscht unten Entscheidungsfindung Abh ngig von der Qualit t des Ballvektors entscheidet der Torwart nun ob die Information ber die Ballbewegung mit in die Entscheidungsfindung einflie t oder nicht Falls
81. erst sollten die Regler so eingestellt werden dass die Farbe sehr gut erkannt wird also auch mehr als die gew nschten Objekte Danach kann ber die Regler die Erkennung soweit heruntergedreht werden dass nur noch die ben tigten Objekte segmentiert werden Im Einzelnen lassen sich die Farben wie folgt segmentieren e Blau Kalibrierung Die Regler geben an wie gro der Blauwert eines Pixels mindestens sein muss um als Blau er kannt zu werden MaxBlau wie gro der Rotwert eines Pixels maximal sein darf um als Blau erkannt zu werden MinRot und wie gro der Gr nwert eines Pixels maximal sein darf um als Blau erkannt zu werden MinGr n Am Anfang sollten MaxBlau niedrig sowie MinRot und MinGr n hoch eingestellt sein Durch Heraufsetzen von MaxBlau und Heruntersetzen von MinRot und MinGr n l sst sich die Erkennung einschr nken e Gelb Kalibrierung Die Regler geben an wie grof der Rotwert eines Pixels mindestens sein muss damit der Pixel als Gelb erkannt wird MaxRot wie gro der Gr nwert eines Pixels mindestens sein muss damit der Pixel als Gelb erkannt wird MaxGr n und wie gro der Blauwert eines Pixels maximal sein darf damit der Pixel als Gelb erkannt wird MinBlau Am Anfang sollten also MaxRot und MaxGr n niedrig und MaxBlau hoch eingestellt sein Durch Heraufsetzen von MaxRot und MaxGr n und Heruntersetzen von MinBlau l sst sich die Erkennung einschr nken e Rot Kalibrierung Die Regler geben an wie gro die
82. f r die Einhaltung der Echtzeit bertragungen die Fehlererkennung und stellt rudiment re Befehle zum Senden und Empfangen bereit e das Controller Modul implementiert Controller spezifische Funktionen und enth lt zur Kom munikation notwendige Parameter z B die Schnittstellengeschwindigkeit e das Wrapper Modul kapselt das Controller Modul und stellt dessen Funktionalit t nach au en ber ein Interface bereit Dies erlaubt den Austausch des Motorcontrollers ohne dass sich die Schnittstelle f r den Benutzer ndert Beschleunigungs modul Wrapper Modul kameleon rt_serlal_app Kommunikationsmodul rt_serial_ mod Abbildung 3 24 Komponenten eines Robotermoduls und deren Realisierung Eingabe sind die Ge schwindigkeiten in x bzw y Richtung sowie die Drehgeschwindigkeit v vy und Up welche durch das Beschleunigungsmodul angepasst werden falls n tig Durch Kinematikgleichungen im Wrappermodul werden diese Geschwindigkeiten auf die einzelnen R der v1 v2 und v3 umgerechnet und an den Motorcontroller bermit telt Mit diesem Ansatz wird eine offene Architektur angestrebt der Motorcontroller kann ausgetauscht werden ohne die Schnittstelle nach au en hin ndern zu m ssen Lediglich die Controller eigenen Befehlss tze erfordern die Implementierung eines neuen Controller Moduls Bevor auf die einzelnen Punkte n her eingegangen wird folgt eine Einf hrung in die verwendeten Kommunikationsprotokolle Das
83. fahnen Poles 2 blau gelb blau und zwei gelb blau gelb 4 einem orange farbenen Ball 5 diversen schwarzen Hindernissen Genau diese Aspekte m ssen in das Weltmodell des Roboters einflie en das durch die Klasse CWorld Model modelliert wird Sie erh lt ihre Eingabedaten entweder aus der Bildverarbeitung oder aus dem Simulator CDortmundClient oder aus aufgezeichneten Daten Diese Daten sind repr sentiert durch die Klasse CPossible0Object eine erweiterbare Contai nerklasse f r erkannte Objekte aus der Bildverarbeitung Die Typen der verschiedenen m glichen Objekte sind in der Datei Global_Defines h definiert Darunter finden sich e Ball der Ball im Roboterkoordinatensystem e Tore Richtung und Entfernung der Tore e Torpfosten Richtung der Torpfosten e Eckfahne Richtung der Eckfahne Pole e Hindernisse Richtung und Entfernung eines Hindernisses 3 3 2 Selbstlokalisation F r das Entscheidungsmodul und dessen sp tere Aktionsauswahl ist es besonders wichtig zu wissen wo sich der Roboter auf dem Spielfeld befindet So sind viele Verhaltensweisen eines Roboters beim Robocup von dessen aktueller Position auf dem Spielfeld abh ngig z B die richtige Positionierung des Torwarts oder der Feldspieler der Torschuss oder das Teamplay Lokale Lokalisation Man kann versuchen die Position lediglich aus einer bekannten Startposition und durch Messen des zur ckgelegten Weges zu berechnen dead reckoning Aufgrund der Dyna mik und der
84. fertig berlassen entwickelt und konstruiert wurde es im Rahmen einer Diplomarbeit von Herrn Roland Hafner 5 Angetrieben wird das Fahrwerk von drei Motoren mit je 20 Watt Leistung die in einem Winkel von 120 zueinander angeordnet sind Die max 6425 Umdrehungen pro Minute eines Motors werden ber ein zweistufiges Planetengetriebe mit der Untersetzung von 19 1 auf ein omnidirektionales Rad bertragen Omnidirektional bedeutet hier dass ein Rad nicht nur in der eigentlichen Laufrichtung des Rades sondern auch orthogonal dazu bewegt werden kann Realisiert wird dieses ber orthogonal zur Laufrichtung des Rades angebrachte Rollen vgl Abbildung 2 2 Diese Rollen bestehen wie das gesamte Rad abgesehen von Verschraubungen aus Polyurethan und sind somit recht haltbar wenngleich sie eine nicht ganz so gute Traktion auf dem Spielfelduntergrund gew hrleisten Eine denkbare Verbesserung w re hier die Laufrollen z B mit einem Gummimaterial zu beschichten Abbildung 2 2 Omnidirektionales Rad Die orthogonal zur Laufrichtung angebrachten Rollen gr n erm glichen Bewegungen nicht nur in der eigentlichen Rad Laufrichtung sondern auch orthogonal zu dieser Ebenfalls im Fahrwerk gelagert sind die f r die Stromversorgung der Motoren des Kontrollboards vgl Unterabschnitte 2 3 1 und 2 3 2 und der Kamera ben tigten Akkumulatoren Bei diesen han delt es sich um drei aus je 10 Zellen bestehende Akkupacks die je 12V und 2400 mAh leisten
85. g Ein grunds tzliches Problem f r die Bahnplanung ist die Tatsache dass das zugrundeliegende Weltbild aufgrund der Kameradaten niemals eine vollst ndige Karte der Umgebung widerspiegelt sondern nur die Objekte innerhalb eines ca 5m Radius korrekt darstellt Dies f hrt zu der ber legung keine vollst ndige Pfadsuche auf dem gesamten Spielfeld durchzuf hren sondern einen re aktiven Algorithmus zu entwerfen der zwar aus Unkenntnis der Position weit entfernter Objekte m glicherweise zun chst eine falsche Entscheidung trifft kurz und mittelfristig jedoch schnell und sicher Man vrieren kann und so auch aufgrund der Dynamik des gesamten Systems langfristig ans Ziel gelangt Man kann die Aufgaben des Strategie Moduls generell in zwei Teilbereiche zerlegen Zum einen soll es f r eine sichere und robuste Ansteuerung des Roboters zu jedem Zeitpunkt w hrend des Spiels sorgen Es soll also Ansteuerungsbefehle generieren die es dem Roboter erm glichen sicher zwischen Hindernissen hindurch zu man vrieren oder etwa den Ball bei Kurvenfahrten zu f hren Diese F hig keiten werden im Folgenden Grundf higkeiten genannt und bilden die Basis zur Ansteuerung des Roboters Zum anderen soll der Roboter intelligentes Spielverhalten zeigen d h er soll den verschie denen Spielsituationen angepasste Man ver fahren und z B nicht auf das eigene Tor spielen Diese Eigenschaften werden im Folgenden als h here F higkeiten bezeichnet 3 4 1 Grun
86. g 2 4 Komponenten der Steuer und Kontrollebene Im Vordergrund zu erkennen sind die drei Arme aus Aluminiumprofilen mit den entsprechenden Biegungen an der Unterseite versehen mit den Halterungen zur Befestigung am Fahrgestell sowie dahinter eine Tr gerplatte e f r die Schusseinheit notwendige Peripherie der f r die Druckluftversorgung der Schusseinheit n tige Drucklufttank die Ausl seelektronik sowie das Druckventil 2 1 4 Der Kameraaufbau Jeder Roboter besitzt ein omnidirektionales Kamerasystem welches einen 360 Rundumblick erm glicht Dieser wird realisiert indem die Kamera nicht direkt auf die Umgebung ausgerichtet ist sondern auf einen Spiegel in dem sich wegen seiner speziellen Form die gesamte Umgebung abbildet F r genauere Informationen hinsichtlich der Funktionsweise und der Abbildung von Bildpunkten auf Weltpunkte siehe Abschnitt B 1 Bei der in diesem System verwendeten Kamera handelt es sich um eine Firewire Kamera der Fa Sony Modell DFW V500 11 mit 1 3 CCD Chip die bei einer Aufl sung von 640 480 Bildpunkten eine maximale Bildrate von 30 fps liefert Diese Kamera ist um den angef hrten 360 Rundum blick zu gew hrleisten senkrecht nach oben auf einen ca 5cm dar ber befestigten hyperbolischen Glasspiegel der Firma Neovision gerichtet Dieser Spiegel bzw diese Spiegel Kamera Kombination erm glicht eine Sichtweite von ca 5m rund um den Roboter Das Problem das sich bei der Entwicklung bzw Konstr
87. ge der Segmentierung an aus e Image schaltet die Anzeige des Bildes an oder aus e POA de aktiviert die Anzeige der gefundenen Objekte als Text e Particles de aktiviert die Darstellung der Partikel und Geometrieeinstellungen e Segment ber die Segment Checkboxen wird die Anzeige der jeweiligen Farbsegmentierung f r das Kamerabild ein bzw ausgeschaltet 77 A 2 TRIBOTS ANWENDUNG ANHANG A BEDIENUNGSANLEITUNG e Blau Maximieren Im Kamerabild kann eine blaue nichtsegmentierte Fl che mit der Maus eingerahmt werden Dr ckt man dann den Blau Maximieren Knopf wird die dort segmen tierte Farbe automatisch f r die Blau Maximierung verwendet Wird also nur ein Teil des blauen Tors erkannt kann dieser eingerahmt und der Knopf genutzt werden um automatisch die Blauerkennung zu verbessern e Blau Minimieren Im Kamerabild kann eine irrt mlich als blau segmentierte Fl che einge rahmt werden Dr ckt man dann den Blau Minimieren Knopf wird der erfasste Farbwert f r die Blauerkennung reduziert bzw ausgeschlossen e Gelb Maximieren Funktion analog zu Blau Maximieren e Gelb Minimieren Funktion analog zu Blau Minimieren Offen ist immer noch die Frage wie das Kamerabild genau segmentiert wird deshalb folgt nun eine Anleitung f r die Kalibrierung mit den vorhandenen Schiebereglern Farbeinstellungen Die Farben sollten der Reihe nach kalibriert und nach jeder korrekten Ein stellung ber den Save Knopf gespeichert werden Zu
88. gkeit Selbstlokalisation Pfadplanung und Fahrverhalten eine Optimierung zu erzielen Zu Beginn wurden uns zur Verf gung gestellt ein Fahrwerk das man ber einen Motorcontrol ler ansteuern konnte und eine Kamera die man ebenfalls mittels einer einsatzf higen Schnittstelle nutzen konnte Diese beiden Grundkomponenten sollten effektiv eingesetzt werden Dazu war es entscheidend sich mit der Ansteuerung der Motoren und dem daf r verwendeten Protokoll aus einanderzusetzen sowie mit der Elektronik des Motorcontrollers ber die ein Ballschu ausgel st werden kann Die Kamera wird als der zentrale Sensor angesehen und zur Erkennung von Objekten eingesetzt Die Bildverarbeitung muss dabei robust und schnell arbeiten weil sich die Umgebung in der die Fu ballroboter agieren sehr schnell ndert Eine zuverl ssige Bildverarbeitung ist notwendig um die Sensorinformationen zur Selbstlokalisation und damit zur Erstellung und Aufrechterhaltung eines Weltbildes verwenden zu k nnen Welche Aktion zu einem Zeitpunkt gew hlt wird h ngt von einem aktuellen Weltbild ab Wie diese Entscheidung aber getroffen wird geh rte ebenso zu den zu l senden Aufgaben der Projektgruppe Neben Einschr nkungen die weiter unten erl utert werden mussten bei der Konstruktion noch weitere Aspekte ber cksichtigt werden Dazu z hlen beispiels weise das Gewicht und die Ausma e des zur Verf gung gestellten Fahrwerks da man dieses weiter nutzen wollte 1 2 Robocu
89. gt nun eine ausf hrliche Erl uterung beider Anwendungen die einen berblick ber die Funktionen und Konfigurationsm glichkeiten gibt Es wird dringend empfohlen die komplette An leitung vor dem ersten Einsatz der Roboter zu lesen und sich genau an die hier beschriebenen Vorge hensweisen zu halten Nur dann ist gew hrleistet dass sich die Roboter fehlerfrei und wie gew nscht auf dem Spielfeld bewegen A 2 Tribots Anwendung Die Tribots Anwendung besteht aus folgenden Komponenten e Hauptfenster e Bildverarbeitungsfenster e Selbstlokalisationsfenster e Pathfinder Fenster e Odometrie Selbstlokalisationsfenster A 2 1 Hauptfenster Das Hauptfenster der Tribots Anwendung ist in vier Bereiche unterteilt Status Active Com ponents GUI Men und Select Parameter Abbildung A 1 zeigt das Hauptfenster das der Anwender nach dem Tribots Programmstart erh lt Im Status Bereich werden die grundlegenden Einstellungen bez glich der Strategie und der Feld aufteilung vorgenommen ber Playertype k nnen dort die unterschiedlichen Rollen f r den Roboter ausgew hlt werden zwei Angriffsstrategien drei Verteidigungsstrategien und verschiedene Torwart typen Eine kurze Erl uterung der einzelnen Spielertypen ist in der Kurzreferenz unter A 5 1 zu 74 A 2 TRIBOTS ANWENDUNG ANHANG A BEDIENUNGSANLEITUNG finden Es sollten maximal zwei Angreifer und maximal drei Verteidiger auf dem Feld stehen da sich bei mehrfacher Zuweisung von Rolle
90. h einen Firewire Repeater mit eingeschleifter Stromversorgung und die An steuerung der Schusseinheit Einige der Komponentenverbindungen weichen bei den verschiedenen Motorcontrollern ab und werden nachfolgend gesondert dargestellt zuerst jedoch arbeiten wir die Gemeinsamkeiten heraus Die Firewire Kamera DFW V500 von Sony 11 wird normalerweise mittels Firewirebus durch den Host mit Strom versorgt Nach dem IEEE1394 Standard wird bei mobilen Endger ten davon abgesehen da die Akku Laufzeit ebendieser stark darunter leiden w rde Der ben tigte Strom muss somit aus einer externen Quelle in die Kamera gespeist werden allerdings ist dieses kameraseitig eigentlich nicht vorgesehen es existiert z B keine Buchse f r eine externe Stromversorgung Unsere L sung liegt im Einsatz eines Firewire Repeaters ber den die Stromversorgung der Kamera l uft Der Repeater wird einerseits durch ein 4 Pol 6 Pol Kabel mit dem mobilen Rechner verbunden und auf der anderen Seite durch einen 6 Pol 6 Pol Kabel mit der Kamera Als externe Stromquelle wird der 12 V Akkupack mit in den Repeater eingeschleift die Kabel dorthin sind in den Abbildungen B 2 und B 4 angedeutet Die Kommunikation der Roboter mit dem Hostrechner vgl Abschnitt 3 5 l uft ber eine WLAN Verbindung ab ein WLAN USB Adapter bernimmt diese Aufgabe Die Stromversorgung des Ad apters erfolgt ber das USB Kabel seine bertragungsrate entspricht den bis dato blichen 11 MBit pro Sek
91. hied sich deshalb zugunsten der omni direktionalen L sung Der weitere Aufbau der Roboterhardware wurde f r diese L sung konzipiert 2 1 1 bersicht ber den Aufbau des Roboters Abbildung 2 1 Roboteraufbau In der Abbildung erkennbar sind die drei Module Fahrwerk 1 Kontroll Steuerebene 2 und Kameraaufbau 3 10 2 1 BERBLICK KAPITEL 2 HARDWARE Bei dem generellen Aufbau der Roboter lassen sich grob drei Module unterscheiden vgl Abbil dung 2 1 1 das Fahrwerk 2 die Kontroll und Steuerebene 3 der Kameraaufbau mit dazugeh rigem Spiegel f r die omnidirektionale Sicht Die einzelnen Module wurden so konstruiert dass sie mit vertretbarem Aufwand voneinander getrennt werden k nnen Beispielsweise m ssen neben einigen Kabeln lediglich sechs Verschrau bungen gel st werden wenn das Fahrwerk vom Rest des Roboteraufbaus getrennt werden soll Dies ist vorteilhaft wenn beispielsweise Reparaturen durchgef hrt werden m ssen oder Modifikationen an bestimmten Roboterkomponenten vorgenommen werden Ferner in Abbildung 2 1 leider nicht erkennbar besitzt jeder Roboter eine Schusseinheit mit der ein vor dem Roboter befindlicher Ball geschossen werden kann 2 1 2 Das Fahrwerk Bei dem verwendeten Fahrwerk handelt es sich um ein sogenanntes omnidirektionales Fahrwerk Dieses bedeutet dass der Roboter ohne sich zu drehen bspw in jede beliebige Richtung fahren kann Das Fahrwerk wurde der Projektgruppe bereits
92. hr gro mittel mehr als 10m 2 Poles gro sehr klein ca 8m 4 Hindernisse gro sehr klein ca 5 6m 8 und mehr Tabelle 3 3 Charakteristische Objekteigenschaften im Kamerabild Bei dieser Vorgehensweise kommt es durchaus vor dass ein Hindernis von mehreren Scanlinien erfasst wird Eine eindeutige Trennung von verschiedenen Hindernissen ist hierdurch nicht m glich doch ist diese bei nebeneinanderstehenden Robotern im Kamerabild auch f r das menschliche Auge nur schwer m glich Distanz und Winkelbestimmung Es ist klar dass die eingezeichneten Begrenzungskreise mit der Bildgeometrie nicht genau bereinstimmen Das wird durch die vielen Parameter des Spiegel und der Kamerahalterung beeinflusst Sind diese beiden Elemente perfekt aufeinander ausgerichtet und diese Kombination wiederum parallel zur Feldoberfl che so werden Winkel zu Objekten korrekt abgebildet Senkrechte Kanten bilden im omnidirektionalen Bild radiale Linien und Kreise um den Roboter ergeben auch wieder Kreise im Bild Diese Eigenschaft bedeutet dass gleiche Entfernungen in jeder Richtung auf die gleiche Entfernung von der Bildmitte abgebildet werden Da dies unter den gegeben technischen Voraussetzungen nur bedingt einstellbar ist ist es mitunter schwierig Pixeldistanzen direkt auf reale Distanz umzurechnen Winkel dagegen werden einigermassen wenn auch nicht v llig gleichm ig abgebildet vgl Abschnitt 3 2 3 3 2 3 Distanzfunktion Durch di
93. hrer Farbkodierung und ihrer definierten Positionen am leichtes ten durch eine Kamera zu erkennen Als Aktionssensor zur lokalen Lokalisation dient die Odometrie information welche von der Roboterschnittstelle bereitgestellt wird Aufgrund der Charakteristik der Sensoren erzeugt die Kamera Daten mit hohem Rauschanteil die ber die Zeit gleichbleibend genau sind Der Aktionssensor also die Odometrie erzeugt sehr gering verrauschte Daten die allerdings nur ber kurze Zeit genau sind und deren Fehler sich schnell akkumulieren Verwendete Sensorinformationen Zur Selbstlokalisation werden von der Bildverarbeitung fol gende Sensorinformationen bereitgestellt e 2 Tore Die Winkel zu den Mittelpunkten der Tore 4 Torpfosten Der Rechte und linke Torpfosten des Tors 4 Torpfosten Fu punkte der Fu punkt eines Torpfosten e 4 Eckfahnen Die Sensorinformationen sind nicht immer vollst ndig da einige Landmarken aufgrund des Rauschens oder weil sie von Hindernissen verdeckt werden nicht stabil erkannt werden k nnen Als Haupteingabedaten f r den Selbstlokalisationsalgorithmus erwiesen sich die Torpfosten als besonders stabil und zuverl ssig Die Winkel zu den Kanten der Tore sind fast von jeder Position des Feldes aus oft auch ber Hindernisse hinweg und innerhalb des Tors sichtbar Generell werden beim gew hlten Kameraaufbau die Winkel zu Objekten recht genau auch ber gr ere Distanzen hinweg wiedergegeben Distanzen sind im Bereich von
94. hten k nnte Nicht zuletzt kann noch einiges im Bereich der Robustheit der Hardware insbesondere in Hinblick auf einen stabileren Kameraaufbau und einen zuverl ssigeren Motorcontroller getan werden Weitere Erweiterungen im Bereich der Hardware sind denkbar Beispielsweise k nnten taktile Senso ren eingebracht werden mit denen Kollisionen zuverl ssiger erkannt und ein gegenseitiges Festfahren der Roboter vermieden werden k nnte Aus den Erfahrungen die das Team bei den Weltmeisterschaften gesammelt hat l sst sich insge samt sagen dass mehr Testspiele unter realen Bedingungen abgehalten werden m ssen um wirklich erfolgreich zu sein Da das Team seine St rke auf den Wettbewerben zeigen konnte hat es einige Einladungen von anderen Teams zu Testspielen erhalten 73 Anhang A Bedienungsanleitung A 1 Vorwort F r die Steuerung des Tribots Teams sind zwei Anwendungen von Bedeutung deren Bedienung in diesem Kapitel beschrieben wird Die eigentliche Tribotsanwendung l uft auf jedem einzelnen Roboter und dient der Ansteuerung TribotsControl ist das Kommunikationsmodul welches ausgelagert auf einem externen Rechner ge startet wird Die Entwicklung beider Anwendungen stand neben der erforderlichen Funktionalit t unter dem Gesichtspunkt von Softwareergonomit t und hoher Benutzerfreundlichkeit So entstand im Verlauf der Projektgruppe ein Endprodukt welches sich auszeichnet durch hohe Funktionalit t und einfache Bedienung Es fol
95. i Felder KickOff N A Role N A und Target N A stellen den aktuellen Status des jeweiligen Roboters dar Dazu geh rt ob er im Ansto Modus ist welche Rolle er innerhalb des Teams zur Zeit spielt und welche Farbe seine Zielfarbe also die Farbe seiner Gegner und somit auch des Tors auf das er spielen soll ist Unter dieser Anzeige kann der Anwender das Verhalten des Roboters umstellen Hier stehen ihm verschiedene Rollen zur Verf gung die der Roboter innerhalb des Teams einnehmen kann Goalie Attack Defender Auch die Target Color kann hier eingestellt bzw ge ndert werden Das Pulldownmenue mit den Werten 1 3 bietet dem Anwender die M glichkeit die KickOff Pre set umzustellen Je nach Wert f hrt der Spieler den eigenen Ansto auf verschiedene Art und Weise aus Der Wert 1 bedeutet zum Beispiel dass der Roboter der den Ansto durchf hren mit dem Ball direkt zum Angriff bergehen soll wogegen 2 und 3 dem Roboter sagen dass er den Ball vorher noch einem Mitspieler zupassen muss Die so ge nderte Konfiguration muss mit dem Knopf Init Player zum Roboter geschickt werden so dass dieser die Einstellungen bernehmen kann Mit den Kn pfen Start und Stop kann der jeweilige 83 A 3 TRIBOTSCONTROL ANWENDUNG ANHANG A BEDIENUNGSANLEITUNG Roboter gestartet bzw gestoppt werden A 3 3 Kommunikation mit dem Team rise Aneen ben Mm n Ama Paas m pirog an 09 ul Abbildung A 9 Team Panel von TCPE Im untere
96. ich 2 ergattert hat um dann im Bereich 3 eine starke Drehung zur linken Torh lfte zu vollf hren falls der gegnerische Torwart auf der rechten Torh lfte steht Die Entscheidung wann solche oder hnliche Man ver gefahren werden h ngt also davon ab in welchem Bereich sich der Roboter mit Ball gerade befindet bzw in welchem Bereich er Ballbesitz erlangt hat Kein Ballbesitz Ist der Roboter nicht im Ballbesitz bleiben die Verteidiger auf ihrer entsprechen den H lfte des Spielfelds Rechts Au en Links Au en und verteidigen das Tor Sie versuchen den Ball nur abzufangen wenn er in ihren Aktionsbereich ger t Der St rmer hingegen versucht in jedem Fall in Ballbesitz zu kommen egal wo er oder der Ball sich auf dem Spielfeld befinden Hier finden f r alle Spielertypen die oben beschriebenen Routinen f r das Man vrieren ohne Ball Anwendung 3 4 3 Entscheidungsfindung f r den Torwart Die Anforderungen an einen Torwart in der Robocup Umgebung sind denen eines echten Torwarts sehr hnlich Er muss schnell reagieren Bewegungsbahnen der B lle gut einsch tzen und sicher bzw 47 3 4 STRATEGIE KAPITEL 3 SOFTWARE Abbildung 3 20 Einteilung des Spielfelds f r Angriffsman ver beim Spiel auf das gelbe Tor zuverl ssig sein Von zentraler Bedeutung sind demnach eine robuste Implementierung eine schnel le pr zise Ansteuerung und die F higkeit die Ballbewegung zu erkennen Letzteres ist besonders wichtig da jede Entscheidung
97. ichtet zu sein siehe Abbildung 3 14 und dennoch mit Hilfe des Anfahrtsvektors so um den Ball zu man vrieren dass er ihn von einer g nstigen Seite her anf hrt Geschwindigkeitskorrektur V llig unabh ngig von der Berechnung des Richtungsvektors des Fahrbefehls wird die entsprechende Geschwindigkeit f r den Fahrbefehl ermittelt Generell versucht der Algorithmus alle Man ver mit maximaler Geschwindigkeit zu fahren Befindet sich der Roboter jedoch im Einflussbereich von Hindernissen oder in der N he des Balls wird die Geschwindigkeit gedrosselt um Kollisionen zu vermeiden Dieser Drosselungsfaktor ist abh ngig von der Entfernung 42 3 4 STRATEGIE KAPITEL 3 SOFTWARE y Xx os RN ern SER ann nn en ee izle Abbildung 3 14 Anfahrtsvektorfeld des Balls Der Roboter wird um den Ball herum zur Anfahrts schneise gelenkt die in einer Linie mit der freien Position im Tor liegt W hrend dieses Man vers beh lt der Roboter die Ausrichtung zur freien Torposition per manent bei zum Hindernis und wird nach au en hin wie beim absto enden Vektorfeld ebenfalls schw cher Mithilfe der angewendeten reaktiven Vektorfeldmethode ist es nun also m glich auf dem Spielfeld jedes beliebige Man ver ohne Ball durchzuf hren Diese Methode ist in der Klasse CPathFinder implementiert Diese Klasse stellt einen Befehls satz zur Verf gung ber den s mtliche Ansteuerungsparameter des omnidirektionalen Fahrwerks auf ei
98. ichung ses fo iaa Ba 3 2 ableiten wobei der Faktor a zur Normalisierung der Wahrscheinlichkeiten dient Odometrie Bei der Aktualisierung durch Odometriedaten wird die Roboterbewegung durch die bedingte Wahrscheinlichkeit p l l 1 dargestellt also die Wahrscheinlichkeit dass der Robo ter von der Position l _ durch die Bewegung a _ an die Position l gelangt Diese Wahrscheinlichkeit modelliert die Messungenauigkeiten der Odometrie hierzu z hlt z B der Schlupf der R der Je ge nauer die Odometrie bzw je besser man sich auf die Odometriedaten verlassen kann desto geringer w hlt man die Varianz der Gau verteilung Die Aktualisierung geschieht mit der Gleichung EOS BETEN 3 3 Validierung Bei der Validierung werden die Partikelwahrscheinlichkeiten durch die Sensordaten neu gewichtet Bel 4 ap st ls 3 4 Es wird die Wahrscheinlichkeit berechnet dass f r einen Partikel der Verteilung eine Sensor messung m glich ist Dabei sind beliebige Sensordaten kombinierbar z B die Winkel unter denen Landmarken gesehen werden und Distanzen zu Landmarken Dieses zweistufige Verfahren kann das globale Lokalisierungsproblem l sen eine Vorgabe der Startposition ist berfl ssig Das Kidnapped Robot Problem wird von diesem Verfahren gel st da eine Validierung der Position zu einer sinkenden Aufenthaltswahrscheinlichkeit f hrt die dadurch zu einer Gleichverteilung konvergiert Sampling Importance Resampl
99. idiert sehr h ufig mit Hindernissen m gliche Ursache Hindernisseinstellung fehlerhaft L sung Die Hindernisseinstellung im Bildverarbeitungsfenster h her stellen m gliche Ursache Banderolen werden als Ball erkannt L sung Wie oben beschrieben die Rotsegmentierung justieren e Problem Roboter schie t ein Tor nach dem anderen m gliche Ursache Alles perfekt eingestellt L sung Sekt kaltstellen 88 Anhang B Hardware In diesem Kapitel finden sich detaillierte Informationen zur Hardware wieder um einen tiefergehenden Eindruck des Zusammenwirkens der in Kapitel 2 vorgestellten Komponenten bieten B 1 Projektion eines Weltpunktes auf einen Bildpunkt Minimun curve Modmuncurve _ R en Omnidirectional imoge eo Focal point Yp Abbildung B 1 Projektion eines Weltpunktes auf einen Bildpunkt Um ein perspektivisches Bild mit Hilfe eines omnidirektionalen Kamerasystems zu erstellen muss eine Beziehung zwischen einem Weltpunkt und einem aufgenommenen Bildpunkt der Kamera erstellt werden So wird der Anwender in die Lage versetzt ein Panoramabild in ein perspektivisches Bild zu transformieren F r dieses Problemstellung kann man die klassischen Bildverarbeitungsmethoden anwenden Der parabolische Spiegel stellt die p yp Ebene dar bei x y Ebene handelt es sich um das aufzuneh mende Bild Durch trigonometrische Gleichungen rechtwinkliger Dreiecke kann man eine Beziehung zwischen Weltpunkt p und Bildpunkt p
100. idung der Plexiglasr hre die Verkleidung dient dabei der Mini mierung von Lichtreflexen in der Plexiglasr hre Erkennbar ist au erdem die Be festigung der Tr gerplatte mittels Metallwinkel Abbildung 2 6 Befestigung des Kameramoduls Zu erkennen ist die Verbindung des Kameramoduls mit der Steuer und Kontrollmodul Ferner erkennt man ebenfalls noch einmal die Befestigung des Spiegels und die unter diesem montierte Kamera Bei der Konzeption und Entwicklung des Kameramoduls wurde wiederum darauf geachtet dass sich das komplette Modul mit nicht zu gro em Aufwand vom Rest des Roboter abmontieren l sst Dieses wurde realisiert indem die Tr gerplatte lediglich mit vier Verschraubungen mit dem Roboter aufbau verbunden ist Ferner erm glicht diese Art der Verschraubung eine Justierung des kompletten Kameramoduls optimalerweise muss die Kamera Spiegel Kombination nat rlich exakt senkrecht an geordnet sein Insgesamt erwies sich dieser Kamera Spiegel Aufbau nicht als optimal beispielsweise schwingt oder wackelt dieser Aufbau recht stark wenn der Roboter f hrt aber f r die an ihn gestellten Anfor derungen erwies er sich als ausreichend 2 2 Steuerrechner Auf dem Steuerrechner l uft die eigentliche Applikation welche neben der Ansteuerung des Control ler Boards z B die Objekterkennung oder die Pfadplanung durchf hrt Als Steuerrechner kann jeder Standard PC oder mobile Rechner mit einer seriellen Schnittstelle und einem Firewire
101. idungen anhand von sichtbaren Vorg ngen treffen soll Der Sensor Kamera liefert eine enorme Datenmenge Zum Einsatz kam die Firewire Kamera DFW V500 von Sony 11 welche 30 Bilder pro Sekunde im YUV Format aufnehmen kann Ein Pixel dieses Bildes besteht aus 2 Byte so dass bei einer Aufl sung von 640 480 Pixeln und 30 Bildern pro Sekunde 18432642 Bytes s oder ca 17 5 MB pro Sekunde verarbeitet werden m ssen Diese Daten enthalten gro e Mengen von Informationen wie man in Abbildung 3 4 erkennen kann Im Vorverarbeitungsschritt werden die Bildinformationen mittels der GNU Bibliotheken lib dc1394 und libraw1394 von der Kamera geholt Die Bibliotheken wurden so ge ndert dass nicht mehr auf das zu holende Bild gewartet wird sondern in regelm igen Abst nden nachgefragt wird ob ein Bild vorhanden ist und dieses dann abgeholt wird Diese Modifikation erm glicht den Neustart der Kamera falls sie durch statische Aufladung oder eine kurze Unterbrechung der Kabelverbindung abst rzen sollte So ist das Programm in der Lage den Grabbing Prozess selbst neu anzusto en wof r bei der Standardbibliothek noch ein Eingriff notwendig war Die von der Kamera ausgelesenen Daten sind f r das menschliche Auge nicht sichtbar verrauscht scheinbar gleichfarbige Fl chen bestehen bei genauer Betrachtung aus unterschiedlichen Schattierun gen Um Algorithmen zu entwickeln die aus m glichst vielen Bildern interessante und verl ssliche Informationen gewinnen ist
102. iel angehalten werden Solange TribotsControl sich im Modus GameRuns befindet wacht die Software st ndig ber auftretende Roboterausf lle und Robotereinwechselungen um darauf dyna misch mit ad quaten Rollenwechseln zu reagieren Ein gestoppter Roboter sei es aus strategischen Gr nden oder aufgrund einer Schiedsrichteranweisung Regelversto wird sofort von TribotsControl als inaktiver Spieler markiert F r die brigen aktiven Spieler wird eine optimale Aufstellung und Rollenverteilung errechnet und per WLAN an die Roboter geschickt Im Gegensatz hierzu werden die Rollenwechsel nicht vorgenommen wenn das Spiel nicht l uft bzw unterbrochen wurde also Ga meRuns false ist Zudem sei angemerkt dass in diesem Modus die Spieler auch als aktive Roboter im TribotsControl verwaltet werden wenn sie gestoppt sind Dies hat den Hintergrund dass die Roboter schon vor dem unmittelbaren Spielbeginn mit der gew nschten Aufstellung ins Spiel gehen und nicht als Einwechselspieler gehandhabt werden m ssen 52 3 6 ROBOTERMODUL KAPITEL 3 SOFTWARE 3 6 Robotermodul 3 6 1 berblick Dieses Modul kapselt alle Hardware nahen Funktionen und stellt dem Anwender nach au en hin eine einfache Schnittstelle zur Ansteuerung von Motorcontrollern bereit Bei dem Entwurf dieses Moduls verfolgte man ein modulares Konzept welches die gesamte Ansteuerung in drei Bereiche siehe Abbildung 3 24 untergliederte e das Kommunikationsmodul ist verantwortlich
103. iert auf mA ber den Controller selbst ist es bereits m glich die Motoren anzusteuern bzw zu regeln jedoch ist ihm die Anordnung der Motoren nicht bekannt Das Wrapper Modul stellt Funktionen zur ein fachen Ansteuerung des omnidirektionalen Antriebs bereit Zur Umsetzung greifen wir auf die in 5 beschriebenen Kinematikgleichungen zur ck Bereitgestellte Funktionen sind etwa 87 3 6 ROBOTERMODUL KAPITEL 3 SOFTWARE e robot_set_wheels_V float vMotirps float vMot2rps float vMot3rps wandelt die ber gebenen Geschwindigkeiten in die Controller spezifische Gr en um und ruft anschlie end den entsprechenden Befehl des Controllers zum Setzen der Geschwindigkeiten auf e setXYPVelocity double _dXPosMP double _dYPosMP double _dPhiMP setzt die Radge schwindigkeiten unter Verwendung der Kinematikgleichungen auf die gew nschten Werte in rad s e robot_comp_thetap_of_mvel berechnet die gew nschte Radgeschwindigkeit um den Roboter in eine Richtung relativ zum Roboterkoordinatensystem fahren zu lassen 3 6 2 Odometrie Um sich bei der Navigation zurechtzufinden muss ein Roboter h ufig Messungen vornehmen z B wie weit er sich von seinem letzten Standpunkt aus fortbewegt und gedreht hat oder wie seine Radgeschwindigkeiten sind Als Sensoren f r diese Aufgabe wurden Rad Encoder eingesetzt von denen es zwei verschiedene Typen gibt e absolute Messwertgeber eine bestimmte Wellenposition wird als Signal in Form eines Codes zur
104. iert werden Die Stromversorgung 92 B 3 ANSTEUERUNG SCHUSSEINHEIT ANHANG B HARDWARE Y DC opplung 12V DC optische TMC 10 Port 1 5 Entk e Akkupack 7 l TIMC 200 24V DC 1 Pono Portl Port2 Abbildung B 5 Stromkabel zwischen den Roboterkomponenten TMC f r einen Motor l uft ber zwei verdrillte Kupferdr hte statt der sechs Adern beim Kameleonboard die ber Schraubklemmen befestigt sind Die Datenleitungen aller drei Encoder werden in einem 14 poligen Flachbandkabel zusammengefasst aber es muss zus tzlicher Aufwand betrieben werden ohmsche Widerst nde sind zwischen einige der vier Datenleitungen pro Encoder einzul ten siehe 6 8 B 3 Ansteuerung Schusseinheit Die Schusseinheit des Roboters wie sie in Abschnitt 2 4 beschrieben ist ben tigt einen Ausl ser genauer gesagt das eingesetzte elektrische Ventil vgl Abbildung 2 12 einen Impuls In unserer L sung ist der Motorcontroller f r diesen Impuls verantwortlich die spezifischen Ans tze sollen in den n chsten beiden Unterabschnitten n her erl utert werden B 3 1 Kameleon Die Ansteuerung der Schusseinheit erfolgt auf recht einfache Weise ein 5 V Reed Relais Schlie er mit Schutzdiode dessen Eingangsseite zwischen 5 V und einem Digital Power Out Ausgang geh ngt wird Pin 2 bzw Pin25 in unserer Implementierung Die Ausga
105. ig und Gr nRot und Gr nBlau hoch eingestellt sein Durch Heraufsetzen von Gr nGr n und Herabsetzen von Gr nRot und Gr nBlau l sst sich die Erkennung einschr nken Schwarz Kalibrierung F r die Schwarz Kalibrierung ist lediglich ein Regler notwendig der angibt wie gro die RGB Werte eines Pixels h chstens sein d rfen damit der Pixel als schwarz erkannt wird Am Anfang sollte der Regler hoch eingestellt sein durch Herabsetzen kann dann die Erkennung einge schr nkt werden A 2 3 Selbstlokalisationsfenster Abbildung A 4 zeigt das Selbstlokalisationsfenster welches man ber das Hauptfenster wie beschrie ben aufrufen kann In ihm ist eine bersicht des Spielfeldes zu sehen auf dem die Partikelverteilung sowie die wahrscheinliche Position des Roboters Partikelanh ufung und rotes Fadenkreuz einge zeichnet ist Sollten mehrere m gliche Positionen gefunden werden Selbstlokalisation springt zwi schen Positionen hin und her bzw schwankt ist die Selbstlokalisation nicht eindeutig m glich was unterschiedliche Ursachen haben kann z B fehlerhafte Erkennung der Tore der Eckfahnen usw X SelfLocalisation alm gg Quality 0 1 GBP 1 YBP 1 V use BG Feat direct Angles 7 use Poles V use YO Feat IV Head nv Angles I use AnalyseJumps use Dist IV Tum Particles FE MV add EQ dist 7 calcw Medangle Padis Abbildung A 4 Selbstlokalisationsfenster der Tribots Anwendung 79 A 2 TRIBOTS ANWENDUNG ANHANG A
106. igen dass es verschiedene Spielertypen wie Angreifer und Verteidiger gibt f r die unterschiedliche Entscheidungen getroffen werden m ssen Die f r dieses Projekt aufgestellte Mannschaft verfolgt eine eher defensive Taktik Die Standard Aufstellung siehe Abb 3 18 f r ein Spiel besteht aus einem St rmer zwei Verteidigern und einem Torwart Der Angreifer ATTACK1 agiert auf dem gesamten Feld Der Rechts Au en Verteidiger DEFENDI deckt den rechten der Links Au en Verteidiger DEFEND2 den linken Bereich der eigenen Spielfeldh lfte ab Beim Ausfall bestimmter Spielertypen werden automatisch abweichende Aufstellungen eingenommen siehe Abschnitt 3 5 Alle im Folgenden beschriebenen Routinen bezie hen sich ausschlie lich auf die Feldspieler Da sich die Entscheidungsfindung dieser Spielertypen von der des Torwarts grundlegend unterscheidet werden die Algorithmen des Torwarts in Unterabschnitt 3 4 3 gesondert behandelt S 4 a Abbildung 3 18 Standard Aufstellung des Teams Grundlage f r die Entscheidungsfindung bildet ein bin rer Entscheidungsbaum siehe Abb 3 19 Zun chst werden f r jeden Spielertypen vier Standard Situationen unterschieden 1 Ansto f r die gegnerische Mannschaft 2 Ansto f r die eigene Mannschaft 3 Freisto f r die gegnerische Mannschaft 46 3 4 STRATEGIE KAPITEL 3 SOFTWARE 4 Elfmeter f r die eigene Mannschaft Standard Situationen Basis Taktik Roboter hat keinen Ball
107. ikroschalter mit Federb gel an die Innenseiten der Ballf hrung Sie wurden so ausgerichtet dass die Schusseinheit bei einem Ballabstand von ca 5 cm zum Roboter ausl ste Das Auslesen der Sensoren erfolgte ber den Motorcontroller K376SBC in einer Zykluszeit von 10 ms Ein irrt mliches Ausl sen z B wenn ein gegnerischer Roboter gegen die Mikroschalter f hrt verhindert eine zus tzliche Sperre Per Software setzbar basierte sie auf Informationen bzgl der Ballposition aus dem Weltbild e Ultraschall Durch Testspiele und die German Open 2003 zeigten sich schnell Schw chen im Einsatz der Mikroschalter Bereits nach einigen Kollisionen l sten die Mikroschalter durch ver bogene Federb gel nicht mehr zuverl ssig aus Die ber hrungslose Messung mittels eines oder zweier Ultraschallsensoren die an der Front des Roboters schr g hinab blicken sollte Besse rung bringen In Tests mit einem separaten Mikrocontroller Board C Controll 11 ergaben sich Messungenauigkeiten von maximal einem Zentimeter Dieses Ergebnis lie sich nicht auf den bis dahin verwendeten Motorcontroller K376SBC bertragen er verf gt ber die ben tigte I C Schnittstelle deren Implementierung und Funktionalit t war aber nicht ausgereift e Kamerabild Das Kamerabild an sich bietet sehr viele Informationen und zusammen mit der Spiegelgleichung sind Entfernungen im Nahbereich gut absch tzbar Wie schon bei den Mikro schaltern betrachtet man die Entfernung des Balls
108. ild der Kamera Die Bildverarbeitung erh lt als Eingabe ein Bild der Kamera bergeben und verarbeitet dieses indem alle interessanten Regionen im Bild herausgefiltert werden Diese Regionen entsprechen im physischen Umfeld Objekten wie Tore Ball Gegner usw Gekennzeichnet sind sie typischer weise durch eine fest vorgegebene Farbgebung 1 Zur Ausgabe aus dem Bildverarbeitungsmodul geh ren neben den Winkeln zu den erkannten Objekten auch die Entfernungen die sowohl in Pixeln im Bild als auch in L ngeneinheiten cm mm gegeben sein k nnen Der Roboter ist dabei Bezugspunkt aller Berechnungen hinsichtlich Entfernungsangaben und Winkel Ausgabe interessante Regionen im Bild mit robozentrischen Winkeln und Entfernungen Weltmodell siehe Abschnitt 3 3 Eingabe Regionen der Bildverarbeitung Sensorinformationen ber die physische Bewegung des Roboters Das Weltmodell ist verantwortlich f r die Erstellung eines Modells einer Karte der Umwelt Aus der Kenntnis der Position und Entfernung zu markanten und festen Punkten im Spielfeld wie Toren oder Eckfahnen Eingabedaten wird die Position des Roboters auf dem Spielfeld eindeutig bestimmt Weiterhin sind im Modell neben der eigenen Position auch die Positionen von Gegnern dem Ball usw enthalten Dabei werden die interessanten Regionen von relativen auf absolute Positionen und Winkel umgerechnet Ausgabe Regionen versehen mit absoluten Winkeln und Positionen Strategiemodul siehe Abschnitt
109. in den Kernel Space und der Signal FiFo bertr gt Fehler bzw R ckmeldungen aus dem Kernel Space in den User Space F r den eigentlichen Datenaustausch zwischen User Space und Kernel Space werden zwei weitere FiFos eingesetzt RTLinux 8 rtLserial_mod a v E 3 8 n_secial_app d 7 E 2 Abbildung 3 27 Kommunikationsschema von RTLinux Der Echtzeitteil der Anwendung im Ker nelspace und der unkritische Teil im Userspace kommunizieren ber vier FiFos wie in der Abbildung dargestellt Zwei der FiFo entsprechen Steuerleitungen und die beiden anderen Datenleitungen Realisiert wurde unser Kommunikationsmodul in zwei Teilen wie bei RTLinux gefordert vel Abbildung 3 27 rt_serial mod c enth lt den echtzeitkritischen Teil die Kommunikation auf der Schnittstelle und rt_serial_app c bernimmt die restlichen Aufgaben wie Fehlererkennung und Bereitstellung weiterer Funktionen Einige der implementierten Funktionen sind e rt_talk int com char send char reveice int recv_len int test ber diesen Aufruf erfolgt die Kommunikation mit der Hardware Die bergebenen Parameter spiegeln die serielle Schnittstelle den Sende und Empfangspuffer die L nge des Empfangspuffers und die anzuwendende Fehlererkennung wider Zur Zeit sind mehrere Fehlererkennungsmechanismen integriert die Controller spezifisch greifen e block long delta_t und wait_for_deblock Ein Standard Linuxsystem hat eine zeitliche Aufl sung von
110. ine Farbe hin untersucht Die zu untersuchenden Pixel mit Abstand r und Winkel y vom Bildmittelpunkt werden dabei zuf llig gezogen Beim Ball ist der Suchraum der ringf rmige Bereich im Bild zwischen dem Roboterradius Rroboter und dem Spielfeldradius Reja Alle diesem Test gegen ber positiven Pixel werden in das Array PositiveBallPartikel einsortiert Im propagate_step Algorithmus werden aus den bereits gefundenen positiv markierten Ballpar tikeln die sich im Array PositiveBallPartikel befinden AnzahlBallPartikel Testkandidaten ausgew hlt Die Testkanditaten werden gleichverteilt aus dem Array PositiveBallPartikel gezo gen und um 20 Pixel in z und y Richtung verschoben Sind diese wiederum in der Farbklasse Ball enthalten so werden sie in das Array PositiveBallPartikel bernommen Wenn sich nach der Suche mindestens ein Partikel in dem Array befindet so gilt der Ball als gefunden Der Mittelwert der positiven Ballpartikel wird berechnet und anhand des Partikels mit dem kleinsten Abstand zur Bildmitte skaliert So ergibt sich eine recht genaue Absch tzung des Aufsatzpunkts des Balls Dieser Aufsatzpunkt wird daraufhin mit Hilfe der Distanzfunktion in eine reale Entfernung umgerechnet und in das PossibleObject Array zur Weiterverabeitung bernommen Dargestellt ist in beiden F llen der Ballalgorithmus 33 3 2 BILDVERARBEITUNG KAPITEL 3 SOFTWARE 1 for i 0 to 100 do 2 r rand RYorizonti RHorizont2 RHoriz
111. ing Aus den Partikeln werden nun N neue Partikel erzeugt Hierbei werden die Partikel mit h heren Wahrscheinlichkeit h ufiger ausgew hlt Diese entsprechen der Position des Roboters am besten und nur in diese interessanten Partikel wird weitere Rechenzeit investiert Implementierung des Algorithmus Der komplette Algorithmus ist in der Klasse CHohensyburg umgesetzt Die Anzahl der zur Repr sentierung der Verteilung n tigen Partikel ist so gew hlt dass die Anzahl gro genug f r eine stabile Verteilung ist und trotzdem noch klein genug um den Rechner nicht zu stark zu belasten in der Praxis haben sich ca 500 700 Partikel als sinnvoll erwiesen Sie belasten die Durchlaufzeit der Hauptschleife ungef hr mit 6 10 ms pro Durchlauf Um die Partikelposition m glichst schnell herauszufinden werden in der Selbstlokalisation Winkel eingesetzt die von der Ausrichtung unabh ngig sind z B die Winkel zwischen Landmarken Die tats chliche Ausrichtung des Roboters wird nach Herausfinden der Position direkt durch die Winkel der Landmarken im Bild bestimmt Hohensyburg In Anlehnung an die Kasinos in Monte Carlo wurde das lokal bekannte Kasino Hohensyburg bei Dortmund als Klassenname gew hlt 37 3 3 WELTMODELL KAPITEL 3 SOFTWARE gt ally o1 FT use BG Feat _ direct Angles _ use Poles use YG Feat Headlinv Angles use AnalyseJu use Dist Turn Particles useLines E add EQ dist _ Calcw Medangle
112. ist Die Dauer eines Hauptschleifendurchlaufs der Tribots Software liegt bei weit unter 100 ms Der Simulator liefert jedoch nur alle 300 ms neue Umgebungsdaten so dass feingesteuerte Bewegungen wie sie z B beim Fahren mit Ball notwendig sind einem zu gro en Fehler unterliegen und zu v llig falschen Man vern im Simulator f hren 62 Kapitel 4 Systemtests 4 1 Bildverarbeitung Distanzfunktionstests Um die korrekte Funktionsweise der Distanzkorrektur zu berpr fen wur den einige Benchmarks durchgef hrt In Abbildung 3 8 kann man die gemessene Entfernung eines Balls in 1 m Entfernung und in 2m Entfernung erkennen Nach der Korrektur ist der Abstand in jede Richtung gleich gro Zus tzlich wurde eine Anfahrt auf einen Ball mit konstanter Geschwindigkeit durchgef hrt siehe Abbildung 4 1 Der jetzt lineare Verlauf der Entfernung ist deutlich zu erkennen In der direkten Umgebung des Roboters lt 40 cm verschwindet der Ball hinter dem Objektiv Da der unterste Punkt des Balls zur Berechnung benutzt wurde tritt hier eine S ttigung der Distanz ein F r die Schussausl sung wird in diesem Bereich der oberste Punkt des Balls benutzt die Entfernung dieses Punktes ist im sehr nahen Bereich aussagekr ftiger 5000 anfahrt txt u 13 4500 7 4000 7 3500 7 3000 F 2500 m Distanz Meter 2000 7 1500 1000 7 500 7 0 l l l l l 0 50 100 150 200 250 300 Frames Abbildung 4 1 Anfahrt auf ei
113. it farbig markierte Objekte im 2 dimensionalen Raum in Echtzeit zu verfolgen In der ersten Phase haben wir diese Bibliothek noch genutzt es wurde aber festgestellt dass f r unsere Zwecke ein eigener Objekterkennungsalgorithmus mehr Performance raushohlen kann Die Bibliothek cvtk ist unter cvtk sourceforge net erh ltlich 3 7 2 Simulator Zum Entwickeln von Standard Man vern wie Torschuss Dribbling Ballanfahrt etc sind Tests in einer simulierten Umgebung von gro em Vorteil Auch vom allgemeinen Fahrverhalten bekommt man einen schnelleren Eindruck wenn man einfache Probel ufe nicht am Real System durchf hren muss Hierf r wurde ein Simulator ben tigt der die f r den Robocup typische Umgebung im Rech ner modelliert und au erdem eine m glichst einfache Einbindung unserer omnidirektionalen Platt form zulie In Frage kamen mehrere Systeme sowie eine komplette Neu Entwicklung eines solchen Software Simulators Aus Zeitgr nden und wegen der einfachen Anpassbarkeit verwendeten wir schlie lich den zusam men von der Freiburger und Stuttgarter Universit t entwickelten Robocup Simulator SimSrv Dieser Simulator siehe Abb 3 29 modelliert ein Fu ballfeld entsprechend den Anforderungen der Robocup Regeln Auf diesem Feld k nnen beliebige durch Plugins definierte Roboter Modelle herumfahren Ein physikalisches Modell sorgt f r die korrekten kinetischen Reaktionen bei Kontakten mit Gegnern oder dem Ball Aufgrund der M glichkeit
114. iten stammen Wir ver 25 3 1 BERBLICK KAPITEL 3 SOFTWARE muten jedoch dass hier das Betriebssystem wiederkehrend anderen Prozessen zuviel Rechenzeit zur Verf gung stellt so dass unser Programm nicht fr h genug die Kontrolle zur ckerh lt um nach Ablauf des des Schleifentimers einen neuen Zyklus einzuleiten Modul Dauer in ms Bildverarbeitung 27 und Weltmodell Strategie 2 Kommunikation 1 Robotermodul 17 stehend inkl Beschleunigungsmodul 20 fahrend GUI 3 inaktiv A 60 ms restl M odulzeiten 7 Tabelle 3 1 Durchlaufzeiten der einzelnen Softwaremodule Der gro e Vorteil der sequentiellen Programmablaufsteuerung gegen ber einer parallelen Abarbei tung der Module liegt darin dass der Aufwand der Synchronisierung von Threads und der zeitlichen Einordnung von Daten z B Objektdaten aus einem Bildverarbeitungsthreads schlicht entf llt Die Module arbeiten immer genau dann wenn neue Informationen f r sie vorliegen wodurch alle Re chenzeit dem gerade rechnenden Modul zur Verf gung steht Tabelle 3 1 zeigt die Zeit an die die Module im Mittel f r die Berechnungen ben tigen Gr ere Abweichungen k nnen unter anderem dann vorkommen wenn in der Bildverarbeitung bei der Ka librierung der Farbeinstellung ein Bild angezeigt werden muss In diesem Falle nimmt das Zeichnen der grafischen Oberfl che berm ig viel Zeit in Anspruch Dar ber hinaus laufen die Algor
115. ithmen stabil 1 while Programm l uft do 2 3 block A 60 ms Start des RT Linux Timer Weltmodell compute_actual_wmstate Aktuelles Bild der Kamera wird geholt und bear beitet Darauf werden Berechnungen im Weltmodell durchgef hrt Strategiemodul gt compute_decision Berechnungen der Strategie es wird eine Aktion und ein Ansteuerungsbefehl bestimmt Kommunikationmodul processMessages Kommunikation mit dem zentralen Kommunika tionsrechner Beschleunigungsmodul driveXYPVelocity Anpassung der Ansteuerung durch Beschleuni gungsmodell Abschicken des Befehls an den Roboter GUl gt processEvents 50 GUI erh lt 50ms Zeit f r alle grafischen Updates wait_for_deblock Falls Schleifen Zeit nicht berschritten wird hier auf den Ablauf des Timer gewartet 9 end while Algorithmus 1 Hauptschleife der Tribots Anwendung in Pseudocode 5Wie Algorithmus 1 zeigt ruft das Weltmodell das Holen und Verarbeiten eines Bildes in der Bildverarbeitung auf Die Messung erfolgt daher im Verbund 6Gemessen mit dem TMC Die unterschiedlichen Durchlaufzeiten ergeben sich weil durch die Bewegung mehr Information ber die zur ckgelegte Strecke bertragen werden m ssen 26 3 2 BILDVERARBEITUNG KAPITEL 3 SOFTWARE 3 2 Bildverarbeitung Die Bildverarbeitung ist bei einem Roboter eine der wichtigsten Grundf higkeiten wenn er sich mit Hilfe von visuellen Informationen orientieren und Entsche
116. ks blieb wurden fast alle neuen Features entweder in selbst erstellten Versuchsaufbauten oder Testspielen gegen die Roboter selbst Eine detaillierte Auflistung der Ergebnisse im Vergleich zu den anderen Teams http 1s1 www cs uni dortmund de merke robocup results ms_go2003_bscolor html Shttp www robocup2003 org 68 4 4 WETTBEWERBE KAPITEL 4 SYSTEMTESTS oder statische Gegner getestet Die Weltmeisterschaften fanden vom 5 bis 9 Juli 2003 statt Wieder eine neue Umgebung auf die man sich und die Roboter einstellen musste W hrend der ersten Spiele wurde klar dass es sich ausgezahlt hatte auf verschiedene Verbesserungen besonders zu achten Im ersten Spiel ging es gegen die bereits bekannten Mostly Harmless aus Graz Diese hatten sich seit den German Open ebenfalls weiterentwickelt hatten allerdings immer noch Probleme mit der Lokalisation und setzten daher auf eine sehr defensive Taktik Der neu implementierte St rmer konnte dieses Bollwerk jedoch vier mal berwinden so dass das Spiel am Ende 4 0 ausging Der n chste Gegner war genau wie wir ein Newcomer Die FU Fighters aus Berlin Das Team an sich hatte schon einige Erfahrung in der Robocup Umgebung gemacht die mitgebrachten Roboter waren jedoch fast neu Diese waren nach einem v llig anderen Prinzip konzipiert als andere sie wa ren wesentlich kleiner als alle anderen hatten aber trotzdem ein omnidirektionales Fahrwerk sowie Kamerasystem Durch ihre geringe Gr e
117. l sung des Pneumatikzylinders Aus diesem Grund ha ben wir Schusseinheit 3 verwendet die den Ball auf die h chste Durchschnittsgeschwindigkeit beschleunigt 4 4 Wettbewerbe 4 4 1 German Open 2003 Im Winter entschloss sich die Projektgruppe zur Teilnahme an den German Open in Paderborn Diese fanden vom 11 bis 13 April 2003 statt Die Entscheidung stellte den bis dahin aufgestellten Zeitplan auf den Kopf bis zu diesem Termin musste eine komplett funktionierende Robotermann schaft fertig sein Im Vorfeld wurde daher ein Projektplan erstellt in dem mehrere Deadlines angegeben waren zu jeder musste ein neues Merkmal implementiert oder eine neue Ausbaustufe fertiggestellt sein Die Erf llung der Kriterien wurde anhand von Benchmarks getestet die den Fortschritt gut dokumen tieren Die Veranstaltung selbst war ein Systemtest unter realen Bedingungen Bis dahin spielten die Roboter ausschlie lich alleine oder gegen statische Gegner M lltonnen das v llig neue Wettbe werbsszenario war ein erster echter Test f r s mtliche Hard und Softwarekomponenten Au erdem musste nat rlich die v llig andere Umgebung ber cksichtigt werden besonders die Kalibrierung der Roboter wuchs zu einer v llig neuen Herausforderung Ein Augenmerk lag auf der Strategie die sich zum ersten Mal gegen v llig andere Roboter auszeichnen konnte Schon zu Turnierbeginn bekamen die Teammitglieder durch die Anwesenheit anderer Teams viele Verbesserungsideen Di
118. le der Selbstlokalisation die auf den Odometriedaten basiert Abbildung A 6 zeigt einen Screenshot des Fensters Der Roboter wird in die Mitte des Spielfeldes gesetzt und ber den Knopf Or Click Here die Selbstlokalisation anschlie end initialisiert Auf der Spielfeld bersicht wird daraufhin die berechnete Position des Roboters eingezeichnet und kann w hrend der Fahrt berwacht werden Das Fenster enth lt zus tzlich alle Daten der Selbstlokalisation und die Ansteuerungsbefehle der Motoren unten links im Bild A 3 TribotsControl Anwendung A 3 1 Allgemeine Informationen Die Kommunikationszentrale des Teams Tribots Brainstormers bildet das Programm TCPE Tri botsControl Padua Edition Hier laufen w hrend des Spiels alle von den Robotern per WLAN iiber 81 A 3 TRIBOTSCONTROL ANWENDUNG ANHANG A BEDIENUNGSANLEITUNG X Odo SL Test 0 xj ODO_SL_TEST Rasterquadrat 500mm 500mm gt Push Joypad Button 1 to set Odo Pos to SL Pos lt or click here clear Path OdoRobo Pos 0 0 SLRobo Pos 0 0 OdoRobo Phi 0 SLRobo Phi 3 4 Amp real Amp supposed MotoriA Wheellv Motor2A Wheel2V Motor3A Wheel3W Abbildung A 6 Odometrie Selbstlokalisationsfenster der Tribots Anwendung tragenen Informationen zusammen und geben dem Anwender die M glichkeit die aktuelle Rolle des jeweiligen Roboters Goalie Defender oder Attacker und seine Zielfarbe hiermit ist die Farbe der Gegenspieler und deren
119. lle Schnittstelle oder einen CAN Bus Im oberen Preissegment finden sich aber ebenso Controller die ber eine drahtlose Verbindung wie Bluetooth mit dem Host kommunizieren k nnen e Mikrocontroller er ist das Kernst ck des Motorcontrollers durch seine Auswahl wird u a die Leistungsf higkeit bestimmt Verbunden mit der Kommunikationsschnittstelle nimmt er Befehle entgegen und wandelt diese z B in PWM Signale zur Motorsteuerung um oder liest einen A D Eingang aus e Leistungselektronik die eingesetzten Motoren k nnen nicht direkt vom Mikrocontroller ange steuert werden da dessen Ausgangsleistung einfach zu schwach ist Daher wird noch zus tzliche Elektronik zwischen Motor und Mikrocontroller eingef gt W hrend des Verlaufs der Projektgruppe kamen zwei verschiedene Controller zum Einsatz das Kameleon 376SBC stand seit Beginn der Projektgruppe zur Verf gung und war bereits w hrend einer Diplomarbeit 5 verwendet worden Nach den German Open 2003 stellte das Fraunhofer Institut f r autonome intelligente Systeme uns auf Nachfrage einen Prototypen ihres selbstentwickelten Motor controllers TMC200 zur Verf gung 2 3 1 Kameleon 376SBC Das Kameleon 376SBC siehe Abbildung 2 8 wurde von der Firma K Team hergestellt mittlerweile ist jedoch die Produktreihe eingestellt worden ein Nachfolger steht mit dem Korebot kurz vor der Markteinf hrung Den Kern des Boards bildet ein MC68376 Mikrocontroller mit einer Taktfrequenz von 20 MHz
120. m Beispiel des Setzens der Motorgeschwindigkeiten zu bleiben mit dem Original Protokoll ben tigte man drei separate Befehle inkl jeweils ein Verbindungsaufbau mit insgesamt sechs Parametern verglichen mit einem Befehl der nur vier Parameter bermittelt um alle Motoren anzusteuern Antwortzeit des Controllers beim Setzen der Motorgeschwindigkeiten Antwortzeit des Controllers beim Setzen der Motorgeschwindigkeiten 2 NT LPRSerCom 80 5 70 7 60 J 50 J 40 H 30 20 F 1 10 sl o i 1 1 L fi 1 L L l o i 1 1 L 1 1 i L 1 0 100 200 300 400 500 600 700 800 900 1000 0 100 200 300 400 500 600 700 800 900 1000 Iterationen Iterationen T T ginal Protokoll Antwortzeit in ms Antwortzeit in ms Abbildung 3 25 Zeit zum Setzen der Motorgeschwindigkeiten Kameleon In den Graphiken er kennt man die Befehlsdauer in ms f r das Setzen aller drei Motorgeschwindigkei ten 1000 Iterationen wurden jeweils f r das Original Protokoll SerCom links und das selbst entworfene Protokoll LPRSerCom rechts durchgefiihrt 14 sweeney cs umass edu 54 3 6 ROBOTERMODUL KAPITEL 3 SOFTWARE Im einem Testprogramm wurde jedem Motor 1000 mal eine Geschwindigkeit von 0 m s zugewie sen Gemessen wurde die Zeit fiir das Setzen aller drei Motorgeschwindigkeiten unter Verwendung der verschiedenen Protokolle Die durchschnittliche Zeit beim Original Protokoll lag bei ca 18 ms Ausrei er lagen im 50 bis 90 ms
121. n gebogen zu werden so dass sie sich nach weiteren 30 cm treffen vgl Abbildung 2 1 und 2 4 Dort sind diese dann miteinander verschraubt so dass die Konstruktion in sich sehr stabil ist Das pyramidenartige Zulaufen der Aluminiumstreben ergab sich aus der Verwendung eines omni direktionalen Kamerasystems diese Art der Konstruktion erm glicht es der Kamera an dem Aufbau vorbei zu sehen Somit werden von ihr auch Objekte erkannt die sich direkt am Roboter befinden Dieses w re beispielsweise bei einem kastenartigen Aufbau nicht ohne weiteres gew hrleistet gewesen Ferner ist in ca 8cm H he also eben noch dort wo die Streben vertikal laufen eine Plattform aus Spanplatte eingesetzt um auf dieser die diversen n tigen Komponenten unterbringen zu k nnen Konkret befinden sich in der Steuer und Kontrollebene die folgenden Komponenten e das Steuerboard zun chst war dieses das Kameleon K376SBC vgl Unterabschnitt 2 3 1 sp ter wurde es ersetzt durch das Fraunhofer AIS TMC 200 Board vgl Unterabschnitt 2 3 2 e der Steuerrechner hierbei handelt es sich um ein JVC MP XP7210DE ein Subnotebook mit einen Mobile Intel Pentium III mit 800 MHz 256 MB RAM einem SiS630ST Grafikchip und einem 8 9 Polysilizium Fl ssigkristall TFT Bildschirm Die Laufzeit mit einen Standardakku liegt bei ca 31 2 bis 51 2 Stunden vgl auch http www jvc de eu mpxp dr datcOlo htm 12 2 1 BERBLICK KAPITEL 2 HARDWARE Abbildun
122. n z B zwei Roboter als Attack 1 Strategien berschneiden k nnen Dennoch ist aber auch eine mehrfache Vergabe m glich ber den Men punkt Targetgoal wird die Farbe des gegnerischen Tors und somit die Spielrichtung festgelegt Angelehnt an das offizi elle Robocup Regelwerk stehen hier gelb yellow und blau blue als Torfarben zur Auswahl Eine bersicht ber die angeschlossenen Module und deren Status ist in dem Feld Active Components zu finden Aktive Module werden durch ein gr nes K stchen angezeigt Main Specials Help Status Playertwe ATTACK2 y Targetgoal BLUE v Active Components fps 0 Camera c50 Robot Communication m GUF Menu 7 Show ImageProcessing GUI 7 Show selfLocalisation GUI 7 Show PathFinder GUI 7 Show OdoSL GUI Select Parameter I UsesimulatedPOAData IV UseselfLocalisation TF Movesimulatedrobot IV moverealRobot STARTISTOP 60 stop Connection to mothership CONNECT Abbildung A 1 Hauptfenster der Tribots Anwendung Im Bereich GUI Menue lassen sich ber Checkboxen verschiedene Ansichten aktivieren und de aktivieren die diverse Funktionen und Kalibrationen erm glichen Diese werden wie bereits erw hnt in den weiteren Kapiteln beschrieben ber die Sektion Select Parameter sind Einstellungen m glich die insbesondere beim Einsatz eines Simulators von Nutzen sind Die Parameter haben im einzelnen f
123. n Bereich des Hauptfensters liegt das Controlpanel f r alle Roboter Hier kann der An wender allgemeine Befehle an alle Roboter zusammen schicken und somit das Team steuern Zun chst einmal hat er vier Kn pfe auf der linken Seite zur Verf gung mit denen er das Spiel starten Start All das Team stoppen Stop All oder alle Roboter auf Ihre vordefinierten Basispositionen setzen kann Home All Mit Connect all wird die Verbindung zwischen allen Robotern und dem TCPE Hauptpro gramm hergestellt Fehler und Probleme werden im Fenster Main Log auf der linken Seite ausge geben Die Anzeige Active Player zeigt die Anzahl der spielbereiten aktiven Spieler an und no game running besagt dass zur Zeit kein Spiel stattfindet Des weiteren hat der Anwender unter Game Control die M glichkeit in den Checkboxen Anstoss Home Anstoss Away und ARC on off allgemeine Einstellungen vorzunehmen die das gesamte Spiel das gesamte Team betreffen So kann der Anwender mit Anstoss Home dem Team signalisieren dass das eigene Team Ansto hat und das Spiel beginnen darf Hingegen hat der Gegner Ansto wenn Anstoss Away aktiviert ist Der Haken bei ARC on off dient dem De aktivieren des Automatic Role Change der automatischen Rollenverteilung im Spiel Wenn diese aktiviert ist bernehmen die Spieler w hrend des Spiels autonom andere Rollen falls diese durch Ausfall des verantwortlichen Roboters nicht be setzt sein sollten Diese Haken m ssen gesetzt sein be
124. n Ger te zur Arbeit am Roboter ben tigt werden neben einer Maus und der Tastatur zur Eingabe fehlt ein Display zur Datenausgabe Das Display an sich bedarf einer Stromversorgung soll diese ber die Akkus m glich sein Wenn nein dann schr nkt die Stromleitung des Bildschirms den Aktions bzw Arbeitsradius ein Wenn doch dann k men nur spezielle 12 V bzw 24 V TFT Bildschirme in Frage Offenbar findet sich auch unter diesem Aspekt in der Verwendung eines Notebooks eine L sung da darin bereits alle Komponenten integriert sind Nicht nur Standard PCs standen auf dem Pr fstand weitere berlegungen gingen in die Richtung von ITX Boards und PC104 Stecksystemen Heutige Notebooks bieten durch die Verbreitung des USB Standards nicht immer eine serielle Abbildung 2 7 Der Steuerrechner JVC MP XP7210 Quelle http www juc de Schnittstelle an und wenn doch sind die Notebooks durch ihre Ausma e f r den Einsatz auf un serer mobilen Plattform nicht geeignet Das Sub Notebook MP XP7210 der Firma JVC wurde aufgrund seiner geringen Ma e von 225 x 29 5 x 177 mm BxHxT und des Gewichtes von nur ca 1050 g ausgew hlt Kaum gr er als ein DINA 5 Blatt ist es geradezu pr destiniert f r unsere Zwecke Wie aber f r Notebooks dieser Gr enord nung zu erwarten fehlt eine serielle Schnittstelle RS232 so dass eine Ersatzl sung durch einen PCMCIA 2 Serial Adapter der Firma Elan gew hlt wurde 15 2 3 MOTORCONTROLLER KAPITEL 2 HA
125. n gen gen Ausgangsdaten sind die Steuerbefehle an die Motoren und die Schusseinheit die ebenfalls bei angeschlossenem Simulator das Roboter Modell im Rechner anstatt den realen Roboter bewegen Es ist grunds tzlich m glich Ein und Ausgangsdaten unabh ngig voneinander am Simulator zu betreiben Also z B die realen Motoren zus tzlich zu den simulierten Motoren im Rechnermodell anzusteuern und so den echten Roboter parallel fahren zu lassen Die Klasse stellt folgende Funktionen bereit e init verbindet den Simulator mit dem Tribots Programm 61 3 7 FREMDE SOFTWARE KAPITEL 3 SOFTWARE e setOmniVelocity setzt die Geschwindigkeit der Motoren im simulierten Roboter Modell e setKicker aktiviert die Schusseinheit im simulierten Roboter Modell e getOdoData liefert die Odometriedaten aufgrund der simulierten Ansteuerungsbefehle interne Berechnung e get bjectArray liefert ein Datenfeld in dem alle Features der omnidirektionalen Kamera aufbereitet sind Dazu geh ren Lage der Eckfahnen Tore Ball Gegner etc Die Verwendung des Simulators eignet sich vor allem f r Tests der rudiment ren Fahreigenschaf ten des Roboters Er wurde daher vor allem f r die Entwicklung der oben beschriebenen Grundf hig keiten eingesetzt Bei komplexeren Spielsituationen insbesondere bei Dribbel Man vern mit Ball erwies sich der verwendete Simulator als eher ungeeignet da die Update Frequenz des physikalischen Modells im Simulator zu gering
126. nd einer 12V Spannungsquelle soll das Problem der Stromversorgung l sen Das Schaltbild der gesamten Ansteuerung ist in Abbildung B 7 dargestellt gt 24V Es PA Pin 1 m 3 Bid e Er UU E A Port 270 YK z 2 2 L1 0 PC817 Pin 4 Ventil GND GND Abbildung B 7 Schaltplan f r die Ansteuerung der Schusseinheit ber TMC 94 B 4 KONFIGURATIONSDATEIEN ANHANG B HARDWARE B 4 Konfigurationsdateien Das harte Codieren von Werten und Parametern macht bei einer nderung eines Parameters oft das Neucompilieren des entsprechenden Programmabschnitts notwendig Ein alternativer Ansatz ist die Auslagerung der relevanten Parameter in eine Konfigurationsdatei die beim Programmstart geladen wird In dem Projekt wurden zwei dieser Dateien eingesetzt die im Folgenden n her beschrieben werden robotControl cfg Diese Datei enth lt Parameter f r die Kommunikation zu den Motorcontrollern und f r die Controller selbt e BOARD darf die Werte 1 und 2 annehmen und dient zur Unterscheidung welcher Motorcon troller angeschlossen ist Kameleon 1 oder TMC200 2 e USE legt fest ob der Controller mit einem Rechner ber PCMCIA 1 oder ber eine normale serielle Schnittstelle verbunden ist e COM_PORT verwendete Schnittstelle z B 0 e COM LAPTOP STBITS Anzahl der Stopbits bei Kommunikation mittels der PCMCIA L sung e COM_TOWER STBITS Anzahl der Stopbits bei einer Kommunikation ber eine normale se
127. ndung 2 2 2 2 2 nn nn nenn 79 A 5 Pathfinder Fenster der Tribots Anwendung e 81 A 6 Odometrie Selbstlokalisationsfenster der Tribots Anwendung 82 A 7 Graphische Oberfl che von TOPE nn 83 A 8 Player Panel von TOPE o rac racor moaca a 27 28 a 802 ne a na a 83 A 9 Team Panel von TOPE nn 84 B 1 Projektion eines Weltpunktes auf einen Bildpunkt o o 89 B 2 Datenkabel Konverter und Adapter zwischen den Roboterkomponenten Kameleon 91 B 3 Stromkabel zwischen den Roboterkomponenten Kameleon 92 B 4 Datenkabel Konverter und Adapter zwischen den Roboterkomponenten TMC 92 B 5 Stromkabel zwischen den Roboterkomponenten TMC 2 2 2 2 93 B 6 Schaltplan f r die Ansteuerung der Schusseinheit ber Kameleon 94 B 7 Schaltplan f r die Ansteuerung der Schusseinheit ber TMC 2 2 94 Tabellenverzeichnis 2 1 2 2 2 3 2 4 3 1 3 2 3 3 3 4 4 1 Al Technische Daten des JVC MP XP7210 2 2 2 Connie 16 Auswahl technischer Daten zum Kameleon 376SBC 2 22 2 2 nn nn 17 Auswahl technischer Daten des Robotic Expansion Boards 2 2 2 2 2 020 18 Auswahl technischer Daten zum TMC200 2 2 2 CE En 19 Durchlaufzeiten der einzelnen Softwaremodule 2 2 2 2 2 Emm nenn 26 Nach Priorit t geordnete Farbklassen in der Bildsegmentierung 28 Charakteristische Objekteigenschaften im Kamerabild
128. nen Ball mit konstanter Geschwindigkeit 63 4 2 SELBSTLOKALISATION KAPITEL 4 SYSTEMTESTS 4 2 Selbstlokalisation F r die Selbstlokalisation wurden mehrere Tests durchgef hrt bei denen der Roboter quer ber das Feld mit unterschiedlichen Geschwindigkeiten gefahren wurde Die Anfangs und Endpunkte wurden gemessen und die Abweichung von der tats chlichen Bewegung bestimmt In den Abbildungen 4 2 und 4 3 sind Ergebnisse solcher Tests dargestellt Abweichung der Selbstlokalisation Selbstlokalisation Lineare Interpolation x 2000 ig 7 4 4 1000 A 7 gt 172 e a gos 3 A 3 K 1000 A hia N Fiy 2000 7 1 1 fi 1 1 fi fi 1 fi 4000 3000 2000 1000 0 1000 2000 3000 4000 Spielfeld Pos X Abweichung der Selbstlokalisation i i Selbstlokalisation Lineare Interpolation x 2000 d 1000 a 4 gt k 72 Ea o Hr a oth 2 0t Se t J 2 E A EN 1000 So ch k S Sh Ky 2000 H Ah 1 1 fi 1 1 fi fi 1 fi 4000 3000 2000 1000 0 1000 2000 3000 4000 Spielfeld Pos X Abbildung 4 2 Fahrt des Roboters quer ber das Spielfeld mit 0 5 m s oben und mit 1 5 m s un ten Bei einem anderen Test sollten mehrere definierte Punkte auf dem Feld vom Roboter selbst ndig angefahren werden Es wurde eine Umgebung geschaffen in der aufgezeichnete Bildverarbeitungs und Odometriedaten benutzt werden um die Selbstlokalisationsalgorithmen immer wieder mit denselben
129. nfache Art manipuliert werden k nnen Es existieren folgende Befehle moveToPosXY Der Roboter f hrt zu einer Position auf dem Spielfeld Dabei h lt er Ausrichtung und Anfahrtsvektor gem den Eingaben durch setApproachPoint und setOrientation ein stop Der Roboter h lt an setOrientation Der Roboter richtet sich auf den bergebenen Punkt auf dem Spielfeld aus Bei allen folgenden Fahrbefehlen beh lt der Roboter diese Ausrichtung bei D h er gleicht eine falsche Ausrichtung permanent durch Eigenrotation aus setApproachPoint Der Anfahrtsvektor wird aus dem bergebenen Bezugspunkt und der Po sition des Ziels berechnet Bezugspunkt und Zielpunkt bilden eine Gerade Auf dieser Geraden vom Bezugspunkt aus gesehen hinter dem Ziel liegt der Anfahrtsvektor Beispiel Zielpunkt ist der Ball Bezugspunkt das blaue Tor Dann f hrt der Roboter den Ball stets von der dem blauen Tor abgewandten Seite an resetApproachPoint Bei zur ckgesetztem Anfahrtsvektor f hrt der Roboter den Zielpunkt immer direkt an und zwar von der Seite von der er sich ihm gerade n hert 43 3 4 STRATEGIE KAPITEL 3 SOFTWARE Man vrieren mit Ball Zum F hren des Balls stehen dem Roboter in der vorliegenden Bauart lediglich zwei flexible ca 10 cm lange H rnchen an einer Flanke zur Verf gung siehe auch Kapitel 3 4 Der Ball wird weder festgeklemmt noch irgendwie sonst am Roboter gehalten d h er ist v llig frei beweglich Hat der Roboter mit Hilfe
130. ngsseite des Relais wird einerseits mit 24 V verbunden und andererseits mit einem Pol des Ventils Als Schaltbild ergibt sich Abbildung B 6 Digitiale E A Ports des K376SBC k nnen nicht genutzt werden da sie maximal ca 1mA Strom bereitstellen vgl 10 Seite 9 das Relais aber erst bei ca 15mA ausl st Das Schaltbild der gesamten Ansteuerung ist in Abbildung B 6 dargestellt B 3 2 TMC Das TMC erm glicht ber insgesamt 10 E A Ports den Anschluss bzw die Ansteuerung Abfrage von Sensoren und Aktoren wobei besondere Vorsicht geboten ist zwischen den Pins der Ports und der angeschlossenen Elektronik ist auf saubere Signaltrennung zu achten Am besten entkoppelt man beides optisch voneinander Hierf r wird ein Optokoppler vom Typ PC817 eingesetzt der ber einen 2700hm Widerstand mit dem entsprechenden E A Pin des TMC verbunden wird Der maximale Strom in diesem Kreis ist somit auf lt 20mA begrenzt und liegt innerhalb der Spezifikationen des PC817 Das elektrische Ventil kann nicht direkt an den Ausgang des Kopplers angeschlossen werden dieser stellt nicht genug Strom zur Ausl sung bereit Ein zus tzlicher Querzweig mit einer Standarddiode 93 B 3 ANSTEUERUNG SCHUSSEINHEIT ANHANG B HARDWARE gt A a Pin2 2 K1 Ik Kameleon aj RRIA L4 1 O Connector 1 X O con O Z 0 Pin 25 Ventil j GND Abbildung B 6 Schaltplan f r die Ansteuerung der Schusseinheit ber Kameleon vom Typ 1N148 einen Transistor BD139 u
131. nsiert der Einsatz eines Pneumatikzylinders der wie in Abbildung 2 11 angebracht ist Die Schusseinheit des Roboters wird pneumatisch betrieben aus Abbildung 2 12 kann man die einzelnen Komponenten entnehmen Der eingesetzte Druckluftbeh lter kann mit bis zu 10 bar betankt werden Um das R ckflie en der Luft zu verhindern setzen wir ein R ckschlagventil ein welches durch einen Aufsatz mit einem Kompressor bzw einer Handluftpumpe Autoventil verbunden wird Die zweite ffnung des Beh lters dient als Auslass und ist ber einen Druckluftschlauch 8 mm mit einem Drosselr ckschlagventil verbunden Dieses Ventil kann f r eine grobe Regulierung der Durchflu menge manuell ge ffnet bzw geschlossen werden Von dort aus wird die Druckluft auf ein 3 2 Wege Magnetventil weitergeleitet d h es besitzt drei ffnungen und zwei definierte Schaltstellungen Die ffnungen sind gekennzeichnet durch die Buchstaben 19 2 4 SCHUSSEINHEIT KAPITEL 2 HARDWARE Abbildung 2 11 Mechanischer Aufbau der Schusseinheit Links im eingefahrenen und rechts im ausgefahrenen Zustand Kolben mit R ckholfeder Drosselr ck schlagventil R ckschlag ventil Lufttank elektr Ventil Abbildung 2 12 Schematische Darstellung des Zusammenspiels der Pneumatik Elemente e P Druckluftanschluss e R Bel ftung e A Anschluss f r einen Zylinder und entsprechend beschalten In der einen definierten Stellung
132. ntiert dies wird aber durch das Gelb ver deckt L sung Im Bildverarbeitungsfenster i die Rot Segmentierung ein aber die Gelb Seg mentierung ausschalten Sieht man jetzt rot segmentierte Pixel im Tor diese herunterre geln bis nur noch der Ball oder zumindest m glichst viel vom Ball aber keine roten Pixel im gelben Tor segmentiert werden e Problem Roboter bewegt sich ruckartig ber das Spielfeld m gliche Ursachen Es werden gelbe Pixel im Spielfeld erkannt L sung Die Gelb Segmentierung an mehreren Stellen auf dem Spielfeld berpr fen e Problem Roboter f hrt sehr h ufig zum Spielfeldrand auch wenn sich dort kein Ball befindet m gliche Ursache Neben dem Spielfeld befinden sich Gegenst nde mit gleicher oder hnli cher Farbe wie der Ball L sung Rotsegmentierung berpr fen und wenn m glich Gegenst nde entfernen 87 A 6 PROBLEMBEHEBUNG ANHANG A BEDIENUNGSANLEITUNG e Problem Die Schusseinheit l st nicht an der Position aus wo sie soll Roboter lokalisieren sich sehr schlecht m gliche Ursache neben dem Spielfeldrand sind Gegenst nde die als Tore erkannt werden L sung Blausegmentierung berpr fen und wenn m glich Gegenst nde entfernen m gliche Ursache Blaue Banderolen der Gegner werden als Tor erkannt L sung Die Blausegmentierung mit einer Banderole im Sichtbereich des Roboters justie ren dabei die Banderole bewegen um verschiedene Blaut ne zu berpr fen e Problem Roboter koll
133. olgende Bedeutungen e Use Simulated POA Data Bei aktivierter Checkbox wird ein Possible Object Array ver 75 A 2 TRIBOTS ANWENDUNG ANHANG A BEDIENUNGSANLEITUNG wendet an Hand dessen der Roboter seinen Fahrweg berechnet Dieser Punkt simuliert eine k nstliche Umgebung Wichtig beim Einsatz des Simulators e Use Selflocalisation ber diese Checkbox l sst sich die Selbstlokalisation de aktivieren e Move Simulated Robot ber diese Checkbox l sst sich die Wiedergabe des eigenen Roboters der Spielfeld Umgebung und der Fahrbewegungen im Simulator de aktivieren e Move Real Robot ber diese Checkbox kann man eine Fahrbewegung des Roboters de Jaktivieren Dies ist z B von Bedeutung wenn man das Programm laufen lassen m chte aber nur den Simulator nutzt und den Roboter nicht real fahren lassen m chte Die Funktion der Kn pfe im unteren Fensterbereich ist weitesgehend selbsterkl rend deshalb wird an dieser Stelle nur kurz darauf eingegangen ber Start Stop wird der eigentlich Fahrmodus des Roboters de aktiviert Connect trennt die Verbindung zu TribotsControl damit diese dann neu initialisiert werden kann Abschlie end folgt die Beschreibung des Fenstermen s teilweise sind die dort enthaltenen Funk tionen parallel ber die o g Kn pfe zu erreichen der Vollst ndigkeit halber aber auch hier zu finden Abbildung A 2 zeigt die aufgeklappten Kontextmen s die man ber Main und Specials erreichen kann Die
134. onen abfragen Eine Erweiterungsplatine das REB siehe Abbildung 2 9 die auf das Kameleon aufgesteckt wird enth lt die notwendige Leistungselektronik zur Ansteuerung von bis zu vier Motoren mit jeweils maximal 20 Watt Zur Erfassung der Motordrehzahl stellt die Platine Anschl sse f r Inkrementalen coder bereit der onboard PID Controller wertet diese Informationen z B zur Drehzahlregelung aus Zus tzlich bietet es eine Vielzahl an Schnittstellen f r Sensoren und zur Ansteuerung weiterer Akto ren wie Servos so k nnen ber einen Teil der analogen E A Pins die aktuelle Versorgungsspannung und die Motorstr me ausgelesen werden serial extension bus cpu extension bus interface extension bus 8Robotic Extension Board 17 2 3 MOTORCONTROLLER KAPITEL 2 HARDWARE Abbildung 2 9 Das Robotic Extension Board f r das Kameleon 3765BC Quelle http www k team com Motion 4 DC Motoren amp Encoder 4 Servo Ausg nge I O 11 A D Wandler 10 Bit Aufl sung 2 D A Wandler 12 Bit Aufl sung 16 digitale Kan le Konfigurierbare I O 16 digitale I O f r Sensorik Schnittstellen I2C Bus Tabelle 2 3 Auswahl technischer Daten des Robotic Expansion Boards 2 3 2 TMC200 Der Triple Motor Controller kurz TMC200 siehe Abbildung 2 10 ist eine Entwicklung des Fraun hofer Instituts fiir autonome intelligente Systeme und zur Zeit noch in einem Teststadium was Hard und Software angeht Er ist f r
135. ont und RHorizontz begrenzen den ungef hren Be reich des Bildes wo der Horizont zu finden ist 3 rand 7 T 4 Bestimme x y aus r amp mit Bildmitte mitte mittey 5 if getPixelColor x y BLUE then 6 if poleBlueTest x y TRUE then T Addiere Partikel x y zu PositvePoleBluePartikel 8 end if 9 if goalBlueTest x y TRUE then 10 Addiere Partikel x y zu PositveGoalBluePartikel 11 end if 12 end if 13 if getPixelColor x y YELLOW then 14 if poleYellowTest x y TRUE then 15 Addiere Partikel x y zu PositvePoleYellowPartikel 16 end if 17 if goal YellowTest x y TRUE then 18 Addiere Partikel x y zu PositveGoalYellowPartikel 19 end if 20 end if 21 end for Algorithmus 2 seed_search Funktion die blaue und gelbe Pixel den Toren und Poles zuordnen kann 1 for i 0 to AnzahlBallPartikel do 2 r rand R Roboter Base Rpeia 3 amp rand r m 4 Bestimme x y aus r amp mit Bildmitte mitte mitte 5 if getPixelColor x y BALL then 6 Addiere Partikel x y zu PositveBallPartikel 7 endif 8 end for Algorithmus 3 sample_step Funktion die dem Objekte zugeh rige Pixel finden soll 1 for i 0 to Anzahl Ball Partikel do 2 z rand 0 PositiveBall Partikel size Bestimme zuf llig zu untersuchenden Partikel 3 Blur YBlur rand 20 20 Zuf llige Wahl eines Punktes in der Partikelumgebung 4 Erzeuge neuen Partikel UTest
136. ort ia analoger WertI Einheit 20mV Bit bzw 2 79mA Bit JB Auslesen aller Motorstr me Befehl JBII Antwort jb Strom0 Strom1 Strom2 Strom3T Einheit 2 79mA Bit NB Stoppen aller Motoren Befehl NBII Antwort nbr PA PWM Amplitude eines Motors setzen Befehl PA Motornummer MotorPWMII Antwort pal Wertebereich 100 bis 100 entspricht 255 bis 255 PB PWM Amplitude aller Motoren setzen Befehl PB MotorOPWM Motor1PWM Motor2PWM Motor3PWMII Antwort pbr Wertebereich 100 bis 100 entspricht 255 bis 255 QA Starten des LPRSerCom Protokolls Befehl QAII Antwort qal QB Starten des SerCom Protokolls Befehl QBII Antwort qbr SB Abfragen aller m glichen Sensordaten Befehl SBII Antwort sb SPD0 SPD1 SPD2 SPD3 Voltage CURO CUR1 CUR2 CUR3 SEN0 SEN1 SEN2 SEN3 SEN4 SENST SPD akt Geschwindigkeit Einheit pulse 10ms Voltage Spannung der Batterie mV CURz Strom am Motor x 0 3 mA SENz Ultraschallsensor x 0 5 cm UB Ultraschallmefwerte abfragen Befehl UBII 99 B 5 KAMELEON KOMMUNIKATIONSPROTOKOLL ANHANG B HARDWARE Antwort ub sensorO sensorl sensor2 sensor3 sensor4 sensor5l Einheit cm VB Version des Protokolls auslesen Befehl VBII Antwort vb Protokollversionl ZB Angeschlossene Motoren feststellen Befehl ZBII Antwort zb motorO motor1 motor2 motor3T 0 Motor nicht angeschlossen 1 Motor angeschlossen 100 Literaturverzeichnis A Bonarini G Kraetzschmar
137. p Die Robocup Initiative wurde 1997 gegr ndet sie dient der Forschung und Lehre innerhalb der Robotik und der K nstlichen Intelligenz An einem Standardproblem dem Fu ballspiel k nnen ver Iuww robocup org 1 3 PROJEKTVERLAUF KAPITEL 1 EINLEITUNG schiedene Ans tze evaluiert werden Konferenzen Schulungen und der einmal pro Jahr stattfindende Wettbewerb bei dem die Forschungsgruppen ihre eigenen Entwicklungen unter dem Aspekt der Konkurrenzf higkeit testen sind Bestandteil der Initiative Die Wettbewerbe sind in Ligen unter teilt Zu der Kategorie Robocup Soccer geh ren die Simulation League Small Size Robot League 180 Middle Size Robot League 2000 Sony Legged Robot League unterst tzt von Sony und Humanoid League seit 2002 Neben dem Robocup Soccer Wettbewerben finden noch die Robocup Rescue und Robocup Junior Wettk mpfe statt Aus den unterschiedlichen Regeln und technischen Anforderungen in den einzelnen Ligen ergeben sich verschiedene Problemstellungen und Forschungs schwerpunkte Unser Team nahm an den Spielen der Middle Size Robot League teil Dort besteht eine Mannschaft aus vier Spielern inklusive dem Torwart Die Ausmafe der Spieler sind begrenzt ihre H he muss zwischen 30cm und 85 cm liegen und die Grundfl che darf ein Quadrat mit einer Seitenl nge von 50 cm nicht berschreiten Externe Sensoren wie eine globale Kamera sind nicht zugelassen die Spieler sind vollst ndig auf eigene Sensoren un
138. r Ball unter einer falschen Position gesehen werden Entsprechend w rde diese fehlerhafte Information bei der Berechnung der zusammengef hrten Ball position das Ergebnis verf lschen Beim Teamspiel selber w re es schon hilfreich wenn sich die Roboter gegenseitig mitteilten dass sie im Ballbesitz sind In Spielen lie en sich Situationen beobachten in denen ein Verteidiger im Ballbe sitz auf das gegnerische Tor st rmte Da jedoch der eigentliche St rmer immer vom Ball angezogen wird behinderte er den eigenen Roboter beim Attackieren des Tor M glicher L sungsansatz k nnte sein den eigenen Roboter dessen Position bekannt w re durchzulassen Viele weitere Formen von Teamspiel w ren denkbar Die Einstellungen der Farbsegmentierung zur Kalibrierung der Bildverarbeitung haben sich f r die Zwecke des Robocup als u erst robust erwiesen Jedoch ist die Farberkennung noch zu sehr von der Beleuchtung der Umgebung abh ngig Schatten auf den Objekten verf lschen die Farben und k nnen gro e Probleme bei der Objekterkennung bereiten Es w re daher w nschenswert die Bildverarbeitung so zu ver ndern dass in Zukunft markante Regionen im Spielfeld unabh ngig von den Beleuchtungsverh ltnissen erkannt werden M glich w re es sich haupts chlich bei der Orien tierung auf Linien im Feld anstelle von farbigen markanten Objekten zu st tzen Damit w rde eine Selbstlokalisation m glich werden die auf Farbinformationen im Bild fast ganz verzic
139. r GUI gestartet beginnt der Roboter eine langsame Drehbewegung Distanztabelle Der Algorithmus sammelt die Pixelabst nde der Messpunkte zu jedem Zeitpunkt und tr gt sie zusammen mit dem zum Ball gemessenen Winkel in ein Array von MarkerFunctions ein Durch die Methode add_measure wird eine fortschreitende Mittelung von mehreren Messwer ten in gleicher Richtung vorgenommen Sobald der Algorithmus mindestens f nf Messwerte aus allen 360 Richtungen genommen hat stoppt er die Drehung Danach werden die Messwerte des Arrays von MarkerFunctions mit einem einfachen Tiefpa Filter gegl ttet Hierdurch ergibt sich eine Cha rakteristik eines Kamera Spiegelaufbaus die durch die f nf Messwerte in jede Richtung definiert ist Danach werden Distanzen mit Hilfe linearer Interpolation zwischen den nun bekannten Entfernungen der St tzpunkte bestimmt Ein Messergebnis der Abst nde der Marker zum Roboter ist in Abbildung 3 7 erkennbar W re die Kameraanordnung perfekt eingestellt so w rden sich Geraden ergeben 3 2 4 Objekttracking Zur Zeiteinsparung bei der Bildverarbeitung nutzt man bestehendes Vorwissen ber die Position von Objekten sie sind so im aktuellen Bild schneller zu finden Dieses als Tracking bekannte Prinzip 31 3 2 BILDVERARBEITUNG KAPITEL 3 SOFTWARE Marker1 Pots rn Markeri een Markeri 180 L Siia en FREE J 160 Cn u 140b Haga J E N lt S A 120 100 ee i J 80 F 7
140. r zur Verf gung das bei der Strategieberechnung nicht ber cksichtigt werden muss Die Ansteuerungsbefehle werde an reale Begebenheiten wie die Gefahr des Umkippens angepasst Dies kann zum Beispiel geschehen wenn der Roboter an zwei aufeinanderfolgenden Zeitpunkten widerspr chliche Ansteuerungen erh lt Beispielsweise fahre zum Zeitpunkt t mit Maximalgeschwindigkeit in Richtung 0 Grad zum Zeitpunkt t 1 mit Maximalgeschwindigkeit in die entgegengesetzte Richtung Im konkret beschriebenen Fall wird der Roboter in eine Kurvenfahrt bergehen um den harten Wechsel zwischen den beiden Ansteuerungsbefehlen auszugleichen Ausgabe adaptierter Ansteuerungsbefehl e Robotermodul siehe Abschnitt 3 6 Eingabe adaptierter Ansteuerungsbefehl der Strategie An allerletzter Stelle im Kontrollfluss der Software verarbeitet das Robotermodul den An steuerungsbefehl an die Hardwareansteuerung des Roboters Dabei leistet es die bersetzung eines auf hohem Niveau formulierten Ansteuerungsbefehls an die spezifische Hardwareplattform des Roboters da beispielsweise mehrere Motorcontroller am selben Roboter betrieben werden k nnen Das Modul das an der Schnittstelle zwischen Applikation und Betriebssystem bzw Roboter hardware steht schickt den Ansteuerungsbefehl an die serielle Schnittstelle des Steuerrechners mit dem der Motorcontroller des Roboters verbunden ist Weiterhin nimmt es Sensorinforma tionen des Roboters entgegen und reicht diese an das Wel
141. rache mit dem Schiedsrichter vom Platz genommen werden 1 3 Projektverlauf Die Arbeit der Projektgruppe gliederte sich in drei Phasen In der Orientierungsphase die vom Anfang des Wintersemesters 2002 03 bis Ende Dezember 2002 dauerte bildeten wir drei Teams mit jeweils vier Student en innen Ziel dieser Phase war es sich mit der Arbeitsumgebung vertraut zu machen Dazu geh rten der Einsatz der Bibliothek cvtk 7 die Ansteuerung der Kamera und die vorhandene Schnittstelle zur Kommunikation mit dem Motorcontroller Mit dem Ende dieser Phase musste jedes Team vorgegebene Benchmarks absolvieren Insgesamt wurden f nf Tests durchgef hrt diese bestanden darin aus unterschiedlichen Positionen sowie Ausrichtungen des Roboters einen orangefarbenen Ball in m glichst kurzer Zeit in ein blaues Tor zu schie en Bei einem der Tests wurde zus tzlich der Ball bewegt was sich als schwierigste Aufgabe erwies und nur von einer Gruppe gel st wurde Am Ende dieser Phase stand fest dass wir eine omnidirektionale Kamera verwenden und ein Team f r die German Open in Paderborn aufstellen w rden Der zweite Teil der Projektarbeit wurde genutzt um L sungen f r die erkannten Probleme der ersten Phase zu finden und sich somit auf die German Open vorzubereiten Anhand der Erfahrun gen aus der 1 Phase und den Vortr gen aus der Seminarphase ergaben sich f r uns die folgenden Schwerpunkte Bildverarbeitung Weltmodell Strategie Kommunikation Roboteransteuer
142. rechnung einbezogen wurden Sein Verhalten wurde vollst ndig neu programmiert hierunter fallen die Entwicklung eines Beschleunigungsmoduls um sein Fahrverhalten besser kontrollieren zu k nnen sowie die Berechnung der Ballgeschwindigkeit Das Beschleunigungsmodul erwies sich als so vorteilhaft dass es anschlie end in alle Robotertypen integriert wurde Einen wesentlichen Beitrag zu den Verbesserungen leisteten die konsequent durchgef hrten Sys temtests Die permanente quantitative Kontrolle der Entwicklung gab Aufschluss ber Fortschritte bei den Verbesserungen und die verbleibenden Aufgaben um die Ziele zu erreichen Obwohl zwischen German Open und der Weltmeisterschaft auf allen Gebieten deutliche Fort schritte erzielt wurden zeigte sich doch im Vergleich mit bis dahin unbekannten Teams dass hinsicht lich Strategie Endgeschwindigkeit und Ausfallsicherheit der Roboter gro es Verbesserungspotential vorhanden ist In Zukunft sollten daher neben Informatikern auch Maschinenbauer und Elektrotech niker am Vorhaben beteiligt werden 5 2 Ausblick Die Projektgruppe hat in der kurzen Zeit von zehn Monaten viel erreicht sie hat eine Mannschaft von autonomen Fu ballrobotern aufgestellt die auf oberem Niveau im internationalen Vergleich spielten Software und Hardware weisen viele positive Eigenschaften auf An vielen Stellen gibt es M glichkeiten zur Erweiterung an denen Weiterarbeit lohnenswert ist Um das Ziel von schnelleren Robotern zu
143. rkehr zu an dauernden Kollisionen und damit zu Paketverlusten kommen Das Tribots Software Framework ist so konstruiert dass die Roboter auch ohne WLAN Verbindung reibungslos funktionieren und nicht auf permanente WLAN Daten angewiesen sind Das Senden der Nachrichten erfolgt durch die Nutzung der QSocket API in einem eigenen Thread so dass Paketverluste und Timeouts nicht zur St rung des gesamten Programmablaufs f hren 3 5 2 Dynamischer Rollenwechsel W hrend eines Roboter Fu ballspiels sind Ausf lle der Protagonisten zu erwarten Zum einen ist die Hardware noch nicht so robust dass sie jeder physikalischen Belastung standh lt zum anderen kann vom Schiedsrichter ein Roboter wegen Regelversto es vom Platz gestellt werden Jede Ver nderung der Anzahl der im Spiel verf gbaren Roboter muss unmittelbar zu einer berpr fung und Anpassung der Rollenverteilung f hren Jeder Roboter hat zu jedem Zeitpunkt eine bestimmte Role zugewie sen sie definiert f r einen Roboter verschiedene Variablen So wird eine bestimmte Homeposition zugewiesen genauso wie der Spielfeldbereich der vom Roboter im Normalzustand angefahren wer den darf Au erdem wird eine Patrolroute festgelegt die der Roboter abf hrt wenn sein aktuelles Weltbild keinen Ball lokalisieren konnte Die bliche Rollenverteilung bei vier Robotern ist GOALIE DEFEND1 DEFEND2 ATTACK2 Sobald w hrend eines Spieles ein Roboter gestoppt wird sendet er diese Information an Tribots
144. ro es Plus herausstellte Abbildung 4 8 WM Padua Zwischenrundenspiel gegen Uni T bingen Nat rlich fielen nicht nur positive Dinge auf im Spiel gegen noch st rkere Gegner traten auch 69 4 4 WETTBEWERBE KAPITEL 4 SYSTEMTESTS Schw chen zutage In der Zwischenrunde musste das Team zun chst gegen Eigen den amtierenden Weltmeister aus Japan antreten Im Vergleich zu diesem wie auch zu anderen absoluten Weltklas seteams war man immer noch zu langsam und die Ballf hrung m sste noch verbessert werden Mit ihren trickreichen St rmern die trotz eines Differential Antriebs schnell und sehr ballgewandt waren konnten die Gegner die eigenen Bem hungen zunichte machen Obwohl man zwei mal in F hrung ging lie en die Japaner nicht locker und gewannen am Ende knapp mit 3 4 Im folgenden Spiel gegen Minho aus Portugal musste daher ein Sieg her um die Chancen auf das Erreichen des Viertelfinales zu wahren Leider trat in diesem Spiel eine weitere Schw che zutage die sich ansatzweise auch schon gegen Mostly Harmless und Argus angedeutet hatte Massive Gegner bereiteten den eigenen Robotern gro e Probleme Minho spielte im Gegensatz zu den beiden ande ren Teams jedoch weitaus cleverer in dem sie sich besonders und im Grunde ausschlie lich in der Defensive auszeichneten Man fand kein Mittel gegen dieses massive Bollwerk und dann konnten sie sich mit ihrer beraus starken Schusseinheit einige Male befreien Zwei von diesen Sch ssen l
145. rrechner auf dem das Hauptprogramm l uft In Kapitel 3 beschreiben wir die von uns entwickelte und eingesetzte Software sowie die algorith mischen Ans tze die wir verwenden Die Struktur des Hauptprogramms verdeutlicht Abschnitt 3 1 Um eine genauere Vorhersage bei der Fahrtplanung o a zu gew hrleisten entschieden wir uns f r einen sequentiellen Ablauf des Programms Die Bildverarbeitung leistet die Einteilung des aufgenom men Bildes in Farbklassen und beschr nkt die Suche nach Objekten auf bestimmte Bereiche in denen sich z B der Ball befinden k nnte Weitere Merkmale der Bildverarbeitung sind die Distanzfunktion und die M glichkeit ein Objekt zu tracken Das Weltmodell setzt die Informationen der Bildverar beitung zur Selbstlokalisation des Roboters auf dem Spielfeld ein Dabei wird die wahrscheinlichste Position des Fu ballroboters berechnet Zus tzliches Wissen ber die Umwelt den Ball die beiden Tore und die Hindernisse ist vorhanden Die Strategie unseres Roboters ist reaktiv Entscheidungen werden anhand von aktuellen Daten gef llt Es wird in Grundf higkeiten und h here F higkeiten un terschieden die erstgenannten sollen auch bei ausgefallener Selbstlokalisation funktionieren Unsere Fu ballroboter erhalten von einem zentralen Programm zus tzliche Kommandos die von der Stra tegie ber cksichtigt werden Das Robotermodul kapselt alle Hardware nahen Funktionen und stellt dem Anwender nach au en hin eine einfache Schnittst
146. ssen anzupassen Die von uns verwandte Methode erm glicht mittels dynamischer Einstellungen die Definition von Unterr umen der Farbklassen F r jede Farbklasse k nnen Inter vallgrenzen angegeben werden welche die Position im RGB Raum bestimmen Beispielsweise k nnen f r die Farbklasse Blau die untere Intervallgrenze des Blauanteils des RGB Wertes sowie die oberen Intervallgrenzen f r den Rot und den Gr nanteil des RGB Wertes eingestellt werden D h alle Pixel deren RGB Werte zum Beispiel in den Intervallen Rot 0 62 Gr n 0 78 und Blau 145 255 liegen geh ren zu der Farbklasse Blau Die Einstellung von drei der sechs Intervallgrenzen gen gt um eine eindeutige Zuordnung der Objekte zu ihren Farbklassen zu gew hrleisten In Tabelle 3 2 sieht man die Einstellungsm glichkeiten der Intervallgrenzen bei den einzelnen Farbklassen Farbklasse Rot Intervallgrenzen Gr n Intervallgrenzen Blau Intervallgrenzen Untere Obere Untere Obere Untere Obere Orange Dyn 255 0 Dyn 0 Dyn Blau 0 Dyn 0 Dyn Dyn 255 Gelb Dyn 255 Dyn 255 0 Dyn Schwarz 0 Dyn 0 Dyn 0 Dyn Wei Dyn 255 Dyn 255 Dyn 255 Gr n 0 Dyn Dyn 255 0 Dyn Tabelle 3 2 Nach Priorit t geordnete Farbklassen mit Angabe der Einstellm glichkeiten der Inter vallgrenzen Abbildung 3 4 Bildverarbeitungsfenster mit Segmentierung aller Farbklassen 28 3 2 BILDVERARBEITUNG KAPITEL 3 SOFTWARE 3 2 2 O
147. st Farbklasse 0 gesammelt Umsetzung Eine g ngige Methode zur Einteilung des RGB Raumes in Farben ist die Erstellung von LookUp Tables die alle zu einer Farbklasse geh renden RGB Werte in Tabellenform enthal ten und somit die Zugeh rigkeit eines Pixels in einer Laufzeit von O 1 liefern In einer Umgebung mit stark schwankenden Lichtverh ltnissen wie beim Robocup ist die Erstellung von LookUp Tables sehr aufwendig da diese oftmals zu viele Werte enthalten so dass Objekte segmentiert werden die nicht erkannt werden sollen oder zu wenig Werte enthalten und die Objekte somit nicht vollst ndig segmentiert werden So entsteht zum Beispiel durch die in der Regel zur Beleuchtung verwendeten Scheinwerfer ein starker kegelf rmiger Lichteinfall von oben Dieser sorgt zu einer Entstehung von Glanzeffekten auf der Oberseite des Balls und zu einer Schattenbildung auf der Unterseite so dass der Ball im Kamerabild nicht nur Orange erscheint sondern von Wei bis Dunkelrot alle Schattierungen 27 3 2 BILDVERARBEITUNG KAPITEL 3 SOFTWARE durchl uft hnliche Probleme treten bei den Toren auf da hier von der Latte und den Pfosten Schat ten auf die R ckwand des Tors geworfen werden die gerade beim blauen Tor zu einer fast schwarzen F rbung des Tors im Kamerabild f hren Um diese Probleme zu l sen mussten wir eine Methode verwenden die es uns erm glicht die Farbklassen m glichst einfach und schnell den gerade herrschen den Lichtverh ltni
148. t abI Setzen der Geschwindigkeit eines Motors Befehl DA Motornummer Motorgeschwindigkeitll Antwort dal Einheit Pulse 10ms Setzen der Geschwindigkeiten aller vier Motoren Befehl DB Motorgeschwindigkeit0 Motorgeschwindigkeit1 Motorgeschwindigkeit2 Motorgeschwindigkeit3ll Antwort dbl Einheit Pulse 10ms Geschwindigkeit eines Motors auslesen Befehl EA Motornummerll Antwort ea MotorgeschwindigkeitI Einheit Pulse 10ms Geschwindigkeit aller Motoren auslesen Befehl EBII Antwort eb Motorgeschwindigkeit0 Motorgeschwindigkeit1 Motorgeschwindigkeit2 Motorgeschwindigkeit3T Einheit Pulse 10ms Setzen bzw Widerrufen der Erlaubnis zum Kicken Befehl FB xII mit x 0 1 Antwort fbr Standard Freigabe ist deaktiviert Positionsz hler eines Motors setzen Befehl GA Motornummer Motorpositionll Antwort gal Einheit Pulse oder A D Bit Positionsz hler aller Motoren setzen Befehl GB MotorpositionO0 Motorposition1 Motorposition2 Motorposition3ll Antwort gbr Einheit Pulse oder A D Bit 98 B 5 KAMELEON KOMMUNIKATIONSPROTOKOLL ANHANG B HARDWARE HA Positionsz hler eines Motors auslesen Befehl HA Motornummerll Antwort ha Motorpositionl Einheit Pulse oder A D Bit HB Positionsz hler aller Motoren auslesen Befehl HBII Antwort hb Motorposition0 Motorposition1 Motorposition2 Motorposition3T Einheit Pulse oder A D Bit IA Auslesen der A D Eing nge Befehl TA Kanalnummerll Antw
149. t und stop steuern zu k nnen 84 A 4 TRIBOTS PROGRAMMSTART ANHANG A BEDIENUNGSANLEITUNG A 4 Tribots Programmstart Der Ubersicht halber wird an dieser Stelle nochmal eine Zusammenfassung gegeben welche Schritte notwendig sind um den Roboter korrekt fahren zu lassen Der nachfolgende Beispielablauf ist eine minimale Anleitung um den Roboter zum Laufen zu bekommen 1 Tribots Anwendung starten Die Tribots Anwendung wird auf dem Laptop des Roboters aus dem Tribots Verzeichnis ber tribots gestartet Programm starten Die Hardware Komponenten sollten nun mit s gestartet werden Die Anwendung wartet nun auf die entsprechenden Befehle der Kommunikationssoftware Module pr fen In dem Feld Active Components sollten nun alle wesentlichen Module aktiv also mit einer gr nen Markierung versehen sein Ist dies nicht der Fall liegt ein Fehler vor eventuell muss z B die Kamera neu gestartet werden Aktiv sein sollten unbedingt Camera Communication und Robot Spielfeldeinstellungen vornehmen ber Status muss nun die Farbe des gegnerischen Tors und die Rolle des eigenen Roboters ausgew hlt werden Farbsegmentierung berpr fen Mit der Taste i muss nun die Bildverarbeitungsoberfl che gestartet werden Es ist vor jedem Start unbedingt erforderlich dass hier die Objekterkennung berpr ft und eventuell die Farb segmentierung korrigiert wird Das Fenster kann anschlie end wieder mit i geschlossen werden
150. tarken Richtungs nderung gro e Winkeldifferenz liegt der Auslenkungspunkt weit neben dem Ball die Rotationsgeschwindigkeit ist entsprechend hoch Ist die Winkeldifferenz nur mi nimal liegt der Auslenkungspunkt quasi im Ball und die Rotationsgeschwindigkeit ist sehr klein Dies entspricht dann lediglich kleineren Kurskorrekturen Das Prinzip des Algorithmus ist in Abb 3 16 erl utert Ziel Ziel A Abbildung 3 16 Dribbling Algorithmus Zum Zeitpunkt t 0 links ist die Winkeldifferenz y zwi schen Orientierung und Ziel gro Der Auslenkungspunkt A wandert weit neben den Ball Gleichzeitig dreht sich der Roboter mit hoher Geschwindigkeit um die eigene Achse in diesem Bsp im Uhrzeigersinn Bei t 1 Mitte ist die Win keldifferenz y geringer Der Auslenkungspunkt A liegt n her am Ball Die Rota tionsgeschwindigkeit verringert sich Die gefahrene Kurve wird weiter Schlie lich zum Zeitpunkt t 2 rechts hat der Roboter die neue Ausrichtung erreicht Die Winkeldifferenz y ist nahezu 0 Die Kurve ist vollendet und geht in eine nur noch mit leichten Korrekturen versehene Geradeaus Fahrt ber Der Vorteil im Vergleich zur Vektorfeldmethode zum Ausweichen von Hindernissen liegt darin dass die beiden hier verwendeten Routinen zur Obstacle Avoidance und gleichzeitigem Dribbeln es erlauben eine st ndige Vorw rtsbewegung beizubehalten so dass der Ball gehalten werden kann Mit Hilfe der zus tzlichen Methoden ist es nun also auch
151. tmodell weiter Ausgabe Ansteuerungsbefehl in Form von Befehlen an die einzelnen R der des Roboters Sen sorinformationen Odometriedaten 3 1 2 Programmablaufsteuerung Das benutzte Betriebssystem auf dem Steuerrechner ist ein Realtime Linux Ein Linux ohne Echtzeit unterst tzung garantiert bei der Abarbeitung von beispielsweise der Kommunikation an der seriellen Schnittstelle nur eine Genauigkeit von ca 10ms Ein Fahrbefehl der ber die serielle Schnittstelle geschickt wird w rde gesichert erst nach 10 ms ankommen Diese Zeitspanne ist f r die echtzeitnahe Kontrolle eines Roboters jedoch zu gro Demgegen ber biete das echtzeitnahe RTLinux eine Ge nauigkeit von ca 1 ms Mehr dazu auf Seite 56 im Abschnitt ber das Roboterkommunikationsmodul In unserer Architektur mit den eingesetzten Algorithmen hat es sich gezeigt dass die Programm schleife siehe Algorithmus 1 mit einer Geschwindigkeit von A 60ms laufen kann was einer funktionsf hig nicht funktionsf hig Dies entspricht der Standardeinstellung eines Linux Durch verschiedene Einstellungen kann die Genauigkeit erh ht werden jedoch besteht hier die gro e Gefahr von unkontrollierbaren Nebenwirkungen 3http www rtlinux org 24 3 1 BERBLICK KAPITEL 3 SOFTWARE Controller zentraler Kommunikations rechner Kommunikation Abbildung 3 2 Datenfluss in der Softwarearchitektur Frequenz von ungef hr 17 Hz entspricht F r
152. u den lokal abgeschlossenen Einheiten der Roboter au erhalb des Spielfelds zum Einsatz kommt Diese Zentrale b ndelt und verarbeitet alle Status und Positionsinformationen die sie kontinuierlich von allen Robotern erh lt Umgekehrt nimmt das Kommunikationsmodul Anweisungen von dem zentralen Kommunikationsrechner entgegen Solch eine Anweisung betrifft die Aufforde rung zum Rollenwechsel an die Roboter verbunden mit einem Verhaltenswechsel Das hei t falls einer der Angreifer ausf llt so wird entschieden welcher Roboter nun jeweils die offene Rolle einnehmen soll Beispielsweise muss Verteidiger 1 an dessen Stelle treten und Verteidiger 23 3 1 BERBLICK KAPITEL 3 SOFTWARE 2 bernimmt nun zus tzlich das Gebiet von Verteidiger 1 Die Komponente fungiert also als Schnittstelle zwischen Roboter und zentralem Kommunikati onsrechner Die Informationen zur selbstlokalisierten Position sowie dem Status des Roboters werden an den Kommunikationsrechner weitergereicht Die Aufforderung zum Rollenwechsel wird an die Strategie weitergeleitet Ausgabe Anweisung zum Rollenwechsel Selbstlokalisationsposition Statusinformation e Beschleunigungsmodul siehe Abschnitt 3 6 3 Eingabe Ansteuerungsbefehl der Strategie Im diesem Untermodul zum Robotermodul siehe n chster Punkt wird der Ansteuerungsbefehl aus der Strategie vor der eigentlichen bersetzung in der Roboterkomponente vorverarbeitet Physikalisches Wissens zum Roboter steht hie
153. uf dem Feld Somit ist es sinnvoll die Suche auf den Horizontbereich zu konzentrieren vgl Abbildung 3 5 Um die ersten Pixel zu finden die jeweils zu einem Tor oder einer Eckfahne geh ren wird im Bereich der Horizontlinie eine randomisierte Suche gestartet In jedem Durchlauf werden 100 Pixel in einem ringf rmigen Bereich darum durch die Funktion seedSearch siehe auch Algorithmus 2 auf verschiedene Bedingungen untersucht Ziel dieser Funktion ist die eindeutige Zuordnung m glichst vieler Pixel zu den Objekten Tor Gelb Tor Blau Pole Gelb Links Pole Gelb Rechts Pole Blau Links und Pole Blau Rechts Ist ein Pixel als blau erkannt so wird zuerst angenommen dass er zum blauen Tor geh re Auf diesem Pixel wird daraufhin die Funktion torBlauTest Pixel durchgef hrt Sie testet ob in Richtung des Eingabepixels auch die Farbe Gelb erkannt wurde Ist dies der Fall liegt offensichtlich eine Eckfahne vor Je nach Abfolge der Erkennung Blau Gelb Blau oder Gelb Blau Gelb wird der Pixel einem Eckfahnen Array zugeordnet Die Reihenfolge der Eckfahnen wird je nach Lage der Tore bestimmt Ball Der Ball kann sich in einem omnidirektionalen Bild lediglich zwischen dem u eren Rand des Kameraobjektivs und der maximalen Ausdehnung des Feldes im Bild aufhalten Durch die Suche in nur dieser Region verhindert man dass Objekte die sich au erhalb des Spielfelds befinden wie etwa Kleidungsst cke f lschlicherweise als Ball erkannt werden Dies ist jedoch
154. uktion dieses Systems stellte war die Be festigung des Spiegels ber der Kamera Die wohl stabilste L sung w re gewesen ihn mittels einiger von unten nach oben ber den Spiegel gef hrten Streben o zu befestigen allerdings w re dieses mit dem Nachteil verbunden dass die Streben dann mit im Bild gewesen w ren was unter Umst nden zu Problemen in der Bildverarbeitung h tte f hren k nnen Daher wurde diese L sung nicht weiter verfolgt stattdessen erwies sich eine L sung mittels einer durchsichtigen Plexiglasr hre als prakti kabel Die Kamera wurde zun chst senkrecht nach oben auf einer h lzernen Tr gerplatte montiert Anschlie end wurde ebenfalls auf dieser Tr gerplatte die Plexiglasr hre derart verschraubt dass sich die Kamera mittig in dieser R hre befindet und der Spiegel von oben in diese R hre eingesteckt Um den Spiegel derart einstecken zu k nnen wurde er ebenfalls an einer quadratischen Tr gerplat te montiert deren Seitenl nge dem Au endurchmesser der Plexiglasr hre entspricht Mittels an der Tr gerplatte montierter Metallwinkel wird diese letztlich oben auf der Plexiglasr hre festgeklemmt und mit einer Metallschelle gegen ein Verrutschen gesichert frames per second Bilder pro Sekunde 3vgl http www neovision cz prods panoramic h3g html 13 2 2 STEUERRECHNER KAPITEL 2 HARDWARE Abbildung 2 5 Montierte Spiegel Tr gerplatte Der Spiegel ist erkennbar am unteren Ende der schwarzen Verkle
155. unde neuere den IEEE802 11g Standard unterst tzende Ger te mit 54 MBit pro Sekunde sind f r unseren Zweck berdimensioniert Wesentliches Entscheidungskriterium f r diesen Adap ter ist die WiFi Kompatibilit t d h Ger te verschiedener Hersteller arbeiten ohne Komplikationen zusammen Zeitweise wurde der Einsatz einer WLAN Bridge getestet da sie eine gr ere Sendeleistung be sitzt Ein essentieller Unterschied in der Signalqualit t konnte von unserer Seite nicht festgestellt 90 B 2 ANSCHLUSSPLAN ANHANG B HARDWARE werden weiterhin ben tigt die Bridge eine zus tzliche Stromversorgung und ist wesentlich gr fer als das USB Pendant weshalb wir uns fiir die USB L sung entschieden haben Das eingesetzte Subnotebook der Marke JVC besitzt keine serielle Schnittstelle nach dem RS232 Standard Der Nachrichtenaustausch mit dem Motorcontroller erfolgt ber einen PCMCIA 2 Serial Adapter der an dem Laptop angeschlossen ist Zwischen Kontroller und Adapter verl uft eine 9 poliges serielles Kabel 1 1 Belegung Eine L sung durch einen USB 2 Serial Adapter wurde ver worfen da die ben tigte Echtzeitkommunikation nicht realisiert werden konnte Beachte Bei der seriellen Kommunikation ber den PCMCIA Adapter wird ein Stopbit verschluckt Beachte Der Adapter besitzt einen Stromsparmodus und wechselt in einen Ruhemodus sofern l nge re Zeit keine Daten ber ihn verschickt wurden Ist er in diesem Ruhezustand und erh lt Datenpaket
156. ung und 2Seit 2003 wird bei Spielen der Midsize League keine Bande mehr verwendet 3colour vision toolkit 1 4 BERSICHT KAPITEL 1 EINLEITUNG Roboterhardware F r jeden dieser Bereiche gab es einen Verantwortlichen der sowohl die Rolle des Ansprechpartners als auch des Projektmanager f r seine Gruppe bernahm Es wurde ein Konzept entworfen das thread orientiert ausgelegt war dieses wurde nach den German Open aufgegeben Wurde in der ersten Phase noch auf einem kleinen 2m 1m Feld getestet benutzten wir jetzt einen Simulator vgl Abschnitt 3 7 2 und ein Spielfeld das sich an den Regeln der Midsize League l orientierte um unsere Arbeit zu validieren Das Testfeld war gr n mit wei en Markern f r die Tor und Seitenauslinien Die oben genannten Marker wurden zur Verifikation einiger Tests eingesetzt Das Feld ma ca 8m in der L nge und ca 4m in der Breite An den Ecken befanden sich Im hohe Eckfahnen die auf der Seite des blauen Tors blau gelb blau gestrichen waren und gelb blau gelb auf Seiten des gelben Tors Ziel dieser Phase war es am Ende eine stabile Bildverarbeitung und einen insgesamt robusten Fu ballroboter zu haben mit dem wir an den German Open 2003 in Paderborn teilnehmen konnten In der letzten Phase wurden Optimierungen am Programm und der Roboter Hardware durch gef hrt um eine erfolgreiche Teilnahme bei der Weltmeisterschaft 2003 in Padua Italien zu garan tieren F r die WM wurde aufgrund der einfach
157. unteren Bereich des Fensters ein aufgezeichnetes Possible Object Array vor bzw zur ckzuspulen Dies kann verwendet werden um die Selbstlokalisation unabh ngig von Hardware zu testen A 2 4 Pathfinder Fenster Das Pathfinder Fenster bietet die M glichkeit die Richtungsvektoren der Potentialfeld Methode sicht bar zu machen und so die Fahrtplanung des Roboters kontrollieren bzw nachvollziehen zu k nnen Wie in Abbildung A 5 zu sehen ist setzt sich das Fenster aus vier Komponenten zusammen dem Info Fenster dem Tool Fenster dem Replay Fenster und der strategischen Spielfeldansicht Das Info Fenster enth lt verschiedene Daten die aktuell ausgelesen werden Hierzu geh rt die aktuelle Position des Roboters 0 0 Mittelpunkt des Spielfeldes die aktuelle Geschwindigkeit in Y die Fahrbefehle die an die Motoren gehen und schlie lich der Movemode Movemode bedeutet in wel cher strategischen Situation sich der Roboter aufgrund der vorliegenden Daten gerade befindet Der Roboter k nnte sich z B in der Situation kein Ballbesitz sehe Ball Ball im Aktionsbereich fahre zu Ball befinden Im Tool Fenster ist die Steuerung der Log Datei m glich ber Replay wird automatisch die tempor re Log Datei geladen Der Datenmitschnitt l uft solange im Hauptfenster Go aktiviert ist Clr Log leert die tempor re Log Datei wieder und ber Id Log kann eine externe Log Datei geladen werden die aber nicht gr er sein sollte als ca 15MB Die Checkbox v
158. ur der Master den Nachrichtenaustausch initiieren darf Antwortzeit des Controllers beim Setzen der Motorgeschwindigkeiten 90 T T T T Originalprotokoll 70 J 60 50 40 30 Antwortzeit in ms o 1 L fi fi 1 L fi 1 1 0 100 200 300 400 500 600 700 800 900 1000 Iterationen Abbildung 3 26 Zeit zum Setzen der Motorgeschwindigkeiten TMC In der Graphik erkennt man die Befehlsdauer in ms f r das Setzen aller drei Motorgeschwindigkeiten 1000 Iterationen Antwortmodus 2 Verglichen mit den ermittelten Werten f r den Controller K376SBC LPRSerCom stellt man eine recht lange Kommunikations dauer fest Begr nden l sst sich dies mit dem eingesetzten Antwortmodus da dieser mehr Daten vom Controller zum Host ber die Schnittstelle schickt Der Befehlssatz des TMC ist klar strukturiert in sog Getter und Setter die entsprechend Pa rameter auslesen oder setzen Auf einen Getter wird immer mit den aktuellen Controller Gr en geantwortet und auf Setter wenn er eindeutig identifiziert wurde mit OK Die einzige Ausnahme bildet der Befehl zum Setzen der Motorgeschwindigkeiten dessen Antwort konfiguriert werden kann Ein Befehl besteht aus einem Befehlswort welches ein oder zwei durch Leerzeichen getrennte Worte enthalten kann Das erste Wort davon beginnt mit einem G f r Getter und S f r Setter Nach dem Befehlswort folgt ein Leerzeichen und anschlie end Zahlenwerte Die Anzahl der Zahl
159. ustausch von ASCII Nachrichten die Unterst tzung des CAN Bus ist board seitig noch nicht implementiert 18 2 4 SCHUSSEINHEIT KAPITEL 2 HARDWARE Abbildung 2 10 Der Motorcontroller TMC200 Quelle http www ais fraunhofer de Mikrocontroller Infineon C164CI Spannungsversorgung 18 30V Leistungsaufnahme lt 1 5 Watt Kommunikation RS 232 CAN E A 3 Motoren amp Encoder 10 A D Wandler 8 Bit Aufl sung Tabelle 2 4 Auswahl technischer Daten zum TMC200 2 4 Schusseinheit Zu einem kompletten Fu ballspieler geh rt neben seiner Bewegungsfreiheit und der F higkeit Ent scheidungen zu treffen eine M glichkeit zur Ballbehandlung z B einem Dribbling oder einem Schuss Der Mensch setzt hierf r seine Beine bestehend aus Muskeln Sehnen und Knochen ein F r Roboter muss eine andere L sung angestrebt werden da die Technik auf diesem Gebiet noch nicht so weit fortgeschritten ist so gibt es z B Nanomuskeln deren Kraft f r unsere Zwecke aber bei weitem nicht ausreichend ist Der verfolgte Ansatz orientiert sich an der Natur des Menschen und bildet mit einer Konstruktion aus Aluminiumteilen ein St ck des Fu es nach siehe Abbildung 2 11 Ein fest mit dem Roboter verschraubtes Aluminiumelement bildet das Standbein Der bewegliche Teil der Schusseinheit ist ber ein Scharnier mit dem oberen Ende des Aluminiumelements verbunden vergleichbar mit dem H ftgelenk Das Fehlen eines Muskels kompe
160. vom Roboter ab einem bestimmen Pegel l st der Schuss aus Jedoch f llt hier eine Latenzzeit von ca 30 60 Millisekunden an so dass der Ball bereits weiter gerollt sein kann und der Schuss ins Leere geht Zur Zeit wird diese Methode verwendet e Fotowiderst nde Zwei Fotowiderst nde wurden leicht schr g nach oben schauend an der Ro boterfront montiert Befindet sich der Ball nah genug an der Front verdeckt sein Schatten das auf die Widerst nde fallende Licht Die daraus resultierende Widerstands nderung wird ber einen PIC ausgewertet und die Schusseinheit ausgel st Wie bei den Mikroschaltern gibt es eine Software Sperre die das irrt mliche Ausl sen vermeidet Diese Variante wurde als letzte getestet verwertbare Ergebnisse stehen aus nttp www c2net de 10 programmable IC 21 Kapitel 3 Software 3 1 berblick Dieses Kapitel beschreibt die Software die die Projektgruppe im Laufe der Projektarbeit entwickelt und eingesetzt hat Die Software die zum Betrieb der Roboter ben tigt und entwickelt wurde gliedert sich in zwei wesentliche Str nge Zum einen gibt es auf jedem Roboter das sogenannte Steuerpro gramm dieses wird in den folgenden Abschnitten 3 2 3 6 beschrieben Zum anderen existiert ein Kommunikationsprogramm das auf einem zentralen Kommunikationsrechner au erhalb des Spiel felds l uft Die dazugeh rige Beschreibung und Bedienungsanleitung findet sich im Anhang A 3 Be vor wir nun wie angek ndigt
161. vor connect all und start all bet tigt werden In dem Spielfeld unter Localisation werden grafisch die aktuellen von der Selbstlokalisation der Roboter errechneten Positionen der einzelnen Spieler angezeigt So hat der Anwender jederzeit die M glichkeit das Verhalten und die Weltsicht der Teamspieler zu erkennen und Fehlverhalten dementsprechend unter Verwendung der mitgeschriebenen Logfiles zu interpretieren Diese Logfiles k nnen mit dem Knopf Flush Logs auf der rechten Seite entleert werden da diese im Laufe der Zeit sehr gro werden k nnen A 3 4 Bedienung von TCPE Wie schon erl utert bietet TCPE dem Anwender die M glichkeit sowohl einzelne Roboter zu starten als auch das gesamte Team zu aktivieren Um ein Spiel zu beginnen muss der Anwender auf connect all dr cken um eine Verbindung mit allen Robotern auf dem Feld herzustellen Sollte es bei einem oder mehreren Robotern auf Anhieb nicht gelingen so muss man den Knopf connect all solange nochmal bet tigen bis die Verbindung zu allen Robotern besteht Erst dann kann man den Befehl start all oder auch stop all bet tigen womit erst jetzt das Spiel gestartet und die ARC aktiviert wird Sollte man nur einen einzelnen Roboter steuern wollen kann man dieses ber die einzelnen Controlpanel im oberen Bereich des Bildschirms machen Auch hier gelten die selben Bedienregeln wie f r das gesamte Team Zuerst muss man init player dr cken um den Spieler zu aktivieren und ihn dann per star
162. waren sie wendig und sehr schnell Das Spiel ging unent schieden 1 1 aus und sollte der einzige Punktverlust in der Vorrunde bleiben denn in den restlichen Spielen wurden die Gegner gr tenteils dominiert Besonders die Hardware zeigte sich auffallend stabil das Wechseln des Steuerboards zum TMC200 war die richtige Entscheidung gewesen Auch die nderungen an der Software best tigten sich al le als erfolgreich die dynamische Rollenverteilung funktionierte auf Anhieb ebenso wie die neuen Strategien u a in Ballf hrungs und Torschu situationen Im weiteren Verlauf der Vorrunde wurden weitere Gegner aus Paderborn besiegt denen man damals noch unterlegen war So wurden die Sparrows aus Ulm die in Paderborn noch das Aus be siegelten mit 6 1 geschlagen Diese hatten massive Hardwareprobleme so dass das Ergebnis deutlich ausfiel da die eigenen Roboter erneut durch Stabilit t gl nzten Auch das folgende Spiel gegen den Angstgegner das Team vom Fraunhofer AIS ging 2 0 aus Die ses Spiel zeigte besonders wie steil unsere Entwicklungskurve wirklich gewesen war da in Paderborn noch eine hohe Niederlage hingenommen werden musste Im abschlie enden Spiel gegen Argus wurde mit 5 0 erneut ein deutlicher Sieg eingefahren dies war aufgrund der Passivit t der Gegner allerdings keine allzu gro e berraschung Diese hatten offensichtlich gr ere Probleme mit der Lokalisation die sich bei den eigenen Robotern im ganzen Turnierverlauf als ein g
163. zzeitig aus dem Spiel herausgenommen werden oder standen f r den Rest des Spiels nicht mehr zur Verf gung Der Erfolg bei den German Open f hrte dazu dass das Team zur Weltmeisterschaft in Padua eingeladen wurde Es blieben zwei Monate Zeit die bei den German Open erkannten Probleme zu beheben und das Gesamtsystem zu optimieren Hierunter fiel die Suche nach einem alternativen Motorcontroller die Verbesserung der Distanz funktion die Verst rkung der Schusseinheit die Stabilisierung des Firewiresystems der Kamera die Weiterentwicklung der Selbstlokalisation und des Objekttrackings sowie die Einf hrung von neuen Strategie Ans tzen so genannte h here F higkeiten Die Umstellung der Systemarchitektur von Threads auf einen serialisierten Ablauf erbrachte eine deutliche Beschleunigung und Stabilisierung der Software Es konnten in k rzerer Zeit mehr Infor mationen ausgewertet werden so dass die Roboter insgesamt schneller und dynamischer wurden Als Konsequenz aus den Roboterausf llen wurde zus tzlich der dynamische Rollenwechsel eingef hrt so dass der Platz eines ausgefallenen Roboters von einem anderen bernommen werden konnte Der Torh ter der sich auf den German Open als stark verbesserungsf hig erwies wurde soweit optimiert dass viele Teams Interesse am Design bekundeten Er wurde mit einer neuen Selbstlokalisa tion ausgestattet bei der zus tzlich zur normalen Funktionalit t noch die Fu punkte der Torpfosten in die Be

Lernende, autonome Fussballroboter -Endbericht-

Contents

Download Pdf Manuals

Related Search

Related Contents